Stored Cross Site Scripting

Cross-site Scripting (XSS) is a client-side code injection attack where an attacker can execute malicious scripts into a website or web application. Stored Cross-Site Scripting affects the web applications that allows users to store data. This action can potentially expose the users to this type of attack. There are many web applications that are vulnerable to Stored Cross-site Scripting. These web applications fail to filter the stored inputs gathered from the users. As these stores that input in a data store for later use.

The Stored XSS attack can be successfully executed when a web application gathers malicious input from a user and then stores the input in a database for later use. The main reason for a successful stored XSS attack is the negligence by the developer. The developer had failed to filter the stored input properly. Due to this negligence, that malicious data will appear to be part of the web application and will run in the user’s browser using the web application’s privileges. As this vulnerability typically involves at least two requests to the application, it will also expose the user to second-order XSS.

The stored cross-site scripting vulnerability can be used to conduct a number of browser-based attacks including:-

• hijack an end user’s browser.
• steal sensitive information viewed by the application’s users.
• perform a pseudo defacement of the vulnerable application.
• Port scanning of internal hosts (The internal hosts refers to the users of the application).
• direct the delivery of browser-based exploits.

A Stored XSS doesn’t require a malicious link to initiate. Successful exploitation can only be initiated when an end-user visits a page with a stored XSS vulnerability. The following are the phases that a typical site faces during a typical stored XSS attack scenario:-

• The attacker will first store malicious code into the vulnerable web application’s page.
• An end user will authenticate himself in the application.
• After login, the user visits the web application’s vulnerable page.
• The malicious code will get executed in the user’s browser.

Input stored by applications are usually used via HTML tags. The stored input can also be found as part of the application’s JavaScript content. At this moment, it is crucial for the application to understand how the input is stored and how the input data is positioned in the context of the page.

Example

Let us consider the following input field is vulnerable to a stored XSS attack.

        <input class="inputbox" type="text" name="email" size="40" value="example@beaglesecurity.com" />

    

The attacker will find ways to inject code into the vulnerable input box.

    <input class="inputbox" type="text" name="email" size="40" value="example@beaglesecurity.com"> MALICIOUS CODE <!-- />
    

Impact

An attacker can perform attacks like:-

• Account hijacking: An attacker can gain access to an end-user account.
• Credential theft: An attacker can steal the credentials of users to access their account.
• Data leakage: Using the credentials, the attacker can steal sensitive information about the user.
• An attacker can fake itself as the host application to the end users and redirect them to the malicious application.
• The other attacks include key-logger attack, website defacement and port scan.

Mitigation / Precaution

Beagle recommends the following fixes:-

• Ensuring that the inputs are properly validated.
• Encoding all input fields.
• Ensuring all cookie properties are properly set.

Written by

Nash N Sulthan

Cyber Security Lead Engineer