Injection flaws (SQL, command) and closing them
Why command and SQL injection happen, their trace in logs and the lasting fix.
Level 201 · 18 lessons · 15 practice labs
Lessons
The root of injection
- What injection is: data mixed with commands: You will understand that injection happens when an application treats user-supplied data as a command, and why that is dangerous.
- Testing your own application: tools and limits: You will learn which tools and which limits to use when testing your own application for injection flaws.
- Dangerous sinks: where injection enters the code
- Short task: mark where input is mixed into a query or command in the lab code
SQL injection
- Anatomy of SQL injection: You will understand how SQL injection arises from gluing query text together and what it can do to a database.
- Recognising an SQL error with Burp Repeater
- Fixing it with parameterised queries: You will apply parameterised queries in your own code and see how keeping data apart from commands removes SQL injection at the root.
- Cutting the database account to least privilege: You will see how limiting a database account to only the rights it needs reduces the damage even if a flaw exists.
- Verifying a fix in your own app with sqlmap: You will confirm with sqlmap, using careful settings in your own test environment, that a query you fixed is no longer injectable.
- Short task: close the SQL injection in the search page and verify with sqlmap
Command and NoSQL injection
- Anatomy of command injection: You will learn which coding mistake leads to command injection and how to recognise that mistake in code.
- Closing command injection: You will close command injection for good by using safe methods that avoid the shell and by checking input strictly.
- NoSQL injection: blocking operator input in MongoDB queries: You will notice when user input turns into an operator inside a MongoDB query and close it with type checks and schema validation.
- Input validation and escaping: You will learn when input validation and escaping help, why they are not enough alone, and where to use them properly.
- Short task: close the command and NoSQL injections and retest both
Detection and retest
- Injection traces in logs and alerts: You will recognise the traces of injection attempts in application and server logs and think up an alert rule for them.
- Writing tests that stop injection coming back
- Capstone: find and close the injection flaws in an application: In the capstone you will find the injection flaws in a fictional company's small application and report their lasting fixes.
Practice labs
- String concatenation in the search page: Find the line in the search page code where input is concatenated into the query and fix it with a parameterised query.
- Recognise the SQL error in Repeater: Show in Repeater that special characters sent to the order filter produce a SQL error and stop the error from reaching users.
- The app account can write to every table: List the excess privileges of the app's database account, define a separate read-only account for reporting and narrow the grants.
- Verify the fix with sqlmap: Retest an endpoint you fixed with sqlmap on limited settings and keep the before-and-after output as evidence.
- Injection in a sort parameter: Prove injection in a sort field that cannot be parameterised and close it by restricting column names to an allow list.
- Command injection in a file converter: Prove the flaw in a converter that passes the file name to a shell command and change the call to a shell-free argument list.
- Blind command injection in a DNS lookup tool: Confirm command injection in a DNS lookup tool that shows no output by a timing difference, fix the code and retest.
- Input validation or escaping: Try both validation and escaping for the command call in the backup page and show with a test which one is sufficient and why.
- A regression test for command injection: Write unit tests that try bad inputs against the command injection you closed and show that a change reintroducing the flaw fails the tests.
- A MongoDB operator in the login form: Prove that sending an operator object in the JSON login request skips authentication and force the fields to string type.
- Data leak through $regex in a search filter: Show that the search filter accepts user-supplied operators and add schema validation that rejects operator keys.
- Close NoSQL and SQL injection in the same service: Find both injections in a service that uses two databases, close both and verify again with a single test suite.
- Injection attempts in the access log: Decode a URL-encoded access log to find injection attempts and list which parameters were targeted.
- The attacking request from the database error log: Match syntax errors in the database error log with the web log and find the request and client that produced them.
- An injection alert rule and its false positives: Write a log rule that catches injection attempts, weed out false positives from legitimate searches and test the rule with replayed traffic.
About this course
Why command and SQL injection happen, their trace in logs and the lasting fix.
What you will learn
- The root of injection
- SQL injection
- Command and NoSQL injection
- Detection and retest
Prerequisites
Finishing the level 101 courses of the same path, or knowing those topics, is enough.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 201; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.