Introduction:
- Cross-site scripting, better known as XSS is an attack in which an attacker injects malicious executable scripts into the code of a trusted source. Typically, this code can run without the need of server-side rendering.
- With tons of efforts spent on its mitigation, Cross-site scripting (XSS) remains one of the most prevalent security threats on the internet.
- Decades of research on the topic has demonstrated that code inspection and testing alone does not eliminate XSS vulnerabilities in complex web applications with a high degree of success.
Cross-Site Scripting
What's the big deal?:
The question most are probably asking right now. Why does it matter? well here are just a few reasons to care:
Cookies
Attackers can read private data specific to the site you are on such as cookies and other local data
Ongoing Operations
As the attackers have access to the site now, they can choose to create further damage by keeping up the oppression! Loading in more JavaScript executable code can further weaken the sites code and in turn they can launch higher scale attacks.
Unlimited Access
With unlimited access to the site, the attackers can change how a user interacts with the site!
Known XSS Attacks:
Cross-site scripting attacks are a type of injection with malicious scripts placed into trusted sites. For this to occur generally, the attacker will send browser side script code to a different end user which in turn the unsuspecting user's browser has no way to know if this is a trusted source or not and executes it anyways. With this in mind, there have been enough attacks done to create different categories (although not all can be classified since there is always an ongoing effort to combat these attacks and can change overtime) these are just a few of the known types:
XSS attacks can generally be categorized into two categories: reflected and stored
Reflected:
Reflected attacks are attacks where injected script is reflected off the web server. These attacks are delivered to a victim through routes such as emails or interaction with another malicious site:
Stored:
Stored attacks are those that have the injected script permanently stored on the targets servers such as in databases, forums, comments, ect.
There is one more lesser known attack, known as DOM-based XSS
Document Object Model (DOM) based attacks are those that enables attackers to inject malicious payload into a webpage that in turn manipulates the client sides browser enviroment.
What is DOM-based XSS?
So what do we mean by this? Well these attacks can change the HTML source code without the need to communicate with the server. This type of attack is orchestrated on the client-side after the initial loading of the page. Since the malicious input is stored within the client's browser environment the attack cannot be detected using traditional methods of analysis.
How can we prevent this type of attack?
Just like the attacks before, the goal is to get information on you. DOM-based vulnerabilities allow adversaries to steal/modify legitimate users' data such as cookies or session tokens to access your sensitive data.
Some ways to help prevent these attacks are as follows:
- JavaScript Frameworks
- Avoiding the use of URI fragments
- Use of a content security policy
- Automated DOM-based XSS vulnerability scanner
- Use of safe APIs
The importance of preventing DOM-based attacks
While these attacks are solely on the client-side of websites, the vulnerability starts on the server-side. Therefore, it is important for developers to take action to try to prevent these attacks as this could be sensitive customer data leaked to the attacker which in turn could make your company lose reputation and trust.
The Continuous Fight:
Googles Approach to XSS Attacks:
A few studies on the matter have taken place over the last few years, one study we wanted to highlight is that of Google's API hardening technique.
Brief Overview:
Google is a well known tech company that is widely known for there vast search engine. There are many other technologies and tasks that happen every single day in the office and one problem Google tried to tackle was that of XSS attacks. Knowing that people around the world rely on their product they had to find a way to harden their cybersecurity force and came up with the idea of creating what they call, API Harding.
Initial Preparation:
Before pouring tons of money into the development of this new technique, Google had to take the time to research past attacks and figure out what made them so vulnerable in the first place. Over two years of time and research was taken to get enough data on the topic prior to development. Google brought to the table in a conference meeting their findings and the new technique that would be later rolled out to all of their various development departments. Starting with Figure 1 Google began breaking down the need for this new technique and tried to bring awareness to this ever growing threat.
The Design:
With extensive research done on the topic, Google found that many solutions to the problem were solved at the later phases of the software development life cycle. The problem with this approach is when an application gets so big its hard to stay on top of vulnerabilities as the functionality and complexity grows. Another key problem these applications face are deadlines on specific aspects of the developmental cycle. A developer will have to split their time on each part of the bigger project making it hard for them to spend countless time testing for bugs or security weakness. Only after an attack has been detected will a developer have to go back to try to find this crack in the code. In response to this trend, Googles new approach confronts weakness at the very beginning stages of web development starting with the compiler.
API Harding involves three key points in creating Safe APIs to help with mitigating potential XSS threats: Safe Types, Safe Builders, and Safe Sinks.
Wide Adoption:
The last step in the development phase was to test out the new software detection on a larger scale. Over two years, Google began rolling out this program to all departments making sure to exempt legacy violations so that existing code could still compile and run while developers took to this new security enforcement. They have developed accompanying measures to help with this mitigation to ensure safe practices and answer any questions they may have. In addition, Google created a "Bug Hunt" Program that actively takes outside sources to comb through code to point out any missed security weaknesses to ensure a safer environment. In most cases the compiler captures API hardening violations and will try to automatically construct a fix and present it to the developer with the error message. Developer feedback is also just as important to help improve the user experience with this new policy and allows for them to bring up any concerns or problems faced when implemented in their projects.
The Results:
With With mandatory compile-time checks now in place, Google launched infrastructure and data pipelines to monitor the company-wide adoption progress and the results showed significant improvements in the way developers handled XSS attacks prior to deployment.
Below are a few results on the matter:
Conclusion:
With the new technique created and implemented Google has taken a new approach on mitigating XSS attacks by creating API Hardening. Using this new software, developers can now have safe alternatives generated for unsafe sinks. This also takes the approach of catching vulnerabilities at the early stages of the development cycle. Google has taken the liberty to make most of this program open sourced so that others can implement this into their own projects and has brought extensive research to the public for others to review.
If you are interested in more on this topic you can read the rest here:
API Harding pdfThis is just one approach to tackling XSS attacks. There are various other ways to solve this problem seeing how there are multiple ways for an attacker to infiltrate a program. With research and development constantly being done we can even the odds!
The Challenge
For this challenge you are tasked with identifying key words discussed in this module. Why not test your knowledge
Mark module as complete:
Great Job!
Why not check out some other modules?
