식별 / 인증 분리
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