무차별 대입 공격을 방어하는 방법

QA 컨설팅 및 소프트웨어 테스트 시리즈의 일부인 이 게시물에서는 웹 애플리케이션 보안의 기본 사항을 다룹니다. 이메일 주소가 어디에나 있는 경우 이메일 주소의 이름 부분을 앱의 로그인 이름으로 사용하지 마세요. 배경에 있는 화이트보드에 비밀번호가 적힌 셀카를 찍지 마세요. 꼭 필요한 경우에만 Captcha를 구현하세요!

위협 모델링 컨텍스트에는 몇 가지 방법과 도구가 있습니다. 그러나 기본적으로 모든 것은 다음 세 가지 질문을 중심으로 이루어집니다.

1. 누가 우리를 공격할 수 있습니까?

2. 우리가 보호하는 리소스/구성 요소는 무엇입니까?

3.시스템 인프라는 어떻게 제공됩니까?

공격자 프로필을 정의하면 사이버 공격 가능성을 평가하는 데 도움이 될 수 있습니다. 물론 프로필은 산업 및 응용 프로그램 유형(은행, 군대, 기업 블로그)에 따라 다릅니다. 몇 가지 예는 다음과 같습니다.

경쟁자

무엇보다도 그들은 데이터를 훔치거나 사용자 경험을 손상시키는 데 관심이 있을 수 있습니다(예: 앱 성능 저하).

봇/해커

반자동 봇은 애플리케이션의 취약성을 식별하여 스팸 또는 암호화폐 채굴을 위해 맬웨어를 주입하려고 시도합니다.

사용자

애플리케이션 사용자는 (종종 자신도 모르게) 보안 격차에 직면하게 됩니다. 예를 들어 사용자 ID 또는 URL을 변경하여 데이터에 대한 무단 액세스 권한을 얻습니다.

자신의 직원

최고의 신뢰가 있더라도 직원은 자신도 모르게 보안 위협이 될 수 있습니다. 일반적인 예로는 도난당한 세션 쿠키, 도난당하고 잘못된 암호 또는 단순히 직원의 컴퓨터에 설치된 맬웨어가 있습니다.

후자는 특히 도전적입니다. “우리는 VPN을 사용하고 신뢰할 수 있는 사용자만 네트워크에 허용합니다. 우리는 안전합니다!” 이러한 종류의 주장은 사용자의 컴퓨터가 감염되는 즉시 뒤집힙니다. 또한 이러한 유형의 바이러스가 회사에 어떻게 침투할지 예측하기 어렵습니다. 외부 포장 없이 배송된 USB 스틱일 수도 있고, 경영진에서 온 듯한 인상을 주는 “내년 최종 영업 계획”이라는 제목의 가짜 이메일일 수도 있습니다. 대부분의 사람들은 이러한 유형의 이메일을 여는 경향이 있습니다.

특히 보호할 가치가 있는 리소스를 분석합니다. 자산? 민감한 데이터? 해킹된 웹사이트로 인한 이미지 손상은 어떤 대가를 치르더라도 예방해야 합니까?

구성 요소

모든 공격 표면을 식별하려면 모든 애플리케이션 구성 요소를 포함하는 개요 다이어그램을 만듭니다. 기본 페이지와 백엔드 API는 중간에 있으며 처음에는 거의 말하지 않습니다. 그러나 차트가 커짐에 따라 주변에서 발견하게 될 사실에 놀랄 수도 있습니다. 오랫동안 업데이트되지 않은 간신히 사용된 레거시 구성 요소 – 침입자를 위한 완벽한 게이트웨이입니다.

프런트 엔드

웹 사이트는 일반적으로 웹 응용 프로그램에 대한 가장 중요한 액세스 지점 중 하나입니다. XXS가 특별한 역할을 하는 등 수많은 프런트엔드 관련 공격에 취약할 수 있습니다. 연락처 양식, 검색창, URL 등 매개변수를 허용하는 모든 구성 요소가 공격 대상이 될 수 있으므로 모든 입력을 확인해야 합니다. 클라이언트 측 애플리케이션 로직이 구현되는 방식을 분석합니다. 또한 사용자에게 어떤 메시지가 표시되는지 확인하고 소스 코드 주석에 숨겨진 단서가 없는지 확인하십시오.

백엔드

모든 웹사이트는 어떤 방식으로든 서버와 통신해야 합니다. 공격자는 API를 통해 직접 이 작업을 수행할 수도 있습니다. 충분히 확보되어 있습니까? 어떤 엔드포인트가 공용이며 실제로 열려 있어야 합니까? 요청은 어떻게 인증됩니까? 승인이 작동합니까? 최종 사용자가 관리 엔드포인트에 액세스할 수 있습니까? Spring Boot Actuator의 /env 끝점을 통해 환경 변수의 값을 가져오는 것을 방지하고 싶을 것입니다.

데이터 베이스

데이터베이스 포트가 열려 있지 않습니까? 관리자만 알고 있는 비밀 URL에 GUI DB 관리자가 설치되어 있지 않다는 보장이 있나요?

모바일 장치

해커가 시스템에 침입하는 가장 인기 있는 방법 – 하지만 그 이유는 무엇입니까?

사용 편의성을 높이기 위해 보안 수준을 낮추는 경우가 많습니다(예: Captcha가 필요하지 않음, 세션이 종료되지 않음). 또한 모바일 앱의 코드베이스는 기본 애플리케이션과 독립적으로 개발할 수 있습니다. 이로 인해 중요한 보안 패치를 잊어버릴 수 있습니다. 모바일 버전의 백엔드 API는 웹사이트 API와 동일한가요? 그렇지 않은 경우 고려해야 할 또 다른 구성 요소입니다.

뉴스 레터

