Brute Force / Replay Attack
Brute Force
최대 로그인 실패 횟수를 기록해 계정을 임시로 정지시키는 방법이 유용하다.
로그인에 실패한 사용자가 몇 초 이내에 다시 로그인을 시도하면 무조건 실패로 처리하거나, 성공이든 실패든 몇 초 이후에 다시 시도하라는 메세지를 주는 방법(throttling)도 고려해볼 수 있으나 요즘 잘 쓰이지는 않는 것 같다.
보통 패스워드가 틀렸을 때 바로 재입력하기 때문에 시간 제한이 있다면 불편할 듯.
Replay Attack
정상적인 사용자가 액세스 권한이나 특별한 권한을 얻기 위해 전송한 데이터를 공격자가 캡쳐해두었다가 재전송하는 공격이다. 최선의 방법은 캡쳐를 당하지 않는 것이지만, 그게 항상 가능하지는 않다.
이를 막기 위해서는 다음과 같은 경우를 피해야 한다.
- 접근이 제한된 리소스에 대한 엑세스를 유지하기 위한 데이터로 지속적인 값 사용
- 접근이 제한된 리소스에 대한 엑세스를 요청하는 데이터의 유출(임시 엑세스만 제공하는 데이터를 사용하는 경우도 포함)
n...r 인증 페이지는 https, POST로 전송하고, 클라이언트에서 JS로 encryption해서 전송하기 때문에 아이디와 패스워드가 그대로 body에 노출되지 않는다. 패스워드는 encpw로 encryption되어 전송되는 것 같은데 아이디도 같이 encryption되는 것으로 추정.
ID/PW를 같은 값으로 입력해도 매번 encpw값이 다르다. encnm을 같이 전송하는 것으로 보아 이를 salt로 사용하는 듯.
이렇게 JS로 패스워드를 해싱하는 방법만 사용하면 패스워드 자체는 노출되지 않지만, 리플레이 공격에는 취약하다.
리플레이 어택을 막기 위한 방법으로 서버와 클라이언트가 공유하는, 매번 변경되는 값을 Cookie로 발급해서 추가적인 salt로 사용하는 방법을 생각해 볼 수 있다. ( Digest 인증 )
이렇게 하면 리플레이해도 해시 결과가 일치하지 않기 때문에 리플레이 공격을 막을 수 있을 듯.
'Security > WebHacking' 카테고리의 다른 글
Blind SQL Injection (0) | 2017.08.08 |
---|---|
Basic SQL injection (0) | 2017.08.08 |
인증(Authentication)과 인가(Authorization) (0) | 2017.06.28 |
Session & HTTP Session hijacking (0) | 2017.06.27 |
Filtering / Escape (0) | 2017.06.27 |