Rediff XSS, the redux

It seems like my praise for Rediff was too quick. I had not tested out the Rediff search site exhaustively. This was brought to my attention by an OWASP Delhi member. Apparently, our friends at Rediff have not "fixed" the XSS Vulnerability in the search area. My attempts at performing a rudimentary XSS were thwarted, but I hadnt explored the possibility of encoding my payload using Javascript escape(), so this time, I tried and came up with this:













Apparently, the folks at Rediff have performed some very poor input validation and have probably only filtered the "<" and ">".

Rediff Redressal.....

My good deed was done for the week. Everytime one does something good for something or someone, one tends to feel good about it, sometimes even gloat about it.

I was surfing the Rediff Site yesterday, yes, the same one which I had eviscerated previously and entered the vile xss script and expected another tirade of scripts to rain down, but to my surprise discovered that it had been fixed. No more output encoding issues and the malicious payload seemed to have been encoded to prevent malicious XSS payload

Here is the screenshot.














But unfortunately, Rediff has not fixed a small pothole, whereas a large patch of road still remains undone. Several other Rediff sites (Rediff Products) are still vulnerable to XSS.

Screenshot:

Who's got the last laugh now. The Blogger XSS Vulnerability

I guess I was asking for punishment. I go looking for Web App Vulnerabilities all over the world, and sure as hell, this is what I will get.

I discovered that once I posted my Rediff Search Engine XSS Vulnerability on Blogger, I noticed something I had seen all too often, the Javascript alert with the rudimentary XSS, and this time, it was on my blog. I was not to happy about it to say the least. I thought "Some Smart Alec must have written up a comment causing the XSS alert, but I was quite sure that couldnt happen because Blogger had some sort of a filter on the comments. I then realized that the XSS alerts were popping up because of the XSS vectors in my Rediff post.

Surprisingly Blogger does not do any kind of validation or output encoding to prevent against these attacks in the posts section. So the blog-author can potentially be serving up XSS on his/her blog and potentially be exposing all the visitor's accounts with that, and since Blogger is a Google service, my session credentials are good for any Google Website. Mail, docs, everything.

But its ok now folks, the bitter pill of my own medicine has been swallowed................ or has it?

Rediff Search Engine XSS Vulnerability

This was something which was quite shocking as the series of events unfolded. I was researching up on output encoding methods to prevent against Cross Site Scripting and I experienced the full blown effect of the evils of bad/no output encoding and of course, no Input validation.

This was something I discovered on Rediff.com's search engine. When I typed in "search:followed by the Javascript alert, I received the infamous Javascript alert with simple 'XSS' written all over it. I was a little perturbed, because my NoScript said that it blocked a cross site scripting attack against taking place, but why was the alert still popping up? Then I was sure that the site was vulnerable to cross site scripting and decided to write about it. When I clicked the "Ok" on the Javascript alert box, another one popped up. This was definitely odd, I hadnt configured the alert for more than once. Then I clicked OK once more to find that there were more Javascript alerts to arrive with things like "XSS", session cookie details, "try_xss" and other alerts which I hadn't written. I then realized that rediff's search engine is scouring the web for pages with the XSS variants was executing that script on the rediff site, which was, beyond imagination and quite horrible. As I was clicking "OK" on the Javascript alert boxes new search results kept showing up and new alerts kept popping. The alerts only stopped with the end of the page.

Not only is Rediff vulnerable to XSS, Rediff has failed to encode their outputs from the search engine and is serving the xss, fresh from other websites, which have ironically, encoded their outputs.


I tried this out on a Google page, but it didn't work .

Anyone want to play around with the Search string try and enter your regular XSS reflected XSS tags check it out.

I have informed Rediff about the vulnerability, hopefully, they should rectify it soon.


Here are the series of screenshots of the xss alerts and the search results expanding each time.

Payment Application Pacman

Lately, I have been flooded with Application Security Assessment work. Applications of all forms, shapes and sizes have been given to me to test, which I have gleefully accepted. The work is supremely interesting. I always knew that there were tons of applications being developed all over the place, but I always figured that they would be of a certain nature, like a plain vanilla E-Commerce Application or a Banking Application, etc. Because of the spate of application security testing I have been doing recently, I have found that there is an application for everything. Right from Flea-Market Management to Cold Storage Management Applications. The granularity of business verticals which applications are catering to today are mind-boggling. Wait, I think I have diverted from my story, haven't I? Damn, I do this all the time, okay, back to the story.

I was testing this application for Payment Card Industry Compliance recently. I was quite impressed with the application at the outset. The application seemed to be loaded with some innovative features and it seemed like a great application for the business vertical it was hoping to address.

I started to test the application a few days later. It was sometime in the evening. I was not in the mood for any more testing. I had done quite a bit that day. I had already finished a preliminary vulnerability assessment of the server and as the assessment would be performed over a few days (yes, I procrastinate, a lot!), I thought of playing some Pacman. It is one of my favourite games. I thought of a slightly weird way to play it. The application I was testing was structured in a way where the user would use the input fields to enter values to be stored in the Database and as the Database updated, the previous inputs would be displayed in the table below it. Great way to test for persistent XSS, thought I. Therefore, I entered this harmless reflected XSS script alert in a field


and this is what I got


"Not bad", thought I, "the developers have managed to keep the bad apples out, or could it be the simplistic process of weeding out the angular bracket using a even simpler client side validation routine?"

Not to be deterred, I fired up my ever-trusty WebScarab and decided to take this attempt at killing two birds with one stone (namely me wanting to play Pacman in a different way and app sec testing) and caught a perfectly harmless request and gave it a interesting twist. I entered as input an html embed pointing to the Pacman Flash game, a lo I was gleefully playing Pacman on an application which had no business storing this in its Databases. One part of my test was done, quite a finding too. Cross Site Scripting (and later CSRF) vulnerabilities rampant on this site.

Coming back to my initial tangent. There are around 108 million distinct websites in the world today and even now, 23% of the world's population is exposed to the Internet, which is looking at a meteoric growth pattern in the future. According to the WASC (Web Application Security Consortium), almost 50% of web applications are vulnerable to Scripting and Information leakage vulnerabilities. As development becomes easier for everyone, we are only going to see more number of sites and apps falling prey to session hijacking, SQL Injection, Denial of Service and many other evolving attacks.

BTW, You can play the evergreen Pacman here