Computer security question. a) Provide a description of a Cross-Site Scripting (

Question

Computer security question.

a) Provide a description of a Cross-Site Scripting (XSS) attack? Provide an example of a simple test to determine if the vulnerability is present in a web application.

b)What is the difference between a stored and reflected XSS? Can you provide an example of each? Ensure that you include the impact to the user, specifically how the attacker gets the user to launch the malicious script?

c)Explain the countermeasures necessary for preventing XSS vulnerabilities within a web application.

Explanation / Answer

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. 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.

One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:

The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server. All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult.

The Stored Cross Site Scripting vulnerability is the most powerful kind of XSS attack. A Stored XSS vulnerability exists when data provided to a web application by a user is first stored persistently on the server (in a database, filesystem, or other location), and later displayed to users in a web page without being encoded using HTML entity encoding. A real life example of this would be the Samy MySpace Worm, which exploited an XSS vulnerability found on MySpace in October of 2005.

The Reflected Cross-Site Scripting vulnerability is by far the most common and well-known type. These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. If unvalidated user-supplied data is included in the resulting page without HTML encoding, this will allow client-side code to be injected into the dynamic page. A classic example of this is in site search engines: if one searches for a string which includes some HTML special characters, often the search string will be redisplayed on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If all occurrences of the search terms are not HTML entity encoded, an XSS hole will result.

At first glance, this does not appear to be a serious problem since users can only inject code into their own pages. However, with a small amount of social engineering, an attacker could convince a user to follow a malicious URL which injects code into the results page, giving the attacker full access to that page's content. Due to the general requirement of the use of some social engineering in this case (and normally in DOM-Based XSS vulnerabilities as well), many programmers have disregarded these holes as not terribly important. This misconception is sometimes applied to XSS holes in general (even though this is only one type of XSS) and there is often disagreement in the security community as to the importance of cross-site scripting vulnerabilities. The simplest way to show the importance of a XSS vulnerability would be to perform a Denial of Service attack. In some cases a Denial of Service attack can be performed on the server by doing the following:

This makes a refresh request roughly about every .3 seconds to particular page. It then acts like an infinite loop of refresh requests, potentially bringing down the web and database server by flooding it with requests. The more browser sessions that are open, the more intense the attack becomes.

Countermeasures necessary for preventing XSS vulnerabilities within a web application

1. Never Insert Untrusted Data Except in Allowed Locations

2. HTML Escape Before Inserting Untrusted Data into HTML Element Content

3. Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes

4. JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values

5. HTML escape JSON values in an HTML context and read the data with JSON.parse

6. CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values

7. URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values

8. Sanitize HTML Markup with a Library Designed for the Job

Related Questions

Navigate

• Browse (All)
• Browse C
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.