OWASP 2023 Top 10

1. 브로큰 액세스 컨트롤

2017년 5위에서 2021년에 목록의 상단으로 올라온 브로큰 액세스 컨트롤은 지속적이고 중대한 위협으로 남아 있습니다. 액세스 컨트롤은 사용자가 사용할 수 있는 리소스와 기능을 제한하며, 시스템이 적절한 제한을 시행하지 못할 때 사용되는 용어입니다.

이는 잘못된 구성, IDOR(안전하지 않은 직접 객체 참조) 등 여러 가지 이유로 발생할 수 있습니다. IDOR은 애플리케이션이 파일이나 데이터베이스 레코드 같은 리소스에 대한 직접 참조를 노출하는 경우입니다. 또한, 세션 관리의 취약점으로 인해 공격자가 사용자의 세션을 가로채는 것과 같은 문제가 발생할 수 있습니다.

개발자와 시스템 관리자는 여기서 최소 권한 원칙을 따라야 합니다. 이는 사용자에게 그들의 업무 수행에 필요한 최소한의 권한만 부여하고 그 이상은 부여하지 않는 것을 의미합니다.

모든 사용자 입력은 악의적인 데이터를 주입하는 공격자를 방지하기 위해 검증되고 정화되어야 하며, API에 액세스 컨트롤이 적용되고 모든 요청에 대한 권한이 확인되어야 합니다.

정기적인 보안 감사와 코드 리뷰는 액세스 컨트롤 문제를 식별하고 해결하는 데 필수적이며, 무단 접근을 제한하기 위해 다중 인증이 강제되어야 합니다.

2. 암호화 실패

이 문제는 이전에 '민감한 데이터 노출'이라고 불리며 3위에 올랐었지만, 이전 이름이 원인보다 증상을 묘사했기 때문에 이름이 변경되었습니다. 암호화는 신용카드 번호와 개인 식별 정보(PII) 같은 매우 민감한 데이터를 전송 중에 보호하는 데 사용되지만, 약한 암호화 알고리즘이나 짧은 암호화 키와 같은 요인들로 인해 실패할 수 있습니다. 이는 공격자가 민감한 데이터를 더 쉽게 해독할 수 있게 만듭니다.

암호화 실패의 다른 예로는 불안전한 비밀번호 저장, 충분하지 않은 전송 계층 보안(중간자 공격으로 이어질 수 있음), 약한 SSL/TLS 프로토콜, 그리고 웹 애플리케이션을 공격에 노출시킬 수 있는 불안전한 암호 스위트가 있습니다.

정기적인 보안 테스트(코드 리뷰 및 취약점 평가 포함)를 실시하여 암호화 취약점을 식별하고 해결하며, 또한 안전한 암호화 라이브러리 사용도 고려하세요.

3. 인젝션

인젝션은 2017년에 1위를 차지했고, 크로스 사이트 스크립팅은 7위였습니다. 이제 이들은 OWASP 2023의 현재 3위를 차지하는 하나의 우산 용어 아래 통합되었습니다.

인젝션 공격은 입력 유효성 검사의 취약점과 불충분한 데이터 처리를 이용합니다. 공격자들은 SQL 쿼리, 코드 스니펫, 명령어 등의 데이터를 웹 애플리케이션 폼이나 URL에 삽입합니다. 이를 통해 적들이 민감한 데이터에 접근하고 애플리케이션의 동작을 조작할 수 있습니다.

인젝션의 예시는 다음과 같습니다:

-       SQL 인젝션: 데이터베이스 공격을 위한 것입니다.

-       크로스 사이트 스크립팅(XSS): 주로 자바스크립트 기반의 브라우저 공격으로, 감염된 웹 페이지를 통해 실행되며 세션 탈취, 쿠키 도난 또는 사용자에 대한 기타 공격으로 이어질 수 있습니다.

-       커맨드 인젝션: 공격자가 애플리케이션이 실행하는 시스템 명령어에 악의적인 명령어를 삽입하여 서버를 제어하거나 허가되지 않은 작업을 수행할 수 있습니다.

