Nearly everyone has at some point had their web browser pop up a message that says something like “Your PC is Infected . . . Click Here to remove the virus”. That message is likely the result of a cross-site scripting (XSS) attack, and clicking on the link will connect to a site that installs malware, or encourages the victim to pay for fraudulent virus removal services.
The above example is just one form of XSS attack. In reality, there are numerous types of XSS attacks and cybercriminals frequently use them to commit their crimes. They pose a major challenge for malware detection systems.
Fortunately, new technologies can identify XSS attacks and the infections they cause.
What is a Cross Site Scripting Attack?
Cross-Site Scripting (XSS) attacks are a type of injection attack where cybercriminals deliver malicious script or code to a client browser, often via a vulnerable web application. In this type of attack, cybercriminals trick users’ browser into executing malicious code. A classic example is causing a browser to display a popup with a link to a website that installs malware. In other cases, an XSS attack will cause a victim’s browser to send confidential data or cookies containing login credentials to the attacker.
An XSS attack can happen when a web application allows users to input information but fails to validate that input. This vulnerability allows cybercriminals to enter malicious code such as JavaScript into a form or search box, and the victim’s browser will execute that code.
For example, imagine a scenario where a web application allows visitors to enter a comment. Unless the application filters it out, an attacker can enter a comment that includes malicious JavaScript. Any browser that subsequently loads that page will read the comment and execute the embedded JavaScript. Because browsers don’t normally display JavaScript, it will be invisible to users and administrators that are viewing the page. The code will execute without their knowledge.
Three Types of XSS Attacks
There are three types of XSS attacks, and it’s important for anyone responsible or engaged in cybersecurity to have at least a high-level knowledge of how each of them works.
Persistent (or stored) XSS Attack
This occurs when a website actually stores the payload, as in the example provided earlier where an attacker enters a comment that contains a malicious script and it resides on the website. Any browser that loads the page containing the comment will execute the script and risk infection.
Reflected (Non-Persistent) XSS Attack
In this type of XSS attack, the victim is typically tricked into opening a link that has a malicious but obscured script appended to the end of the URL. When the victim’s browser executes the link, the target website echoes or reflects the script back to the user’s browser, typically in the form of an error message, response field, or search result. When the victim’s browser receives this reflected script, it executes it on the victim’s device.
For example, an attacker crafts a URL that connects to a website that doesn’t remove JavaScript from a user’s input. The attacker includes instructions at the end of the URL that requests the target website to search for an unintelligible term. Embedded in those instructions is an obscured script that directs the user’s browser to grab their own session cookie and transmit it to the attacker. When an unsuspecting victim clicks this malicious link, the target website will attempt to search for the unintelligible term. Unable to find it, the website returns the request, including the malicious script, to the user’s browser with a message like “Unable to find unintelligible term.” When the victim’s browser receives this data back from the server, in the process of displaying the message it executes the embedded script that steals the user’s session cookie.
Document Object Module (DOM)-Based XSS Attack
As web applications gain in sophistication, web designers have shifted more and more of the processing to the user’s browser. When a user connects to a website, it’s common for their browser to generate some of the code that it will execute.
In a DOM-based XSS attack, cybercriminals pollute a browser’s data or environment in such a way that the code it generates is malicious. A browser’s data set or environment is called a DOM (Document Object Module), and contains, among other things, data that has been input by the user (i.e. name, address or other information). The browser uses the data within the DOM to generate the code it will execute. In a DOM-based XSS attack, malicious scripts are injected into the DOM, resulting in the creation and execution of malicious code.
Attackers corrupt the DOM by crafting a malicious URL. The attacker appends a type of script to the end of the URL that is not sent to the server but processed by the browser itself. When a user clicks on the malicious URL, the browser loads the script into the DOM where it becomes part of the code the browser generates.
A key differentiator between DOM-based and other XSS attacks is that in a DOM-based attack the malicious code never touches, nor is transmitted to or from the webserver. This has a number of ramifications, one being that a DOM-based XSS attack cannot be stopped by server-side controls or filters.
Why XSS Attacks Are So Dangerous
XSS attacks have been around for many years, but they are still a major concern, so much so that OWASP, a well-known index of web application vulnerabilities, lists XSS attacks as one of the Top 10 Most Critical Web Application Security Risks. XSS attacks accounted for nearly half of all web-based exploits last year according to WhiteHat Security’s 2016 Web Applications Security Statistics Report.
Unfortunately, XSS attacks are not going away anytime soon because they are easy for cybercriminals to design and execute, and because so many websites are vulnerable to this type of attack. Research from Acunetix found that 33% of all websites have XSS vulnerabilities and are subject to attack. Snyk, a provider of vulnerability scanning products, believes the number is even higher, reporting that roughly 50% of the world’s websites have XSS vulnerabilities and are subject to attack.
XSS attacks are relatively easy for an attacker to pull off—and they are powerful weapons. JavaScript, executing within a modern browser has access to numerous objects and functions that cybercriminals can leverage to steal information and wreak havoc. For instance:
- JavaScript can use HTML5 APIs to access the victim’s webcam, microphone, geolocation, and specific files from the victim’s device. User opt-in is required for some of these functions, but by combining XSS attacks with social engineering, cybercriminals can often fool users into agreeing.
- JavaScript has access to cookies that store session tokens. Attackers that steal a user’s session token can impersonate that user.
- Furthermore, JavaScript can send unlimited types of HTTP requests to virtually any destination. This provides attackers with a nearly endless arsenal of malicious tools.
XSS attacks create the ideal environment for attackers to escalate an initial foothold to a more extensive and damaging intrusion. With social engineering and the browser capabilities listed above, cybercriminals can use an XSS attack to execute sophisticated operations including cookie theft, keylogging, user impersonation, session hijacking, data theft, and many other malicious activities.
Most Malware Detection Systems Struggle to Spot XSS Attacks
With the proper resources, it’s not particularly difficult to determine if a web application is vulnerable to XSS attacks. There are a number of scanners and penetration tests available that will assess web code for XSS vulnerabilities, including how well the code filters user input for JavaScript.
While determining if a web application is susceptible to an XSS attack is relatively straightforward, detecting when an XSS attack is currently occurring is a great deal more difficult.
Most malware detection systems rely on the process of scanning files for malware attack signatures. In those cases where the malicious code resides on the webserver, as in persistent XSS attacks, signature-based products can evaluate a webpage and detect known attacks. But most systems will not detect new malware because it won’t have an attack signature. Reflective and DOM-based XSS attacks are a greater challenge because the malware is never stored on the webserver. There is nothing on the server for signature-based products to analyze, therefore they are ineffective against reflective and DOM-based XSS attacks.
Web application firewalls and intrusion detection systems (IDS) offer another layer of protection because they monitor the communication between a web application and the user’s browser. This enables them to detect user input that contains extraneous data like JavaScript. The firewall or IDS can then block the malicious request so it never reaches the webserver. Although a high number of false positives are likely, this capability helps detect both persistent and reflective XSS attacks in those cases where attack signatures exist. However, since DOM-based XSS attacks operate wholly within the browser and never transmit their malicious payload, neither IDS nor web application firewalls can detect them.
Effective Detection of XSS Attacks
To minimize XSS attacks, organizations need to evaluate their web application code and remove XSS vulnerabilities. But they must also implement security tools that will detect XSS attacks. That requires advanced products that go beyond analyzing files for attack signatures to monitoring network traffic for code injection.
To effectively detect all three types of XSS attacks (persistent, reflective, and DOM-based), organizations need a comprehensive solution that is capable of:
- Evaluating any object that a browser may open, or that may launch a browser. This includes email messages, attachments, downloads, webpages, and any other document that contains HTML links. See Lastline’s blog Top 10 Malicious Email Threats for more information.
- Rapid static analysis of each object, evaluating them for malicious capabilities and links, known attack signatures, structural deviations, and other anomalies. For more information about malicious links, see Lastline’s blog Protection from Malicious Links.
- Performing full behavioral analysis by completely executing each object and testing it for evasion techniques and malicious actions. See Machine Learning is Transforming Malware Detection to learn more.
- Network monitoring for activity created by malware operating on a network, such as code injection, malware communicating with command and control servers, and other anomalous activity.
Final Takeaways
XSS attacks are a constant problem that organizations must address, both at the vulnerability level and at an actual attack level. While the security industry has given a lot of attention to finding and correcting XSS vulnerabilities in web code, they haven’t done nearly as much to detect an actual XSS attack.
This lack of effective solutions is due in part, to the difficulty in detecting the various types of XSS attacks and infections. Known persistent XSS infections are relatively easy to detect. But unknown infections and non-persistent infections (both reflective and DOM-based) are difficult or even impossible for most malware detection systems to identify.
Fortunately, tools have emerged during the last few years that have the necessary capabilities and therefore can detect all three types of XSS attacks.
The post Malware Detection—Discovering Cross-Site Scripting Attacks appeared first on Lastline.
Article Link: https://www.lastline.com/blog/cross-site-scripting-attack/