How To Test Cross Origin Resource Sharing Vulnerability (OTG-CLIENT-007)

Hello Everyone, This blog is all about Cross Origin Resource Sharing (CORS) Vulnerability. In my one year of research, I found various type of bypass, that I would like to discuss. I will keep this blog to the point without discussing backend reason, so that beginner can find it an easy one. If a site is allowing access control header at the output response then play with all the request and capture it on burp or any proxy you use. After getting all directory on burp -> target -> sitemap, then this is a good time to test !! Most of the people just test it on one point, but each directory has its own way to set access control header. So, test it on every directory. For example -dir1        -sub_dir1        -sub_dir2 -dir2        -sub_dir1        -sub_dir2 Here you need to test on dir1 and dir2. How To Test First, put any random character at origin header at the input and see the output response. POST/GET  /page/etc Host: ...... origin: areyo

How I found 5 store XSS on a private program. Each worth "1,016.66$"

Hello everyone,

This is my second blog of the series "Sharing Is Caring". What I have learnt until now because of those guys who believe in that 'methodology' :)

The site is private, so call it

1- Store XSS using comment body

I found that on a, the comment body was reflecting on user own profile. So, I started hunting in a way to find something special.

After many tried and tested with each and every payload I got nothing. But, I believe in a sentence "There is always a way to bypass" {Thanks to zahid ali who once said this and proved it on facebook, when bypassed same feature three times}

Anyway, I didn't give up and thinking to bypass. Later, an idea clicked on my mind to use payload on second or third line as I have read in other researcher posts. The xss got store when I used my favourite payload <svg/onload=alert(1337)> on the second line of the body.

Time spent: 9-10 hours

2- Store XSS using the file attachment

This XSS was very easy to find. But I found it at the end when the program was about to close. I am more curious about how nobody found it.

I saw a file attachment feature and tested it as my regular technique. I uploaded request on burp and sent to intruder. Then uploaded all file extensions on burp to see what extensions are allowed.

Extensions which was allowed [.txt, .png, .jpg and  '.xhtml' . Yes .xhtml !! ]

For POC I uploaded the below code and reported it.

<?xml version="1.0" encoding="iso-8859-1"?>  
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"   
<html xml:lang="en" lang="en" xmlns="">  
<p>This is a POC</p>
Time spent: 1 hour

3- Store XSS on the notification

This type of XSS is my most favourite, I found it 3 times on different program. There was a feature on, when a user performs any activity then follower user gets the notification. On notification the HTML tag was not sanitizing, So i used payload  "><svg/onload=alert(1337)> and made notification store xss.

4- Store XSS using encoding

I found that on one endpoint the data was stored on a user profile. But it was blocking < tag.

When I come across that situation, I just take the request on the burp and send the request to the intruder with the below payloads to see < sign can bypass or not.



Luckly, &#X000003C; was working. So i just used ">&#X000003C;svg/onload=alert(1337)>  and got store xss on user profile.

5- Weird Store XSS

This XSS took around 2-3 days to find a bypass. I am not allowed to use the exact term of the site that would help other to get clue. So it is one point where < and > sign was allowed but only width and height can be used.

For example:  < svg width=100 height=100> was allowed but when I used event handler it blocked. After two days I was about to give up. But I gave it one more day :)

On one moment I sent the request to intruder with payload POST /< svg width=100 hight=100>test

 I forgot that i have added <svg width=100 hight=100>. So intruder tried different payload on 'test'. At one point the payload was
<svg width=100 hight=100><script>alert(1)</script>

With the above payload, the store xss truly stored. Actually, the filter was checking the first HTML tag. It is really weird behaviour to me how this payload worked <svg><script>alert(1)</script>

Reach me on Facebook or Twitter


Post a comment

Popular posts from this blog

How i was able to get admin panel on a private program

How To Test Cross Origin Resource Sharing Vulnerability (OTG-CLIENT-007)