-       LDAP 인젝션: 공격자가 인증 및 권한 부여에 사용되는 LDAP 쿼리를 조작하여 접근 권한을 얻습니다.

-       XML 인젝션: 공격자가 XML 데이터에 악의적인 내용을 삽입하여 애플리케이션의 파싱 과정을 방해하거나 접근 권한을 얻습니다.

-       서버 측 템플릿 인젝션(SSTI): 공격자가 서버 측 템플릿에 악의적인 코드를 삽입하여 서버에서 코드를 실행합니다.

4. 불안전한 디자인

이 OWASP 2023 범주는 2021년에 새로 생겼으며, 해커들이 이용할 수 있는 잘못된 애플리케이션 설계와 아키텍처의 결함을 다룹니다. 불안전한 디자인 취약점은 팀이 보안 모범 사례를 준수하지 않고 애플리케이션을 만드는 코드 설계 단계에서 잠재적 위협을 충분히 예측하고 평가하지 못할 때 발생합니다.

불안전한 디자인의 예는 지나치게 상세한 오류 메시지를 생성하는 앱입니다. 오류 상황에 대해 너무 자세한 정보를 제공하고 애플리케이션 환경이나 기타 관련 데이터에 대한 진단적 힌트를 제공한다면, 공격자에게 유용한 정보를 제공할 수 있습니다. 이 정보를 사용하여 경로 탐색이나 SQL 인젝션과 같은 다른 공격을 시작할 수 있습니다.

일관된 위협 모델링을 사용하여 알려진 공격 방법을 차단함으로써 디자인 취약점을 완화하는 것이 중요합니다.

5. 보안 미설정

이 범주는 이제 2017년의 XML 외부 엔티티(XXE) 범주를 포함합니다. 보안 미설정은 다양한 잠재적 취약점을 포함하지만, 가장 흔한 것들은 다음과 같습니다:

·       패치되지 않은 취약점

·       기본 설정

·       사용되지 않는 페이지

·       보호되지 않은 파일 및 디렉토리

·       불필요한 서비스

·       취약한 XML 파일 사용

웹마스터들이 자주 저지르는 실수 중 하나는 CMS(콘텐츠 관리 시스템) 기본 설정을 변경하지 않는 것입니다. CMS 애플리케이션은 사용자 친화적이지만, 최종 사용자에게 보안 위험을 초래할 수 있습니다. 많은 공격은 전적으로 자동화되어 있으며 기본 설정을 이용한 공격에 의존하므로, CMS 설치 시 이러한 설정을 변경하는 것이 잠재적 공격을 상당 부분 완화하는 데 중요합니다.

댓글 관리, 사용자 접근 제어, 사용자 정보 가시성 및 기본 파일 권한 설정을 조정하여 보안을 강화할 수 있습니다.

6. 취약하고 구식인 구성요소

가장 단순한 웹사이트조차 프레임워크, 라이브러리, 확장 프로그램, 플러그인 등 많은 의존성을 가지고 있으며, 이 모든 것은 최신 상태로 유지되어야 합니다. 공격자들은 취약한 구성요소를 가진 웹사이트를 찾아 멀웨어를 퍼뜨리거나 피싱 공격을 시작하는 등의 이용을 시도하므로, 어떤 이유로든 업데이트를 설치하지 않는 것은 좋지 않은 생각입니다.

어떤 소프트웨어의 최신 버전은 최신 보안 업데이트를 포함할 것이지만, 웹사이트가 많은 의존성에 의존하는 경우 이는 쉽게 말할 수 있지만 행하기 어렵습니다. 이를 해결하기 위한 첫 번째 단계는 환경에 연결된 모든 구성요소를 나열하고 각각의 동작을 최신 상태로 유지하는 목록을 생성하는 것입니다. Reflectiz와 같은 도구가 자동으로 이를 수행할 수 있습니다.

7. 식별 및 인증 실패

