웹 취약점 진단 체크리스트

hyun·2023년 1월 8일
OWASP TOP 10보안웹웹 보안웹 취약점 진단
1
post-thumbnail

이번 면접 준비하면서 OWASP top 10을 처음알 게 되었다. 개발 공부는 정말 끝이 없는 것 같다. 그래도 지금이라도 알아서 다행이라고 생각하며 웹 취약점 진단 체크리스트에 대해 찾아본 내용을 정리하여 포스팅하고자 한다.

목적

웹 기반 침해 사고는 설계시 데이터베이스 접근, 관리자 인증 및 사용자 인증, 설계 방식에 대한 보안성 검토가 이뤄지지 않기 때문이다. 웹 진단 체크리스트를 통해 근본적인 보안 문제를 점검하여 원인을 파악하고 미비 사항에 대한 조치를 취하여 보안 사고를 예방할 수 있다.



가이드

KISA- 주요정보통신기반시설 기술적 취약점 분석 평가 상세 가이드

https://www.kisa.or.kr/2060204/form?postSeq=12&page=1


OWASP Top 10

OWASP top 10은 웹 환경에서의 취약점을 위험도순으로 top 10을 선정한다. 3~4년 주기로 아래 사이트에 top 10을 업데이트 한다. 참고로 최근에 한 발표는 2021에 발표했다.
(https://owasp.org/www-project-top-ten/)


각 취약점에 대한 설명 및 예방법은 위 공식 페이지에서 번역기 돌린 것!

1.Broken Access Control

설명

  • 최소 권한 또는 거부 원칙 위반, 특정 기능, 역할 또는 사용자에 대해서만 액세스가 부여되어야 하지만 누구나 사용할 수 있는 경우.

  • URL(파라미터 조작 또는 강제 브라우징), 내부 애플리케이션 상태 또는 HTML 페이지를 수정하거나 API 요청을 수정하는 공격 도구를 사용하여 액세스 제어 검사를 우회합니다.

  • 고유 식별자(안전하지 않은 직접 객체 참조)를 제공함으로써 다른 사람의 계정을 보거나 편집할 수 있습니다.

  • POST, PUT 및 DELETE에 대한 액세스 제어가 누락된 API 액세스.

  • 특권의 상승. 사용자로 로그인하지 않고 사용자로 행동하거나 사용자로 로그인할 때 관리자로 행동합니다.

  • JSON 웹 토큰(JWT) 액세스 제어 토큰으로 재생하거나 변조하거나 권한을 높이거나 JWT 무효화를 남용하기 위해 조작된 쿠키 또는 숨겨진 필드와 같은 메타데이터 조작.

  • CORS 잘못된 구성은 승인되지 않은/신뢰할 수 없는 출처에서 API 액세스를 허용합니다.

  • 인증되지 않은 사용자 또는 표준 사용자로서 권한 있는 페이지를 강제로 탐색하십시오.


예방하는 방법

  • 공공 자원을 제외하고, 기본적으로 거부합니다.

  • 액세스 제어 메커니즘을 한 번 구현하고 CORS(Cross-Origin Resource Sharing) 사용을 최소화하는 것을 포함하여 애플리케이션 전체에서 재사용하십시오.

  • 모델 액세스 컨트롤은 사용자가 레코드를 생성, 읽기, 업데이트 또는 삭제할 수 있다는 것을 수락하기보다는 레코드 소유권을 시행해야 합니다.

  • 고유한 애플리케이션 비즈니스 제한 요구 사항은 도메인 모델에 의해 시행되어야 합니다.

  • 웹 서버 디렉토리 목록을 비활성화하고 파일 메타데이터(예: .git)와 백업 파일이 웹 루트 내에 존재하지 않도록 하십시오.

  • 로그 액세스 제어 실패, 적절한 경우 관리자에게 경고(예: 반복되는 실패).

  • 자동화된 공격 도구의 피해를 최소화하기 위해 API 및 컨트롤러 액세스를 제한하십시오.

  • 상태 저장 세션 식별자는 로그아웃 후 서버에서 무효화되어야 합니다. 무자국적 JWT 토큰은 공격자의 기회 창을 최소화하기 위해 수명이 짧아야 한다. 더 오래 지속되는 JWT의 경우 액세스를 취소하기 위해 OAuth 표준을 따르는 것이 좋습니다.


2.Cryptographic Failures

설명

첫 번째는 전송 및 저장 중인 데이터의 보호 요구를 결정하는 것이다. 예를 들어, 비밀번호, 신용 카드 번호, 건강 기록, 개인 정보 및 비즈니스 비밀은 주로 해당 데이터가 EU의 일반 데이터 보호 규정(GDPR) 또는 PCI 데이터 보안 표준(PCI DSS)과 같은 금융 데이터 보호와 같은 개인 정보 보호에 해당하는 경우 추가 보호가 필요합니다.


예방하는 방법

  • 애플리케이션에 의해 처리, 저장 또는 전송된 데이터를 분류하세요. 개인 정보 보호법, 규제 요구 사항 또는 비즈니스 요구에 따라 민감한 데이터를 식별하십시오.

  • 민감한 데이터를 불필요하게 저장하지 마세요. 가능한 한 빨리 폐기하거나 PCI DSS 준수 토큰화 또는 절단을 사용하세요. 보관되지 않은 데이터는 도난당할 수 없습니다.

  • 모든 민감한 데이터는 저장 중이 암호화되도록 하세요.

  • 최신의 강력한 표준 알고리즘, 프로토콜 및 키가 제자리에 있는지 확인하십시오; 적절한 키 관리를 사용하십시오.

  • TLS with forward secrecy (FS) 암호, 서버의 암호 우선 순위 지정 및 보안 매개 변수와 같은 안전한 프로토콜로 전송 중인 모든 데이터를 암호화하십시오. HTTP Strict Transport Security(HSTS)와 같은 지시어를 사용하여 암호화를 시행하십시오.

  • 민감한 데이터가 포함된 응답에 대한 캐싱을 비활성화하세요.

  • 데이터 분류에 따라 필요한 보안 제어를 적용하십시오.

  • 민감한 데이터를 전송하기 위해 FTP 및 SMTP와 같은 레거시 프로토콜을 사용하지 마십시오.

  • Argon2, scrypt, bcrypt 또는 PBKDF2와 같은 작업 요소(지연 요소)로 강력한 적응형 및 소금에 절인 해싱 함수를 사용하여 비밀번호를 저장하십시오.

  • 초기화 벡터는 작동 방식에 적합한 것을 선택해야 합니다. 많은 모드에서 이것은 CSPRNG(암호화학적으로 안전한 의사 난수 생성기)를 사용하는 것을 의미합니다. nonce가 필요한 모드의 경우, 초기화 벡터(IV)는 CSPRNG가 필요하지 않습니다. 모든 경우에 IV는 고정 키에 두 번 사용해서는 안 됩니다.

  • 암호화 대신 항상 인증된 암호화를 사용하세요.

  • 키는 암호화적으로 무작위로 생성되어야 하며 바이트 배열로 메모리에 저장되어야 한다. 비밀번호가 사용되는 경우, 적절한 비밀번호 기본 키 파생 기능을 통해 키로 변환해야 합니다.

  • 암호화 무작위성이 적절한 곳에서 사용되고, 예측 가능한 방식으로 또는 낮은 엔트로피로 시드되지 않았는지 확인하십시오. 대부분의 최신 API는 보안을 얻기 위해 개발자가 CSPRNG를 시드할 필요가 없습니다.

  • MD5, SHA1, PKCS 번호 1 v1.5와 같은 사용되지 않는 암호화 기능과 패딩 체계를 피하십시오.

  • 구성과 설정의 효과를 독립적으로 확인하세요.


3.Injection

설명

사용자가 제공한 데이터는 애플리케이션에 의해 검증, 필터링 또는 삭제되지 않습니다. 텍스트 인식 탈출 없이 동적 쿼리 또는 비파라미터화 호출은 인터프리터에서 직접 사용됩니다. 대적인 데이터는 추가적이고 민감한 레코드를 추출하기 위해 ORM(객체 관계형 매핑) 검색 매개 변수 내에서 사용됩니다. 적대적인 데이터는 직접 사용되거나 연결됩니다. SQL 또는 명령은 동적 쿼리, 명령 또는 저장 프로시저의 구조와 악성 데이터를 포함합니다.

더 일반적인 주입 중 일부는 SQL, NoSQL, OS 명령, ORM(Object Relational Mapping), LDAP, Expression Language(EL) 또는 OGNL(Object Graph Navigation Library) 주입이다. 그 개념은 모든 통역사들 사이에서 동일하다. 소스 코드 검토는 애플리케이션이 주입에 취약한지 감지하는 가장 좋은 방법입니다. 모든 매개 변수, 헤더, URL, 쿠키, JSON, SOAP 및 XML 데이터 입력에 대한 자동 테스트가 강력히 권장됩니다. 조직은 CI/CD 파이프라인에 정적(SAST), 동적(DAST) 및 대화형 애플리케이션 보안 테스트 도구를 CI/CD 파이프라인에 포함시켜 프로덕션 배포 전에 도입된 주입 결함을 식별할 수 있습니다.


#### 예방하는 방법

  • 선호되는 옵션은 인터프리터 사용을 완전히 피하거나, 매개 변수가 있는 인터페이스를 제공하거나, ORM(Object Relational Mapping Tools)로 마이그레이션하는 안전한 API를 사용하는 것입니다.
    참고: 매개 변수가 지정되더라도, PL/SQL 또는 T-SQL이 쿼리와 데이터를 연결하거나 EXECUTE IMMEDIATE 또는 exec()로 적대적인 데이터를 실행하는 경우 저장 프로시저는 여전히 SQL 주입을 도입할 수 있습니다.

  • 긍정적인 서버 측 입력 유효성 검사를 사용하세요. 많은 애플리케이션이 텍스트 영역이나 모바일 애플리케이션용 API와 같은 특수 문자가 필요하기 때문에 이것은 완전한 방어가 아닙니다.

  • 잔여 동적 쿼리의 경우, 해당 인터프리터의 특정 이스케이프 구문을 사용하여 특수 문자를 이스케이프하십시오.
    참고: 테이블 이름, 열 이름 등과 같은 SQL 구조는 이스케이프할 수 없으므로 사용자가 제공한 구조 이름은 위험합니다. 이것은 보고서 작성 소프트웨어의 일반적인 문제이다.

  • 쿼리 내에서 LIMIT 및 기타 SQL 컨트롤을 사용하여 SQL 주입의 경우 레코드의 대량 공개를 방지하십시오


4.Insecure Design

설명

불안정한 디자인은 "누락되거나 비효율적인 제어 설계"로 표현되는 다양한 약점을 나타내는 광범위한 범주이다. 불안정한 디자인은 다른 모든 상위 10개 위험 범주의 원천이 아니다. 안전하지 않은 설계와 안전하지 않은 구현 사이에는 차이가 있다. 우리는 어떤 이유로 설계 결함과 구현 결함을 구별하며, 근본 원인과 개선이 다릅니다. 보안 설계는 여전히 악용될 수 있는 취약점으로 이어지는 구현 결함이 있을 수 있다. 안전하지 않은 디자인은 정의에 따라 완벽한 구현으로 고칠 수 없으며, 특정 공격을 방어하기 위해 필요한 보안 제어는 결코 만들어지지 않았다. 안전하지 않은 설계에 기여하는 요인 중 하나는 개발 중인 소프트웨어나 시스템에 내재된 비즈니스 위험 프로파일링의 부족과 필요한 보안 설계 수준을 결정하지 못하는 것이다.

예방

  • AppSec 전문가와 함께 안전한 개발 수명 주기를 설정하고 사용하여 보안 및 개인 정보 보호 관련 제어를 평가하고 설계하십시오.

  • 부품을 사용할 준비가 된 안전한 디자인 패턴이나 포장 도로 라이브러리를 설정하고 사용하세요

  • 중요한 인증, 액세스 제어, 비즈니스 논리 및 주요 흐름을 위해 위협 모델링을 사용하세요

  • 보안 언어와 컨트롤을 사용자 스토리에 통합하세요

  • 애플리케이션의 각 계층에서 타당성 검사를 통합하세요 (프래프루엔드에서 백엔드까지)

  • 모든 중요한 흐름이 위협 모델에 저항하는지 확인하기 위해 단위 및 통합 테스트를 작성하십시오. 애플리케이션의 각 계층에 대한 사용 사례와 오용 사례를 컴파일하세요.

  • 노출 및 보호 요구에 따라 시스템 및 네트워크 계층의 계층을 분리하십시오.

  • 모든 계층에서 설계에 따라 세입자를 견고하게 분리하세요

  • 사용자 또는 서비스에 의한 자원 소비 제한


5.Security Misconfiguration

설명

응용 프로그램이 다음과 같다면 응용 프로그램은 취약할 수 있다.

1) 애플리케이션 스택의 모든 부분에서 적절한 보안 강화가 없거나 클라우드 서비스에 대한 부적절하게 구성된 권한이 없습니다.

