Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cross Site Scripting Defense Presentation


Published on

Cross site scripting (XSS) is a type of computer security vulnerability typically found in web applications, but in proposing defensive measures for cross site scripting the websites validate the user input and determine if they are vulnerable to cross site scripting. The major considerations are input validation and output sanitization.
There are lots of defense techniques introduced nowadays and even though the coding methods used by developers are evolving to counter attack cross site scripting techniques, still the security threat persist in many web applications for the following reasons:
• The complexity of implementing the codes or methods.
• Non-existence of input data validation and output sanitization in all input fields of the application.
• Lack of knowledge in identifying hidden XSS issues etc.
This proposed project report will briefly discuss what cross site scripting is and highlight the security features and defense techniques that can help against this widely versatile attack.

Published in: Internet
  • Be the first to comment

Cross Site Scripting Defense Presentation

  1. 1. Cross-site scripting defense Presented by Sarker Iftekhar Alam Yemi Aladeokin Igbape Maro
  2. 2. Outline  Introduction to XSS  Conditions for Cross site scripting  Cross site scripting key players  Types of XSS  How to test for cross site scripting  Defending against Cross site scripting  XSS prevention rules summary  Conclusion
  3. 3. Introduction to XSS Scripting: Web Browsers can execute commands  Embedded in HTML page  Supports different languages (JavaScript, VBScript, ActiveX, etc.)  Most prominent: JavaScript “Cross-Site” means: Foreign script sent via a server to a client  Attacker makes Web-Server deliver malicious script code  Malicious script is executed in Client’s Web Browser Attack:  Steal Access Credentials, Denial-of-Service, Modify Web pages  Execute any command at the client machine
  4. 4. Cross-Site Scripting Cross site scripting (XSS) vulnerability is mainly caused by the failure of web applications in sanitizing user inputs embedded in web pages. To add to this, many other attack methods, such as Information Disclosures, Content Spoofing and Stolen Credentials could all be side-effects of an XSS attack. CONDITIONS FOR CROSS-SITE SCRIPTING  A Web application accepts user input  The input is used to create dynamic content  The input is insufficiently validated
  5. 5. Cross-Site Scripting – Key Players  An Attacker • Anonymous Internet User • Malicious Internal User  An organization`s web server (i.e. Web application) • External (e.g.: Shop, Information, CRM, Supplier) • Internal (e.g.: Employees Self Service Portal)  A Client • Any type of customer • Anonymous user accessing the Web-Server
  6. 6. Cross-Site Scripting – Key Players Denial-of-Service  Crash Users`Browser, Pop-Up-Flodding, Redirection Access to authentication credentials for Web application  Cookies, Username and Password  Normal users (Personal data, Business data, Misuse of account)  High privileged users (Control over Web application, web server and database) Access to User`s machine  Use ActiveX objects to control machine  Upload local data to attacker`s machine Spoil public image of company
  7. 7. Type of XSS Stored or Persistent XSS:  Data provided by a client is first stored on the server such as a database or file system and later displayed to the users. This scenario usually requires a particular kind of vulnerable application, particular one that involves storing data in a database.  Persistent XSS is less frequent but the damage can be more devastating because once the payload is stored, it has the potential of infecting all of the visitors to the vulnerable web page.  Persistent XSS is also referred to as Type 2 XSS because the attack is carried out via two requests: one for injecting malicious code and having it stored on the web server, and the other for when victims load HTML pages containing the payload.  Typical goals of Persistent XSS attacks: Cookie theft and Data theft
  8. 8. Example: Forums / message boards Once a forum is identified as vulnerable, attackers may open a new topic and insert malicious scripts in the topic title or body. They can also tag the topic using popular keywords so that the topic is a popular search result. The content of the forum post will be stored by the server. When the victims browse topics or search for certain keywords, they may reach the infected topic. When the topic loads, its contents will be sent to the victim’s browser and the payload may be executed. Alternatively, attackers may build tools that automatically post malicious scripts in replies on popular / sticky topics, send private messages containing the payload to forum members, etc..
  9. 9. Defending Against Persistent / Stored XSS a) Server-side  Validate User Input The best way to prevent Persistent XSS is to make sure that all user input is properly validated before it gets stored permanently on the web server,  Sanitize static contents A second line of defense, make sure that the static content presented to users is also sanitized. b) Client-side  Disable JavaScript Users cannot take any particular actions in order to prevent such an attack, other than disabling JavaScript within their browser (disabling JavaScript is not seen as an adequate solution since several websites require it to function properly).  Update web browsers The only thing that can help in this case is using secure and up to date web browsers, with XSS filters turned on and hope for the best
  10. 10. Types of XSS Reflected XSS: n a reflected cross-site scripting attack, the user unwittingly sends code to a web server which then "reflects" that code back to the user's browser, where it is executed and performs a malicious act Typical goals: Session Hijacking, Bypassing access control and Malware Attack Session hijacking process:  Hacker sends link to victim, link contain XSS  Victim views page via XSS link supplied by attacker  XSS code executes on victims browser and sends cookie to attackers server  Cookie is stolen. The attacker can then hijack the victims session
  11. 11. Type of XSS DOM-based vulnerabilities  DOM XSS is a type of attack which relies on inappropriate handling, in the HTML page, of the data from its associated DOM.  Among the objects in the DOM, there are several which the attacker can manipulate in order to generate the XSS condition, and the most popular, from this perspective, is the document.url, document.location and document.referrer objects.  The Document Object Model is a convention for representing and working with objects in an HTML document (as well as in other document types)
  12. 12. Defending against DOM XSS attacks  The DOM XSS attack is difficult to detect by server-side attack detection and prevention tools, because usually the malicious payload does not get to the server and hence cannot be sanitized in the server-side code, like in the case of other XSS attacks.  Sanitization and prevention techniques apply, but in this case the code review as well as the implementation of sanitization functionality needs to be performed on the client-side code.  Avoiding client-side sensitive actions such as rewriting or redirection, using client-side data;  Using intrusion prevention systems which are able to inspect inbound URL parameters and prevent the inappropriate pages to be served.
  13. 13. How to test for Cross site scripting  Make notes of all the pages that display input originating from current or other users.  Test by injecting malicious JavaScript to see if they are ultimately displayed back to the user.  Carry out an examination of the code to ensure that the application data is HTML encoded before it is rendered to users.
  14. 14. Defending Cross Site Scripting  Appropriate output encoding or avoidance of thread input * The contextual output encoding or escaping method is the major defense mechanism to stop cross site scripting. * HTML entity encoding * Javascript escaping * CSS escaping
  15. 15. Defending Cross Site Scripting (contd.)  Securely authenticating untrusted HTML input Many forums and webmail like to allow users to implement some of the structures that html provides.  It could be limited subset of html markup  It prevent switching into any execution context HTML sanitization engine must run during untrusted html content accessing to ensure that it does not contain any xss.
  16. 16. Defending Cross Site Scripting (contd.)  Cookie based Security Many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies and its easy to steal the session cookies. To mitigate this threat:- * Attach the session cookies to the IP address of the user who actually login. * Allow only that IP who can access that session only. * Can be use HttpOnly flag which allows a web server to set a cookie that is unavailable to client-side scripts
  17. 17. Defending Cross Site Scripting (contd.)  HTTPOnly Cookie Flag Microsoft Developers defines HTTPOnly as additional flag included in set-cookie HTTP response header. Using this flag mitigates risk of client side scripting. When client access any website, website server sets this HTTPOnly. It can only be set if browsers supports it if not browser ignores it.
  18. 18. Defending Cross Site Scripting (contd.) Scanning Service * Scanning web application with the scanner such as The Zed Attack proxy (ZAP) , the client receives detailed information on how it was performed and thus has a chance to fix the issues before the same attack is attempted by someone else.
  19. 19. Defending Cross Site Scripting (contd.) After scanning , it can provide the details vulnerabilities of the web application with the solution and the risk level . This will help to identify and fix the problem easily.
  20. 20. XSS Prevention Rules Summary Context Code Sample Defence HTML Body <body> DATA </body> HTML Escape Convert & to &amp Convert < to &lt Convert > to &gt Convert " to &quot Convert ' to &#x27 Convert / to &#x2F HTML Attributes <div attr=DATA> </div> escape all characters with the HTML Entity &#xHH; format, include spaces except alphanumeric. GET or POST parameter <a href=”DATA”> </a> Replace space with + Escape every character except alphanumeric with % followed by two digit HEX code JavaScript Variable <script>alert(“DATA”)</script> Escape all characters with Unicode escaping format. uXXXX Avoid backslash encoding CSS value <div style=”height:DATA”> </div> CSS escaping supports XX and XXXXXX (CSS hexadecimal encoding). HTML Body (HTML data type) <div> DATA</div> Using libraries like AntySamy, HTML Sanitizer
  21. 21. Q & A