💀 SQL Injection이 뭔데 이렇게 난리야?

야 솔직히 말해서 ㅋㅋㅋ SQL Injection은 진짜 개발자들한테는 악몽 그 자체임 😱
2023년 기준으로도 OWASP Top 10 보안 취약점에서 여전히 상위권을 차지하고 있는 공격 기법이거든?

간단하게 설명하면, 해커가 웹 애플리케이션의 입력 필드에 악의적인 SQL 코드를 집어넣어서
데이터베이스를 마음대로 조작하는 공격 방식이야. 진짜 무섭지 않냐고 ㅠㅠ

근데 말이야, 이게 왜 이렇게 위험하냐면...
일반적인 해킹은 시스템 침투가 어려운데, SQL Injection은 그냥 웹사이트 로그인 창이나 검색창 같은
누구나 접근 가능한 입력 필드를 통해 공격할 수 있다는 거지 🎯

마치 정문으로 당당하게 걸어 들어가는 느낌? ㅋㅋㅋ 보안 담당자 입장에선 진짜 열받는 상황임

🔍 SQL Injection 공격 원리 파헤치기

자 이제 본격적으로 들어가볼까? 🤓
SQL Injection이 어떻게 작동하는지 알아야 방어도 제대로 할 수 있으니까!

일반적인 로그인 쿼리를 생각해보자. 개발자가 이렇게 코드를 짰다고 가정해볼게:

String query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";

정상적인 사용자라면 username에 "hong", password에 "1234"를 입력하겠지?
그럼 실제 실행되는 SQL은 이렇게 됨:

SELECT * FROM users WHERE username = 'hong' AND password = '1234'

SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = '아무거나'

ㅋㅋㅋㅋ 봤지? '1'='1'은 항상 참이니까
비밀번호 체크는 의미가 없어지고 그냥 admin 계정으로 로그인이 되어버리는 거야 😈

이게 바로 가장 기본적인 SQL Injection 공격 원리임!

근데 진짜 무서운 건 여기서부터야... 해커들은 단순히 로그인만 뚫는 게 아니라
데이터베이스 전체를 장악할 수도 있거든 💣

🛡️ 핵심 방어 기법 총정리

자 이제 진짜 중요한 파트다! 🔥
SQL Injection을 막는 방법들을 하나씩 제대로 알아보자구~

참고로 이런 보안 지식은 재능넷 같은 플랫폼에서도 엄청 인기 있는 주제임
실무에서 바로 써먹을 수 있는 기술이니까 ㅇㅈ?

솔직히 말해서 이거 하나만 제대로 써도 SQL Injection의 99%는 막을 수 있음 ㄹㅇ 💪

Prepared Statement는 SQL 쿼리의 구조와 데이터를 완전히 분리하는 방식이야.
쿼리 템플릿을 먼저 컴파일하고, 나중에 사용자 입력을 파라미터로 바인딩하는 거지.

// ❌ 취약한 코드
String query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(query);

// ✅ 안전한 코드
String query = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement pstmt = connection.prepareStatement(query);
pstmt.setString(1, username);  // 첫 번째 ? 에 username 바인딩
pstmt.setString(2, password);  // 두 번째 ? 에 password 바인딩
ResultSet rs = pstmt.executeQuery();

# ❌ 취약한 코드
cursor.execute(f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'")

# ✅ 안전한 코드
cursor.execute("SELECT * FROM users WHERE username = ? AND password = ?", (username, password))

// ❌ 취약한 코드
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = mysqli_query($conn, $query);

// ✅ 안전한 코드
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username AND password = :password");
$stmt->bindParam(':username', $username);
$stmt->bindParam(':password', $password);
$stmt->execute();

// ❌ 취약한 코드
const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;
connection.query(query, (error, results) => { ... });

// ✅ 안전한 코드
const query = 'SELECT * FROM users WHERE username = ? AND password = ?';
connection.query(query, [username, password], (error, results) => { ... });

왜 이게 안전하냐면? 🤔

Prepared Statement를 사용하면 사용자 입력이 무조건 데이터로만 처리되기 때문이야.
아무리 ' OR '1'='1 같은 걸 입력해도, 그냥 문자열 데이터로 인식되는 거지.
SQL 명령어로 해석되지 않는다는 게 핵심!

요즘 개발자들은 직접 SQL 쿼리 짜는 것보다 ORM을 많이 쓰잖아? ㅇㅇ
Hibernate, JPA, Django ORM, Sequelize 같은 거 말이야 🎯

ORM을 제대로 사용하면 내부적으로 Prepared Statement를 사용하기 때문에
SQL Injection 위험이 크게 줄어들어!

// ✅ 안전한 방법
@Query("SELECT u FROM User u WHERE u.username = :username AND u.password = :password")
User findByUsernameAndPassword(@Param("username") String username, @Param("password") String password);

// 또는 메서드 이름 기반 쿼리
User findByUsernameAndPassword(String username, String password);

# ✅ 안전한 방법
user = User.objects.filter(username=username, password=password).first()

# ❌ 위험한 방법 (raw SQL 사용 시)
user = User.objects.raw(f"SELECT * FROM users WHERE username = '{username}'")

# ✅ raw SQL 사용해야 한다면 이렇게
user = User.objects.raw("SELECT * FROM users WHERE username = %s", [username])

// ✅ 안전한 방법
const user = await User.findOne({
  where: {
    username: username,
    password: password
  }
});

// ❌ 위험한 방법
const users = await sequelize.query(`SELECT * FROM users WHERE username = '${username}'`);

// ✅ raw query 사용해야 한다면 이렇게
const users = await sequelize.query(
  'SELECT * FROM users WHERE username = :username',
  { replacements: { username: username } }
);

Prepared Statement가 최강이긴 한데, 그래도 입력 검증은 기본 중의 기본이야 ㅇㅇ
다층 방어(Defense in Depth) 전략의 일환으로 반드시 해야 함! 🛡️

// 사용자명은 영문자와 숫자만 허용, 3-20자
if (!username.matches("^[a-zA-Z0-9]{3,20}$")) {
    throw new IllegalArgumentException("Invalid username format");
}

// 정렬 컬럼은 미리 정의된 값만 허용
String[] allowedColumns = {"name", "date", "price"};
if (!Arrays.asList(allowedColumns).contains(sortColumn)) {
    throw new IllegalArgumentException("Invalid sort column");
}

// ❌ 이런 방식은 우회가 쉬움
String cleaned = input.replaceAll("'", "");  // 작은따옴표만 제거
String cleaned = input.replaceAll("--", "");  // 주석만 제거

// 해커는 이렇게 우회 가능:
// ' 대신 %27 (URL 인코딩)
// -- 대신 /**/ (다른 주석 방식)
// OR 대신 ||

저장 프로시저도 SQL Injection 방어에 효과적일 수 있어 📦
단, 프로시저 내부에서 동적 SQL을 안전하게 작성해야 한다는 전제 조건이 있음!

-- ✅ 안전한 저장 프로시저 예제 (MySQL)
DELIMITER //
CREATE PROCEDURE GetUserByCredentials(
    IN p_username VARCHAR(50),
    IN p_password VARCHAR(255)
)
BEGIN
    SELECT * FROM users 
    WHERE username = p_username 
    AND password = p_password;
END //
DELIMITER ;

-- 호출 (Java 예제)
CallableStatement cstmt = connection.prepareCall("{call GetUserByCredentials(?, ?)}");
cstmt.setString(1, username);
cstmt.setString(2, password);
ResultSet rs = cstmt.executeQuery();

-- ❌ 위험한 저장 프로시저
CREATE PROCEDURE UnsafeSearch(IN search_term VARCHAR(100))
BEGIN
    SET @query = CONCAT('SELECT * FROM products WHERE name LIKE ''%', search_term, '%''');
    PREPARE stmt FROM @query;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END;

프로시저 안에서도 동적 SQL 만들 때는 파라미터 바인딩을 써야 한다는 거! ⚡

이거 진짜 많이 놓치는 부분인데 ㅋㅋㅋ
에러 메시지에서 DB 구조나 쿼리 정보가 노출되면 해커한테 힌트를 주는 꼴이야 🙈

MySQL Error: You have an error in your SQL syntax near 'admin' OR '1'='1' at line 1
Table 'users' doesn't exist in database 'myapp_production'
Column 'credit_card_number' cannot be null

로그인에 실패했습니다. 다시 시도해주세요.
요청을 처리하는 중 오류가 발생했습니다.
잘못된 요청입니다.

상세한 에러 정보는 서버 로그에만 기록하고, 사용자한테는 일반적인 메시지만 보여주는 게 정석! 📝

DB 계정에 필요 이상의 권한을 주지 말자는 거야 🔐

예를 들어 웹 애플리케이션이 단순히 데이터 조회만 하는 기능이라면
굳이 DELETE, DROP 같은 권한을 줄 필요가 없잖아?

-- 읽기 전용 계정
CREATE USER 'webapp_read'@'localhost' IDENTIFIED BY 'strong_password';
GRANT SELECT ON myapp.* TO 'webapp_read'@'localhost';

-- 쓰기 가능 계정 (필요한 테이블만)
CREATE USER 'webapp_write'@'localhost' IDENTIFIED BY 'strong_password';
GRANT SELECT, INSERT, UPDATE ON myapp.orders TO 'webapp_write'@'localhost';
GRANT SELECT, INSERT, UPDATE ON myapp.order_items TO 'webapp_write'@'localhost';

-- ❌ 이렇게 하지 말 것
GRANT ALL PRIVILEGES ON *.* TO 'webapp'@'localhost';

만약 SQL Injection 공격이 성공하더라도, 계정 권한이 제한되어 있으면
피해 범위를 최소화할 수 있어! 이게 바로 다층 방어 전략의 핵심이야 🎯

WAF는 웹 애플리케이션 앞단에서 악의적인 트래픽을 차단하는 방화벽이야 🔥

대표적인 WAF 솔루션:

WAF는 알려진 SQL Injection 패턴을 실시간으로 탐지하고 차단할 수 있어.
하지만 이것도 완벽하진 않으니까 코드 레벨의 방어와 함께 사용해야 함! 💪

🔬 실전 테스트 및 검증 방법

자 이제 방어 기법은 다 배웠으니, 실제로 잘 적용됐는지 테스트해봐야겠지? 🧪

보안 테스트는 반드시 허가된 환경에서만 진행해야 해!
남의 사이트 테스트하다가 불법 해킹으로 걸릴 수 있으니까 조심 ㅋㅋㅋ

' OR '1'='1
' OR '1'='1' --
' OR '1'='1' /*
admin' --
admin' #
' UNION SELECT NULL--
' UNION SELECT NULL, NULL--
1' ORDER BY 1--
1' ORDER BY 2--
1' ORDER BY 3--

이런 입력에 대해 정상적으로 에러 처리가 되거나 차단되면 OK! ✅
만약 이상한 동작을 하거나 DB 에러가 노출되면 취약한 거야 ⚠️

' AND SLEEP(5)--
1' AND (SELECT * FROM (SELECT(SLEEP(5)))a)--
'; WAITFOR DELAY '00:00:05'--

이런 입력 후 응답이 5초 지연되면 취약한 거임!

수동 테스트는 시간이 오래 걸리니까, 자동화 도구를 활용하는 것도 좋은 방법이야 🤖

테스트 도구도 좋지만, 가장 확실한 건 코드 리뷰야! 👀
다음 체크리스트를 활용해서 코드를 점검해보자:

🎓 프레임워크별 보안 가이드

각 프레임워크마다 SQL Injection 방어 방법이 조금씩 다르니까
주요 프레임워크별로 정리해봤어! 📚

// ✅ 안전한 방법
String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
List<User> users = jdbcTemplate.query(sql, 
    new Object[]{username, password},
    new BeanPropertyRowMapper<>(User.class));

// ✅ NamedParameterJdbcTemplate (더 가독성 좋음)
String sql = "SELECT * FROM users WHERE username = :username AND password = :password";
MapSqlParameterSource params = new MapSqlParameterSource();
params.addValue("username", username);
params.addValue("password", password);
List<User> users = namedParameterJdbcTemplate.query(sql, params, 
    new BeanPropertyRowMapper<>(User.class));

// ✅ 메서드 이름 기반 쿼리 (가장 안전)
public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByUsernameAndPassword(String username, String password);
}