2) 불필요한 기능이 활성화되거나 설치됩니다(예: 불필요한 포트, 서비스, 페이지, 계정 또는 권한).

3) 기본 계정과 비밀번호는 여전히 활성화되어 있고 변경되지 않습니다.

4) 오류 처리는 스택 추적이나 다른 지나치게 유익한 오류 메시지를 사용자에게 보여줍니다.

5) 업그레이드된 시스템의 경우, 최신 보안 기능이 비활성화되거나 안전하게 구성되지 않습니다.

7) 애플리케이션 서버, 애플리케이션 프레임워크(예: Struts, Spring, ASP.NET), 라이브러리, 데이터베이스 등의 보안 설정은 보안 값으로 설정되지 않습니다.

8) 서버는 보안 헤더나 지시문을 보내지 않거나 보안 값으로 설정되지 않습니다.

9) 소프트웨어가 구식이거나 취약합니다(A06:2021-취약하고 오래된 구성 요소 참조).

10) 협력적이고 반복 가능한 애플리케이션 보안 구성 프로세스가 없다면, 시스템은 더 높은 위험에 처해 있다.


예방

  • 반복 가능한 경화 프로세스를 사용하면 적절하게 잠긴 다른 환경을 빠르고 쉽게 배포할 수 있습니다. 개발, QA 및 생산 환경은 모두 각 환경에서 사용되는 다른 자격 증명으로 동일하게 구성되어야 합니다. 이 과정은 새로운 안전한 환경을 설정하는 데 필요한 노력을 최소화하기 위해 자동화되어야 한다.

  • 불필요한 기능, 구성 요소, 문서 및 샘플이 없는 최소한의 플랫폼. 사용하지 않는 기능과 프레임워크를 제거하거나 설치하지 마세요.

  • 패치 관리 프로세스의 일환으로 모든 보안 노트, 업데이트 및 패치에 적합한 구성을 검토하고 업데이트하는 작업(A06:2021-취약 및 오래된 구성 요소 참조). 클라우드 스토리지 권한(예: S3 버킷 권한)을 검토하십시오.

  • 세분화된 애플리케이션 아키텍처는 세분화, 컨테이너화 또는 클라우드 보안 그룹(ACL)을 통해 구성 요소 또는 테넌트 간의 효과적이고 안전한 분리를 제공합니다.

  • 보안 헤더와 같은 고객에게 보안 지침을 보냅니다.

  • 모든 환경에서 구성과 설정의 효과를 확인하는 자동화된 프로세스.


