Sucuri Cloud Proxy is a very well known WAF capable of preventing DOS, SQL Injection, XSS and malware detection and prevention. It acts as a reverse proxy which means that all the traffic sent to an application behind Sucuri WAF would be first sent to Sucuri’s network which (based upon it’s signature database) would check if a particular request is legitimate or not, if it’s legitimate it would let it reach the application otherwise it would blocked.
Notice that in this case as well we have a valid and completly harmless text being considered as an XSS attack vector.
Sucuri XSS Filter
Let’s get to the main topic, In this post i would be revealing one of the many bypasses i found for sucuri’s XSS filter. The full bypass works with user interaction, however given that you follow the given methodology you would easily be able to construct a bypass that does not require user interaction.
As per the following link Sucuri’s cloud proxy has a built in XSS filter capable of detection and blocking XSS attempts. “Our CloudProxy firewall does protect your site against XSS script injections if you want to prevent them from ever being used to compromise your site“. So I decided to test the effectiveness, however due to absence of testbed i had to attempt it on a live website. So let’s get started.
The following is the methodology I utilize when i am up against any WAF:
i) Brute Force (Throwing random payloads and known bypasses for other filters to see if they are able to bypass the filter)
ii) Regex Reversing (The rules are reverse engineered to see what is allowed vs what is not allowed to construct a bypass)
iii) Browser Bugs (When (i) and (ii) fails, I go with browser specific bugs such as charset inheritance, RPO etc and other quirks)
For bypassing Sucuri the second methodology was utilized i.e. Regular expression reversing.
Initial Tests – Brute Force
I made initial tests with tons of different vectors, however i quickly figured out that Brute forcing would not be the way to go about bypassing this filter.
<svg><script/href=//?? /> – IE
<isindex action=//goo.gl/nlX0P type=image>
<form action=//goo.gl/nlX0P><input type=”submit”>
<meta http-equiv=”refresh” content=”0;url=//goo.gl/nlX0P”>
<isindex action=j	a	vas	c	r	ipt:alert(1)
Constructing A Bypass – Regex Reversing
During my tests i found that <a tag along with href attribute was allowed. However i found that as soon as i enter anything after the = my vector is blocked.
I thought perhaps they are detecting the regular expressions expects a SPACE after anchor tag, so i tried forward slash (/) however it was blocked.
The next option was to try characters that could be used instead of white space such as x0c which stands for “Form Feed” or perhaps newlines.
I came to the conclusion that the regex only looks for a “Space” and “Forward slash” between a tag and href attribute. However, i since Form feed only works in google chrome, i didn’t wanted to generate a browser specific bypass. So, i used the following vector.
Here is how the input was being reflected.
The next step was to check if the regex is filtering out case sensitive payloads. However, it was also being filtered out.
Inside of href attribute : could be used instead of “:” which would be decoded by the browser at the run time.
However, as could be seen from the above figure the html entities are not being reflected back. This could be easily defeated by using hex encode to encode & and ; signs.
Combining all pieces of puzzle leads to full bypass:
Both the website owner and the vendor has been notified about the vulnerability.
WAF’s should only be considered as an additional layer of protection not a primary layer of protection. Due to the fact that rely upon blacklist, in almost all the situations it’s possible to bypass them.
Update2: It seems like securi is now blocking “Prompt” as well as the “Confirm” keyword, the following vector bypasses it –
“><p id=””onmouseover=u0070rompt(1) //
Update 3: @soaj1664ashar found another way to bypass the filter:
“><p id=”u0070rompt(1)”onmouseover=u0065val(id) //
Update 4: Mathias Karlson used a neat trick to yet again bypass Sucuri XSS filter, he figured out that a=”b” i added a little bit of css magic to make user interaction unavoidable.
Unavoidable User Interaction
The above bypass could be combined with with css magic to bypass it with unavoidable user interaction.