CROSS SITE SCRIPTING.ppt
- 1. REGT NO : 010650035 RANK : ASI(RM) NAME : YASHVIR SINGH UNIT : BICIT NEW DELHI CROSS SITE SCRIPTING MOI
- 2. Overview Introduction What is XSS? Method Of XSS Preventing XSS Attack Conclusion Questions
- 3. What is XSS? Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
- 4. An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site
- 5. Types of XSS Reflected XSS Stored XSS (“Persistent XSS”) DOM Based XSS
- 7. Stored XSS JavaScript supplied by the attacker is stored by the website (e.g. in a database) Doesn’t require the victim to supply the JavaScript somehow, just visit the exploited web page More dangerous than Reflected XSS Has resulted in many XSS worms on high profile sites like MySpace and Twitter (discussed later)
- 9. DOM Based XSS The attacker provides the victim with some malicious data. This is often done by persuading the victim to clicking on a link, with the malicious data embedded in the URL. At this point the malicious data is still just data. Scripts running in the browser use the malicious data in client-side DOM manipulation, as part of their normal operation. The browser renders (or otherwise processes) the DOM, running the malicious data as commands. The bad thing (whatever the attack was - e.g. sending user data or session IDs to the attacker) happens.
- 10. The attacker provides the victim with some malicious data. This is often done by persuading the victim to clicking on a link, with the malicious data embedded in the URL. At this point the malicious data is still just data. Scripts running in the browser use the malicious data in client-side DOM manipulation, as part of their normal operation. The browser renders (or otherwise processes) the DOM, running the malicious data as commands. The bad thing (whatever the attack was - e.g. sending user data or session IDs to the attacker) happens. DOM Based XSS
- 12. Is XSS Dangerous? Yes Defeats Same Origin Policy Just think, any JavaScript you want will be run in the victim’s browser in the context of the vulnerable web page Hmmm, what can you do with JavaScript?
- 13. What can you do with JavaScript? Access/Modify DOM Access cookies/session tokens Pop-up alerts and prompts “Circumvent” same-origin policy Virtually deface web page Detect installed programs Detect browser history Capture keystrokes (and other trojan functionality) Port scan the local network
- 14. What can you do with JavaScript? (cont) Induce user actions Redirect to a different web site Determine if they are logged on to a particular site Capture clipboard content Detect if the browser is being run in a virtual machine Rewrite the status bar Exploit browser vulnerabilities Launch executable files (in some cases)
- 15. Preventing XSS The first method you can and should use to prevent XSS vulnerabilities from appearing in your applications is by escaping user input. Escaping data means taking the data an application has received and ensuring it’s secure before rendering it for the end user. By escaping user input, key characters in the data received by a web page will be prevented from being interpreted in any malicious way. In essence, you’re censoring the data your web page receives in a way that will disallow the characters – especially < and > characters – from being rendered, which otherwise could cause harm to the application and/or users.
- 16. Validating input Validating input is the process of ensuring an application is rendering the correct data and preventing malicious data from doing harm to the site, database, and users. While whitelisting and input validation are more commonly associated with SQL injection, they can also be used as an additional method of prevention for XSS. Whereas blacklisting, or disallowing certain, predetermined characters in user input, disallows only known bad characters, whitelisting only allows known good characters and is a better method for preventing XSS attacks as well as others.
- 17. A third way to prevent cross-site scripting attacks is to sanitize user input. Sanitizing data is a strong defense, but should not be used alone to battle XSS attacks. It’s totally possible you’ll find the need to use all three methods of prevention in working towards a more secure application. Sanitizing user input is especially helpful on sites that allow HTML markup, to ensure data received can do no harm to users as well as your database by scrubbing the data clean of potentially harmful markup, changing unacceptable user input to an acceptable format.
- 18. Conclusion XSS vulnerabilities are bad. Avoid introducing XSS vulnerabilities in your code. Please. They will only cause delays in getting your apps into production.