6.Vulnerable and Outdated Components

설명

아래와 같은 경우 해당 취약점에 속한다.

1) 사용하는 모든 구성 요소의 버전을 모르는 경우(클라이언트 측과 서버 측 모두). 여기에는 직접 사용하는 구성 요소와 중첩된 종속성이 포함됩니다.

2) 소프트웨어가 취약하거나, 지원되지 않거나, 오래된 경우. 여기에는 OS, 웹/애플리케이션 서버, 데이터베이스 관리 시스템(DBMS), 애플리케이션, API 및 모든 구성 요소, 런타임 환경 및 라이브러리가 포함됩니다.

3) 정기적으로 취약점을 스캔하지 않고 사용하는 구성 요소와 관련된 보안 게시판을 구독하는 경우.

4) 기본 플랫폼, 프레임워크 및 종속성을 위험 기반의 적시에 수정하거나 업그레이드하지 않는 경우. 이것은 일반적으로 패치가 변경 통제 중인 월별 또는 분기별 작업인 환경에서 발생하며, 조직은 고정된 취약점에 며칠 또는 몇 달 동안 불필요하게 노출될 수 있습니다.

5) 소프트웨어 개발자가 업데이트, 업그레이드 또는 패치된 라이브러리의 호환성을 테스트하지 않는 경우.

