OWASP Top Ten – Injection

  • Home
  • OWASP Top Ten – Injection
OWASP Top Ten – Injection

OWASP Top Ten – Injection

Today’s entry in the OWASP Top Ten series is Injection. If we are going to call a vulnerability a classic, this would be it. In the latest version of the OWASP Top Ten, the venerable vulnerability Cross Site Scripting has been combined with other classic injections, such as SQL injection, to form this powerhouse category.

Injection flaws can be as benign as simply defacing a web page, but at their most serious form, lead to full account and system compromise. The XSS to account and/or system takeover is one of Brackish Security’s favorite exploits. There are several variations of the theme, but this one is an XSS -> cross-site request forgery -> remote code execution via a malicious plugin upload.

A generalization of this, in layman’s terms would be, “A cross site scripting vulnerability is utilized to force an admin user to upload a plugin that can execute arbitrary code on the server.” Many content management systems (and other systems) have this type of functionality. If an attacker finds one XSS, the game is over.

Examples in Real Life

Injection flaws are often the method of attack when it comes to external defenses being compromised and/or data being dumped. Here are some links to some real life bugs found in production systems.

Here is an SQLi found in a Department of Defense asset.

https://hackerone.com/reports/771215

Or an SSTI at Uber

https://hackerone.com/reports/125980

Another SSTI at Shopify

https://hackerone.com/reports/423541

Mitigation

Nowadays, many frameworks provide input sanitization functions which ‘clean up’ all user input. These functions have improved over the years, and while every once in a blue moon a bypass is released, they are effectively 100% effective – if used correctly. SQL injection, for example, has been greatly reduced because many frameworks now provide SQL command parameterization or sanitization.

Additionally, static and dynamic analysis tools should be used as early as possible in the development process. Brackish even suggests that individual developers should be trained on these tools and required to use them to scan their own code on a regular basis. An organization can also enable these scans on every commit, if necessary, or on some other frequent cadence.

What Else?

Despite the existence of the sanitization functions in frameworks, it can be argued the injection is still king, when it comes to vulnerabilities. Brackish researchers still find them regularly while doing penetration tests and independent research (most recently this one).

Despite developer’s best efforts and despite the usage of static and dynamic analysis tools, injection flaws still exist in software. Not to mention, your organization may be using flawed third-party software. Source code analysis, penetration tests, and web application/API tests can help uncover these flaws and keep your organization protected. Contact Brackish today, and we can help keep you secure.