1. Prevent Cross-Site Scripting (XSS) attack
SEC835
Prevent Cross-Site
Scripting (XSS) attack

2. Cross-Site Scripting
Instead 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 languages
We use “XSS” to refer to these vulnerabilities, so as to avoid confusion with “CSS” (cascading style sheets)

3. Cross-Site Scripting (XSS) Attacks
A 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 script
The attacker finds a victim and gets him to click the link
The 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 browser
The victim’s browser executes the malicious script, which may be crafted to pass data from the victim to the attacker, or other actions

4. 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

5. Cross-Site Scripting Attack in Action
The attacker sends a victim a link containing a malicious payload.
The victim, tricked into clicking the link, sends a request (and the payload) to the vulnerable application interface.
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.
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.

6. Cross-Site Scripting Attack sample
A sample attack link (to view cookie values) might look like this:
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=“ Address” value=“x”><script>document.location=‘
</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.

7. Common XSS Attack Vectors
Search engines that echo the search keyword that was entered
Error messages that echo the string that contained the error
Forms that are filled out where values are later presented to the user
Web message boards that allow users to post their own messages

8. 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

9. XSS Vulnerability – Type 2
XSS Type 2 has been implemented via
Stored data
Local html files stored on a user’s computer
HTML help files
HTML resources

10. XSS Vulnerability – Type 2
XSS 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.

11. JavaScript urls JavaScript 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

12. Indirect Ways to Inject Code
ActionScript (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 JavaScript
See

13. 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

14. 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 files
If the resource takes input from the URL and displays that, you might have an XSS issue
This 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

15. 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

16. Remedies Strong data input validation
Be 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

17. White- vs. Black-List
(Diagram)

18. Remedies Implemented by web developers Encoding output
Forcing the codepage
Adding double quotes around all tag properties
Inserting data in the innerText property
Browser hardening

19. Remedies details Encoding output Forcing the codepage
Convert dangerous symbols, including html tags, to their html representation
E.g. < becomes &lt
For ASP use HTMLEncode method
Forcing the codepage
Set a codepage explicitly by specifying the allowable charset

20. 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

21. Lab task Work on the spreadsheet re Vulnerability
Cell O3 – put your comments
The venues leading to XSS
Work on the spreadsheet re Countermeasures
Cells A11 – put your comments
How to prevent XSS