Combining DOM and reflected XSS to bypass input sanitation in Checkpoint.com

Elikrem
Elikrem
Feb 17 · 3 min read

I was looking around checkpoint.com to see if I could find any low hanging fruits. Checkpoint does not have a bug bounty program, but as a company that does a great job exposing vulnerabilities in others applications, it made me want to check if the camel sees its own hump.

So I started with some google dorking looking for any interesting endpoints. After a few minutes I stumbled upon a page that looked very old fashioned — https://appwiki.checkpoint.com/appwikisdb/public.htm . This is always a good indication when looking for an unsecured web application.

Obviously the first thing that draw my attention was the search bar. I opened Burp Suite and intercepted the request. I ran a random string and saw it was reflected in the value attribute inside an input tag.

The next step was trying to break out of the attribute context, adding some Javascript and pop an alert box. So I added double-quotes closing off the value attribute and added “onload=alert()” and… nothing. The payload did was not reflected in the response. I removed the parenthesis, sent it again and the payload reemerged. So obviously I had some input validation going on here.

After playing around a bit, I found out that besides the parenthesis, the single-quote (‘), semi-colon (;), backtick (`), smaller-greater-than (<>) signs and the word “script” were also sanitized. I tried different payloads but could not find something that would work.

One mistake I made from the start was using the “onload” event inside the input tag. “Onload” is my go-to JS event when searching for XSS, but I was not aware that it will fire only if the input tag has a “type=image” attribute with a valid “src”. So I might have missed some payloads that would have worked. But it only lead to finding a cooler payload eventually.

After figuring out which signs were sanitized, I looked for what signs I still had in my arsenal. I had the square-brackets ([]), plus sign (+), dot (.) and equal sign (=). I consulted with a fellow researcher Gal Goldshtein that suggested using “window.location” object and constructing the “javascript:alert()” string from other JS objects by accessing their string indexes.

First I changed the JS event to “onmouseover” which works with the input tag and tested the payload “onmouseover=window.location=navigator.userAgent[0]”. It worked great. As my User-agent was “Mozilla…” I was forwarded to “/appwikisdb/M”.

Now that I had a working POC I needed to construct the real payload. But Instead of looking for the payload’s characters in different JS objects, we figured out we can use the URL hash and access it using window.location.hash. This way we can add the payload in the hash without sending it to the server and access it from the reflected response. Basically injecting a DOM XSS vulnerability using a reflected XSS. There was one small issue, when calling the window.location.hash object it responds with the the hashtag symbol (#). So using “window.location=window.location.hash” with “#javascript:alert(/xss/)” in the URL hash will be rendered as “window.location=#javascript:alert(/xss/)” breaking the script. Since I could not use the substring() method due to parenthesis, I had to concatenate all the strings in the hash besides the first character.

So I did, and here is the final payload:

https://appwiki.checkpoint.com/appwikisdb/applicationList_public.htm?searchTerm=yyyyy”%20onmouseover=”window.location=window.location.hash[1]+window.location.hash[2]+window.location.hash[3]+window.location.hash[4]+window.location.hash[5]+window.location.hash[6]+window.location.hash[7]+window.location.hash[8]+window.location.hash[9]+window.location.hash[10]+window.location.hash[11]+window.location.hash[12]+window.location.hash[13]+window.location.hash[14]+window.location.hash[15]+window.location.hash[16]+window.location.hash[17]+window.location.hash[18]+window.location.hash[19]+window.location.hash[20]+window.location.hash[21]+window.location.hash[22]+window.location.hash[23]&widget=true&=&view=false#javascript:alert(/xss/)

And… Bang!

The vulnerability was reported and patched by Checkpoint’s Security team within 3 hours.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade