sql 인젝션 csrf차이 구별하고 막는 방법

얼마 전 운영 중인 사이트의 로그인 오류가 갑자기 늘어 로그를 확인한 적이 있습니다. 처음엔 공격이라고 생각했지만, 원인은 배포 과정에서 바뀐 데이터베이스 연결 설정이었습니다. 장애를 볼 때는 이런 구분이 중요합니다. 보안 문제도 마찬가지입니다. sql 인젝션 csrf차이를 모르면 서로 다른 공격에 같은 방어책을 적용하기 쉽습니다.

공격자가 건드리는 지점부터 다르다

SQL 인젝션은 사용자가 입력한 값이 데이터베이스 명령의 일부로 해석되는 문제입니다. 검색어, 로그인 아이디, 게시글 번호처럼 평범한 입력도 대상이 됩니다. 서버가 입력값을 SQL 문장에 그대로 이어 붙이면, 원래 의도한 조회 조건이 바뀌거나 권한 밖의 데이터에 접근할 수 있습니다.

CSRF는 로그인된 사용자의 브라우저를 이용해 원치 않는 요청을 보내는 문제입니다. 사용자가 공격자가 마련한 화면을 열었을 때, 브라우저가 기존 로그인 쿠키를 함께 보내는 상황을 노립니다. 서버가 요청의 출처와 의도를 확인하지 않으면 비밀번호 변경, 배송지 수정, 관리자 설정 변경 같은 작업이 실행될 수 있습니다.

짧게 구분하면 SQL 인젝션은 서버가 입력을 명령으로 잘못 다루는 문제이고, CSRF는 서버가 요청을 사용자의 의사로 잘못 받아들이는 문제입니다. SQL 인젝션은 공격자가 직접 입력을 보낼 수 있는 곳을 찾습니다. CSRF는 이미 로그인한 사용자의 브라우저와 그 브라우저에 저장된 인증 정보를 이용합니다.

로그와 증상은 어떻게 다르게 보이나

SQL 인젝션을 의심할 때는 검색·로그인·목록 조회 요청에서 비정상적인 입력 패턴이 반복되는지 봅니다. 특정 요청 뒤 데이터베이스 오류가 급증하거나, 평소보다 응답 데이터가 많아지고 조회 시간이 길어지는 현상도 단서입니다. 다만 오류가 안 보인다고 안전한 것은 아닙니다. 화면에 오류를 숨긴 상태에서도 취약점은 남을 수 있습니다.

CSRF는 요청 자체가 정상 사용자의 세션으로 기록될 수 있어 더 헷갈립니다. 예를 들어 관리자 계정에서 설정 변경 이력이 남았는데 본인은 작업한 적이 없다면, 로그인 기록만 확인해서는 부족합니다. 변경 시각의 요청 방식, Origin 같은 요청 헤더, CSRF 토큰 검증 결과, 해당 계정이 접속한 화면을 함께 확인해야 합니다. 헤더가 없다는 사실 하나만으로 공격이라고 단정할 수도 없습니다.

운영 현장에서는 먼저 무엇이 바뀌었는지 확인합니다. 회원 정보 한 건이 수정됐는지, 조회 결과가 새어 나갔는지, 데이터베이스 전체에 영향을 줬는지에 따라 대응 범위가 달라집니다. 로그는 원인 파악에 필요하지만 보관 기간이 짧으면 사고 시점을 놓칩니다. 변경 이력과 접근 로그의 보관 기간을 백업 정책만큼 구체적으로 잡아두는 편이 좋습니다.

막는 방법도 각각 따로 적용해야 한다

SQL 인젝션 방어의 기본은 준비된 문장과 매개변수 바인딩입니다. 사용자 입력을 SQL 문자열에 이어 붙이지 않고 값으로 전달해야 합니다. 검색 조건뿐 아니라 정렬 기준, 테이블명처럼 매개변수로 처리하기 어려운 부분은 허용 목록에서만 고릅니다. 입력에서 특수문자를 지우는 방식만으로는 충분하지 않습니다. 데이터베이스 계정 권한도 서비스 기능에 필요한 범위로 줄여야 사고 범위를 제한할 수 있습니다.

CSRF 방어에는 상태를 바꾸는 요청마다 예측하기 어려운 토큰을 검증하는 방식이 널리 쓰입니다. 로그인 쿠키의 SameSite 설정도 함께 점검합니다. 다만 SameSite 하나에만 기대면 브라우저 동작과 요청 흐름에 따라 빈틈이 생길 수 있습니다. 중요한 변경 요청에는 토큰 검증과 Origin 확인을 함께 두고, 비밀번호 변경처럼 피해가 큰 작업에는 재인증을 요구할 수 있습니다. 조회 요청으로 데이터가 바뀌는 구조라면 요청 방식부터 고쳐야 합니다.

자주 듣는 질문이 있습니다. 웹 방화벽을 켰으니 두 문제를 해결한 것 아니냐는 겁니다. 방화벽은 의심스러운 요청을 줄이는 보조 장치입니다. SQL 문장을 안전하게 만드는 코드나 사용자의 의도를 확인하는 서버 검증을 대신하지 못합니다. CORS 설정 역시 CSRF 토큰 검증의 대체품으로 보면 안 됩니다.

사고가 났을 때 확인할 순서

• 변경된 데이터와 설정을 먼저 파악하고, 사고 시각 전후의 애플리케이션·데이터베이스·인증 로그를 보존합니다.
• SQL 인젝션이 의심되면 취약한 입력 경로와 데이터베이스 계정 권한을 확인하고, 유출·변조 범위를 조사합니다.
• CSRF가 의심되면 영향을 받은 계정의 세션을 종료하고, 문제의 변경 기능에 토큰과 요청 출처 검증이 적용됐는지 확인합니다.
• 복구가 필요하면 백업을 바로 덮어쓰지 말고 별도 환경에서 복원해 사고 이전 데이터와 현재 데이터를 비교합니다.

백업은 있다는 사실보다 실제로 복원되는지가 중요합니다. 운영 중인 사이트라면 정기적으로 복원 시간을 재고, 데이터베이스와 업로드 파일의 시점이 맞는지도 확인해야 합니다. 두 공격은 시작점이 다르지만 사고 뒤 필요한 기록과 복구 절차는 겹칩니다. 평소에 입력 처리, 인증 요청, 백업 복원을 각각 점검해두면 장애가 생겼을 때 추측에 쓰는 시간을 줄일 수 있습니다.