[정보보안] OWASP Top 10 – 웹 애플리케이션 보안 위험(2021년)

2024년 1회 정보보안실기시험에 OWASP Top 10 항목 중 SSRF(Server-Side Request Forgery)가 출제되었습니다(문제 내용이 정확히 기억나지 않지만). 암호화 오류(Cryptographic Failures)를 포함하여 Top 10 항목 중 2021년에 새롭게 반영된 카테고리에 대해 자세히 알아보겠습니다(예방 방법 및 공격 시나리오).

OWASP는 “Open Web Application Security Project”의 약자로, 웹 애플리케이션 보안에 중점을 둔 비영리 단체입니다. OWASP는 웹 애플리케이션 보안을 향상시키기 위한 여러 가지 자원과 도구를 제공하고, 보안 전문가와 개발자들 간의 지식 공유를 촉진합니다. OWASP Top 10은 현재 가장 위험한 웹 애플리케이션 보안 취약점을 열거한 목록입니다. 이 목록은 주로 공격자가 가장 많이 이용하는 취약점을 다루고 있으며, 개발자들이 주의를 기울여야 할 중요한 보안 취약점들을 알려줍니다.

출처: https://owasp.org/www-project-top-ten/

• A01:2021-깨진 액세스 제어(Broken Access Control)가 다섯 번째에서 첫 번째 위치로 이동합니다. 94%의 애플리케이션이 어떤 형태로든 손상된 액세스 제어에 대해 테스트되었습니다. 손상된 액세스 제어에 매핑된 34개의 CWE(공통 약점 열거)는 다른 어떤 범주보다 애플리케이션에서 더 많이 발생했습니다.
• A02:2021-암호화 오류(Cryptographic Failures)는 2위로 한 단계 올라갔습니다. 2017년 버전에서는 민감한 데이터 노출(Sensitive Data Exposure)로 알려진 카테고리로 근본 원인이 아닌 광범위한 증상이었습니다. 여기서 새롭게 초점을 맞추는 것은 종종 민감한 데이터 노출이나 시스템 손상으로 이어지는 암호화와 관련된 오류입니다.
• A03:2021-주입(Injection)이 첫 번째 위치에서 세 번째 위치로 내려왔습니다. 응용 프로그램의 94%가 특정 형태의 주입에 대해 테스트되었으며 이 범주에 매핑된 33개의 CWE는 응용 프로그램에서 두 번째로 많이 발생합니다. 이제 Cross-site Scripting(XSS)이 2021년 버전에서 이 범주에 포함됩니다.
• A04:2021 – 안전하지 않은 디자인(Insecure Design)은 2021년의 새로운 카테고리로, 디자인 결함과 관련된 위험에 중점을 둡니다. 업계로서 진정으로 “Move left”하려면 위협 모델링, 보안 설계 패턴 및 원칙, 참조 아키텍처를 더 많이 사용해야 합니다.
• A05:2021-보안 구성 오류(Security Misconfiguration)가 2017년 버전에서는 6번이었는데 5번으로 올라갔습니다. 90%의 애플리케이션이 어떤 형태로든 잘못된 구성에 대해 테스트되었습니다. 고도로 구성 가능한 소프트웨어로 더 많은 변화가 이루어지면서 이 범주가 상승하는 것은 놀라운 일이 아닙니다. 2017년 버전의 XML External Entities (XXE) 범주는 이제 이 범주의 일부입니다.
• A06:2021-취약하고 오래된 컴포넌트(Vulnerable and Outdated Components)의 2017년 버전 제목은 “Using Components with Known Vulnerabilities”이었습니다. Top 10 community survey에서는 2위이지만, 데이터 분석을 통해 상위 10위 안에 들기에 충분한 데이터가 있었습니다. 이 범주는 2017년 9위에서 상승했으며 위험을 테스트하고 평가하는 데 어려움을 겪는 알려진 문제입니다. 이는 포함된 CWE에 매핑된 CVE(Common Vulnerability and Exposures)가 없는 유일한 범주이므로 기본 악용 및 영향 가중치 5.0이 점수에 반영됩니다.
• A07:2021-식별 및 인증 실패(Identification and Authentication Failures)는 2017년 버전에서는 두 번째 위치인 “Broken Authentication”이었으나 일곱 번째 위치로 내려오며 이제 식별 실패와 더 관련이 있는 CWE를 포함합니다. 이 범주는 여전히 상위 10위 안에 포함되지만 표준화된 프레임워크의 가용성 증가가 도움이 되는 것으로 보입니다.
• A08:2021 – 소프트웨어 및 데이터 무결성 오류(Software and Data Integrity Failures)는 2021년에 새로 추가된 카테고리로, 소프트웨어 업데이트, 중요한 데이터, 그리고 CI/CD 파이프라인과 관련하여 무결성을 검증하지 않고 가정하는 것에 중점을 둔니다. 이 범주의 10개 CWE에 매핑된 CVE/CVSS(Common Vulnerability and Exposures/Common Vulnerability Scoring System) 데이터에서 가중치가 가장 높은 영향 중 하나입니다. 2017년의 안전하지 않은 역직렬화(Insecure Deserialization)는 이제 이 더 큰 범주의 일부입니다.
• A09:2021 – 보안 로깅 및 모니터링 실패(Security Logging and Monitoring Failures)는 이전에 불충분한 로깅 및 모니터링이었으며 업계 설문 조사(#3)에서 추가되어 2017년 버전 열 번째에서 아홉 번째로 올라갔습니다. 이 범주는 더 많은 유형의 오류를 포함하도록 확장되었으며 테스트하기 어렵고 CVE/CVSS 데이터에 잘 표시되지 않습니다. 그러나 이 범주의 오류는 가시성, 사고 경고 및 포렌식에 직접적인 영향을 미칠 수 있습니다.
• A10:2021 – 서버측 요청 위조(Server-Side Request Forgery, SSRF)는 2021년의 새로운 범주로, 상위 10개 커뮤니티 설문조사(#1)에서 추가되었습니다. 데이터는 평균 이상의 테스트 범위와 함께 악용 및 영향 가능성에 대한 평균 이상의 평가를 통해 상대적으로 낮은 발생률을 보여줍니다. 이 범주는 현재 데이터에는 표시되지 않지만 보안 커뮤니티 구성원이 이것이 중요하다고 말하는 시나리오를 나타냅니다.

A02:2021-암호화 오류(Cryptographic Failures)

1. 예방하는 방법
   • 애플리케이션에서 처리, 저장 또는 전송되는 데이터를 분류합니다. 개인 정보 보호법, 규제 요구 사항 또는 비즈니스 요구 사항에 따라 민감한 데이터를 식별합니다.
   • 민감한 데이터를 불필요하게 저장하지 마세요. 가능한 한 빨리 폐기하거나 PCI DSS 호환 토큰화 또는 ​​잘라내기를 사용하십시오. 보관되지 않은 데이터는 도난당할 수 없습니다.
   • 저장되어 있는 모든 민감한 데이터를 암호화하세요.
   • 최신의 강력한 표준 알고리즘, 프로토콜 및 키가 마련되어 있는지 확인하세요. 적절한 키 관리를 사용하십시오.
   • 순방향 비밀성(forward secrecy, FS) 암호를 사용하는 TLS, 서버에 의한 암호 우선 순위 지정 및 보안 매개변수와 같은 보안 프로토콜을 사용하여 전송 중인 모든 데이터를 암호화합니다. HSTS(HTTP Strict Transport Security)와 같은 지시어를 사용하여 암호화를 시행합니다.
   • 데이터 분류에 따라 필요한 보안 제어를 적용합니다.
   • 민감한 데이터를 전송하기 위해 FTP 및 SMTP와 같은 레거시 프로토콜을 사용하지 마십시오.
   • Argon2, scrypt, bcrypt 또는 PBKDF2와 같은 작업 요소(지연 요소)가 포함된 강력한 적응형 솔티드 해싱 기능을 사용하여 비밀번호를 저장합니다.
   • 초기화 벡터(Initialization Vector, IV)는 작동 모드에 맞게 선택해야 합니다. 많은 모드에서 이는 CSPRNG(암호적으로 안전한 의사 난수 생성기, cryptographically secure pseudo random number generator)를 사용하는 것을 의미합니다. nonce가 필요한 모드의 경우 초기화 벡터에는 CSPRNG가 필요하지 않습니다. 모든 경우에 초기화 벡터는 고정 키에 두 번 사용되어서는 안 됩니다.
   • 암호화만 사용하는 대신 항상 인증된 암호화를 사용하세요.
   • 키는 암호화 방식으로 무작위로 생성되어야 하며 메모리에 바이트 배열로 저장되어야 합니다. 비밀번호를 사용하는 경우 적절한 비밀번호 기반 키 파생 기능을 통해 비밀번호를 키로 변환해야 합니다.
   • 적절한 경우 암호화 무작위성이 사용되는지, 예측 가능한 방식으로 또는 낮은 엔트로피로 시드되지 않았는지 확인하세요. 대부분의 최신 API에서는 개발자가 보안을 확보하기 위해 CSPRNG를 시드할 필요가 없습니다.
   • MD5, SHA1, PKCS 번호 1 v1.5와 같이 더 이상 사용되지 않는 암호화 기능 및 패딩 구성표를 사용하지 마세요.
   • 구성 및 설정의 효율성을 독립적으로 확인합니다.
2. 공격 시나리오 예
   • 시나리오 #1: 애플리케이션은 자동 데이터베이스 암호화를 사용하여 데이터베이스의 신용 카드 번호를 암호화합니다. 그러나 이 데이터는 검색 시 자동으로 해독되므로 SQL 삽입 결함으로 일반 텍스트로 신용카드 번호를 검색할 수 있습니다.
   • 시나리오 #2: 사이트는 모든 페이지에 대해 TLS를 사용 또는 시행하지 않거나 약한 암호화를 지원합니다. 공격자는 네트워크 트래픽(예: 안전하지 않은 무선 네트워크)을 모니터링하고, 연결을 HTTPS에서 HTTP로 다운그레이드하고, 요청을 가로채고, 사용자의 세션 쿠키를 훔칩니다. 그런 다음 공격자는 이 쿠키를 재생하고 사용자의 (인증된) 세션을 하이재킹하여 사용자의 개인 데이터에 액세스하거나 수정합니다. 위의 내용 대신 전송된 모든 데이터(예: 송금 수취인)를 변경할 수 있습니다.
   • 시나리오 #3: 비밀번호 데이터베이스는 솔트 처리되지 않은 해시 또는 단순 해시를 사용하여 모든 사람의 비밀번호를 저장합니다. 파일 업로드 결함으로 인해 공격자가 비밀번호 데이터베이스를 검색할 수 있습니다. 모든 무염 해시는 미리 계산된 해시의 레인보우 테이블을 통해 노출될 수 있습니다. 단순하거나 빠른 해시 함수로 생성된 해시는 솔트 처리된 경우에도 GPU에 의해 깨질 수 있습니다.

A04:2021 – 안전하지 않은 디자인(Insecure Design)

1. 예방하는 방법
   • AppSec 전문가와 함께 보안 개발 수명주기를 설정하고 사용하여 보안 및 개인 정보 보호 관련 제어를 평가하고 설계하는 데 도움을 줍니다.
   • 구성 요소를 사용할 준비가 된 안전한 설계 패턴 또는 포장 도로의 라이브러리를 구축하고 사용합니다.
   • 중요한 인증, 액세스 제어, 비즈니스 로직 및 키 흐름에 위협 모델링을 사용합니다.
   • 보안 언어 및 제어를 사용자 스토리에 통합
   • 애플리케이션의 각 계층(프런트엔드에서 백엔드까지)에서 타당성 검사를 통합합니다.
   • 모든 중요한 흐름이 위협 모델에 저항하는지 확인하기 위해 단위 및 통합 테스트를 작성합니다. 애플리케이션의 각 계층에 대한 사용 사례와 오용 사례를 컴파일합니다.
   • 노출 및 보호 요구 사항에 따라 시스템 계층과 네트워크 계층의 계층 계층을 분리합니다.
   • 모든 계층에 걸쳐 설계에 따라 테넌트를 강력하게 분리합니다.
   • 사용자 또는 서비스별 리소스 소비 제한
2. 공격 시나리오 예
   • 시나리오 #1: 자격 증명 복구 워크플로에는 NIST 800-63b, OWASP ASVS 및 OWASP Top 10에서 금지하는 “질문과 답변”이 포함될 수 있습니다. 질문과 답변은 두 명 이상의 신원 증거로 신뢰할 수 없습니다. 답을 알 수 있으므로 금지됩니다. 이러한 코드는 제거하고 보다 안전한 설계로 대체해야 합니다.
   • 시나리오 #2: 영화관 체인에서는 단체 예약 할인을 허용하며 보증금을 요구하기 전까지 최대 15명의 참석자가 있습니다. 공격자는 이러한 흐름을 위협적으로 모델링하고 몇 번의 요청으로 600석과 모든 영화관을 한 번에 예약할 수 있는지 테스트하여 막대한 수입 손실을 초래할 수 있습니다.
   • 시나리오 #3: 소매 체인의 전자 상거래 웹사이트는 경매 웹사이트를 재판매하기 위해 고급 비디오 카드를 구매하는 암표상이 운영하는 봇으로부터 보호할 수 없습니다. 이는 비디오 카드 제조업체와 소매 체인 소유자에게 끔찍한 평판을 안겨주고 어떤 가격으로도 이 카드를 얻을 수 없는 열성팬들 사이에서 지속적인 불화를 불러일으킵니다. 사용 가능한지 몇 초 이내에 이루어진 구매와 같은 신중한 안티 봇 설계 및 도메인 논리 규칙은 허위 구매를 식별하고 그러한 거래를 거부할 수 있습니다.

A08:2021 – 소프트웨어 및 데이터 무결성 오류(Software and Data Integrity Failures)

1. 예방하는 방법
   • 디지털 서명이나 유사한 메커니즘을 사용하여 소프트웨어나 데이터가 예상 소스에서 나온 것인지, 변경되지 않았는지 확인하세요.
   • npm 또는 Maven과 같은 라이브러리 및 종속성이 신뢰할 수 있는 저장소를 사용하고 있는지 확인하세요. 위험 프로필이 더 높은 경우에는 검증을 거쳐 알려진 양호한 내부 저장소를 호스팅하는 것이 좋습니다.
   • OWASP 종속성 검사 또는 OWASP CycloneDX와 같은 소프트웨어 공급망 보안 도구를 사용하여 구성 요소에 알려진 취약점이 포함되어 있지 않은지 확인하십시오.
   • 소프트웨어 파이프라인에 악성 코드나 구성이 유입될 가능성을 최소화하기 위해 코드 및 구성 변경 사항에 대한 검토 프로세스가 있는지 확인하세요.
   • 빌드 및 배포 프로세스를 통해 흐르는 코드의 무결성을 보장하기 위해 CI/CD 파이프라인에 적절한 분리, 구성 및 액세스 제어가 있는지 확인하십시오.
   • 직렬화된 데이터의 변조 또는 재생을 감지하기 위한 어떤 형태의 무결성 검사나 디지털 서명 없이 서명되지 않거나 암호화되지 않은 직렬화된 데이터가 신뢰할 수 없는 클라이언트에 전송되지 않도록 합니다.
2. 공격 시나리오 예
   • 시나리오 #1 서명 없는 업데이트: 많은 홈 라우터, 셋톱 박스, 장치 펌웨어 등은 서명된 펌웨어를 통해 업데이트를 확인하지 않습니다. 서명되지 않은 펌웨어는 점점 더 공격자의 표적이 되고 있으며 더욱 악화될 것으로 예상됩니다. 향후 버전에서 수정하고 이전 버전이 만료될 때까지 기다리는 것 외에는 수정할 메커니즘이 없기 때문에 이는 주요 관심사입니다.
   • 시나리오 #2 SolarWinds 악성 업데이트: 국가는 업데이트 메커니즘을 공격하는 것으로 알려져 있으며, 최근 주목할만한 공격은 SolarWinds Orion 공격입니다. 소프트웨어를 개발하는 회사는 안전한 빌드 및 업데이트 무결성 프로세스를 갖추고 있었습니다. 그럼에도 불구하고 이들은 전복될 수 있었고 몇 달 동안 회사는 18,000개 이상의 조직에 고도로 표적화된 악성 업데이트를 배포했으며 그 중 약 100개 정도가 영향을 받았습니다. 이는 역사상 가장 광범위하고 중대한 위반 중 하나입니다.
   • 시나리오 #3 안전하지 않은 역직렬화: React 애플리케이션이 Spring Boot 마이크로서비스 세트를 호출합니다. 함수형 프로그래머로서 그들은 코드가 변경되지 않도록 노력했습니다. 그들이 생각해낸 해결책은 사용자 상태를 직렬화하고 이를 각 요청과 함께 앞뒤로 전달하는 것입니다. 공격자는 “rO0” Java 개체 서명(base64)을 발견하고 Java Serial Killer 도구를 사용하여 응용 프로그램 서버에서 원격 코드 실행을 얻습니다.

A10:2021 – 서버측 요청 위조(Server-Side Request Forgery, SSRF)

1. 네트워크 계층에서 예방하는 방법
   • SSRF의 영향을 줄이기 위해 별도의 네트워크에서 원격 리소스 액세스 기능을 분할합니다.
   • 필수적인 인트라넷 트래픽을 제외한 모든 트래픽을 차단하려면 “deny by default” 방화벽 정책이나 네트워크 액세스 제어 규칙을 시행하십시오.
2. 애플리케이션 계층에서 예방하는 방법
   • 클라이언트가 제공한 모든 입력 데이터를 정리하고 검증합니다.
   • “positive access list“을 사용하여 URL 스키마, 포트 및 대상을 적용합니다.
   • 클라이언트에게 원시 응답(raw response)을 보내지 마십시오.
   • HTTP 리디렉션 비활성화
   • DNS 리바인딩 및 “time of check, time of use” (TOCTOU) 경쟁 조건(race condition)과 같은 공격을 방지하려면 URL 일관성에 유의하세요.
   • 거부 목록이나 정규식을 사용하여 SSRF를 완화하지 마세요. 공격자는 거부 목록을 우회할 수 있는 페이로드 목록, 도구 및 기술을 보유하고 있습니다.
3. 공격 시나리오 예
   공격자는 SSRF를 사용하여 다음과 같은 시나리오를 사용하여 웹 애플리케이션 방화벽, 방화벽 또는 네트워크 ACL 뒤에서 보호되는 시스템을 공격할 수 있습니다.
   • 시나리오 #1: 내부 서버 포트 스캔 – 네트워크 아키텍처가 분할되지 않은 경우 공격자는 내부 네트워크를 매핑하고 연결 결과나 연결 경과 시간 또는 SSRF 페이로드 연결 거부를 통해 내부 서버에서 포트가 열려 있는지 또는 닫혀 있는지 확인할 수 있습니다.
   • 시나리오 #2:file:///etc/passwd 민감한 데이터 노출 – 공격자는 로컬 파일이나 내부 서비스에 액세스하여 및 와 같은 민감한 정보를 얻을 수 있습니다 http://localhost:28017/.
   • 시나리오 #3: 클라우드 서비스의 메타데이터 스토리지 액세스 – 대부분의 클라우드 제공업체는 http://169.254.169.254/. 공격자는 메타데이터를 읽어 중요한 정보를 얻을 수 있습니다.
   • 시나리오 #4: 내부 서비스 손상 – 공격자는 내부 서비스를 악용하여 RCE(원격 코드 실행) 또는 DoS(서비스 거부)와 같은 추가 공격을 수행할 수 있습니다.