Script Attacks Are Growing (And Fast)
Open source front-end libraries, such as like jQuery, Modernizr or Facebook’s popular React framework, make it easier to build and maintain websites by shifting the burden for key functionalities out of the site code and into the library. Libraries are used to supply fonts, emoticons and graphics capabilities, among other uses.
Aside from harvesting sensitive user data, these scripts are also used to insert malware into the browser or desktops of unsuspecting users. The malware might hijack a browser for cryptocurrency mining or, ironically, turn the browser into a node on a global bot network used to break into accounts.
Some common ways malicious script attack types work include:
- Directly hacking into third-party services and manipulating the code that is served
- Creating third-party services that resemble other third-party services and tricking web and application developers into using them
- Inserting code disguised as patches into open source libraries, with the hope the community won’t notice
- Creating modules and extensions to common frameworks, like Magento and WordPress, or contributing infected code to such open source server-side modules
- Exploiting known holes in third-party libraries
Attacks Can Be Hard To Spot
Another smart attack was a malicious script that added a field for a U.S. social security number to the standard information request form for an address, name and email on a travel website. Due to their subtlety and the fact that the malicious code runs outside of the site’s perimeter (directly loaded to the user’s browser from the third-party service), third-party script attacks can go undetected for weeks or months.
Because many companies leverage pieces of the same code to power both websites and hybrid mobile apps, the attack often works on both vectors. This was the case with the British Airways attack; the company’s web application and hybrid mobile app shared code for core functionalities.
How To Fight Back
There are a number of steps site reliability engineers (SREs) and security teams must undertake to fight back against such script attacks. For starters, SREs should keep a tight inventory of every third-party script running on every page on a site and regularly check to make sure there have not been new scripts installed or illegitimate changes made to existing scripts.
For all open source components, it's important to monitor bug reports and security updates. Most open source libraries have specific security processes that generally include a subscription to email updates when security issues arise.
Restrict or limit the use of third-party vendors on sensitive pages, like payment or login, where an attack may be extremely painful. Restricting third-party scripts can be done also by using a Content Security Policy (CSP) or loading third-party scripts in separate iframes (inline frames) to limit their access to the rest of the page. However, these methods aren’t easy to implement and may break the functionality of the scripts or page, so they should be carefully administered.
Monitoring services that track the website and look for signs of anomalous behavior are pretty common, though we’ve seen advanced attackers that detect these services and will serve them a clean script while serving targeted users an infected one.