6) 구성 요소의 구성을 보호하지 않는 경우(A05:2021-Security Misconfiguration 참조).


예방하는 방법

다음과 같은 패치 관리 프로세스가 마련되어야 한다.

  • 사용하지 않는 종속성, 불필요한 기능, 구성 요소, 파일 및 문서를 제거하십시오.

  • 버전, OWASP Dependency Check, retire.js 등과 같은 도구를 사용하여 클라이언트 측 및 서버 측 구성 요소(예: 프레임워크, 라이브러리) 및 종속성의 버전을 지속적으로 인벤토리하십시오. 구성 요소의 취약점에 대해 CVE(Common Vulnerability and Exposures) 및 NVD(National Vulnerability Database)와 같은 소스를 지속적으로 모니터링합니다. 소프트웨어 구성 분석 도구를 사용하여 프로세스를 자동화하십시오. 사용하는 구성 요소와 관련된 보안 취약점에 대한 이메일 알림을 구독하세요.

  • 보안 링크를 통해 공식 소스에서만 구성 요소를 얻을 수 있습니다. 수정된 악성 구성 요소를 포함할 가능성을 줄이기 위해 서명된 패키지를 선호합니다(A08:2021-소프트웨어 및 데이터 무결성 실패 참조).

  • 유지 관리되지 않거나 이전 버전의 보안 패치를 만들지 않는 라이브러리와 구성 요소를 모니터링하세요. 패치가 불가능한 경우, 발견된 문제를 모니터링, 감지 또는 보호하기 위해 가상 패치를 배포하는 것을 고려하십시오.

  • 모든 조직은 애플리케이션이나 포트폴리오의 수명 동안 업데이트 또는 구성 변경을 모니터링, 선별 및 적용하기 위한 지속적인 계획을 보장해야 합니다.