// ✅ @Query 어노테이션 (JPQL)
@Query("SELECT u FROM User u WHERE u.username = :username AND u.password = :password")
Optional<User> findByCredentials(@Param("username") String username, 
                                  @Param("password") String password);

// ❌ 위험한 방법
@Query(value = "SELECT * FROM users WHERE username = '" + username + "'", nativeQuery = true)
List<User> unsafeMethod(String username);

# ✅ 안전한 방법
user = User.objects.filter(username=username, password=password).first()

# ✅ Q 객체 사용
from django.db.models import Q
users = User.objects.filter(Q(username=username) & Q(password=password))

# ✅ extra() 메서드 (파라미터 바인딩)
users = User.objects.extra(
    where=['username = %s AND password = %s'],
    params=[username, password]
)

# ❌ 위험한 방법
users = User.objects.raw(f"SELECT * FROM users WHERE username = '{username}'")

# ✅ raw() 사용해야 한다면 이렇게
users = User.objects.raw("SELECT * FROM users WHERE username = %s", [username])

// ✅ Prepared Statement
const [rows] = await connection.execute(
    'SELECT * FROM users WHERE username = ? AND password = ?',
    [username, password]
);

// ✅ Named placeholders
const [rows] = await connection.execute(
    'SELECT * FROM users WHERE username = :username AND password = :password',
    { username, password }
);

