JSON-based SQL attacks bypassed WAFs, but not Contrast Protect

Recently, Contrast’s Labs research team came across an article discussing a Web Application Firewall (WAF) bypass.

As the article discusses, several modern and popular databases (MySQL, PostgreSQL, SQLite and Microsoft SQL Server) have built-in JavaScript Object Notation (JSON) support in their respective Structured Query Language (SQL) engines. This allows them to better query any JSON content stored in their database. However, the unintended result is that new SQL tautology syntax (‘ OR ‘a’=’a) can be made and leveraged in SQL injections.

For example, here is a tautology using MySQL’s JSON capabilities:

JSON_EXTRACT extracts a given value based on a given key. The above tautology has a hardcoded JSON string from which it extracts a value by using JSON_EXTRACT and then comparing it with a normal string within SQL. Ultimately, it resolves to something like the following:

Assuming such a tautology payload is used in a vulnerable SQL query, a query like the following might occur:

The above query would return all rows in the table! But what does this new “SQL tautology syntax” mean in terms of web application protections? Will tools catch it?

Any tooling that relies on patterns to identify exploits, such as WAFs, needs to be updated to catch this. In fact, the above article discusses the authors working with five major WAF vendors on releasing patches to catch this new syntax. 

While this is just one exploit for one vulnerability type, the reality is that this can occur for any number of exploits for any given vulnerability type. Any new exploitation syntax or bypasses will require a pattern update in order to be caught by a WAF. 

Daunting, right? It’s a never-ending game of whack-a-hole … 

How to stop chasing these endlessly mutating exploits

Is there a way to address the “root” issue, rather than pattern-matching the numerous and never-ending permutations of an exploit? 

Contrast thinks so. Our Runtime Application Self-Protection (RASP) product, Protect, does just that. 

Protect detected and blocked the above exploit out of the box, with no updates or patches. Protect’s SQL injection rule analyzes SQL queries and will detect and block if user input alters the meaning of a query, effectively blocking the root issue of SQL injection. This rule, and all of the Protect rules, are positioned and designed to detect and block the root issues of vulnerabilities. Therefore, Protect can offer great protection against an ever-evolving landscape of exploits. 

Get in touch for a demo today.