7.Identification and Authentication Failures

설명

아래와 같은 경우 해당 취약점에 속한다.

  • 공격자가 유효한 사용자 이름과 비밀번호 목록을 가지고 있는 자격 증명 스터핑과 같은 자동화된 공격을 허용합니다.

  • 무차별 대입이나 다른 자동화된 공격을 허용한다.

  • "Password1" 또는 "admin/admin"과 같은 기본, 약한 또는 잘 알려진 비밀번호를 허용합니다.

  • 안전할 수 없는 "지식 기반 답변"과 같은 약하거나 비효율적인 자격 증명 복구와 잊어버린 비밀번호 프로세스를 사용합니다.

  • 일반 텍스트, 암호화 또는 약한 해시된 암호 데이터 저장소를 사용합니다(A02:2021-암호화 실패 참조).

  • 누락되었거나 유효하지 않은 다중 요소 인증이 있습니다.

  • URL에 세션 식별자를 노출합니다.

  • 로그인 성공 후 세션 식별자를 재사용하세요.

  • 세션 ID를 올바르게 무효화하지 않습니다. 사용자 세션이나 인증 토큰(주로 싱글 사인온(SSO) 토큰)은 로그아웃이나 비활성 기간 동안 제대로 무효화되지 않습니다.


예방하는 방법

  • 가능한 경우, 자동화된 자격 증명 스터핑, 무차별 대입 및 도난당한 자격 증명 재사용 공격을 방지하기 위해 다중 요소 인증을 구현하십시오.

  • 특히 관리자 사용자를 위해 기본 자격 증명으로 배송하거나 배포하지 마십시오.

  • 상위 10,000개의 최악의 비밀번호 목록에 대해 새롭거나 변경된 비밀번호를 테스트하는 것과 같은 약한 비밀번호 검사를 구현하십시오.

  • 암기된 비밀 또는 기타 현대적인 증거 기반 암호 정책에 대한 섹션 5.1.1의 국립 표준 기술 연구소(NIST) 800-63b 지침에 암호 길이, 복잡성 및 순환 정책을 조정하십시오.

  • 모든 결과에 동일한 메시지를 사용하여 계정 열거 공격에 대해 등록, 자격 증명 복구 및 API 경로가 강화되도록 하십시오.

  • 실패한 로그인 시도를 제한하거나 점점 더 지연시키지만, 서비스 거부 시나리오를 만들지 않도록 주의하십시오. 자격 증명 스터핑, 무차별 대입 또는 기타 공격이 감지되면 모든 오류를 기록하고 관리자에게 경고하십시오.

  • 로그인 후 엔트로피가 높은 새로운 무작위 세션 ID를 생성하는 서버 측의 안전한 내장 세션 관리자를 사용하세요. 세션 식별자는 URL에 없고, 안전하게 저장되며, 로그아웃, 유휴 및 절대 시간 초과 후에 무효화되어서는 안 됩니다.


8.Software and Data Integrity Failures

설명

