Tuesday, 11 March 2014

Cross Site Scripting Filter Bypassing using Header Injection (CRLF).....

Cross Site Scripting Filter Bypassing using CRLF.....

This is my first technical writing. So please share your reviews and suggestions..

I would like to share a cross site scripting vulnerability found in one of the application I was testing. Usually xss is very common in the websites. However I found this one interesting, as this vulnerability is triggered using another known vulnerability CRLF.

The application I was testing is very secured in case of xss as it is having restrictions on both input and output.
1. whenever a tag with "<" and ">" together (like <script>)is used in input, the application will filter and redirect to an error page.
2. If you use either "<" or ">" without the other then it'll encode the input to html entity encoded form.
So I find this irritating and tried all known attack vectors, found nothing but logged out forcibly.

So I stopped hunting for xss and concentrated more on other conventional bugs. After a long search, I found an interesting page where there is an option to download a certain file. So as usual, like all the others, I tried to get an LFI & RFI but instead of an LFI,  found something different.. The files I'm trying to include are not getting included. But the filename parameter value is reflecting as an empty attachment name. 

So I tried few garbage chars first and when they were returned as the attachment name, then finally I tried with the /r/n and to my surprise they are also returned by the server, however they are not parsed. So, as a final attempt I tried encoded format and  bingo.. The server parsed the %0d%0a chars and the next statements are returned as the response headers..

But this finding was not enough for me. So I tried to include some html code to execute and failed again because every time  html tag is used, the server redirects to an error page and logs-me-out. It is because of the attachment type header, the content is not directly rendering but it downloads the page.

So to bypass this html tag based filter I needed a html tag which need not be closed and should be able to execute a javascript.. so I searched here n there for a while, and came up with the following body tag,

I crafted my payload as     %0d%0a%0a%0a<body/onload=alert(1)   and used it as the input.. as a result the server parsed the input and sent a file with <body/onload=alert(1) as the response.

As the file is having no file name and because of the file permissions enforced on the current page, the file download window will not allow to save the file. So the only option left for the user is to click "open"  and guess what.... alert(1) popped up..

The downloaded file will be executed or opened outside the domain scope as the developer did not enforce any html entity encoding on the contents of the downloaded file, and this fact also helped me to get the xss...

Finally I got an xss in the application developed very carefully especially to restrict xss...

This is the story of an xss triggered with crlf.. please share ur suggestions & reviews at mohan.gcsm@gmail.comfacebook.com/mohan.gcsm