R1905_Glan Loyan Dsouza CyberSapiens Internship session task 9

XSS Vulnerabilities
R1905_Glan Loyan Dsouza CyberSapiens Internship session task 9

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to
compromise the interactions that users have with a vulnerable application. It allows an attacker to
circumvent the same origin policy, which is designed to segregate different websites from each other.
Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry
out any actions that the user is able to perform, and to access any of the user's data. If the victim user
has privileged access within the application, then the attacker might be able to gain full control over all
of the application's functionality and data.

Reflected XSS:

Reflected XSS occurs when user input is immediately returned by a web application in an error
message, search result, or any other response that includes some or all of the input provided by the user
as part of the request, without that data being made safe to render in the browser, and without
permanently storing the user provided data. In some cases, the user provided data may never even
leave the browser (see DOM Based XSS below).

Stored XSS :

Stored XSS generally occurs when user input is stored on the target server, such as in a
database, in a message forum, visitor log, comment field, etc. And then a victim is able to retrieve the
stored data from the web application without that data being made safe to render in the browser. With
the advent of HTML5, and other browser technologies, we can envision the attack payload being
permanently stored in the victim’s browser, such as an HTML5 database, and never being sent to the
server at all.

DOM Based XSS

As defined by Amit Klein, who published the first article about this issue [1], DOM Based XSS is a
form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the
source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the
browser. For example, the source (where malicious data is read) could be the URL of the page (e.g.,
document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call
that causes the execution of the malicious data (e.g., document.write).

Blind XSS:

Blind XSS vulnerabilities are a variant of persistent XSS vulnerabilities. They occur when the
attacker input is saved by the web server and executed as a malicious script in another part of the
application or in another application.

XSS Attack Consequences:

The consequence of an XSS attack is the same regardless of whether it is stored or reflected (or
DOM Based). The difference is in how the payload arrives at the server. Do not be fooled into thinking
that a “read-only” or “brochureware” site is not vulnerable to serious reflected XSS attacks. XSS can
cause a variety of problems for the end user that range in severity from an annoyance to complete
account compromise. The most severe XSS attacks involve disclosure of the user’s session cookie,
R1905_Glan Loyan Dsouza CyberSapiens Internship session task 9

allowing an attacker to hijack the user’s session and take over the account. Other damaging attacks
include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to
some other page or site, or modifying presentation of content. An XSS vulnerability allowing an attacker
to modify a press release or news item could affect a company’s stock price or lessen consumer
confidence. An XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage
information resulting in an overdose.

Preventing cross-site scripting is trivial in some cases but can be much harder depending on the
complexity of the application and the ways it handles user-controllable data.In general, effectively
preventing XSS vulnerabilities is likely to involve a combination of the following measures:

• Filter input on arrival.At the point where user input is received, filter as strictly as
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.

Reference:

https://portswigger.net/web-security/cross-site-scripting

https://owasp.org/www-community/attacks/xss/