// ❌ 위험한 방법
const query = `SELECT * FROM users WHERE username = '${username}'`;
const [rows] = await connection.query(query);

// ✅ 안전한 방법
const user = await User.findOne({
    where: {
        username: username,
        password: password
    }
});

// ✅ Op 연산자 사용
const { Op } = require('sequelize');
const users = await User.findAll({
    where: {
        [Op.and]: [
            { username: username },
            { password: password }
        ]
    }
});

// ❌ 위험한 방법
const users = await sequelize.query(
    `SELECT * FROM users WHERE username = '${username}'`
);

// ✅ raw query 사용해야 한다면
const users = await sequelize.query(
    'SELECT * FROM users WHERE username = :username',
    {
        replacements: { username: username },
        type: QueryTypes.SELECT
    }
);

// ✅ 안전한 방법
$user = User::where('username', $username)
            ->where('password', $password)
            ->first();

// ✅ Query Builder
$users = DB::table('users')
           ->where('username', $username)
           ->where('password', $password)
           ->get();

// ❌ 위험한 방법
$users = DB::select("SELECT * FROM users WHERE username = '$username'");

// ✅ raw query 사용해야 한다면
$users = DB::select('SELECT * FROM users WHERE username = ?', [$username]);

// ✅ Named binding
$users = DB::select('SELECT * FROM users WHERE username = :username', 
                    ['username' => $username]);

// ✅ LINQ (가장 안전)
var user = context.Users
    .Where(u => u.Username == username && u.Password == password)
    .FirstOrDefault();

// ✅ FromSqlRaw (파라미터 바인딩)
var users = context.Users
    .FromSqlRaw("SELECT * FROM Users WHERE Username = {0} AND Password = {1}", 
                username, password)
    .ToList();

// ✅ FromSqlInterpolated (보간 문자열)
var users = context.Users
    .FromSqlInterpolated($"SELECT * FROM Users WHERE Username = {username}")
    .ToList();

// ❌ 위험한 방법
var query = $"SELECT * FROM Users WHERE Username = '{username}'";
var users = context.Users.FromSqlRaw(query).ToList();

