XSS (Cross Site Scripting) is a server vulnerability and the victim is the client's web browser. It consists on injecting a malicious script code (generally JavaScript) into the web browser. The injected script will be executed in the context of the vulnerable web server, Same Origin Policy (SOP) is, therefore, bypassed, and the script has access to client's confidential data (cookie,online banking informations...).
There are three types of this vulnerability: stored XSS, reflected XSS and DOM-based XSS
Reflected XSS occurs when a web server reflects back a malicious script, injected in the request, to the client's web browser.
The chronology of this attack is as fellow
1. The victim access the vulnerable web server (www.vulnerable.com) and provide its
credentials for authentication,
2. the web server authenticates the victim and sets a cookie for her session,
3. a hacker sends the victim an Email asking her to click on a forged URL with malicious
parameters,
4. the victim clicks on the link,
5. the server reflects back the malicious script which is executed by the browser,
Figure 1: Reflected XSS attack chronology
Example 1: The web server is vulnerable to reflected XSS
Suppose the following request is sent to a vulnerable web site
http://www.vulnerable.com/<script>alert("hello world")</script>
Of course the server will respond with a 404 page not found. The vulnerable web server will include the name of the requested webpage (a malicious script) in the error message (see bellow). The script will, then, be executed by the web browser.
The requested URL /<script>alert("hello world")</script> was not found on this server
The best way to defeat this is
- Sanitizing the special characters included in the server's error messages, this way the script will be interpreted as a text by the browser. This is the default behavior of Apache web server. As we can see bellow, Apache replaces < with < , > with > and " with "
Figure 2: Apache 404 error message source code
OR- Do not include requested page's name in the server's error messages.This is the default behavior of Microsoft IIS
Figure 3: IIS 404 error message
Also, it is worth to note that, by default, Internet Explorer replaces received error messages with it own, this is called friendly error messages
Figure 4: IE friendly error message option
This example is taken from xssed.com an online archive of XSS vulnerable websites . The script is embedded in a search string.
http://www.industrie.gov.tn/marquage-ce/www/fr/recherche.asp?cles=<BODY
ONLOAD=alert("By-Hedi-Mlika")>
As we can see,from the source code, the website reflects back the search string with no special characters sanitization.
The script,which fires an alert box is executed!
How to protect
The protection mechanisms can be implemented on the server side and/or the client side.
On the server side the reflected strings should always be sanitized.
On the client side many web browsers implements XSS filter which is a built-in feature in Internet Explorer and Google Chrome (called XSSAuditor), while it is provided as an extension (NoScript
add-on ) in Firefox.
Bellow is a brief comparison between those three filters. more details can be found in this research
paper.
- NoScript uses regular expressions to identify the presence of JavaScript code in HTTP request parameters and sanitizes them before submitting the request.
- IE XSS filter works differently, it monitors both the request and response, it sanitize a script code detected in the response if it matches the one detected in the request. It uses regular expressions for detecting scripts
IE filter is implemented before the HTML parser. This design permits only a syntax analysis of the response not its semantic, this lowers the precision of the filter
Figure 5: IE8 XSS filter architecture
- Chrome XSSAuditor: uses a same approach as IE filter. If a matching script is detected, its execution is skipped. XSSAuditor is implemented between HTML parser and JavaScript engine.This is a more efficient design as the filter can examine the semantics of the response as interpreted by the parser
Figure 6: Chrome XSSAuditor Architecture
No comments:
Post a Comment