Stored Cross-Site Scripting(Non-Privileged User to Anyone)

Vulnerability Category: A7- Cross-site Scripting

Vulnerability Description: A Stored Cross-Site Scripting (XSS) vulnerability occurs when a web application sends stored strings that were provided by an attacker to a victim’s browser in such a way that the browser executes part of the string as code. The string contains malicious data and is initially stored server-side, often in the application’s database. The application later retrieves the malicious data and inserts it into a web page. This results in the victim’s browser executing the attacker’s code within a legitimate user’s session.

Impact: Stored XSS can use to steal cookies, password or to run arbitrary code on victim’s browser

Recommendation:

Filter input on arrival. At the point where user input is received, filter as strictlyas possible based on what is expected or valid input.

Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.

Use appropriate response headers. To prevent XSS in HTTP responses that aren’t intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.

Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.

Severity : High

CVSS v3.0 Score: 8.1

CVSS v3.0 Vector: CVSS:3.0/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:N

How to test:

● Test all relevant “entry points” via which attacker-controllable data can enter the application’s processing, and all “exit points” at which that data might appear in the application’s responses.

● Parameters or other data within the URL query string and message body.

● Any out-of-band routes via which an attacker can deliver data into the application.

Blind XSS

It is a type of stored XSS where attackers input is saved by server and is reflected in a totally different application used by system admin/team member.

How to Test:

● Try Injecting Blind XSS payloads into User-Agent or Referer/Origin headers and Cookie Values

● Inject Blind XSS payloads on fields like address, contact forms, first name field of credit card

Tools to test:

● XSS Hunter is the tool to use to check Blind XSS

Link: https://xsshunter.com

Note: If i wrote any mistakes in my posts please notify me I will rectify and learn more about it

#infosec enthusiast, pentester