// ✅ SqlCommand with Parameters
using (SqlCommand cmd = new SqlCommand(
    "SELECT * FROM Users WHERE Username = @username AND Password = @password", 
    connection))
{
    cmd.Parameters.AddWithValue("@username", username);
    cmd.Parameters.AddWithValue("@password", password);
    
    using (SqlDataReader reader = cmd.ExecuteReader())
    {
        // 결과 처리
    }
}

🚀 고급 방어 전략

기본 방어 기법은 다 배웠으니, 이제 좀 더 고급 기법들을 알아보자! 🎯
실무에서 진짜 프로처럼 보안을 챙기려면 이런 것들도 알아야 해 ㅇㅇ

Database Activity Monitoring은 DB에 대한 모든 접근과 쿼리를 실시간으로 감시하는 시스템이야 👁️

RASP는 애플리케이션 내부에서 실시간으로 공격을 탐지하고 차단하는 기술이야 🛡️
WAF보다 더 정교하게 공격을 막을 수 있어!

만약 SQL Injection 공격이 성공하더라도, 데이터가 암호화되어 있으면
해커가 실제 정보를 읽을 수 없어! 🔐

-- 암호화하여 저장
INSERT INTO users (username, email, credit_card) 
VALUES ('hong', 'hong@example.com', AES_ENCRYPT('1234-5678-9012-3456', 'encryption_key'));

-- 복호화하여 조회
SELECT username, email, AES_DECRYPT(credit_card, 'encryption_key') as credit_card
FROM users 
WHERE username = ?;

허니팟은 일부러 취약해 보이는 가짜 시스템을 만들어서
해커를 유인하고 공격 패턴을 분석하는 기법이야 ㅋㅋㅋ 진짜 똑똑하지? 🍯

직접적인 SQL Injection 방어는 아니지만, 전체적인 보안 강화에 도움이 돼 🔧

// Express.js 예제
const helmet = require('helmet');
app.use(helmet());

// 또는 수동 설정
app.use((req, res, next) => {
    res.setHeader('X-Content-Type-Options', 'nosniff');
    res.setHeader('X-Frame-Options', 'DENY');
    res.setHeader('X-XSS-Protection', '1; mode=block');
    res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
    res.setHeader('Content-Security-Policy', "default-src 'self'");
    next();
});

아무리 완벽하게 구축해도 시간이 지나면 새로운 취약점이 생길 수 있어 ⏰
정기적인 보안 감사는 필수야!

💼 실무 적용 가이드

이론은 충분히 배웠으니 이제 실무에 어떻게 적용할지 알아보자! 🚀

사실 재능넷 같은 플랫폼에서도 DB 보안 컨설팅이나 코드 리뷰 서비스가 인기 있는데
그만큼 실무에서 제대로 적용하기가 쉽지 않다는 거지 ㅠㅠ

기존 시스템을 개선하는 건 더 어려워 ㅋㅋㅋ
한 번에 다 바꿀 수 없으니까 우선순위를 정해서 단계적으로 진행해야 해 📊

아무리 좋은 기술을 도입해도 팀원들이 제대로 이해하고 사용하지 못하면 소용없어 👥
보안은 결국 사람이 만드는 거니까!

실무에서 바로 사용할 수 있는 체크리스트를 만들어봤어! 📋
이거 프린트해서 책상에 붙여놓고 개발할 때마다 확인하면 좋음 ㅋㅋ

## SQL Injection 보안 체크리스트

### 필수 항목 (하나라도 통과 못하면 Reject)
- [ ] 모든 SQL 쿼리가 Prepared Statement 또는 ORM 사용
- [ ] 문자열 연결로 쿼리 생성하는 코드 없음
- [ ] 사용자 입력이 직접 쿼리에 삽입되지 않음

### 권장 항목
- [ ] 입력 검증 로직 존재
- [ ] 화이트리스트 기반 검증 사용
- [ ] 에러 메시지에 DB 정보 노출 없음
- [ ] 적절한 로깅 구현
- [ ] 단위 테스트 포함