지원서에서 이메일을 보내나요? 이메일에 웹사이트 콘텐츠에 대한 링크가 포함되어 있습니까? 관련 콘텐츠가 페이지에 직접 있습니까, 아니면 뉴스레터 전용 영역에 있습니까? 콘텐츠를 별도의 위치에 두는 것은 또 다른 취약한 구성 요소입니다.

인프라/클라우드 구성 요소

특히 클라우드 환경에서는 애플리케이션에 수많은 추가 구성 요소가 있습니다. 여기에는 예를 들어 서비스 검색(예: Eureka), 관리 도구(Spring Boot Admin), 로깅 및 메트릭(Kibana, Grafana) 또는 기타 도구(Redis, RabbitMQ)가 포함됩니다. 개발자/테스터가 집에서 연결하기 위해 포트를 열지 않았습니까?

타사 소프트웨어

일부 비즈니스 프로세스를 다루는 특별한 BPM 제품군을 사용하고 계십니까? 아니면 비즈니스 규칙 관리 시스템을 사용합니까? 외부 파트너와 통합할 수도 있습니까? 다시 말하지만 이들은 고려해야 할 구성 요소입니다.

모든 보호 개념은 개별적입니다. 세부 사항이나 구성 요소가 너무 작지 않습니다. RSS 피드, 캐시 서버 또는 웹 사이트용 이국적인 플러그인과 같은 수많은 작은 것들은 매우 빨리 잊혀질 수 있습니다.

모든 소프트웨어 구성 요소가 매핑된 후에는 인프라와 관련하여 투명성을 만드는 것이 중요합니다. 얼마나 많은 환경이 있습니까? 사용 중인 서버는 무엇입니까? 이들은 어떻게 서로 연결되어 있습니까? 인터넷 연결 상태는 어떻습니까?

개발 및 테스트 환경 보호

공격자의 관점에서 보면 개발 및 테스트 환경이 가장 흥미롭습니다. 그 이유는 여기서의 보안 구성은 일반적으로 프로덕션보다 “더 관대”하기 때문입니다. 프로그래머의 편안함은 종종 시스템의 보안보다 우선 순위가 높습니다.

공격자가 개발 환경에 대한 액세스 권한을 얻으면 다음과 같은 다양한 활동을 수행할 수 있습니다.

• 프로덕션 서버에 대한 성공적인 공격에 대비하십시오.
• 데이터 도용(수정되지 않은 프로덕션 데이터를 개발 환경에 복사하여 생성된 취약성은 드문 일이 아닙니다.)
• 암호 도용(일부는 프로덕션에서 유효할 수 있음)
• 개발 서버에 악성코드 설치
• 자세한 디버깅 로그 분석

소스 코드 저장소에 대한 외부 액세스도 제한되어야 합니다. 그렇지 않으면 공격자가 구성 파일에서 암호를 읽을 수 있습니다.

공격자는 어떻게 개발 환경을 찾을 수 있습니까?

DNS 전송

먼저 도메인을 분석하고 DNS 정보를 전송하려고 시도합니다. 이를 가능하게 하는 한 가지 도구는 호스트 프로그램(DNS 조회 유틸리티)입니다. 쿼리 유형을 NS로 정의하면 지정된 도메인의 이름 서버 항목이 표시됩니다.

$ 호스트 -t NS example.com

example.com 이름 서버 b.iana-servers.net.

example.com 이름 서버 a.iana-servers.net.

그런 다음 호스트는 목록 모드에서 영역 전송을 시도합니다(-I 옵션 사용 가능).

$ 호스트 -l example.com b.iana-servers.net

전송이 성공하면 공격자는 dev.example.com, test.example.com, qa.example.com 등과 같은 등록된 모든 하위 도메인을 보게 됩니다. 각각의 IP 주소도 볼 수 있습니다. 이를 방지하려면 DNS 구성을 확인하고 영역 전송이 차단되었는지 확인하십시오.

DNS 무차별 대입

간단한 DNS 전송이 실패하면 공격자는 DNS 무차별 대입을 사용하여 하위 도메인을 확인하려고 시도할 수 있습니다. 이를 수행할 수 있는 소프트웨어 중 하나는 dnsenum입니다. 도메인 접두사 목록이 있는 사전, 대상 도메인 및 DNS 서버가 제공되면 기존의 모든 하위 도메인이 반환됩니다. 수많은 가능한 접근 방식을 포함하는 dnsenum에 대한 공개 사전이 있습니다.

일반적으로 공격자는 서버의 IP 주소를 얻은 후 포트를 스캔하고 열린 포트를 찾고 추가 단계를 계획합니다. 모범 사례는 사설 네트워크의 모든 테스트 환경을 공개로부터 숨기고 VPN 네트워크를 통해서만 직원에게 원격 액세스를 허용하는 것입니다.

마지막으로 프로덕션 환경뿐만 아니라 테스트 환경에서도 HTTPS 연결을 사용하는 것을 고려할 수 있습니다. 여기서는 관련이 없으므로 인증서는 자체 서명될 수 있습니다. 어쨌든 직원이나 컴퓨터에 설치된 바이러스가 VPN의 HTTP 트래픽을 분석할 수 없다는 것이 중요합니다.

이 문서는 웹 애플리케이션에 대한 일종의 보안 브리핑을 목적으로 합니다. 개발자와 비즈니스 경제학자를 대상으로 합니다. 수많은 주제가 간략하게 다루어졌으며 물론 Google에서 자세히 알아볼 수 있습니다. 남은 말: 우리 시대에는 적어도 기본적인 안전 예방 조치를 아는 것이 매우 중요합니다. 보안 관점에서 확인해야 할 모든 사항이 포함된 체크리스트도 도움이 됩니다. 다음 포스팅에서는 다양한 공격 방법에 대해 알아보겠습니다.