#### Cross-Site Scripting Attacks #### The XSS attacks allow an attacker to inject client-size script into the web-pages viewed by users. See /var/www/html & /var/www/cgi-bin for some examples. We distinguish between two types of XSS attacks: 1) Non-persistent: The attack is immediately executed on the client side. For example, a user might click on a malicious URL sent to him via an email by the attacker. 2) Persistent: The attack vector is stored on the remote server and is executed by all users who load the client-size code (see addstring.html for an example) To better understand how the attack works, let's take a look at xss1.html & xss1.pl. ## xss1.html & xss1.pl ## -- param() routine is used to set a CGI parameter to a single or a multi-valued value. -- ss is the name of the field from which we are reading the input -- print header this tells the browser what type of document to expect, and gives other optional information, such as the language, expiration date, and whether to cache the document. -- The <<"EOT"; syntax is a nice way of printing formatted text that spans multiple lines. It says "print everything until you get to EOT. -- Note that the code prints \$output in the tags, which prevent text from begin interpreted as html. The problem, once again, comes from the fact that user's input is not filtered or sanitized. In particular, if the input first closes tag, then everything that follows will be interpreted as code! For example, steals the user's cookie and sends it as an argument to attacker's script xssStealSecretl.pl. (??) What is a cookie? (AA) "A small piece of data sent from a website and stored in a user's web browser while the user is browsing that website. Every time the user loads the website, the browser sends the cookie back to the server to notify the website of the user's previous activity. Cookies were designed to be a reliable mechanism for websites to remember stateful information (such as items in a shopping cart) or to record the user's browsing activity (including clicking particular buttons, logging in, or recording which pages were visited by the user as far back as months or years ago). Can you see why an attacker might want to steal user's cookie? An attacker can craft a malicious URL, upon clicking which the client-size attack is executed resulting in stealing user's cookie for that particular website. This is known as a non-persistent XSS attack. ## xssAddString.html & xssAddString.pl ## Often user's input is stored on the remote server. In this example, user's string gets added into a text file. All system's users can show strings in the file. However, an attacker can inject code in the test file, such that when the users show strings this client-code written by the attacker in the text file will be executed. Again, the code can redirect users to a malicious website, steal their cookies and so on. This is known as a persistent XSS attack. ### Prevention ### (from https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet) ## RULE #0 - Never Insert Untrusted Data Except in Allowed Locations ## <script>...NEVER PUT UNTRUSTED DATA HERE...</script> directly in a script  inside an HTML comment <div ...NEVER PUT UNTRUSTED DATA HERE...=test /> in an attribute name <NEVER PUT UNTRUSTED DATA HERE... href="/test" /> in a tag name <style>...NEVER PUT UNTRUSTED DATA HERE...</style> directly in CSS ## RULE #1 - HTML Escape Before Inserting Untrusted Data into HTML Element Content ## <body>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</body> div>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</div> any other normal HTML elements ## RULE #2 - Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes ## <div attr=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>content</div> inside UNquoted attribute <div attr='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'>content</div> inside single quoted attribute <div attr="...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">content</div> inside double quoted attribute ## RULE #3 - JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values ## <script>alert('...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...')</script> inside a quoted string <script>x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'</script> one side of a quoted expression <div onmouseover="x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'"</div> inside quoted event handler Except for alphanumeric characters, escape all characters less than 256 with the \xHH format to prevent switching out of the data value into the script context or into another attribute. DO NOT use any escaping shortcuts like \" because the quote character may be matched by the HTML attribute parser which runs first. ## RULE #4 - CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values ## ## RULE #5 - URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values ## <a href="http://www.somesite.com?test=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a > ## RULE #6 - Sanitize HTML Markup with a Library Designed for the Job ## !!