SQL Injection에 대하여
웹 어플리케이션에서 사용자에게 입력받은 값을 이용해 데이터베이스를 조회하는 경우가 많다.
이때 사용자 입력값을 제대로 검증하거나 안전하게 처리하지않고 SQL 쿼리에 그대로 포함하면 공격자가 의도하지않은 SQL문장을 실행하도록 만들 수 있다.
이러한 공격을 SQL Injection(인젝션)이라고 한다.
SQL 인젝션이 발생하는 이유
SQL 인젝션의 가장 큰 원인은 사용자 입력값을 신뢰하고 SQL 쿼리에 그대로 직접 결합할 때 발생한다.
SELECT *
FROM Users
WHERE id = '사용자입력'
AND password = '사용자입력';이처럼 사용자를 조회하는 쿼리가 있다고 할 때
정상적인 사용자는 아이디와 비밀번호를 입력할 것이다.
그런데 공격자는 일반적인 문자열 대신 SQL문법으로 해석될 수 있는 값을 입력하는 경우
애플리케이션이 이를 단순 문자열로 처리하지않고 쿼리문의 일부로 붙여버리면,
개발자가 의도하지 않은 조건이나 명령이 데이터베이스에 그대로 전달 될 수 있다.
사용자 입력 검증 부족
가장 기본적인 원인은 사용자 입력값에 대해 검증이 부족한 것이다.
숫자만 입력되어야 하는 곳에 문자나 SQL 구문이 들어가도 그대로 처리하거나, 사용자 입력값을 아무런 검사 없이 데이터 베이스 쿼리에 그대로 전달하면 문제가 생길 확률이 높다.
그러므로 입력 데이터의 형식, 길이, 허용 가능한 문자 등을 확인하는 과정이 필요하다.
하지만 입력값 검증만으로는 SQL 인젝션을 완벽히 막을 수는 없다.
Prepared Statement
파라미터화된 쿼리라고 하는데 이 방식이 SQL 인젝션을 막는데 중요한 개념이다.
"SELECT * FROM users WHERE id = '" + userInput + "'"Prepared Statement를 사용하지 않은 쿼리는 위와 같은데
SELECT * FROM users WHERE id = ?Prepared Statement를 사용하면 이렇게 된다.
?에 사용자 입력값을 별로의 파라미터로 전달한다.
그러면 데이터베이스는 해당 입력을 SQL 명령어가 아닌 단순한 값으로 처리하게된다.
ORM은 SQL Injection을 막을 수 있을까?
ORM으로 JPA가 대표적인데
이런 ORM은 일반적으로 파라미터 처리를 자동으로 해주기 때문에 직접 SQL 문자열을 조립하는 것보다 SQL 인젝션 위협을 줄이는데 도움이 된다.
하지만 ORM이 무조건 안전한 것은 아닌데, ORM에서도 Raw 쿼리, 네이티브 쿼리 같은 기능을 사용하여 사용자 입력값을 문자열로 직접 붙이면 다시 SQL 인젝션이 발생할 수 있다.
논리적 오류를 이용한 SQL Injection
SQL 인젝션의 대표적 방식 중 하나로 SQL의 논리 연산을 조작해 원래 조건을 항상 참으로 만든다.
SELECT *
FROM Users
WHERE id = 'INPUT1'
AND password = 'INPUT2';사용자를 조회하는 쿼리가 있을 때
정상적인 쿼리의 실행결과는 사용자가 입력한 아이디와 비밀번호가 모두 일치해야 조회 결과가 반환된다.
그런데 애플리케이션이 사용자 입력을 검증하거나 파라미터화 하지 않고 SQL문에 그대로 삽입할 경우, SQL 공격 가능성이 있다.
' OR 1=1 --이런 SQL문이 있는데
SELECT *
FROM Users
WHERE id = '' OR 1=1 -- ...이렇게 붙여서 공격에 사용할 수 있다.
쿼리를 보면 OR 1=1라고 적혀있는데 1=1은 항상 참이다.
그러면 OR기에 전체 조건 역시 참이 될 수 있다.
또한 --는 일부 SQL 환경에서는 뒤쪽 내용을 주석으로 처리하는 데 사용된다.
따라서 원래 존재하던 비밀번호 검사 부분이 쿼리 해석에서 제외될 수 있다.
SQL 문법이 DB마다 다르기 때문에 공격 SQL문은 DB에 따라 달라질 수 있다.
결과적으로 원래 쿼리문이 의도했던 아이디가 일치하고 AND 비밀번호도 일치해야한다에서
공격으로 인해 앞의 조건과 상관없이 OR 항상 참인 조건으로 변형할 수 있는 것이다.
굳 👍