SQL 삽입 방지
SQL 삽입의 작동 방식을 이해하고 매개변수화된 질의와 준비된 문을 사용하여 견고한 방어책을 구현합니다.
SQL 삽입 방지은(는) CoddyKit의 무료 Secure Coding & OWASP Top 10 for Backend 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Secure Coding & OWASP Top 10 for Backend 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Secure Coding & OWASP Top 10 for Backend 강의에는 총 4개의 강의가 포함되어 있습니다.
이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.
What is SQL Injection?
Imagine you're talking to a database using a special language called SQL. Sometimes, bad actors can trick your application into sending unexpected SQL commands to the database.
This trick is called SQL Injection (SQLi). It happens when user input is treated as part of the SQL command itself, rather than just data.
SQLi can lead to:
- Data theft or modification
- Bypassing login screens
- Gaining control over the database server
How SQLi Works: A Login Example
Let's say a login form takes your username and password. The application might build a SQL query like this to check if you exist:
SELECT * FROM users WHERE username = 'your_username' AND password = 'your_password';
What if 'your_username' isn't just a name, but also a piece of SQL code?
The Vulnerable Code
A common mistake is building SQL queries by directly combining (concatenating) user input with the query string. Here's a simplified example in Java:
public class Main {
public static void main(String[] args) {
String username = "admin"; // User input
String password = "pass123"; // User input
// DANGEROUS: String concatenation
String query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "';";
System.out.println("Executing query:\n" + query);
// In a real app, this query would go to the database.
}
}Crafting the Malicious Input
Now, imagine a malicious user enters this as their username:
admin' OR '1'='1
And any text for the password. When combined with the vulnerable query, it becomes:
SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = 'any_password';
The OR '1'='1' part makes the condition always true, effectively bypassing the password check and logging the attacker in!
Introducing Prepared Statements
The best defense against SQL Injection is using Prepared Statements (also known as Parameterized Queries).
They separate the SQL logic from the user-provided data. Instead of directly inserting input, you use placeholders (like ?) in your query.
The database then understands that anything provided for these placeholders is pure data, not part of the command.
Prepared Statements in Action
Here's how you'd use a prepared statement to safely query for a user by their ID. Notice the ? placeholder.
public class Main {
public static void main(String[] args) {
int userId = 123; // User input
// Secure: Using a placeholder for the value
String sql = "SELECT name, email FROM users WHERE id = ?;";
// In a real application, you'd 'prepare' this SQL
// and then 'set' the parameter value (userId) separately.
System.out.println("Prepared SQL: " + sql);
System.out.println("Parameter 1 (id): " + userId);
// The database treats 'userId' as a value, not SQL code.
}
}How Parameters Prevent SQLi
When you use a prepared statement:
- Separation of concerns: The SQL query structure is sent to the database first.
- Data vs. Code: The database 'pre-compiles' the query. Then, when you provide values for the placeholders, it treats them strictly as data.
- Automatic Escaping: The database automatically handles any special characters in your input, preventing them from being interpreted as SQL commands.
This ensures that malicious input like ' OR '1'='1 cannot alter the query's intent.
Securing the Login Example
Let's fix our vulnerable login example using prepared statements. Now, even if a user tries to inject SQL, it will be treated as part of their username/password, not as a command.
public class Main {
public static void main(String[] args) {
String username = "admin' OR '1'='1"; // Malicious input
String password = "any_password"; // Malicious input
// SECURE: Using prepared statement with placeholders
String sql = "SELECT * FROM users WHERE username = ? AND password = ?;";
// Simulating how parameters are set (conceptual)
System.out.println("Prepared SQL: " + sql);
System.out.println("Parameter 1 (username): " + username);
System.out.println("Parameter 2 (password): " + password);
System.out.println("\nDatabase will look for a user with the literal username 'admin' OR '1'='1' and the given password. This user likely won't exist. Attack thwarted!");
}
}Beyond Login: All SQL Operations
Prepared statements aren't just for SELECT queries. You should use them for ALL SQL operations that involve user input:
INSERTstatements (e.g., adding a new user)UPDATEstatements (e.g., changing a user's profile)DELETEstatements (e.g., removing data)
Always assume user input is malicious until proven otherwise. Parameterized queries are your first line of defense.
Quick Check: Secure Query
Which of the following code snippets correctly uses parameterized queries to prevent SQL Injection when searching for a product by name?
Recap: SQL Injection Prevention
Great job! In this lesson, you learned about:
- What SQL Injection is and its dangers.
- How vulnerable applications can be exploited by concatenating user input directly into SQL queries.
- The importance of using Prepared Statements (Parameterized Queries) as the primary defense mechanism.
- How prepared statements separate data from code, preventing malicious input from altering query logic.
Always use prepared statements for any SQL operation involving user input to keep your backend secure!
자주 묻는 질문
“SQL 삽입 방지” 강의는 무료인가요?
네 — “SQL 삽입 방지” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Secure Coding & OWASP Top 10 for Backend 강의 전체를 잠금 해제할 수 있습니다. Secure Coding & OWASP Top 10 for Backend 강의에는 총 4개의 강의가 포함되어 있습니다.
“SQL 삽입 방지”에서 뭘 배우나요?
SQL 삽입의 작동 방식을 이해하고 매개변수화된 질의와 준비된 문을 사용하여 견고한 방어책을 구현합니다. 브라우저에서 직접 실행하는 실습 코드로 Secure Coding & OWASP Top 10 for Backend을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
Secure Coding & OWASP Top 10 for Backend을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 Secure Coding & OWASP Top 10 for Backend은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.
“SQL 삽입 방지” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 Secure Coding & OWASP Top 10 for Backend 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 Secure Coding & OWASP Top 10 for Backend 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.