--- id: sql-injection title: "SQL Injection" category: "Database" status: "draft" verification_status: "conceptual" canonical_id: "" aliases: ["SQL μΈμ μ…˜"] duplicate_of: "" source_trust_level: "B" confidence_score: 0.87 created_at: 2026-07-04 updated_at: 2026-07-04 review_reason: "" merge_history: [] tags: ["sql", "database", "w3schools", "security", "injection"] raw_sources: ["https://www.w3schools.com/sql/sql_injection.asp"] applied_in: [] github_commit: "" --- # [[SQL Injection]] ## 🎯 ν•œ 쀄 톡찰 (One-line insight) SQL injection exploits raw string concatenation of user input into a query β€” a tautology like `OR 1=1` or a batched `; DROP TABLE ...` can turn a single-row lookup into a full-table dump or destructive command. [S1] ## 🧠 핡심 κ°œλ… (Core concepts) - **SQL injection** β€” a code injection technique where attackers insert malicious SQL into user-input fields to read, modify, or delete sensitive data. [S1] - **Root cause** β€” building SQL strings by concatenating raw user input, e.g. `txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;`. [S1] - **Tautology injection (`1=1`)** β€” input like `105 OR 1=1` makes the WHERE clause always true, returning every row. [S1] - **Tautology injection (`""=""`)** β€” the same idea applied to string-quoted login fields (`" OR ""="`), bypassing username/password checks entirely. [S1] - **Batched statement injection** β€” a semicolon lets an attacker append an entirely separate destructive statement, e.g. `UserId = 105; DROP TABLE Suppliers;`. [S1] ## 🧩 μΆ”μΆœλœ νŒ¨ν„΄ (Extracted patterns) - **Never trust concatenated input** β€” every example in the source traces back to the same root cause: building a SQL string by directly concatenating unescaped, unvalidated user input. [S1] - **The fix lives in the next two chapters** β€” the source explicitly defers the mitigation (SQL Parameters, SQL Prepared Statements) rather than covering it here. [S1] ## πŸ“– μ„ΈλΆ€ λ‚΄μš© (Details) - Vulnerable pattern: `txtUserId = getRequestString("UserId"); txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;`. [S1] - Tautology exploit: input `105 OR 1=1` yields `SELECT * FROM Users WHERE UserId = 105 OR 1=1;`, returning ALL rows. [S1] - Login bypass exploit: input `" OR ""="` on both fields yields `SELECT * FROM Users WHERE Name ="" or ""="" AND Pass ="" or ""=""`, which is always true. [S1] - Batched destructive exploit: `SELECT * FROM Users WHERE UserId = 105; DROP TABLE Suppliers;`. [S1] ## βš–οΈ λͺ¨μˆœ 및 μ—…λ°μ΄νŠΈ (Contradictions & updates) μ†ŒμŠ€μ—μ„œ λͺ¨μˆœλ˜λŠ” μ •λ³΄λŠ” λ°œκ²¬λ˜μ§€ μ•ŠμŒ. ## πŸ› οΈ 적용 사둀 (Applied in summary) ν˜„μž¬ 발견된 μ‹€μ œ 적용 사둀가 μ—†μŠ΅λ‹ˆλ‹€ β€” λ‹€μŒ 두 챕터(SQL Parameters, SQL Prepared Statements)κ°€ 이 문제의 μ‹€μ œ 해결책을 μ œμ‹œν•œλ‹€. [S1] ## πŸ’» μ½”λ“œ νŒ¨ν„΄ (Code patterns) Vulnerable string-concatenation pattern (illustrative, NOT recommended): ``` txtUserId = getRequestString("UserId"); txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId; ``` ## βœ… 검증 μƒνƒœ 및 신뒰도 - **μƒνƒœ:** draft - **검증 단계:** conceptual - **좜처 신뒰도:** B (W3Schools β€” widely used educational reference, not a primary standards body) - **μ‹ λ’° 점수:** 0.87 - **쀑볡 검사 κ²°κ³Ό:** μ‹ κ·œ 생성 (New discovery) ## πŸ”— 지식 κ·Έλž˜ν”„ (Knowledge Graph) - **μƒμœ„/루트:** [[SQL Tutorial]] - **κ΄€λ ¨ κ°œλ…:** [[SQL Parameters]], [[SQL Prepared Statements]] - **μ°Έμ‘° λ§₯락:** μ‚¬μš©μž μž…λ ₯을 λ‹€λ£¨λŠ” λͺ¨λ“  쿼리 μž‘μ„± μ „ λ°˜λ“œμ‹œ 인지해야 ν•  λ³΄μ•ˆ μœ„ν˜‘ β€” 해결책은 λ‹€μŒ 두 챕터. ## πŸ“š 좜처 (Sources) - [S1] W3Schools β€” SQL Injection β€” https://www.w3schools.com/sql/sql_injection.asp ## πŸ“ λ³€κ²½ 이λ ₯ (Change history) - 2026-07-04: Initial draft synthesized from the W3Schools "SQL Injection" page (Astra wiki-curation, P-Reinforce v3.1 format).