소프트웨어 및 데이터 무결성 실패는 무결성 위반으로부터 보호하지 않는 코드 및 인프라와 관련이 있습니다. 이러한 예는 애플리케이션이 신뢰할 수 없는 소스, 저장소 및 콘텐츠 전송 네트워크(CDN)의 플러그인, 라이브러리 또는 모듈에 의존하는 경우입니다. 안전하지 않은 CI/CD 파이프라인은 무단 액세스, 악성 코드 또는 시스템 손상의 가능성을 초래할 수 있습니다. 마지막으로, 많은 응용 프로그램에는 이제 자동 업데이트 기능이 포함되어 있으며, 여기서 업데이트는 충분한 무결성 확인 없이 다운로드되고 이전에 신뢰할 수 있는 응용 프로그램에 적용됩니다. 공격자는 잠재적으로 자체 업데이트를 업로드하여 모든 설치에 배포하고 실행할 수 있습니다. 또 다른 예는 객체나 데이터가 공격자가 보고 수정할 수 있는 구조로 인코딩되거나 직렬화되는 경우 안전하지 않은 역직렬화에 취약하다.


예방하는 방법

  • 디지털 서명 또는 유사한 메커니즘을 사용하여 소프트웨어 또는 데이터가 예상 소스에서 왔으며 변경되지 않았는지 확인하십시오.

  • npm 또는 Maven과 같은 라이브러리와 종속성이 신뢰할 수 있는 저장소를 사용하는지 확인하십시오. 더 높은 위험 프로필을 가지고 있다면, 심사된 내부 정상으로 확인된 저장소를 호스팅하는 것을 고려해 보세요.

  • OWASP Dependency Check 또는 OWASP CycloneDX와 같은 소프트웨어 공급망 보안 도구가 구성 요소에 알려진 취약점이 포함되어 있지 않은지 확인하는 데 사용되었는지 확인하십시오.

  • 소프트웨어 파이프라인에 악성 코드나 구성이 도입될 가능성을 최소화하기 위해 코드 및 구성 변경에 대한 검토 프로세스가 있는지 확인하십시오.

  • CI/CD 파이프라인에 적절한 분리, 구성 및 액세스 제어가 있는지 확인하여 빌드 및 배포 프로세스를 통해 흐르는 코드의 무결성을 보장합니다.

  • 서명되지 않았거나 암호화되지 않은 직렬화된 데이터가 직렬화된 데이터의 변조 또는 재생을 감지하기 위해 어떤 형태의 무결성 검사 또는 디지털 서명 없이 신뢰할 수 없는 클라이언트로 전송되지 않도록 하십시오.


9.Security Logging and Monitoring Failures

설명

OWASP Top 10 2021로 돌아가서, 이 범주는 활성 위반을 탐지, 에스컬레이션 및 대응하는 데 도움이 됩니다. 로깅과 모니터링 없이는 위반을 감지할 수 없습니다. 불충분한 로깅, 탐지, 모니터링 및 활성 응답은 언제든지 발생합니다.

1) 로그인, 실패한 로그인 및 고부가가치 트랜잭션과 같은 감사 가능한 이벤트는 기록되지 않습니다.

2) 경고와 오류는 부적절하거나 불분명한 로그 메시지를 생성합니다.

3) 애플리케이션과 API 로그는 의심스러운 활동을 모니터링하지 않습니다.

4) 로그는 로컬에만 저장됩니다.

5) 적절한 경고 임계값과 응답 에스컬레이션 프로세스가 마련되어 있지 않거나 효과적이지 않습니다.

6) 동적 애플리케이션 보안 테스트(DAST) 도구(예: OWASP ZAP)에 의한 침투 테스트 및 스캔은 경고를 트리거하지 않습니다.

7) 애플리케이션은 실시간 또는 거의 실시간으로 활성 공격을 감지, 에스컬레이션 또는 경고할 수 없습니다.

8) 사용자나 공격자가 로깅 및 경고 이벤트를 볼 수 있도록 함으로써 정보 유출에 취약합니다(A01:2021-Broken Access Control 참조).


예방하는 방법

