OWASP Tip: A03:2021 – Injection
i.e. Cross-Site Scripting (XSS), SQL injection (SQLi), and Command Injection
Greetings my friends! I hope last week’s Avoiding Cryptographic Failures Checklist was helpful and informative, and did anyone figure out what the subtitle said? This week we back with our next step in our journey through the OWASP Top 10 with A03:2021 – Injection. Injection is an area I often see when auditing apps1, and is something I’ve already covered quite extensively, so I’ll be proving some links to learn more, rather than rehashing existing posts.
👉 Want me to hack your app and work with you to help improve your security?
🕵️ Book a Laravel Security Audit and Penetration test!
Looking to learn more?
⏩ Security Tip #5: The Cookie ‘Secure’ Flag
▶️ In Depth #1: Encryption
A03:2021 – Injection
If you’re like me, the first things that come to mind when you see the word “Injection” are Cross-Site Scripting (XSS) and SQL Injection (SQLi). “Command Injection” should be in there too, but without a funky acronym, I often forget to list it! While this may not be what you immediately think of out of context of web security2, when you’re in that context, it should exactly what comes to mind.
Number 3 in the Top 10 is Injection, which covers XSS, SQLi, and Command Injection. Interestingly, the 2017 Top 10 featured “Injection” in the #1 position, covering SQLi and Command Injection3 and XSS separated out at #7. They were merged together and bumped down to #3. Which, given how easy injection can be to abuse, is a good sign how the industry is changing.
The OWASP Guide defines injection attacks as:
User-supplied data is not validated, filtered, or sanitized by the application.
Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter.
Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.
Hostile data is directly used or concatenated. The SQL or command contains the structure and malicious data in dynamic queries, commands, or stored procedures.
All of this can be summarised into 4 simple words4:
DON’T TRUST USER INPUT!
We’ve covered it many times in Laravel Security in Depth, and so much so that there are interactive challenges in our intentionally vulnerable webapp for SQLi and XSS, which you can and should go explore5.
To learn more about not trusting user input, check out these posts:
In Depth look at how to safely escape output safely, how XSS works, what escaping options are available in Laravel, and access details for the interactive XSS challenges.
Validating HTML & Markdown Input
Security Tip covering how to keep HTML and Markdown user input safe and avoid injection attacks.
In Depth look at how different forms of SQL Injection work (i.e. Basic, Union, Error, Timed, etc) how to avoid SQLi in your apps, and access details for the interactive SQLi challenges.
Security Tip to remind you to parameterise your database queries, and why. Leads into the SQL Injection In Depth post.
Security Tip around not trusting user input and using the Laravel validator.
Between those posts and the interactive challenges, you should have a good grasp on Injection and why it’s so important to be aware of, and why you should never trust user input! 😏
The top three feature heavily in sites I’ve audited.
My partner does tell me that I’m paranoid about security…
Oh I wish there was a nice acronym for this… 😭
If you’ve been to one of my talks before, you’ll recognise this!
The intentionally vulnerable webapp is great reason for becoming a paid subscriber, and I can only maintain and build it due to my wonderful paid subscribers. 🥰