인증 및 신원 관리 실패는 애플리케이션을 악의적인 행위자가 정당한 사용자로 위장하는 위험에 노출시킵니다. 유효 기간 없이 구성된 세션 ID는 계속 실행될 수 있습니다. 약한 비밀번호는 추측에 취약할 수 있으며, 로그인 시도에 대한 제한이 없으면 자동화된 공격이 성공할 때까지 계속됩니다.

이러한 문제를 해결하기 위해 애플리케이션 내에서 다중 인증 요소(MFA)를 구현합니다. 또한, 개발자들은 권장되는 비밀번호 길이, 복잡성 및 회전 정책을 준수해야 할 필요성을 인식해야 합니다.

8. 소프트웨어 및 데이터 무결성 실패

이것들은 설계 결함의 일종입니다. 현대 아키텍처의 복잡성으로 인해 개발자들은 종종 다양한 출처에서 플러그인과 라이브러리를 파이프라인에 추가하고 그들의 무결성을 확인하지 않습니다. 이들 중 하나라도 실패하면 애플리케이션이 무단 정보 공개, 시스템 손상 또는 악의적 코드 삽입에 취약해질 수 있습니다. 이것이 제3자 및 오픈 소스 플러그인과 라이브러리의 활성 목록을 유지하고 지속적인 위협 모니터링을 수행하는 것이 중요한 이유입니다.

9. 보안 로깅 및 모니터링 실패

불량한 로깅 및 모니터링 기능은 사고가 누락되고 경고가 생성되지 않으며, 상당한 피해를 입힐 만큼 충분히 오랫동안 눈에 띄지 않을 수 있습니다.

로그인 시도 및 실패는 로그되어야 하며, 서버 장애 시를 대비하여 로그의 백업이 필요합니다. 로그는 모니터링 시스템이 의심스

러운 활동을 감지하거나 적시에 경고를 발생시킬 수 있도록 정확해야 하며, 또한 변조로부터 보호되어야 합니다.

취약점을 완화하기 위해 모든 로그인 시도(실패 포함)를 기록하고, 로그의 사본을 유지하며, 반탐퍼 메커니즘을 사용하고, 정기적으로 모니터링 시스템을 테스트하세요.

10. 서버 측 요청 위조(SSRF)

이 취약점은 공격자가 서버를 통해 다른 내부 또는 외부 리소스에 대한 무단 요청을 할 수 있게 합니다. SSRF 공격에서 공격자는 입력 필드나 애플리케이션의 파라미터를 조작하여 서버가 임의의 URL로 요청을 보내게 할 수 있으며, 이는 종종 사용자가 알지 못하는 상태에서 발생합니다.

공격자는 이 취약점을 악용하여 민감한 데이터에 접근하거나 내부 리소스와 상호 작용하거나 서버를 대신하여 행동을 수행할 수 있으며, 이는 애플리케이션이나 그 인프라의 완전한 손상으로 이어질 수 있습니다.

SSRF 취약점을 완화하기 위해 개발자들은 다음과 같은 모범 사례를 따라야 합니다:

입력 검증: 요청에 악의적인 URL이나 IP 주소가 사용되는 것을 방지하기 위해 사용자 제공 입력을 적절히 검증하고 정화합니다.

화이트리스팅: 허용된 URL 또는 IP 범위에 대한 화이트리스팅을 구현하여 서버가 알려진 안전한 리소스로 요청을 제한합니다.

방화벽 규칙: 서버로부터 특정 리소스와 프로토콜로의 나가는 요청을 제한하기 위해 방화벽 및 네트워크 설정을 구성합니다.

안전한 API 사용: 애플리케이션이 외부 리소스에 요청을 해야 하는 경우, 안전한 API 또는 공개 접근을 위해 의도된 특정 엔드포인트를 사용합니다.

최소 권한: SSRF 공격이 발생할 경우 잠재적 피해를 제한하기 위해 서버가 외부 리소스에 접근할 수 있는 최소 권한을 갖도록 합니다.