Cross Site Scripting

Cross-Site Scripting (XSS) is a type of attack that can occur in many forms, but in general they occur when data of some type enters a web application through an untrusted source (in the major of cases, a web request).

Typically, this data is included as part of dynamic content that has not gone through checks to ensure it is all trustworthy.

Read: Hunting Cross Site Scripting (XSS)

NOTE: Dynamic content is any type of content that is generated on the fly or on demand. Typically, this means that a user, browser, or services makes a request, which is sent to a server. The server interprets the request and returns data in the form of a web page.

In many cases the content that causes the attack to occur in the form of JavaScript, but it is not restricted to this format.

In fact, it could come in the form of HTML, Flash, or other executable code. Because of the vast amounts of code that can be executed by a web browser, the variation that this type of attack can assume are almost boundless.

Some of the most common goals include reading or stealing cookies, interfering with session information, redirecting to a location of the attacker’s choosing, or any number of other tasks.

Store and reflected XSS attacks are the two main forms of this attack, so let’s look at each:

Stored XSS Attacks: XSS attacks that fall into this category tend to be the most dangerous type. The attack is enabled by any web application that allows a visitor to store data when they visit the site.

In practice, a web application gathers input from a visitor and stores the input within a data store for later retrieval and use.

The process goes awry when a malicious visitor visits the site and their malicious input is stored in the data store.

Once this happens, their data will be part of the site, and when a subsequent visitor comes to the site, they inadvertently run the date data.

Since the code runs locally, it will run with the security privileges of the client application.

Depending on how the data is crafted, the attack can carry cost a number of tasks, including these:

• Hijacking another user’s browser.
• Capturing sensitive information viewed by application users
• Pseudo defacement of the application
• Port scanning of internal hosts (internal in relation to the users of the web application)
• Directed delivery of browser-based exploits

Adding to the danger of stored XSS is that the victim need only visit the page with the crafted attack and need not click a link.

The following phases relate to a typical stored XSS attack scenario:

• The attacker stores malicious code into the vulnerable page.
• The user authentication in the application.
• The user visits a vulnerable page.
• Malicious code is executed by the user’s browser.

Stored XSS is particularly dangerous in application areas where users with high privileges have access. When such a user visits the vulnerable page, the attack is automatically executed by their browser. This might expose sensitive information such as session authorization tokens.

Reflectecd XSS Attacks: These attacks are a little more complicated in that injected code in bounced or reflected off a web server in the form of an error message or other result.

Typically, these attacks make their way to the victim in the form of an email or via a different web server.

A user may be tricked into clicking a link in a web page or message. Once clicked, the link would then cause the user to execute code.

In practice, reflected cross-site scripting occurs when a malicious party injects browser executable code within a single HTTP response.

Because the code is not persistent and is not stored, it will only impact users who open a specially designed link where the attack is part of the URL itself.

Since the attack is relatively easy to carry out compared to its store procedure cousin, it is encountered much more frequently than stored attacks.

This type of attack typically leverages JavaScript, VBScript, or other scripting languages where appropriate.

In the wrong hands, this type of attack can install key loggers, steal victim cookies, perform clipboard theft, or change the content of the page (for example, download links).

In general, XSS attack consequences typically are the same no matter what form of the attack takes: disclosure of the user’s session cookie or allowing an attacker to hijack the user files, installing Trojan horse programs, redirecting the user to another page or site, and modifying presentation of content.

GETTING FIXATED

Another type of session hijack is the session fixation attack. This type of attack is targeted specifically at web application; it exploits vulnerabilities in the way these packages manage their session IDs.

The vulnerability exists when an application fails to create a new session ID when a new user authenticates to the application.

The attacker must induce a user to authenticate using a known session ID and then hijack the session.

There are several techniques to execute the attack, which vary depending on the application. Here are some common techniques:

• The session ID is sent to the victim in a hyperlink and the victim accesses the site through the malicious URL.
• The victim is tricked into authenticating in the target web server, using a login form developed by the attacker. The form can be hosted in the web server or directly in HTML-formatted email.
• The attacker uses code injection, such as cross-site scripting, to insert malicious code in the hyperlink sent to the victim and fix a session ID in its cookie.
• Using the <META> tag is also considered a code injection attack, although it’s different from the XSS attack, where the undesirable scripts can be disabled or the execution can be denied.
• HTTP header response uses the server response to fix the session ID in the victim’s browser. By including the parameter Set-Cookie in the HTTP header response, the attacker is able to insert the value of the session ID in the cookie and send it to the victim’s browser.