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.

Overreliance on Javascript: Pen-tester's pet

I am sure all of you have been acquainted with the input validation situation where the developer validates all his input on the client-side using some poorly written Javascript to boot. Well, I recently experienced a new high in Javascript overreliance, and this was precious!!

I came across an application which relied heavily on Role Based Access Control. The Application is an Enterprise Application which has several types of users and several different "screens" that each user can access, thereby restricting the user's access based on the user's role. Well, this is how a traditional access control system works.

So, what would one do to ordinarily circumvent these controls? The first thing I tried was the URL route, where I scanned the app for URLs and entered these URLs to elevate my privileges. I was easily able to do this and the pages that clearly weren't meant for my user role kept appearing. When I tried to input some data and submit the form, the server threw me a big fat Javascript alert, "Access Denied".

Then I revoked the temporary permissions on my NoScript and the entire application fell apart. The Application so heavily relied on Javascript that the access to the links was controlled using Javascript only.

The code went something like this:

function Menu()
 {
 var UserRole=document.getElementById('userRole').value;

 switch(UserRole)
 {
 case 'elevatedPrivUser':      
  document.getElementById('thisScreen').style.display='none'; 
  break;
 case  'lowerPrivUser':       
  document.getElementById('someOtherScreen').style.display='none';
  break;
 case 'evenLowerPrivUser':
  document.getElementById('yetAnotherScreen').style.display='none';
  break;

As you can see here the Developer had left this brilliant bit of Javascript on each and every page. This was the basis of the Role Based Access Control System of the Application. Then I thought, surely, even if I accessed any one of these pages and tried to submit a request, the server would stonewall me and throw me out. I tried it out. Guess what?....More Javascript. Luckily, the Javascript wasnt available on plain view in that page, but clearly Javascript was the only validation which had been provided to validate user role and by disabling Javascript, I was able to pass my request over to the server which was accepted instantaneously.

So, the next time I go try to test an app for elevation of privileges, I will not bother with the session hijacking or the sniffing. I will just ask my NoScript to do the job and I will check whether the developer believes that "Client-side Scripting is the best!!!!"