API8:2019 - Injection
Tags: cybersecurity, hacking, api, owasp
Published: 2022-02-26 22:48:30

Well, well, well, what have we here? :monocle_face:

![The oogie boogie](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2xijjsbgaxmw6tdq2m9w.gif)
 
Injection, huh? Okay then. So that's what we are going to be talking about!

## :national_park: Looking at the Docs

We may say that dealing with user-controllable inputs is, essentially, part of what every single API does. Because of that, the documentation of libs/frameworks can have some notes like the following ones:

[Rails](https://guides.rubyonrails.org/security.html#intranet-and-admin-security) => `Having one single place in the admin interface or Intranet, where the input has not been sanitized, makes the entire application vulnerable. Possible exploits include stealing the privileged administrator's cookie, injecting an iframe to steal the administrator's password or installing malicious software through browser security holes to take over the administrator's computer.`

[Express](https://expressjs.com/en/5x/api.html#req) => `As req.body’s shape is based on user-controlled input, all properties and values in this object are untrusted and should be validated before trusting. For example, req.body.foo.toString() may fail in multiple ways, for example foo may not be there or may not be a string, and toString may not be a function and instead a string or other user-input.`

[Django](https://docs.djangoproject.com/en/4.0/topics/security/) => `Django also gives developers power to write raw queries or execute custom sql. These capabilities should be used sparingly and you should always be careful to properly escape any parameters that the user can control. In addition, you should exercise caution when using extra() and RawSQL.`

All this worry is because when we pick up any random input and use it in an application workflow without previous verification, anything can happen! :scream:

## :syringe: Example 1 - CVE-2021-44228

Surely y'all already know about Log4Shell, and it is a perfect example of what an injection can result in. Log4j 2, by default, performed string substitutions in its logs in order to execute expressions.

Because HTTP requests tend to be in logs, payloads containing JNDI lookups in the URL or in HTTP headers such as User-Agent could be being used in order to retrieve sensitive data or even get RCEs. :astonished:

## :syringe: Example 2 - Insecure Deserialization

Also known as **Object Injection**, this one is a great example too!

Some APIs have converting complex data structures to specific formats (binary or string ones) and vice versa as part of how they do their job. These processes are called serialization and deserialization.

When these APIs do the deserialization process without previous checks, even if the deserialized object won't have a use at all, there's always a chance of bad things happening. For example, prototype pollution can be the result of an insecure deserialization implementation!

## :books: External materials

As my goal with this series is to just explain what each flaw is, I would like to suggest what I used to learn more about injections, so you guys get better the details of it:

https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa8-injection.md

https://www.wallarm.com/what/api8-injection

https://apisecurity.io/encyclopedia/content/owasp/api8-injection.htm

https://cwe.mitre.org/data/definitions/77.html