Most Common Web Application Security Vulnerabilities #3: Cross Site Scripting (XSS)
Types of XSS attacks
Cross-Site Scripting attacks are a sort of injection, where malicious scripts are injected into a trusted web application. At the point When an attacker sends a malicious browser side script to an end user by utilizing a web application, a XSS attack occurs. These types of attacks are very common, and it permits the occasion to exploit the flaw for an attacker on a web application which uses inputs from a user inside the output it generates without validating or encoding it. Subsequently, by using those flaws an attacker can dispatch a XSS attack to send a malicious script to an unsuspecting user & the content will be executed in the end user’s browser as it has no way to know that the script is malicious and should not be trusted.
Stored XSS (Persistent) — A JavaScript is embedded into a request which is then stored by the application & When the web page is loaded, it will be altered to include the malicious script and executed under the context of the user. This malicious information perseveres and keeps on to executing each time a user loads the page.
Reflected XSS (Non persistent) — Once the Script is embedded into the request, at that point it is reflected by the server in the response and executed by the browser in the immediate next step. In the event that an attacker tricks a user to clicking on a malicious link, the page sent in the response will be altered to include infused JavaScript that will execute under the context of the user.
DOM Based XSS — In here the web application does not directly serve up the malicious script to the targeted browser. In a DOM-based XSS attack, the application has vulnerable client-side scripts which deliver the malicious script to the target’s browser, Similar to a reflected attack. On the other hand, a DOM-based attack does not store the malicious script on the vulnerable server itself.
The Root Cause for XSS attacks
- Input coming into web applications is not validated
- Output to the browser is not HTML encoded
Defects related to XSS are hard to recognize as well as to eliminate from a web application. One fundamental explanation behind that is, there are wide range of HTML tags which can be utilized to transmit a malicious JavaScript. So, performing a security review of the code and looking for all the spots where input from a HTTP request might advance into the HTML output is the most ideal approach to identify this sort of flaws. There are tools like Nessus, Nikto and some others which can help to scan the web application to recognize these XSS flaws. but they can only scratch the surface. In the event that one piece of a web application is vulnerable, there is a high probability that there are different issues as well.
XSS attacks, After-effects
If it is possible for an attacker to exploit the third party and infuse malicious code into the script, they can launch an attack towards the users of the application. In that case, an outside malicious script will be executed with the same privileges as a local script (accessing application data and performing actions available to the current user). Further the effect is particularly huge if the vulnerability is externally available or prior to the authentication, where it is more effectively discoverable and exploited by attackers.
- Hijack an account.
- Access browser history and clipboard contents.
- Spread web worms.
- Scan and exploit intranet appliances and applications.
- Control the browser remotely.
Protecting against XSS Attacks
By giving out encoded user information into HTML entities by the application, can ensure that the stored user input is not executing by the browser. This ensures that the browser will only display the user input and not interpret it as a command. At the very least, it is a best practice to output encode the following characters:
- “<” = “<”
- “&” = “&”
- “>” = “>”
- “/” = “/”
- double quote = “"”
- single quote = “'”
Furthermore, encoding is also context specific. For instance, inserting into CSS requires CSS escaping, JavaScript requires JavaScript escaping and URL requires URL escaping. All things considered it is prudent to utilize a standard library to encode the output. There are libraries available for most of the platforms, including the OWASP Enterprise Security API (ESAPI). Moreover, when conceivable using server-side dynamic pages rather than client-side document rewriting or redirection, or other sensitive actions, using client-side data can reduce the Dom-based XSS flaws.
Conclusion
A successful XSS attack leads to an attacker controlling the victim’s browser or account on the vulnerable web application where it results in any action that can be performed by the user. Mostly XSS is used for session hijacking where the attacker using JavaScript to trick the victim to transmit session cookies. through that the attacker can perform “session riding” and complete the attack by taking over the application.
Consider a situation wherein a JavaScript is injected, and it gets stored. The administrator then loads that into a web browser and if the application is vulnerable against XSS attack the attacker will have the admin session tokens which is why XSS can be very dangerous.
Some Resources :
The “X-XSS-Protection” Header : This instructs the browser to activate the inbuilt XSS auditor to identify and block any XSS attempts against the user.
OWASP Encoding Project : A library written in Java by OWASP.
The XSS Protection Cheat Sheet by OWASP : A checklist to be followed during development with variety of examples.
Content Security Policy : It instructs the browser about “safe” sources apart from which no script should be executed from any origin.
