식별 / 인증 분리
DATE : 2023/11/29
이제부터는 식별과 인증 과정이 분리되어있는 경우, 로그인을 우회하기 위한 방법을 찾아볼 것이다!
Query를 살펴보기 전에, 식별 / 인증 동시 실행과 동일한 Query를 사용했을 때
어떤 결과가 나오는 지 살펴보도록 하자.
[ case 1 ] : ' or '1'='1
우선 항상 참이 되는 조건을 or 연산자와 주입하는 경우에는 로그인을 할 수 없게 된다.
왜 로그인을 할 수 없느냐!!!
where문의 조건은 모든 사용자의 정보를 DB에서 가져오도록 하는 데
비밀번호를 비교하는 부분에서는 딱 하나의 ROW와 사용자가 입력한 값을 비교하게 된다.
이때 딱 하나의 ROW는 QUERY 결과로 반환 된 결과의 첫 번째 ROW가 된다.
현재 DB에는 총 4명의 정보가 들어있고, 그 중 첫 번째는 Dilymung씨의 정보이기 때문에
사용자가 입력한 "hanhxx1234"와 "goodDog"를 비교하게 되고
이 두 값은 일치하지 않기에 결과적으로
Login fail 결과를 얻게 된다. 주석을 사용하는 경우에도 식별과 인증을 따로 실행하는 경우에는
의미가 없기 때문에 동일한 결과가 나올 것이다.
[ case 2 ]
그렇다면 다른 Query는 어떨까??
위와 같이 id를 입력하는 경우에는 ID가 hanhxx인 경우에만 조건이 참이 되기 때문에
로그인에는 성공할 수 있지만, 우회를 하기에는 부적절한 듯하다.
[ case 3 & 4 ]
and 연산자를 사용하는 경우에도, True 조건을 주입하게 되면
id가 hanhxx인 row를 조회하고 사용자가 입력한 비밀번호와 비교하는,
지극히 이상적인 로그인 과정을 수행하기 때문에 이 경우도 우회하기 위해 사용하기에는 부적절하다.
그렇다고 false 조건을 쓰면 뭐가 다르냐?! 정답은 NO!
and false는 무엇이든 false로 만들어 버리는 무자비한 놈이기 때문에
(query 결과를 array로 변환해 'pass' 값을 가져오는 데, 반환 된 row가 없다 보니
값이 null이라며 에러까지 내고 있다. )
이렇게 풀어서 얘기했지만, 결국 요점은 무엇이냐!
식별 & 인증을 동시에 수행하는 경우 사용했던 동일한 방법으로는 로그인을 우회할 수 없다는 것이다.
그렇기 때문에 우리는 다른 방안을 고민해볼 필요가 있다!!!
대략 일주일 정도 이런 저런 시도를 해보면서 확정 지은 한 가지는
사용자가 입력한 값으로 query를 실행하고 그 결과로 나온 비밀번호와 사용자가 입력한 비밀번호를
비교하는 로직은 어찌할 수 없는 부분이기 때문에
우리는 추가적으로 실행시키고 싶은 또 다른 기능을 Query에 주입해야 할 듯하다.
여기서 말하는 또 다른 기능이란,
등등 (1)select문 맨 뒤에 위치하거나
(2)하나의 select문이 끝난 뒤에 연결해서 쓸 수 있는 keyword를 의미한다.
그 중에서도 고민 고민 하다 시도해볼 만 하다 싶었던 keyword는 바로, UNION!!
Query를 실행해보기 전에, UNION이 어떤 녀석인지 먼저 알아보도록 하자.
Last updated