SANS Digital Forensics and Incident Response Blog

Leaving the Backdoor Open: Risk of Remotely Hosted Web Scripts


Many websites leverage externally hosted scripts to add a broad range of functionality, from user interaction tracking to reactive design. However, what you may not know is that by using them you are effectively handing over full control of your content to the other party, and could be putting your users at risk of having their interactions misdirected or intercepted.

How so? Well, when you reference a script file, either locally or remotely, you are effectively adding that code into your page when it's loaded by the user. JavaScript, as an example, is a very powerful language that allows you to dynamically add or modify content on the fly. If the location and content of the script is controlled by someone else, the other party is able to modify the code as they see fit, whenever they wish. Let's hope they never get compromised or go rogue!


How many of you would click Yes if this warning came with a script? Not many I suspect!

Demonstration of concept

I've put together a small demo page on my website to show the issue ( It's pretty straight forward, I've referenced a script hosted on an external site - in this case my attempt to include some old style blink tags on my page.


However, rather than the intended script, the JavaScript on the other end was replaced with the following code, which redirects the user away from the intended site to, potentially, something malicious such as a phishing page.


It's that easy. This concept is pretty basic, but what if the script was setup to conduct keylogging, or manipulate input data before it's submitted? Uh-oh!

Well that doesn't sound good, any suggestions?

Firstly, use the debugging functionality of your favourite browser to identify whether your website leverages any externally hosted scripts. I've used Google Chrome against my website and can see that Google Analytics fits into that category.


Now consider whether you can bring the scripts in-house and store them on your server. If you can't and must use externally hosted scripts, it may be worth keeping an eye on what is being served up. Perhaps even schedule a web content malware scan against the script files on a regular basis. Additionally, make sure the site hosting the script is still live and the domain hasn't expired, making it available for sale!

Happy holidays!

-Adam (Twitter: @CyberKramer)


Posted December 19, 2017 at 1:13 AM | Permalink | Reply


Doesn't subresource integrity mitigate this issue? (Assuming browser support)

Posted December 22, 2017 at 4:52 PM | Permalink | Reply

Adam Kramer

I think SRI is a good start, but I don't imagine that vendors keep their code static for long, which may put most people off implementing it as any minor change could break your website by denying access to the script ''" it would be good if there was a web script certification method (a bit like digital signatures for .exe files), so the vendors can update their websites at their discretion, and as long as they keep their keys safe, our browsers can certify and we can verify the scripts authenticity.