티스토리 뷰
이번에 이야기할 취약점은 인증실패 횟수제한에 대한 내용입니다. 실제 인증실패 횟수 자체가 취약점이 되진 않지만, Fuzzing 프로그램을 이용한 공격 등을 방지하기 위해 인증에 대해 횟수를 제한하는 안전한 코딩에 대한 내용이 될 것입니다. 특히 행안부 기준으로 반드시 확인해야하는 내용이며, 이 부분은 실제 소스코드 자동화 툴을 이용한 진단은 불가능하여, 소스코드를 수동으로 분석하거나, 동적진단을 통해 발견해야 하는 취약점이죠.
인증실패 횟수와 관련된 케이스는 아래와 같습니다.
01. 로그인 인증실패 횟수제한 부재 02. 비회원 인증실패 횟수제한 부재 03. 2차 패스워드 검증실패 횟수제한 부재 04. 2-Factor 인증실패 횟수제한 부재 05. 패스워드 변경실패 횟수제한 부재 06. 인증값 인증실패 횟수제한 부재 07. 외부 포인트 사용 인증실패 횟수제한 부재 08. 쿠폰 등록실패 횟수제한 부재 |
이 밖에도 다양한 케이스가 존재합니다.
01. 로그인 인증실패 횟수제한 부재
인증 실패횟수에 대해 이야기할 때 가장 기본이 되는 로그인입니다. 로그인을 위해 ID와 패스워드를 입력하여 정확히 입력한 경우 로그인 인증을 획득하여 해당 서비스를 이용하는데, 이때 일반적으로 ID는 많은 부분 공개가 되는 정보입니다. 이와 관련하여 계정명 자체도 마스킹을 해줘야 하지만, 계정명 그대로 이메일에 적용되는 경우가 많기 때문에, 계정명의 탈취는 그리 어려운 부분은 아닙니다. 게다가 많은 사용자들이 패스워드를 기억하기 쉽게 사용하고, 자신이 이용하는 대부분의 서비스에 동일한 패스워드를 사용하기 때문에, 한번 계정정보가 탈취되면 그 영향도는 실제로 엄청나다고 생각합니다. 거기에 관리자 계정이나 관리자권한을 갖는 테스트 계정은 대체로 비슷하거나 유추가 가능한 계정명을 사용하기 때문에, 이를 집중적으로 공격했을 때는 엄청난 일이 발생할 것입니다.
공격자는 계정명을 알게 되면 Fuzzing 프로그램을 이용하여 Brute Force, Dictionary 공격 등을 수행하는데, 공격을 하다보면 언젠가는 뚤리게 될 것입니다. 이를 방지하기 위해 인증실패 횟수를 제한하여 Fuzzing 공격을 통해 계정정보가 탈취될 확률을 매우 낮추거나, 시간을 오래 걸리게 만들 수 있습니다.
로그인 실패횟수는 DB 로그인 관련 테이블에 실패횟수에 대한 컬럼을 추가하고, 로그인 요청을 처리하는 서버측 코드에서 실패할 경우 숫자를 증가시키고, 특정횟수(약 5회) 이상일 경우 더 이상 ID/패스워드로 로그인이 되지 않도록 처리합니다. 만약 정상적인 로그인에 성공할 경우 실패횟수를 다시 0으로 초기화 시켜줍니다. 만약 로그인 인증실패 횟수가 특정횟수를 초과할 경우, 아래와 같은 형태로 대응이 필요해집니다.
실패횟수 제한 예제 - 로그인 실패횟수가 5회 이상일 경우, 로그인 잠금상태로 변경 - 로그인 실패횟수가 5회 이상일 경우, reCAPTCHA 등의 2차 입력값 추가 입력으로 변경 |
로그인이 잠기게 되면 더 이상 로그인을 수행하지 못하도록 제한되어야 하며, 휴대폰 본인인증이나 관리자 요청을 통해 로그인 잠금상태를 해제시켜줘야 합니다. reCAPTCHA를 이용할 경우, 매번 다른 값이 입력되기 때문에 Fuzzing 프로그램을 통해 공격이 불가능하도록 방지해줘야 합니다. 서비스 목표에 따라 실패 횟수 이후의 대응방법을 결정하면 될 듯 합니다.
02. 비회원 인증실패 횟수제한 부재
ID와 패스워드를 사용하는 회원 로그인 이외에도 비회원 서비스를 제공하는 경우가 있습니다. 비회원도 일반 회원의 로그인과 동일하게 인증실패에 대한 횟수를 제한해야 합니다. 비회원이 사용하는 인증정보는 일반 회원이 사용하는 ID / 패스워드보다 더 간단한 값이 사용될 수 있기 때문입니다. 인증실패 횟수나 제한방법은 일반회원과 동일하게 적용하면 됩니다.
03. 2차 패스워드 검증실패 횟수제한 부재
중요기능을 제공하기 전에는 2차 패스워드를 검증해줘야 합니다. 세션ID가 탈취되거나 CSRF 공격을 통해 중요기능을 제공해줘야 할 경우를 방지하기 위해 서비스 제공 전 2차 패스워드를 다시한번 확인하여 정상적인 사용자인지를 검증해줘야 합니다. 이때 패스워드를 다시 입력받아 현재 세션 소유자의 패스워드와 맞는지를 검증해 줄 때, 패스워드 인증에 대해 실패횟수를 제한하지 않을 경우, 세션ID를 탈취당한 경우, Fuzzing 프로그램을 이용할 경우 해당 사용자의 패스워드를 탈취가 가능성이 발생합니다. 계정명은 탈취가 패스워드보다 쉽기 때문에 2차 패스워드를 검증할 경우에도 반드시 실패횟수를 제한해야 합니다.
2차 패스워드 제한 예제 - 5회 입력 실패 시, 재로그인 전까지 2차 인증요청 제한 - 5회 입력 실패 시, 특정시간(약 30분) 간 2차 인증요청 제한 |
04. 2-Factor 인증실패 횟수제한 부재
ID/패스워드 이외에 2-Factor 인증을 추가해 더욱 안전한 로그인 처리가 가능해집니다. 특히 외부관리자 서비스의 경우 계정정보가 탈취될 경우, 임팩트가 더 치명적이기 때문에 2-Factor 인증을 추가해줘야 합니다. 이러한 로그인 프로세스에서 지식기반의 외부관리자의 계정정보가 탈취되더라도 생채기반 또는 소유기반의 추가 정보까지 정확하게 일치해야 하므로 외부관리자 서비스를 악의적 사용자에게 제공을 방지할 수 있게 되죠. 하지만, 만약 2-Factor에 대해 인증실패를 제한하지 않을 경우, 결국 외부관리자 서비스에 접근이 가능해질 것입니다.
때문에 2-Factor 인증에 대해서도 실패횟수를 제한해줘야 하는데, 특히 로그인과 2-Factor의 프로세스와 인증횟수를 별도로 분리하지 않고 동시에 처리 및 제한하므로서 더욱 안전하게 계정보안을 확보하는 것이 권고되어집니다.
05. 패스워드 변경실패 횟수제한 부재
회원정보에서 패스워드를 변경 시 전 기존의 패스워드를 확인하여 기능요청자가 정상사용자인지를 검증하거나, 기존의 패스워드를 동일하게 사용하지 못하도록 한번 더 입력받습니다. 또는 비밀번호 찾기 시 패스워드 변경 전 별도의 URL을 통해 이전 패스워드와 동일한지 검증하는 경우, 입력받은 값에 대해 요청횟수를 제한하지 않을 경우, Fuzzing 프로그램을 통해 패스워드를 탈취할 가능성이 존재하게 됩니다.
때문에 패스워드 변경 시 기존 패스워드를 확인 시 인증실패를 제한할 경우는 중요기능 제공 전 2차 패스워드 검증과 동일하게 처리하면 되며, 비밀번호 찾기 시에는 기존 패스워드와 동일하게 사용하는지를 별도의 URL로 분리하지 않고, 패스워드 정책을 적용하여 임의의 패스워드를 생성하여 회원정보를 통해 SMS 또는 EMail로 전달되도록 로직을 구성해야 합니다.
06. 인증값 인증실패 횟수제한 부재
특정 중요기능 제공 전 2차 패스워드 이외에 SMS 본인인증 등의 인증값을 통해 사용자를 인증하는 경우가 있습니다. 이 때 사용자에게 전달받는 인증값에 대해서도 인증실패 횟수를 제한해야 합니다. 특히 인증값은 일종의 토큰값이기 때문에 아래 3가지 파기처리 로직을 가져야 합니다.
인증토큰값의 파기처리 - 일회성 사용으로 한번 정상사용될 경우 재사용이 금지되도록 파기해야 함 - 짧은 일정시간 동안만 사용이 가능하도록 타임아웃을 적용 후 특정시간이 지난 경우 파기해야 함 - 인증실패 횟수를 적용하여 특정횟수(약 3~5회) 이상 실패 시 발급한 인증토큰값을 파기처리 해야 함 |
이렇게 발급받은 인증값에 대해 인증처리 횟수를 제한하고, 만약 특정횟수(약 3~5회) 이상 실패하게 되면, 인증을 제한하거나, 인증값을 재발급받도록 유도하여, 기존에 발급받은 인증값을 사용하지 못하도록 제한해야 합니다.
07. 외부 포인트 사용 인증실패 제한횟수 부재
다른 서비스의 포인트를 사용하기 위해서 결제단계에서 별도의 인증을 추가하는 경우가 있습니다. 이 경우 진단대상의 서비스 이용자와 외부 포인트의 소유자가 동일한 인물인지를 검증하기 위해 별도의 인증과정을 진행합니다. 만약 별도의 인증과정이 없을 경우, 세션탈취를 통해 타인의 포인트 또한 사용이 가능해지기 때문에 추가 인증을 진행해줘야 합니다. 때문에 외부 포인트를 사용하기 위해서는 별도의 인증절차를 추가해줘야 하는데, 이때 인증절차에 대해 실패횟수를 제한하지 않게 되면, Fuzzing 프로그램 등을 통해 타 서비스의 인증정보가 탈취될 수 있거나, 포인트 사용이 가능해지게 됩니다.
08. 쿠폰 등록실패 횟수제한 부재
온/오프라인 또는 EMail/SMS 등으로 쿠폰을 발급하여 해당 쿠폰을 사용하는 서비스를 제공할 경우, 쿠폰등록 시 횟수를 제한해야 합니다. 쿠폰번호는 대체로 고정된 자리수의 숫자로 구성된 경우가 많기 때문에, 횟수를 제한해줘야 합니다. 쿠폰 등록을 제한하지 않을 경우, Fuzzing 프로그램을 통해 구매하지 않은 쿠폰을 등록하거나, 타인이 구매 후 등록하지 않은 쿠폰을 악의적인 사용자가 등록해버릴 수 있기 때문에 반드시 등록횟수를 제한해야 합니다. 쿠폰등록은 다른 인증횟수제한과는 다르게 일정횟수이상 잘못된 쿠폰을 등록하게 될 경우, 일정시간동안 등록이 불가능하도록 제한을 해줘야 합니다.
Fin
'Web Analytics > Vulnerabilities' 카테고리의 다른 글
계정명 노출 분석 (0) | 2019.04.15 |
---|---|
Password 관련 취약점 분석 (0) | 2019.03.09 |
Download 취약점 분석 (0) | 2019.03.06 |
Upload 취약점 분석 (0) | 2019.03.03 |
SQL Injection 취약점 분석 (0) | 2019.03.03 |
- Total
- Today
- Yesterday