SQL Injection (SQLi) attacks verhindern
SQLi injects malicious SQL durch Benutzer Eingabe. Lernen parameterized queries, Eingabe validation, und der Prinzip von least privilege.
- 1
SQLi occurs when user input is concatenated into SQL queries. Example: "SELECT * FROM users WHERE name = '" + input + "'" — input ' OR 1=1 -- returns all users. Prevention: (1) Parameterized queries / prepared statements (primary defense) — the query and data are sent separately, the database never interprets data as SQL. (2) Input validation (secondary). (3) Least privilege — database user can only do what it needs. (4) ORM with parameterized queries.
- 2 SQL-Formatierer →
Formatieren SQL queries to identify injection-prone patterns. Look for string concatenation ('...' + input + '...'), dynamic SQL (EXEC), and unparameterized queries. Format the query with placeholders (?, :name) to show the parameterized form.
- 3 Regex-Ersetzung →
Validieren and sanitize input before using it in queries. Whitelist allowed characters (alphanumeric for identifiers, specific patterns for dates/emails). Reject input that contains SQL metacharacters (', ", ;, --, /*, */). Note: validation is secondary — always use parameterized queries as the primary defense.
Häufige Fragen
- Are parameterized queries 100% safe?
- For data values, yes — the database treats parameters as data, never as SQL. However, parameterized queries cannot be used for identifiers (table names, column names) — those must be validated against a whitelist. Dynamic SQL (EXECUTE/EXEC) with concatenated identifiers is still vulnerable. Use ORM query builders or whitelist validation for identifiers.
- What is blind SQL injection?
- When the application does not return SQL errors or query results directly. The attacker infers information by observing behavior: boolean-based (page differs if condition is true/false), time-based (SLEEP() delays response if condition is true), out-of-band (DNS/HTTP exfiltration). Parameterized queries prevent all forms of SQLi, including blind.