웹 애플리케이션은 종종 악의적인 공격자의 표적이 됩니다. 이러한 애플리케이션은 공개적으로 액세스할 수 있거나 적어도 로그인 페이지가 공개되어 있기 때문에 단호한 공격자가 보안 결함이 있는 사이트를 찾는 것은 어렵지 않습니다. 공격자는 종종 웹 애플리케이션의 로그인 페이지 보안 취약점을 악용하여 과도한 부하를 유발하고 잠재적으로 사이트를 다운시키려고 시도합니다.
이러한 취약점 중 하나는 많은 로그인 흐름의 일부인 보안 질문 페이지에서 찾을 수 있습니다. 이 글에서는 이 시나리오를 살펴보고, 왜 문제가 되는지 살펴보고, 보안 위험을 완화하는 방법에 대한 지침을 제공합니다.
보안 질문이 공백으로 표시된 로그인 페이지
로그인 페이지 보안 취약점은 생각보다 흔한 문제입니다. 많은 웹사이트와 애플리케이션의 로그인 과정에서 보안을 강화하기 위해 기존의 사용자 이름/비밀번호 단계를 확장하는 추가 인증 보호 장치가 있습니다. 2단계 로그인 흐름을 상상해 보세요. 첫 번째 단계에서는 사이트에서 사용자 아이디와 비밀번호 조합을 요청합니다. 이러한 자격 증명을 올바르게 입력하면 두 번째 단계에서는 보안 질문(계정을 처음 설정할 때 지정한 질문)에 대한 답변을 요청합니다.
이 두 번째 단계는 일반적으로 첫 번째 단계를 성공적으로 완료한 사용자를 기반으로 보안 질문을 삽입하는 페이지 보기 템플릿을 기반으로 구축됩니다. 전체 2단계 로그인 흐름은 기본적으로 다음과 같이 작동합니다:
- 앨리스가 로그인 페이지(https://www.example.com/login)를 방문합니다.
- 앨리스가 사용자 이름과 비밀번호 조합을 제출합니다.
- 서버가 제출된 자격 증명을 확인합니다.
- 자격 증명이 정확했기 때문에 서버는 브라우저를 후속 페이지(https://www.example.com/login2)로 리디렉션하고, 요청 헤더에 고유 토큰을 포함하여 Alice가 로그인 흐름의 첫 단계를 통과했는지 확인합니다.
- 서버는 템플릿을 기반으로 이 페이지를 렌더링하여 Alice를 위해 가져온 보안 질문과 함께 응답을 위한 텍스트 입력 및 제출 버튼을 삽입합니다.
- 앨리스가 보안 질문에 대한 답변을 제출합니다.
- 서버는 앨리스가 보안 질문에 올바르게 답변했는지 확인한 다음 로그인합니다.
흐름의 두 번째 페이지(https://www.example.com/login2)에 집중해 보겠습니다. 첫 번째 단계를 거치지 않고 브라우저에서 바로 해당 페이지를 방문하면 어떤 일이 일어날지 상상해 보세요.
한 가지 시나리오에서는 서버가 요청 헤더에 유효한 토큰이 없는지 확인하고(로그인 흐름의 첫 단계를 성공적으로 통과하지 못했음을 의미), 다시 시작하기 위해 https://www.example.com/login 으로 리디렉션할 수 있습니다.
그러나 다른 시나리오에서는 서버가 여전히 템플릿을 기반으로 페이지를 렌더링합니다. 해당 사용자에 대한 해당 보안 질문을 찾을 수 없는 경우(서버에 어떤 중간 인증 사용자인지 알려주는 토큰이 없기 때문에) 결과 페이지는 다음과 같이 표시될 수 있습니다:
보안 질문이 없는 어색한 보안 질문 페이지가 남게 됩니다. 무의미한 페이지입니다.
무의미하긴 하죠. 하지만 무해할까요? 그렇게 확신하지 마세요.
보안에 미치는 영향
이 시나리오를 계속 진행하면서 사용자(또는 사용자보다 더 악의적인 사람)가 이 '보안 질문'에 대한 답변을 제출하면 어떻게 될까요? 서버는 사용자의 답변을 평가하기 위해 CPU 주기를 할당할 것입니다. 텍스트 입력을 처리하고, 요청 헤더에서 고유 토큰을 찾고, 답변을 검증하기 위해 데이터베이스 쿼리를 실행할 수도 있습니다.
보안 질문이 공란인 로그인 페이지는 사소해 보일 수 있지만(여기저기서 CPU를 몇 번 낭비하는 것이 무슨 문제인가요?) 심각한 보안 문제로 이어질 수 있습니다.
- 백엔드 처리 리소스 낭비: 무의미한 양식 제출을 처리하는 데 네트워킹 및 컴퓨팅 리소스가 소모되며 데이터베이스 리소스도 소모될 수 있습니다.
- 서비스 거부(DoS) 공격 가능성: 공격자가 봇넷을 설정하여 양식 제출을 반복적으로 전송하여 시스템에 과부하를 일으킬 수 있습니다.
- 취약성 증가: DoS 공격이 성공하면 전체 시스템이 다운될 수 있습니다.
공격자가 이 취약점을 악용하여 서버의 처리 능력을 낭비할 수 있다면 합법적인 사용자의 서비스가 중단되고 시스템이 추가 공격에 노출될 수 있습니다.
결국 그렇게 무해한 것은 아닙니다.
애플리케이션의 보안과 안정성을 유지하기 위해 이와 같은 취약점을 해결하는 방법을 살펴보세요.
방어하는 방법
이 특정 시나리오의 경우 login2 엔드포인트를 처리하는 서버는 요청 헤더에 유효한 토큰이 있는지 확인해야 합니다. 적절한 토큰이 없으면 추가 처리를 수행하지 않고 사용자를 로그인 흐름의 첫 번째 단계로 리디렉션해야 합니다. 이렇게 하면 404 또는 401과 마찬가지로 요청을 정상적으로 처리하는 데 사용되는 리소스를 최소화할 수 있습니다.
그러나 이 시나리오는 서버에 과도한 부하를 주는 반복적인 요청이라는 보다 일반적인 보안 문제를 강조합니다. 물론 빈 보안 질문이 있는 무의미한 로그인 페이지를 악용하면 처리 리소스가 많이 사용되기 때문에 서버에 더 빨리 과부하가 걸릴 수 있습니다. 하지만 봇넷은 완벽하게 정상적인 사용자 이름/비밀번호 로그인 페이지에도 과도한 요청을 할 수 있습니다.
이러한 종류의 공격으로부터 웹 애플리케이션을 보호하려면 다음 조치를 구현하세요:
- 웹 애플리케이션 방화벽(WAF)을 사용하세요: WAF는 DoS 보호 기능을 제공하고 악성 봇을 탐지 및 차단하여 자동화된 공격의 위험을 줄일 수 있습니다. Linode의 앱 마켓플레이스에는 이에 도움이 될 수 있는 Haltdos Community WAF가 포함되어 있습니다.
- 속도 제한을 구현합니다: 주어진 시간 내에 단일 IP 주소가 수행할 수 있는 요청 수를 제한하세요. 전송률 제한을 사용하면 공격자(및 봇)가 시스템에 요청이 폭주하는 것을 방지할 수 있습니다.
- 모니터링 및 알림 사용: 지속적인 모니터링 도구는 의심스러운 요청 패턴을 감시하여 잠재적인 공격에 대해 실시간으로 알려줍니다. 즉시 알림을 받으면 신속하게 대응하고 문제를 완화할 수 있습니다.
결론
보안 질문이 비어 있는 로그인 페이지의 경우를 살펴보았습니다. 언뜻 보기에는 별 의미가 없는 이상한 에지 페이지처럼 보입니다. 하지만 공격자는 이와 같은 취약점을 악용하여 리소스를 낭비하고 잠재적으로 시스템을 다운시킬 수 있습니다. 보안 질문 페이지는 이러한 취약점의 한 예에 불과합니다.
보안을 염두에 두고 애플리케이션을 설계하고 보안 코딩 관행을 채택했다면 좋은 출발을 한 것입니다. 하지만 애플리케이션에도 WAF 사용, 전송률 제한, 지속적인 모니터링 및 알림 등 시스템 및 인프라 수준에서 구현된 보안 조치가 필요합니다. 적절한 보안 조치를 취하면 이러한 공격의 표적이 될 위험을 크게 줄일 수 있습니다.
애플리케이션 보안에 대한 자세한 안내와 팁은 풍부한 보안 관련 가이드 라이브러리가 있는 Linode 문서를 참조하세요. 시스템과 사용자를 보호하는 방법을 안내하는 유용한 리소스를 찾을 수 있습니다.
내용