It’s always hard to explain why XSS in login or registration forms is dangerous. What we usually aim for when exploiting XSS is executing commands on behalf of our victim or – if possible – steal his session cookie to take over the session. For this to work we need two things:
- An XSS Flaw
- A logged in user
Both are equally important for this kind of attack. So what are we able to do if the XSS vulnerability is only reachable when the user isn’t logged in?
“Exploits of a mom” by Randall Munroe (xkcd.com)
SQL-injections are one of the most common and most severe vulnerabilities in web applications today. They are caused by unsanitized user input inside SQL statements and their impact can reach from sensitive information disclosure to complete takeover of the affected server. Either as a direct or indirect result of the injection itself. How much an attacker is able to see or change depends on the privileges of the account that’s used to communicate with the database.
If the database account in use is permitted to use the mysql functions “load_file” or “outfile” he is able to read or write files on the server. However most of the time this is not the case and an attacker has to deal with a limited set of available functions. If you have the outfile privilege you don’t have to see the output of the SQL query to cause some serious damage or take over the whole server. But usually being able to see the output is a key component of a successful SQL-injection attack. So what are we able to do if there’s no way for us to get feedback from the database?
You can disable functions in PHP
If you own a web server running PHP it is a good idea to disable dangerous functions you don’t need for your website. If an attacker manages to run code on your Server the impact will be limited to the functionality the permitted functions provide. Luckily PHP gives us an easy way to do this. All you have to do is adding the functions you want to disable to the disable_functions directive. However, under some circumstances the execution of system commands might still be possible and I’ll show you an example using a .htaccess file with enabled mod_cgi.
This is where the trouble starts.
You’ve seen them. They are all over the web. Sometimes they contain valuable information or warn you before closing an important browser window. But most of the time they are really annoying and almost everybody clicks on “Ok” without really reading them. I’m talking about alert boxes. If you hear “XSS” you almost immediately think of them. And that’s a huge problem.
[INFO] All this was tested on Chrome and Chromium 49 and 50.0.2661.75 Since the XSS Auditor gets security updates regularly these bypasses might not work anymore by the time you read this post. [/INFO]
Photo of me and the auditor
Since @brutelogic and I have had a lot of fun bypassing filters, creating challenges and finding new XSS methods and payloads in the past we thought we should try our luck on Chrome’s Auditor. You can read about the results of our research here. The bypasses we found can be used in many cases but there might be some situations where you can’t use them, for example when there’s no closing script tag or with some special chars after the actual payload like > or ?. However, there are some uncommon ways you could try.
Yes, it’s possible
What always bugged me about template strings is this: While they can be very useful to prove that there’s an underlying XSS issue, the POC you can create with them is not really convincing. You might show that you are able to pop an alert, but there’s no way to show the owner of an affected site that this is really executed on his domain. That might be a problem in some scenarios. So I decided to find out if it’s possible to alert document.domain with them.
actual photo of me in front of the product logo
I was talking to a friend about attacks on web applications. He said he uses the Ninja Firewall WAF in his company to block automated threads. Since I had some spare time I decided to try my luck bypassing it.
A mail cow.
I was thinking about a relaunch of this website the other day. There were some things that I wanted to do different, the design wasn’t too great and some of the software I used turned out not to be as secure as I thought. One example is mailcow.