지금까지 만들었던 로그인 로직들을 보면 어지간하면 sql injection 공격을 하기 어렵다.
하지만 어떤 사람이든 실수는 하기 마련이다.
이번에는 개발자가 실수로 개발과정에서 보안 허점을 만들었다는 가정으로 로그인 로직을 작성해본다.
해당 코드에서 무엇이 실수일까? 코드를 유심히보면 20행의 userid 부분을 bindvalue로 처리해주지 않았다는 것이다.
이럴 경우 SQL injection 공격에 그대로 노출되어버린다. 실제로 공격을 실행해보면 그대로 로그인 되어버리는것을
볼 수 있다.
반대의 경우도 마찬가지이다. id부분만 막으면 된다고 생각하고 password를 막지않은 경우에도 문제가 발생한다.
이 경우는 id를 알고 password를 sql injection하면 인증이 통과되어버린다. 비밀번호를 몰라도 아이디만 알면 통과해버리는 경우가 발생해버린다.
실수 1과 2가 다른점은 막은것이 id인지 password인지의 차이점이지만 실상 두가지 모두 SQL injection의 취약할 수 밖에 없다. 막는 방법은 두가지 모두 제대로 처리해줘야한다.
해당 경우에는 아무런 보안처리를 하지 않았다. 이렬 경우는 SQL injection에 매우 취약한 상태이다.
제대로 된 처리를 해주어야한다.
실수-4는 한가지 가정을 해보자. 만약 strpos를 이용해서 문자열의 포함된 것을 차단한다고 해보자.
그것이 union이나 ' 또는 #같은 특수문자일 수 있다. 하지만 이를 하나라도 실수로 누락시킬 경우
SQL injection에 취약해져버린다. 이렇게 사람이 수동적으로 처리해야하는 로직은 실수가 발생할 수 있다.
실수 5는 preg_replace를 사용했다는 점이 있다. 물론 특수문자를 치환하는것도 있지만
취약점이 존재하는 함수다. 그 외에도 한가지 더 취약한 점이있다.
실수5의 코드를 보면 무엇이 취약점이 될 수 있을까?
바로 ' # 이 없다는 것이다. 이와 같은 실수가 존재할 경우 SQL injection에 취약할 수 밖에 없다.
실수 6은 무엇이 문제일까? 바로 ID인증부분만 보안처리 했다는것이다.
비밀번호는 보안처리가 없어서 취약할 수 밖에 없다.