개발자는 애플리케이션의 위험에 따라 다음 제어의 일부 또는 전부를 구현해야 한다.

  • 모든 로그인, 액세스 제어 및 서버 측 입력 유효성 검사 실패를 의심스럽거나 악의적인 계정을 식별할 수 있는 충분한 사용자 컨텍스트로 기록할 수 있고 법의학 분석이 지연될 수 있도록 충분한 시간을 유지하십시오.

  • 로그 관리 솔루션이 쉽게 사용할 수 있는 형식으로 로그가 생성되었는지 확인하십시오.

  • 로깅 또는 모니터링 시스템에 대한 주입이나 공격을 방지하기 위해 로그 데이터가 올바르게 인코딩되었는지 확인하십시오.

  • 고부가가치 트랜잭션에 추가 전용 데이터베이스 테이블과 같은 변조 또는 삭제를 방지하기 위해 무결성 제어가 있는 감사 추적이 있는지 확인하십시오.

  • DevSecOps 팀은 의심스러운 활동이 감지되고 신속하게 대응할 수 있도록 효과적인 모니터링과 경고를 구축해야 합니다.

  • 국립 표준 기술 연구소(NIST) 800-61r2 이상과 같은 사고 대응 및 복구 계획을 수립하거나 채택하십시오.

  • OWASP ModSecurity Core Rule Set와 같은 상용 및 오픈 소스 애플리케이션 보호 프레임워크와 사용자 지정 대시보드와 경고를 특징으로 하는 Elasticsearch, Logstash, Kibana(ELK) 스택과 같은 오픈 소스 로그 상관 관계 소프트웨어가 있습니다.

10.Server-Side Request Forgery

설명

SSRF 결함은 웹 애플리케이션이 사용자가 제공한 URL을 검증하지 않고 원격 리소스를 가져올 때마다 발생합니다. 이를 통해 공격자는 방화벽, VPN 또는 다른 유형의 네트워크 액세스 제어 목록(ACL)으로 보호되는 경우에도 응용 프로그램이 예기치 않은 목적지로 작성된 요청을 보내도록 강요할 수 있습니다.

최신 웹 애플리케이션이 최종 사용자에게 편리한 기능을 제공함에 따라, URL을 가져오는 것은 일반적인 시나리오가 된다. 결과적으로, SSRF의 발생률이 증가하고 있다. 또한, 클라우드 서비스와 아키텍처의 복잡성으로 인해 SSRF의 심각성이 높아지고 있다.

예방하는 방법

개발자는 깊이 제어에서 다음 방어의 일부 또는 전부를 구현하여 SSRF를 방지할 수 있다.

1) 네트워크 계층에서

  • SSRF의 영향을 줄이기 위해 별도의 네트워크에서 원격 리소스 액세스 기능을 세분화하세요

  • 필수 인트라넷 트래픽을 제외한 모든 것을 차단하기 위해 "기본적으로 거부" 방화벽 정책 또는 네트워크 액세스 제어 규칙을 시행하십시오.

  • 애플리케이션을 기반으로 방화벽 규칙에 대한 소유권과 수명 주기를 설정하세요.

  • 방화벽에서 허용되고 차단된 모든 네트워크 흐름을 기록하세요 (A09:2021-보안 로깅 및 모니터링 실패 참조).

2) 애플리케이션 레이어에서:

  • 클라이언트가 제공한 모든 입력 데이터를 소독하고 검증하세요

  • 긍정적인 허용 목록으로 URL 스키마, 포트 및 대상을 시행하세요

  • 고객에게 원시 응답을 보내지 마세요.

  • HTTP 리디렉션 비활성화

  • DNS 재결합 및 "체크 시간, 사용 시간"(TOCTOU) 경쟁 조건과 같은 공격을 피하기 위해 URL 일관성에 유의하십시오.

  • 거부 목록이나 정규 표현식을 사용하여 SSRF를 완화하지 마세요. 공격자는 거부 목록을 우회할 수 있는 페이로드 목록, 도구 및 기술을 가지고 있다.

3) 고려해야 할 추가 조치:

  • 프론트 시스템에 다른 보안 관련 서비스를 배포하지 마세요(예: OpenID). 이러한 시스템의 로컬 트래픽 제어(예: localhost)

  • 전용적이고 관리 가능한 사용자 그룹이 있는 프론트엔드의 경우 네트워크 암호화를 사용합니다(예: 매우 높은 보호 요구를 고려하기 위한 독립 시스템의 VPN)



자료 출처

https://sk-infosec-ready.tistory.com/342
https://www.igloo.co.kr/security-information/한발-앞서-살펴보는-owasp-top-10-2021-draft/
https://owasp.org/www-project-top-ten/

profile
hyun
크리스마스 캐럴을 좋아하는 사람!
이전 포스트

Blob 이해해보기

다음 포스트

JS 보안 취약점

0개의 댓글