### 추가 확인 사항
- [ ] 동적 쿼리 생성 시 안전한 방법 사용
- [ ] ORM raw query 사용 시 파라미터 바인딩 확인
- [ ] 저장 프로시저 사용 시 내부 동적 SQL 안전성 확인

### 코멘트
(리뷰어 의견 작성)

🎯 실전 시나리오 및 해결책

이론만 알면 뭐해 ㅋㅋ 실전에서 어떻게 적용하는지가 중요하지!
자주 마주치는 시나리오들과 해결 방법을 알아보자 💡

// 사용자가 정렬 컬럼을 선택할 수 있는 기능
String sortColumn = request.getParameter("sort"); // "name", "date", "price" 등
String query = "SELECT * FROM products ORDER BY " + sortColumn;

이렇게 하면 해커가 sort=name; DROP TABLE products-- 이런 식으로 공격 가능 😱

// 화이트리스트 방식
String sortColumn = request.getParameter("sort");
List<String> allowedColumns = Arrays.asList("name", "date", "price");

if (!allowedColumns.contains(sortColumn)) {
    sortColumn = "name"; // 기본값
}

String query = "SELECT * FROM products ORDER BY " + sortColumn;
// 이제 안전! sortColumn은 검증된 값만 들어감

String keyword = request.getParameter("keyword");
String query = "SELECT * FROM products WHERE name LIKE '%" + keyword + "%'";

// Java
String keyword = request.getParameter("keyword");
String query = "SELECT * FROM products WHERE name LIKE ?";
PreparedStatement pstmt = connection.prepareStatement(query);
pstmt.setString(1, "%" + keyword + "%"); // % 기호는 코드에서 추가

// Python
keyword = request.args.get('keyword')
cursor.execute("SELECT * FROM products WHERE name LIKE ?", (f"%{keyword}%",))

// Node.js
const keyword = req.query.keyword;
const query = 'SELECT * FROM products WHERE name LIKE ?';
connection.query(query, [`%${keyword}%`], (error, results) => { ... });

// 여러 개의 ID를 받아서 조회
String ids = request.getParameter("ids"); // "1,2,3,4,5"
String query = "SELECT * FROM products WHERE id IN (" + ids + ")";

// Java
String[] idArray = request.getParameter("ids").split(",");
List<Integer> ids = new ArrayList<>();

// 입력 검증 및 변환
for (String id : idArray) {
    try {
        ids.add(Integer.parseInt(id.trim()));
    } catch (NumberFormatException e) {
        // 잘못된 입력 무시 또는 에러 처리
    }
}

// 동적으로 ? 생성
String placeholders = String.join(",", Collections.nCopies(ids.size(), "?"));
String query = "SELECT * FROM products WHERE id IN (" + placeholders + ")";

PreparedStatement pstmt = connection.prepareStatement(query);
for (int i = 0; i < ids.size(); i++) {
    pstmt.setInt(i + 1, ids.get(i));
}

// Python (더 간단함)
ids = [int(x) for x in request.args.get('ids').split(',') if x.isdigit()]
placeholders = ','.join(['?'] * len(ids))
query = f"SELECT * FROM products WHERE id IN ({placeholders})"
cursor.execute(query, ids)

필터 조건이 여러 개이고 선택적으로 적용되는 경우 🤔

// Java 예제
StringBuilder query = new StringBuilder("SELECT * FROM products WHERE 1=1");
List<Object> params = new ArrayList<>();

if (name != null && !name.isEmpty()) {
    query.append(" AND name LIKE ?");
    params.add("%" + name + "%");
}

if (minPrice != null) {
    query.append(" AND price >= ?");
    params.add(minPrice);
}

if (maxPrice != null) {
    query.append(" AND price <= ?");
    params.add(maxPrice);
}

if (category != null && !category.isEmpty()) {
    query.append(" AND category = ?");
    params.add(category);
}

PreparedStatement pstmt = connection.prepareStatement(query.toString());
for (int i = 0; i < params.size(); i++) {
    pstmt.setObject(i + 1, params.get(i));
}

