Real-time third-party code injection

The risk associated with inclusion of externally-hosted code on websites and how to mitigate it

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

🔒 Related Stories: Application Security | Penetration Testing

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I’ve noticed a trend both on penetration tests and while browsing web sites in general that I find a bit concerning. Many web sites are including code directly from third parties over the Internet in their webpages. Certain services require you to include code that reaches out and connects to a third-party service. For example, if you integrate your site with Google Analytics to track website visitor statistics, you will most likely integrate a snippet of JavaScript from Google to do that. When your webpage loads, it will reach out and send some data over to Google.

It seems that in this age of cloud and APIs (Application Programming Interfaces), everything is connecting to everything. My question to you is this: How do you know that code you are downloading and including dynamically in your website is secure when you are downloading whatever is there at any given moment? How do you know that the third-party code is the same code you tested when it went through your QA process? And you did test it, scan it, and review it for security vulnerabilities before you put it into production. Right?

Although some third-party integrations are useful and help improve website functionality, if companies are not careful, they may end up serving malware on their websites. Attackers leveraged third-party code in some of the Magecart data breaches. JavaScript loaded into a website stole credit card and other sensitive data. Sites that incorporate third-party advertising directly into their websites may be open to serving up malware contained in ads. That is especially true when companies that allow advertisers to upload content or point to arbitrary URLs.

How do you know what third-party code is included from the Internet when your webpage loads? There are multiple things you’ll need to inspect. The first thing you can do is open a web browser and visit your web page. Open the developer tools for your browser and inspect all the URLs that you don’t host yourself that the web page is linking to and loading. In Google Chrome, click on the View menu, then Developer, then Developer Tools. In this case, I’m taking a look at the CNN website.

Next, click on Sources. In the list below, some of the items are single files that are part of the home page hosted on cnn.com. The websites here that don’t have cnn.com in the URL are likely content included from a third-party service. That means the company doesn’t own or control all the content served on its website, and that third-party can change it at any time.

But wait. There’s more! Sometimes pages have dynamic content that reaches out to third-party domain names that are not present in the code picked up by browser web developer tools. You can capture these connections if you run a sniffer like Wireshark on your system while connecting to the web page. Alternatively, use a host-based firewall like Little Snitch (for those using a Mac) that alerts you each time new connections occur. Take a look at how many different domains are loaded when I opened CNN.com based on my host-based firewall alerts.

Why is the page loading so many different domain names? I don’t know. I could spend a lot of time investigating each one, but many web pages you are loading are doing the same thing. Sites hosting advertising are usually the worst offenders (if you consider this tactic an offense). Try this on any of the news sites you frequent. As I discuss in my cybersecurity book, each new connection you make to and from your systems is another point of attack.

And yet, there is still more. If you reload the page, different domains will pop up. Additionally, sometimes web pages have domains that load after a delay, so you have to wait for a while to see everything the page loads. Each piece of third-party code loaded into a website is a source of compromise for the website or web visitors, if attackers can inject their code into that component. That’s a lot of attack vectors to manage.

Another consideration is that when penetration testing websites, third-party systems are usually out of scope. That means the penetration tester can’t actively probe and test those third-party systems for vulnerabilities and test to see if they can exploit them. If you include code hosted on third-party systems, your site may still be vulnerable even if the penetration tester found no other issues.

Sometimes integration with third parties requires a real-time API to connect two systems. However, I find in many cases that organizations can easily host code instead of downloading it. That is especially true of JavaScript code. It also applies to images and static content that may leak content or hide malicious code. For example, I frequently see a third-party component called bootstrap.js. You can run this code in one of two ways. One way is to include the link to the bootstrap.js file hosted by the third-party developer. The other way is to download the code and host it in your organization’s code repository. The latter is preferable. That way, you can analyze it with static code analysis tools and validate that the version you tested is the version deployed to production.

One benefit of pulling the code from the third-party website is that you will automatically get security updates when the vendor releases new code. That option comes at the risk of the vendor releasing a security vulnerability either through a mistake or an attack by a malicious actor. A CORS misconfiguration or other vulnerability may expose credentials to a third-party site. If the external provider is facing an outage, your site may experience issues or downtime. For all these reasons, it is often better to host the code on your servers and validate its integrity with a checksum or other file integrity mechanism to make sure no one has tampered with it.

If you cannot host the code on your website, you should still analyze it with dynamic and static testing tools if the third-party allows. You should also monitor it to know if it changes. You can also use a proxy that retrieves the code from the third party, inspects it, and then serves it to your customers. Of course, your proxy must be very secure. You may not want to do this if your site is submitting if sensitive data such as credit cards sent to an e-commerce credit card processor.

Hopefully, now you will take a look at your website to investigate how many resources you are pulling dynamically off the Internet, versus hosting them on your website. Consider if it might be better in some cases to download the code, font-files, and images served up dynamically and host them on your domain. That may not work in all cases, but where you can, it will help reduce the attack vector and let you monitor and maintain code integrity.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2020

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab