Web Security Series #9 — Exploiting Second-Order SQL Injection via Stored User Input

Web Security Series #9 — Exploiting Second-Order SQL Injection via Stored User Input | by Laibakashif - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original Web Security Series #9 — Exploiting Second-Order SQL Injection via Stored User Input SQL Injection is widely known as one of the most dangerous vulnerabilities in web applications. Most testers focus on first-order SQL… Laibakashif Follow ~5 min read · March 25, 2026 (Updated: March 25, 2026) · Free: Yes SQL Injection is widely known as one of the most dangerous vulnerabilities in web applications. Most testers focus on first-order SQL injection , where malicious input is executed immediately after submission. However, in many real-world applications, user input is first stored in the database and later reused in SQL queries. This scenario introduces a more subtle and often overlooked vulnerability known as Second-Order SQL Injection . In this write-up, I demonstrate how a SQL injection payload inserted during user registration can remain harmless initially but later execute when the application reuses that stored input during the login process , ultimately revealing hidden data from the database. When to Use Second-order SQL Injection testing is performed when: Applications store user-controlled input such as usernames, emails, bios, or preferences. Stored values are later reused in internal SQL queries . The application trusts previously stored input. First-order SQL injection attempts fail or appear filtered. This type of testing typically occurs during advanced exploitation and deep application analysis . Objective The goal of this lab is to: Understand how second-order SQL injection works. Insert a SQL payload during the Sign Up process . Observe how the payload remains inactive at registration. Trigger the injection later during Login . Reveal hidden Bio information from the application. Prerequisites To perform this lab, the following knowledge and tools are helpful: Basic understanding of SQL Injection Understanding of SQL logic and comments Ability to analyze application behavior Access to the vulnerable lab environment Lab Overview This lab includes two core functionalities: Sign Up Stores user credentials in the database. Login Uses stored values to authenticate the user and display account details. An important observation in this lab is that: The Bio field exists in the database , but it is not displayed under normal conditions . Our goal is to trigger the application to reveal this hidden data. Steps (Detailed Walkthrough) 1 — Understanding Normal Application Behavior Before attempting any attack, we first observe how the application works under normal conditions. Create a test account using: testing : testing Then log in using the same credentials. Observation Login works successfully. The user dashboard loads normally. The Bio field is not displayed . This confirms the expected behavior before exploitation. 2 — Inject Payload During Sign Up Now we attempt a second-order SQL injection by inserting a malicious payload during the registration phase. Payload used: 'or 1=1-- - : test This means: Username: 'or 1=1-- - Password: test What Happens Here At the time of sign up: The payload is not executed . It is simply stored inside the database . The application treats it as a normal string. The account is created successfully, which is expected. This is a key indicator of second-order injection potential . 3 — Trigger the Stored Injection During Login Now we log in using the stored malicious credentials. username: 'or 1=1-- - password: test Observation After logging in: The SQL payload executes. The application behavior changes. The previously hidden Bio information is now revealed . This confirms that the stored payload was executed during the login process. Evidence of Second-Order SQL Injection The attack works because the application: ✔ Stores user input without proper validation ✔ Reuses stored input in SQL queries ✔ Does not sanitize the stored value before execution As a result, the injected SQL logic becomes active later in the application workflow. This confirms the presence of Second-Order SQL Injection . Why the Attack Works The vulnerability occurs due to how the application processes stored data. Step-by-step explanation: During Sign Up , the payload is saved in the database as a normal string. The application assumes stored data is safe and does not sanitize it. During Login , the application constructs a SQL query using the stored value. The query effectively becomes: SELECT * FROM users WHERE username = '' or 1=1-- -' AND password='test'; Here's what happens: 1=1 makes the condition always true. -- comments out the remaining part of the query. The SQL query returns unintended records. Because of this, the application exposes additional data such as the Bio field , which was not visible previously. This demonstrates a classic Second-Order SQL Injection attack . Key Characteristics of Second-Order SQL Injection Second-order SQL injection typically involves: Stored attacker-controlled input Later execution of that stored input Unsafe SQL query construction Lack of input validation or prepared statements These vulnerabilities are often harder to detect because the injection does not occur immediately. Mitigation Strategies To prevent Second-Order SQL Injection , developers should implement the following security practices: Use prepared statements (parameterized queries) for all database interactions. Sanitize and validate user input both before storing and before using it in queries . Never trust data retrieved from the database as inherently safe. Apply input validation and output encoding consistently across the application. Implement proper secure coding practices when handling authentication logic. Perform regular security testing and code reviews . Conclusion This lab demonstrated how SQL injection attacks can occur even when malicious input does not execute immediately. Second-order SQL injection highlights a critical security lesson: stored data should never be trusted blindly . By understanding how these attacks work, security professionals and developers can better identify hidden vulnerabilities and strengthen application security. Connect With Me If you found this write-up helpful, feel free to follow my cybersecurity learning journey. 🔗 LinkedIn: www.linkedin.com/in/laibakashif0011 #cybersecurity #sql-injection #ethical-hacking #web-application-security #bug-bounty Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).