// JPA Specification 사용
public class ProductSpecification {
    public static Specification<Product> hasName(String name) {
        return (root, query, cb) -> 
            name == null ? null : cb.like(root.get("name"), "%" + name + "%");
    }
    
    public static Specification<Product> priceBetween(Integer min, Integer max) {
        return (root, query, cb) -> {
            if (min != null && max != null) {
                return cb.between(root.get("price"), min, max);
            } else if (min != null) {
                return cb.greaterThanOrEqualTo(root.get("price"), min);
            } else if (max != null) {
                return cb.lessThanOrEqualTo(root.get("price"), max);
            }
            return null;
        };
    }
}

// 사용
Specification<Product> spec = Specification.where(hasName(name))
                                           .and(priceBetween(minPrice, maxPrice));
List<Product> products = productRepository.findAll(spec);

대량의 데이터를 처리할 때도 보안을 놓치면 안 돼! ⚡

// Java - Batch Insert
String query = "INSERT INTO logs (user_id, action, timestamp) VALUES (?, ?, ?)";
PreparedStatement pstmt = connection.prepareStatement(query);

for (LogEntry log : logs) {
    pstmt.setInt(1, log.getUserId());
    pstmt.setString(2, log.getAction());
    pstmt.setTimestamp(3, log.getTimestamp());
    pstmt.addBatch();
    
    // 1000개씩 배치 실행
    if (logs.indexOf(log) % 1000 == 0) {
        pstmt.executeBatch();
        pstmt.clearBatch();
    }
}

// 남은 것 실행
pstmt.executeBatch();

📈 성능 vs 보안 트레이드오프

솔직히 말하면 보안 기능을 추가하면 성능이 약간 떨어질 수 있어 ⚖️
하지만 걱정 ㄴㄴ! 제대로 최적화하면 성능 저하를 최소화할 수 있거든 ㅇㅇ

// ❌ 비효율적
for (User user : users) {
    PreparedStatement pstmt = connection.prepareStatement("INSERT INTO logs VALUES (?, ?)");
    pstmt.setInt(1, user.getId());
    pstmt.setString(2, user.getAction());
    pstmt.executeUpdate();
    pstmt.close(); // 매번 생성/삭제
}

// ✅ 효율적
PreparedStatement pstmt = connection.prepareStatement("INSERT INTO logs VALUES (?, ?)");
for (User user : users) {
    pstmt.setInt(1, user.getId());
    pstmt.setString(2, user.getAction());
    pstmt.executeUpdate();
}
pstmt.close(); // 한 번만 생성/삭제

PreparedStatement pstmt = connection.prepareStatement("INSERT INTO logs VALUES (?, ?)");
for (User user : users) {
    pstmt.setInt(1, user.getId());
    pstmt.setString(2, user.getAction());
    pstmt.addBatch(); // 배치에 추가
}
pstmt.executeBatch(); // 한 번에 실행!

// HikariCP 설정 예제 (가장 빠른 연결 풀)
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/mydb");
config.setUsername("user");
config.setPassword("password");
config.setMaximumPoolSize(10);
config.setMinimumIdle(5);
config.setConnectionTimeout(30000);
config.setIdleTimeout(600000);
config.setMaxLifetime(1800000);

// Prepared Statement 캐싱 활성화
config.addDataSourceProperty("cachePrepStmts", "true");
config.addDataSourceProperty("prepStmtCacheSize", "250");
config.addDataSourceProperty("prepStmtCacheSqlLimit", "2048");

HikariDataSource dataSource = new HikariDataSource(config);

입력 검증도 CPU를 사용하긴 하지만, 요즘 하드웨어 성능으로는 거의 무시할 수준이야 💪
오히려 잘못된 입력으로 인한 DB 부하가 더 큰 문제!

// 효율적인 검증 순서
public boolean validateUsername(String username) {
    // 1. 길이 체크 (가장 빠름)
    if (username == null || username.length() < 3 || username.length() > 20) {
        return false;
    }
    
    // 2. 간단한 문자 체크
    for (char c : username.toCharArray()) {
        if (!Character.isLetterOrDigit(c)) {
            return false;
        }
    }
    
    // 3. 복잡한 검증은 필요할 때만
    // (예: DB 중복 체크)
    
    return true;
}

WAF는 모든 요청을 검사하니까 당연히 지연이 발생해 ⏱️
하지만 클라우드 WAF는 CDN과 통합되어 있어서 오히려 전체 성능이 향상될 수도 있음!

직접 벤치마크 테스트를 해봤어! (참고용이니까 환경에 따라 다를 수 있음) 📊

보다시피 보안 기능을 추가해도 성능 저하는 크지 않아! ✨
게다가 SQL Injection 공격을 받으면 시스템 전체가 마비될 수 있으니까
약간의 성능 저하는 충분히 감수할 가치가 있어 ㅇㅈ?

🔮 미래의 보안 트렌드

기술은 계속 발전하고 있고, 보안 기법도 진화하고 있어 🚀
앞으로 어떤 방향으로 나아갈지 한번 살펴보자!

요즘 핫한 AI가 보안 분야에도 적용되고 있어 ㅋㅋ
머신러닝으로 SQL Injection 패턴을 학습하고 실시간으로 탐지하는 거지 🤖

"아무도 믿지 마라"는 컨셉 ㅋㅋㅋ
내부 네트워크라고 해서 안전하다고 가정하지 않는 거야 🔒

요즘 서버리스(Lambda, Cloud Functions)나 컨테이너(Docker, Kubernetes) 많이 쓰잖아?
이런 환경에서도 SQL Injection 방어는 필수야! 📦

// AWS Lambda 예제 (Node.js)
const mysql = require('mysql2/promise');

exports.handler = async (event) => {
    const connection = await mysql.createConnection({
        host: process.env.DB_HOST,
        user: process.env.DB_USER,
        password: process.env.DB_PASSWORD,
        database: process.env.DB_NAME
    });
    
    try {
        // ✅ Prepared Statement 사용
        const [rows] = await connection.execute(
            'SELECT * FROM users WHERE username = ?',
            [event.username]
        );
        
        return {
            statusCode: 200,
            body: JSON.stringify(rows)
        };
    } finally {
        await connection.end();
    }
};

블록체인 기술을 활용해서 DB 접근 로그를 변조 불가능하게 만드는 거야 ⛓️
해커가 침입해도 로그를 지우거나 수정할 수 없으니까 추적이 가능해짐!

양자 컴퓨터가 상용화되면 현재의 암호화 기법들이 무력화될 수 있대 ㄷㄷ
그래서 양자 내성 암호(Post-Quantum Cryptography)가 연구되고 있어 ⚛️

💬 마무리하며

와... 여기까지 읽었다면 진짜 대단한 거야 ㅋㅋㅋ 박수! 👏👏👏

SQL Injection은 오래된 공격 기법이지만 여전히 위험하고,
제대로 방어하지 않으면 큰 피해를 입을 수 있어.

하지만 걱정 ㄴㄴ! 이 글에서 배운 내용들만 제대로 적용하면
99% 이상의 SQL Injection 공격을 막을 수 있어 🛡️

보안은 한 번 설정하고 끝나는 게 아니라 지속적으로 관리해야 하는 것이야 🔄

새로운 공격 기법이 계속 나오고 있으니까
항상 최신 보안 트렌드를 공부하고 시스템을 업데이트해야 해!

혹시 DB 보안이나 코드 리뷰가 필요하다면
재능넷에서 전문가들의 도움을 받는 것도 좋은 방법이야 ㅇㅇ
실무 경험이 풍부한 개발자들이 많이 활동하고 있거든 👨‍💻👩‍💻

자, 이제 당신도 SQL Injection 전문가가 됐어! 🎉
오늘 배운 내용을 실무에 바로 적용해보고,
안전한 애플리케이션을 만들어보자구~

해킹은 막고, 사용자는 보호하고, 회사는 지키고! 🚀

화이팅! 💪💪💪