블로그

OWASP 톱 10의 새로운 위험 범주: 예상치 못한 상황 예상하기

게시일 : 2025년 12월 01일
마지막 업데이트: 2025년 12월 01일

OWASP가 2025년 상위 10대 리스크를 발표함에 따라 기업들은 특히 주의해야 할 몇 가지 새로운 위험 카테고리가 생겼는데, 여기에는 모르는 것이 실제로 피해를 줄 수 있다는 것을 단번에 증명하는 새로운 카테고리가 포함되어 있습니다.

새로운 카테고리인 예외적 상황의 잘못된 처리에서는 조직이 비정상적이거나 예측할 수 없는 상황을 예방, 감지 및 대응할 준비가 되어 있지 않을 때 어떤 문제가 발생할 수 있는지를 설명합니다. OWASP에 따르면 이 취약점은 애플리케이션이 비정상적인 상황이 발생하는 것을 방지하지 않거나, 문제가 발생했을 때 이를 식별하지 못하거나, 예상치 못한 상황이 발생했을 때 제대로 대응하지 못하거나 전혀 대응하지 않을 때 발생할 수 있습니다. 

기업이 예상하지 못한 상황에 대비해야 한다는 생각은 고도로 분산되고 상호 연결된 오늘날의 시스템 현실을 반영합니다. 예외적 상황의 잘못된 처리에는 24개의 공통 약점 열거 (CWE)가 포함되어 있기 때문에 OWASP가 전혀 들어본 적 없는 문제에 대해 이야기하는 것은 아닙니다. 부적절한 오류 처리, 이벤트 열기 실패, 논리적 오류 및 기타 시나리오를 포함하는 이러한 CWE는 비정상적인 조건에서 발생할 수 있습니다. 예를 들어 부적절한 입력 유효성 검사, 함수 처리의 높은 수준의 오류, 일관성 없는(또는 존재하지 않는) 예외 처리로 인해 발생할 수 있습니다. "애플리케이션이 다음 명령을 확신할 수 없을 때마다 예외 조건이 잘못 처리된 것입니다."라고 OWASP는 말합니다.

이러한 예외적인 상황으로 인해 시스템이 예측할 수 없는 상태에 빠지면 시스템 충돌, 예기치 않은 동작 및 오래 지속되는 보안 취약점이 발생할 수 있습니다. 이러한 종류의 중단을 방지하는 핵심은 기본적으로 최악의 상황을 예상하고 예상치 못한 상황이 발생할 때마다 대비할 수 있는 계획을 세우는 것입니다.

[동영상 보기]

예외적인 상황과 상위 10위권의 진화

웹 애플리케이션 보안에 가장 심각한 위험을 나타내는 4년에 한 번씩 발표되는 상위 10대 목록의 구성은 수년 동안 상당히 안정적이었으며, 일부 카테고리는 목록에서 이동하고 4년마다 한두 개씩 추가되기도 했습니다. 2025년에는 예외적 조건의 잘못된 처리(10위)를 포함하여 두 가지 항목이 새로 추가되었습니다. 3위를 차지한 소프트웨어 공급망 장애는 이전 카테고리인 취약하고 오래된 구성 요소 (2021년 6위)를 확장한 것으로, 이제 광범위한 소프트웨어 손상을 포함합니다. (점수를 매기는 분들을 위해, 액세스 제어 실패가 여전히 1위의 위험으로 남아 있습니다). 

최신 카테고리를 구성하는 예외적인 조건은 로직 버그, 오버플로, 사기 거래, 메모리, 타이밍, 인증, 권한 부여 및 기타 요인에 대한 문제 등 다양한 취약성을 야기할 수 있습니다. 이러한 유형의 취약점은 시스템 또는 데이터의 기밀성, 가용성, 무결성에 영향을 미칠 수 있습니다. 예를 들어 공격자는 애플리케이션의 결함이 있는 오류 처리를 조작하여 취약점을 악용할 수 있다고 OWASP는 설명합니다. 

예기치 않은 상황을 처리하지 못하는 한 가지 예는 애플리케이션이 서비스 거부 공격 중에 파일이 업로드되는 동안 예외를 식별했지만 이후 리소스를 해제하지 못하는 경우입니다. 이 경우 리소스가 잠겨 있거나 사용할 수 없는 상태로 유지되어 리소스가 고갈됩니다. 공격자가 다단계 금융 거래에 침입하는 경우, 오류가 감지된 후에도 거래를 롤백하지 않는 시스템에서는 공격자가 사용자의 계정을 탈취할 수 있습니다. 거래 도중에 오류가 발견되면 전체 거래를 롤백하고 다시 시작하는 '실패 종료'를 하는 것이 매우 중요합니다. 중간에 트랜잭션을 복구하려고 하면 복구할 수 없는 실수가 발생할 수 있습니다.

실패 닫힘 대 실패 열기

그렇다면 이 두 가지 작업의 차이점은 무엇일까요? 명확히 알아봅시다:

개방 실패: 시스템이 '개방 실패'하면 계속 작동하거나 문제가 발생해도 '개방' 상태로 유지됩니다. 이 기능은 계속 실행하는 것이 매우 중요할 때 유용하지만 보안상 위험할 수 있습니다.

폐쇄 실패: 시스템이 '폐쇄 실패'하면 문제가 발생했을 때 자동으로 종료되거나 보안 상태가 됩니다. 이는 무단 액세스를 방지하는 데 도움이 되므로 보안 측면에서 더 안전합니다.

예기치 않은 오류 처리

이러한 위험을 방지하려면 미지의 상황에 대비하는 것부터 시작해야 합니다. 여기에는 시스템 오류가 발생했을 때 이를 감지하고 문제 해결을 위한 조치를 취할 수 있어야 합니다. 공격자에게 중요한 정보를 노출하지 않고 사용자에게 적절히 알리고, 이벤트를 기록하며, 필요한 경우 경고를 발령할 수 있어야 합니다. 

다음은 인젝션 지점을 식별하는 데 사용할 수 있는 사이트 설치 경로와 함께 SQL 쿼리 오류를 공개하는 예시입니다:

경고: odbc_fetch_array()는 매개 변수 /1이 D:\app\index_new.php의 188줄에 주어진 리소스, 부울일 것으로 기대합니다.

이상적인 시스템에는 모니터링 또는 통합 가시성 도구와 같은 기능과 함께 간과된 오류를 포착하는 글로벌 예외 처리기 또는 진행 중인 공격을 알리는 반복되는 오류나 패턴을 감지하는 기능이 있어야 합니다. 이렇게 하면 기업의 오류 처리 취약점을 이용하려는 공격을 방어하는 데 도움이 될 수 있습니다.

예를 들어 표준 Java 웹 애플리케이션의 경우, 전역 오류 처리기는 web.xml 배포 설명자 수준에서 구성할 수 있습니다(이 경우 Servlet 사양 버전 2.5 이상에서 사용되는 구성).

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

ns="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 

http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

version="3.0">
...
  <error-page>
     <exception-type>java.lang.Exception</exception-type>
     <location>/error.jsp</location>
</error-page>
...
</web-app>

이 작은 코드 블록은 Java 웹 애플리케이션에 백그라운드에서 문제가 발생했을 때 수행해야 할 작업을 알려줍니다. 사용자에게 혼란스러운 오류 메시지나 빈 화면을 표시하는 대신 조용히 문제를 파악하여 사용자 지정 오류 페이지로 전송합니다. 이 경우 해당 페이지는 error.jsp입니다.

일반적인 java.lang.Exception 유형을 처리하도록 설정되어 있기 때문에 전체 앱의 마스터 오류 처리기 역할을 합니다. 즉, 오류가 발생하는 위치에 상관없이 사용자는 원시 기술 세부 정보가 표시되는 대신 친숙하고 일관된 동일한 오류 페이지로 리디렉션됩니다.

예상치 못한 상황 방지

조직은 가능한 한 예외적인 상황이 발생하지 않도록 노력하는 것이 가장 이상적입니다. 예를 들어 속도 제한, 리소스 할당량, 스로틀링 및 기타 제한을 구현하면 서비스 거부 및 무차별 대입 공격을 방지하는 데 도움이 될 수 있습니다. 동일하게 반복되는 오류를 식별하여 자동화된 로깅 및 모니터링을 방해하지 않도록 통계로만 포함할 수 있습니다. 시스템에는 다음과 같은 기능도 포함되어야 합니다:

엄격한 입력 유효성 검사를 통해 올바르게 형성되고 위생 처리된 데이터만 워크플로에 입력되도록 합니다. 이는 데이터 흐름의 초기 단계, 즉 데이터가 수신되는 즉시 이루어져야 합니다.

오류 처리 모범 사례를 통해 오류가 발생한 곳에서 바로 잡을 수 있습니다. 오류는 효율적으로 처리해야 합니다: 사용자에게 로그를 보관하고 필요한 경우 알림을 보내야 한다고 명확히 알려야 합니다. 글로벌 오류 처리기는 놓친 오류를 포착하는 데도 이상적입니다. 

일반적인 거래 안전도 필수입니다. 문제가 발생하면 항상 "실패한 트랜잭션"을 롤백하세요. 트랜잭션을 중간에 수정하려고 하면 더 큰 문제가 발생할 수 있습니다.

중앙 집중식 로깅, 모니터링 및 알림과 함께 글로벌 예외 처리기를 사용하면 사건을 신속하게 조사하고 이벤트를 일관된 프로세스로 처리하는 동시에 규정 준수 요건을 더 쉽게 충족할 수 있습니다.

프로젝트의 설계 단계에서 수행되는 위협 모델링 및/또는 보안 설계 검토.

코드 검토 또는 정적 분석은 물론 최종 시스템에 대한 스트레스, 성능 및 침투 테스트도 수행합니다.

예외적 상황의 잘못된 처리는 새로운 범주일 수 있지만 사이버 보안의 몇 가지 기본 원칙을 포함하며 기업이 반드시 예상하지 못한 상황에 대비해야 하는 이유를 강조합니다. 예외적인 상황이 어떤 형태로 나타날지는 알 수 없지만 반드시 발생한다는 것은 알고 있습니다. 핵심은 모든 상황을 동일한 방식으로 처리할 수 있도록 준비하여 피할 수 없는 상황이 발생했을 때 이러한 상황을 더 쉽게 감지하고 대응할 수 있도록 하는 것입니다. 

SCW 신뢰 점수™ 사용자참고 사항 :

OWASP 상위 10 2025 표준에 맞춰 Learning Platform 콘텐츠를 업데이트함에 따라 풀스택 개발자의 신뢰 점수가 약간 조정될 수 있습니다. 궁금한 점이 있거나 지원이 필요한 경우 고객 성공 담당자에게 문의하시기 바랍니다.

리소스 보기
리소스 보기

OWASP Top 10 2025는 예외 조건의 잘못된 처리를 10위에 추가했습니다. "실패 폐쇄" 로직, 전역 오류 처리기, 엄격한 입력 유효성 검사를 통해 위험을 완화합니다.

더 알고 싶으신가요?

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

데모 예약
공유하세요:
저자
게시일: 2025년 12월 01일

공유하세요:

OWASP가 2025년 상위 10대 리스크를 발표함에 따라 기업들은 특히 주의해야 할 몇 가지 새로운 위험 카테고리가 생겼는데, 여기에는 모르는 것이 실제로 피해를 줄 수 있다는 것을 단번에 증명하는 새로운 카테고리가 포함되어 있습니다.

새로운 카테고리인 예외적 상황의 잘못된 처리에서는 조직이 비정상적이거나 예측할 수 없는 상황을 예방, 감지 및 대응할 준비가 되어 있지 않을 때 어떤 문제가 발생할 수 있는지를 설명합니다. OWASP에 따르면 이 취약점은 애플리케이션이 비정상적인 상황이 발생하는 것을 방지하지 않거나, 문제가 발생했을 때 이를 식별하지 못하거나, 예상치 못한 상황이 발생했을 때 제대로 대응하지 못하거나 전혀 대응하지 않을 때 발생할 수 있습니다. 

기업이 예상하지 못한 상황에 대비해야 한다는 생각은 고도로 분산되고 상호 연결된 오늘날의 시스템 현실을 반영합니다. 예외적 상황의 잘못된 처리에는 24개의 공통 약점 열거 (CWE)가 포함되어 있기 때문에 OWASP가 전혀 들어본 적 없는 문제에 대해 이야기하는 것은 아닙니다. 부적절한 오류 처리, 이벤트 열기 실패, 논리적 오류 및 기타 시나리오를 포함하는 이러한 CWE는 비정상적인 조건에서 발생할 수 있습니다. 예를 들어 부적절한 입력 유효성 검사, 함수 처리의 높은 수준의 오류, 일관성 없는(또는 존재하지 않는) 예외 처리로 인해 발생할 수 있습니다. "애플리케이션이 다음 명령을 확신할 수 없을 때마다 예외 조건이 잘못 처리된 것입니다."라고 OWASP는 말합니다.

이러한 예외적인 상황으로 인해 시스템이 예측할 수 없는 상태에 빠지면 시스템 충돌, 예기치 않은 동작 및 오래 지속되는 보안 취약점이 발생할 수 있습니다. 이러한 종류의 중단을 방지하는 핵심은 기본적으로 최악의 상황을 예상하고 예상치 못한 상황이 발생할 때마다 대비할 수 있는 계획을 세우는 것입니다.

[동영상 보기]

예외적인 상황과 상위 10위권의 진화

웹 애플리케이션 보안에 가장 심각한 위험을 나타내는 4년에 한 번씩 발표되는 상위 10대 목록의 구성은 수년 동안 상당히 안정적이었으며, 일부 카테고리는 목록에서 이동하고 4년마다 한두 개씩 추가되기도 했습니다. 2025년에는 예외적 조건의 잘못된 처리(10위)를 포함하여 두 가지 항목이 새로 추가되었습니다. 3위를 차지한 소프트웨어 공급망 장애는 이전 카테고리인 취약하고 오래된 구성 요소 (2021년 6위)를 확장한 것으로, 이제 광범위한 소프트웨어 손상을 포함합니다. (점수를 매기는 분들을 위해, 액세스 제어 실패가 여전히 1위의 위험으로 남아 있습니다). 

최신 카테고리를 구성하는 예외적인 조건은 로직 버그, 오버플로, 사기 거래, 메모리, 타이밍, 인증, 권한 부여 및 기타 요인에 대한 문제 등 다양한 취약성을 야기할 수 있습니다. 이러한 유형의 취약점은 시스템 또는 데이터의 기밀성, 가용성, 무결성에 영향을 미칠 수 있습니다. 예를 들어 공격자는 애플리케이션의 결함이 있는 오류 처리를 조작하여 취약점을 악용할 수 있다고 OWASP는 설명합니다. 

예기치 않은 상황을 처리하지 못하는 한 가지 예는 애플리케이션이 서비스 거부 공격 중에 파일이 업로드되는 동안 예외를 식별했지만 이후 리소스를 해제하지 못하는 경우입니다. 이 경우 리소스가 잠겨 있거나 사용할 수 없는 상태로 유지되어 리소스가 고갈됩니다. 공격자가 다단계 금융 거래에 침입하는 경우, 오류가 감지된 후에도 거래를 롤백하지 않는 시스템에서는 공격자가 사용자의 계정을 탈취할 수 있습니다. 거래 도중에 오류가 발견되면 전체 거래를 롤백하고 다시 시작하는 '실패 종료'를 하는 것이 매우 중요합니다. 중간에 트랜잭션을 복구하려고 하면 복구할 수 없는 실수가 발생할 수 있습니다.

실패 닫힘 대 실패 열기

그렇다면 이 두 가지 작업의 차이점은 무엇일까요? 명확히 알아봅시다:

개방 실패: 시스템이 '개방 실패'하면 계속 작동하거나 문제가 발생해도 '개방' 상태로 유지됩니다. 이 기능은 계속 실행하는 것이 매우 중요할 때 유용하지만 보안상 위험할 수 있습니다.

폐쇄 실패: 시스템이 '폐쇄 실패'하면 문제가 발생했을 때 자동으로 종료되거나 보안 상태가 됩니다. 이는 무단 액세스를 방지하는 데 도움이 되므로 보안 측면에서 더 안전합니다.

예기치 않은 오류 처리

이러한 위험을 방지하려면 미지의 상황에 대비하는 것부터 시작해야 합니다. 여기에는 시스템 오류가 발생했을 때 이를 감지하고 문제 해결을 위한 조치를 취할 수 있어야 합니다. 공격자에게 중요한 정보를 노출하지 않고 사용자에게 적절히 알리고, 이벤트를 기록하며, 필요한 경우 경고를 발령할 수 있어야 합니다. 

다음은 인젝션 지점을 식별하는 데 사용할 수 있는 사이트 설치 경로와 함께 SQL 쿼리 오류를 공개하는 예시입니다:

경고: odbc_fetch_array()는 매개 변수 /1이 D:\app\index_new.php의 188줄에 주어진 리소스, 부울일 것으로 기대합니다.

이상적인 시스템에는 모니터링 또는 통합 가시성 도구와 같은 기능과 함께 간과된 오류를 포착하는 글로벌 예외 처리기 또는 진행 중인 공격을 알리는 반복되는 오류나 패턴을 감지하는 기능이 있어야 합니다. 이렇게 하면 기업의 오류 처리 취약점을 이용하려는 공격을 방어하는 데 도움이 될 수 있습니다.

예를 들어 표준 Java 웹 애플리케이션의 경우, 전역 오류 처리기는 web.xml 배포 설명자 수준에서 구성할 수 있습니다(이 경우 Servlet 사양 버전 2.5 이상에서 사용되는 구성).

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

ns="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 

http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

version="3.0">
...
  <error-page>
     <exception-type>java.lang.Exception</exception-type>
     <location>/error.jsp</location>
</error-page>
...
</web-app>

이 작은 코드 블록은 Java 웹 애플리케이션에 백그라운드에서 문제가 발생했을 때 수행해야 할 작업을 알려줍니다. 사용자에게 혼란스러운 오류 메시지나 빈 화면을 표시하는 대신 조용히 문제를 파악하여 사용자 지정 오류 페이지로 전송합니다. 이 경우 해당 페이지는 error.jsp입니다.

일반적인 java.lang.Exception 유형을 처리하도록 설정되어 있기 때문에 전체 앱의 마스터 오류 처리기 역할을 합니다. 즉, 오류가 발생하는 위치에 상관없이 사용자는 원시 기술 세부 정보가 표시되는 대신 친숙하고 일관된 동일한 오류 페이지로 리디렉션됩니다.

예상치 못한 상황 방지

조직은 가능한 한 예외적인 상황이 발생하지 않도록 노력하는 것이 가장 이상적입니다. 예를 들어 속도 제한, 리소스 할당량, 스로틀링 및 기타 제한을 구현하면 서비스 거부 및 무차별 대입 공격을 방지하는 데 도움이 될 수 있습니다. 동일하게 반복되는 오류를 식별하여 자동화된 로깅 및 모니터링을 방해하지 않도록 통계로만 포함할 수 있습니다. 시스템에는 다음과 같은 기능도 포함되어야 합니다:

엄격한 입력 유효성 검사를 통해 올바르게 형성되고 위생 처리된 데이터만 워크플로에 입력되도록 합니다. 이는 데이터 흐름의 초기 단계, 즉 데이터가 수신되는 즉시 이루어져야 합니다.

오류 처리 모범 사례를 통해 오류가 발생한 곳에서 바로 잡을 수 있습니다. 오류는 효율적으로 처리해야 합니다: 사용자에게 로그를 보관하고 필요한 경우 알림을 보내야 한다고 명확히 알려야 합니다. 글로벌 오류 처리기는 놓친 오류를 포착하는 데도 이상적입니다. 

일반적인 거래 안전도 필수입니다. 문제가 발생하면 항상 "실패한 트랜잭션"을 롤백하세요. 트랜잭션을 중간에 수정하려고 하면 더 큰 문제가 발생할 수 있습니다.

중앙 집중식 로깅, 모니터링 및 알림과 함께 글로벌 예외 처리기를 사용하면 사건을 신속하게 조사하고 이벤트를 일관된 프로세스로 처리하는 동시에 규정 준수 요건을 더 쉽게 충족할 수 있습니다.

프로젝트의 설계 단계에서 수행되는 위협 모델링 및/또는 보안 설계 검토.

코드 검토 또는 정적 분석은 물론 최종 시스템에 대한 스트레스, 성능 및 침투 테스트도 수행합니다.

예외적 상황의 잘못된 처리는 새로운 범주일 수 있지만 사이버 보안의 몇 가지 기본 원칙을 포함하며 기업이 반드시 예상하지 못한 상황에 대비해야 하는 이유를 강조합니다. 예외적인 상황이 어떤 형태로 나타날지는 알 수 없지만 반드시 발생한다는 것은 알고 있습니다. 핵심은 모든 상황을 동일한 방식으로 처리할 수 있도록 준비하여 피할 수 없는 상황이 발생했을 때 이러한 상황을 더 쉽게 감지하고 대응할 수 있도록 하는 것입니다. 

SCW 신뢰 점수™ 사용자참고 사항 :

OWASP 상위 10 2025 표준에 맞춰 Learning Platform 콘텐츠를 업데이트함에 따라 풀스택 개발자의 신뢰 점수가 약간 조정될 수 있습니다. 궁금한 점이 있거나 지원이 필요한 경우 고객 성공 담당자에게 문의하시기 바랍니다.

리소스 보기
리소스 보기

아래 양식을 작성하여 보고서를 다운로드하세요.

우리는 당신에게 우리의 제품 및 / 또는 관련 보안 코딩 주제에 대한 정보를 보낼 수있는 귀하의 허가를 바랍니다. 우리는 항상 최대한의주의를 기울여 귀하의 개인 정보를 취급 할 것이며 마케팅 목적으로 다른 회사에 판매하지 않을 것입니다.

전송
양식을 제출하려면 '분석' 쿠키를 활성화하세요. 완료되면 언제든지 다시 비활성화할 수 있습니다.

OWASP가 2025년 상위 10대 리스크를 발표함에 따라 기업들은 특히 주의해야 할 몇 가지 새로운 위험 카테고리가 생겼는데, 여기에는 모르는 것이 실제로 피해를 줄 수 있다는 것을 단번에 증명하는 새로운 카테고리가 포함되어 있습니다.

새로운 카테고리인 예외적 상황의 잘못된 처리에서는 조직이 비정상적이거나 예측할 수 없는 상황을 예방, 감지 및 대응할 준비가 되어 있지 않을 때 어떤 문제가 발생할 수 있는지를 설명합니다. OWASP에 따르면 이 취약점은 애플리케이션이 비정상적인 상황이 발생하는 것을 방지하지 않거나, 문제가 발생했을 때 이를 식별하지 못하거나, 예상치 못한 상황이 발생했을 때 제대로 대응하지 못하거나 전혀 대응하지 않을 때 발생할 수 있습니다. 

기업이 예상하지 못한 상황에 대비해야 한다는 생각은 고도로 분산되고 상호 연결된 오늘날의 시스템 현실을 반영합니다. 예외적 상황의 잘못된 처리에는 24개의 공통 약점 열거 (CWE)가 포함되어 있기 때문에 OWASP가 전혀 들어본 적 없는 문제에 대해 이야기하는 것은 아닙니다. 부적절한 오류 처리, 이벤트 열기 실패, 논리적 오류 및 기타 시나리오를 포함하는 이러한 CWE는 비정상적인 조건에서 발생할 수 있습니다. 예를 들어 부적절한 입력 유효성 검사, 함수 처리의 높은 수준의 오류, 일관성 없는(또는 존재하지 않는) 예외 처리로 인해 발생할 수 있습니다. "애플리케이션이 다음 명령을 확신할 수 없을 때마다 예외 조건이 잘못 처리된 것입니다."라고 OWASP는 말합니다.

이러한 예외적인 상황으로 인해 시스템이 예측할 수 없는 상태에 빠지면 시스템 충돌, 예기치 않은 동작 및 오래 지속되는 보안 취약점이 발생할 수 있습니다. 이러한 종류의 중단을 방지하는 핵심은 기본적으로 최악의 상황을 예상하고 예상치 못한 상황이 발생할 때마다 대비할 수 있는 계획을 세우는 것입니다.

[동영상 보기]

예외적인 상황과 상위 10위권의 진화

웹 애플리케이션 보안에 가장 심각한 위험을 나타내는 4년에 한 번씩 발표되는 상위 10대 목록의 구성은 수년 동안 상당히 안정적이었으며, 일부 카테고리는 목록에서 이동하고 4년마다 한두 개씩 추가되기도 했습니다. 2025년에는 예외적 조건의 잘못된 처리(10위)를 포함하여 두 가지 항목이 새로 추가되었습니다. 3위를 차지한 소프트웨어 공급망 장애는 이전 카테고리인 취약하고 오래된 구성 요소 (2021년 6위)를 확장한 것으로, 이제 광범위한 소프트웨어 손상을 포함합니다. (점수를 매기는 분들을 위해, 액세스 제어 실패가 여전히 1위의 위험으로 남아 있습니다). 

최신 카테고리를 구성하는 예외적인 조건은 로직 버그, 오버플로, 사기 거래, 메모리, 타이밍, 인증, 권한 부여 및 기타 요인에 대한 문제 등 다양한 취약성을 야기할 수 있습니다. 이러한 유형의 취약점은 시스템 또는 데이터의 기밀성, 가용성, 무결성에 영향을 미칠 수 있습니다. 예를 들어 공격자는 애플리케이션의 결함이 있는 오류 처리를 조작하여 취약점을 악용할 수 있다고 OWASP는 설명합니다. 

예기치 않은 상황을 처리하지 못하는 한 가지 예는 애플리케이션이 서비스 거부 공격 중에 파일이 업로드되는 동안 예외를 식별했지만 이후 리소스를 해제하지 못하는 경우입니다. 이 경우 리소스가 잠겨 있거나 사용할 수 없는 상태로 유지되어 리소스가 고갈됩니다. 공격자가 다단계 금융 거래에 침입하는 경우, 오류가 감지된 후에도 거래를 롤백하지 않는 시스템에서는 공격자가 사용자의 계정을 탈취할 수 있습니다. 거래 도중에 오류가 발견되면 전체 거래를 롤백하고 다시 시작하는 '실패 종료'를 하는 것이 매우 중요합니다. 중간에 트랜잭션을 복구하려고 하면 복구할 수 없는 실수가 발생할 수 있습니다.

실패 닫힘 대 실패 열기

그렇다면 이 두 가지 작업의 차이점은 무엇일까요? 명확히 알아봅시다:

개방 실패: 시스템이 '개방 실패'하면 계속 작동하거나 문제가 발생해도 '개방' 상태로 유지됩니다. 이 기능은 계속 실행하는 것이 매우 중요할 때 유용하지만 보안상 위험할 수 있습니다.

폐쇄 실패: 시스템이 '폐쇄 실패'하면 문제가 발생했을 때 자동으로 종료되거나 보안 상태가 됩니다. 이는 무단 액세스를 방지하는 데 도움이 되므로 보안 측면에서 더 안전합니다.

예기치 않은 오류 처리

이러한 위험을 방지하려면 미지의 상황에 대비하는 것부터 시작해야 합니다. 여기에는 시스템 오류가 발생했을 때 이를 감지하고 문제 해결을 위한 조치를 취할 수 있어야 합니다. 공격자에게 중요한 정보를 노출하지 않고 사용자에게 적절히 알리고, 이벤트를 기록하며, 필요한 경우 경고를 발령할 수 있어야 합니다. 

다음은 인젝션 지점을 식별하는 데 사용할 수 있는 사이트 설치 경로와 함께 SQL 쿼리 오류를 공개하는 예시입니다:

경고: odbc_fetch_array()는 매개 변수 /1이 D:\app\index_new.php의 188줄에 주어진 리소스, 부울일 것으로 기대합니다.

이상적인 시스템에는 모니터링 또는 통합 가시성 도구와 같은 기능과 함께 간과된 오류를 포착하는 글로벌 예외 처리기 또는 진행 중인 공격을 알리는 반복되는 오류나 패턴을 감지하는 기능이 있어야 합니다. 이렇게 하면 기업의 오류 처리 취약점을 이용하려는 공격을 방어하는 데 도움이 될 수 있습니다.

예를 들어 표준 Java 웹 애플리케이션의 경우, 전역 오류 처리기는 web.xml 배포 설명자 수준에서 구성할 수 있습니다(이 경우 Servlet 사양 버전 2.5 이상에서 사용되는 구성).

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

ns="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 

http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

version="3.0">
...
  <error-page>
     <exception-type>java.lang.Exception</exception-type>
     <location>/error.jsp</location>
</error-page>
...
</web-app>

이 작은 코드 블록은 Java 웹 애플리케이션에 백그라운드에서 문제가 발생했을 때 수행해야 할 작업을 알려줍니다. 사용자에게 혼란스러운 오류 메시지나 빈 화면을 표시하는 대신 조용히 문제를 파악하여 사용자 지정 오류 페이지로 전송합니다. 이 경우 해당 페이지는 error.jsp입니다.

일반적인 java.lang.Exception 유형을 처리하도록 설정되어 있기 때문에 전체 앱의 마스터 오류 처리기 역할을 합니다. 즉, 오류가 발생하는 위치에 상관없이 사용자는 원시 기술 세부 정보가 표시되는 대신 친숙하고 일관된 동일한 오류 페이지로 리디렉션됩니다.

예상치 못한 상황 방지

조직은 가능한 한 예외적인 상황이 발생하지 않도록 노력하는 것이 가장 이상적입니다. 예를 들어 속도 제한, 리소스 할당량, 스로틀링 및 기타 제한을 구현하면 서비스 거부 및 무차별 대입 공격을 방지하는 데 도움이 될 수 있습니다. 동일하게 반복되는 오류를 식별하여 자동화된 로깅 및 모니터링을 방해하지 않도록 통계로만 포함할 수 있습니다. 시스템에는 다음과 같은 기능도 포함되어야 합니다:

엄격한 입력 유효성 검사를 통해 올바르게 형성되고 위생 처리된 데이터만 워크플로에 입력되도록 합니다. 이는 데이터 흐름의 초기 단계, 즉 데이터가 수신되는 즉시 이루어져야 합니다.

오류 처리 모범 사례를 통해 오류가 발생한 곳에서 바로 잡을 수 있습니다. 오류는 효율적으로 처리해야 합니다: 사용자에게 로그를 보관하고 필요한 경우 알림을 보내야 한다고 명확히 알려야 합니다. 글로벌 오류 처리기는 놓친 오류를 포착하는 데도 이상적입니다. 

일반적인 거래 안전도 필수입니다. 문제가 발생하면 항상 "실패한 트랜잭션"을 롤백하세요. 트랜잭션을 중간에 수정하려고 하면 더 큰 문제가 발생할 수 있습니다.

중앙 집중식 로깅, 모니터링 및 알림과 함께 글로벌 예외 처리기를 사용하면 사건을 신속하게 조사하고 이벤트를 일관된 프로세스로 처리하는 동시에 규정 준수 요건을 더 쉽게 충족할 수 있습니다.

프로젝트의 설계 단계에서 수행되는 위협 모델링 및/또는 보안 설계 검토.

코드 검토 또는 정적 분석은 물론 최종 시스템에 대한 스트레스, 성능 및 침투 테스트도 수행합니다.

예외적 상황의 잘못된 처리는 새로운 범주일 수 있지만 사이버 보안의 몇 가지 기본 원칙을 포함하며 기업이 반드시 예상하지 못한 상황에 대비해야 하는 이유를 강조합니다. 예외적인 상황이 어떤 형태로 나타날지는 알 수 없지만 반드시 발생한다는 것은 알고 있습니다. 핵심은 모든 상황을 동일한 방식으로 처리할 수 있도록 준비하여 피할 수 없는 상황이 발생했을 때 이러한 상황을 더 쉽게 감지하고 대응할 수 있도록 하는 것입니다. 

SCW 신뢰 점수™ 사용자참고 사항 :

OWASP 상위 10 2025 표준에 맞춰 Learning Platform 콘텐츠를 업데이트함에 따라 풀스택 개발자의 신뢰 점수가 약간 조정될 수 있습니다. 궁금한 점이 있거나 지원이 필요한 경우 고객 성공 담당자에게 문의하시기 바랍니다.

웨비나 보기
시작

아래 링크를 클릭하여 이 자료의 PDF를 다운로드하세요.

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

보고서 보기데모 예약
리소스 보기
공유하세요:
더 알고 싶으신가요?

공유하세요:
저자
게시일: 2025년 12월 01일

공유하세요:

OWASP가 2025년 상위 10대 리스크를 발표함에 따라 기업들은 특히 주의해야 할 몇 가지 새로운 위험 카테고리가 생겼는데, 여기에는 모르는 것이 실제로 피해를 줄 수 있다는 것을 단번에 증명하는 새로운 카테고리가 포함되어 있습니다.

새로운 카테고리인 예외적 상황의 잘못된 처리에서는 조직이 비정상적이거나 예측할 수 없는 상황을 예방, 감지 및 대응할 준비가 되어 있지 않을 때 어떤 문제가 발생할 수 있는지를 설명합니다. OWASP에 따르면 이 취약점은 애플리케이션이 비정상적인 상황이 발생하는 것을 방지하지 않거나, 문제가 발생했을 때 이를 식별하지 못하거나, 예상치 못한 상황이 발생했을 때 제대로 대응하지 못하거나 전혀 대응하지 않을 때 발생할 수 있습니다. 

기업이 예상하지 못한 상황에 대비해야 한다는 생각은 고도로 분산되고 상호 연결된 오늘날의 시스템 현실을 반영합니다. 예외적 상황의 잘못된 처리에는 24개의 공통 약점 열거 (CWE)가 포함되어 있기 때문에 OWASP가 전혀 들어본 적 없는 문제에 대해 이야기하는 것은 아닙니다. 부적절한 오류 처리, 이벤트 열기 실패, 논리적 오류 및 기타 시나리오를 포함하는 이러한 CWE는 비정상적인 조건에서 발생할 수 있습니다. 예를 들어 부적절한 입력 유효성 검사, 함수 처리의 높은 수준의 오류, 일관성 없는(또는 존재하지 않는) 예외 처리로 인해 발생할 수 있습니다. "애플리케이션이 다음 명령을 확신할 수 없을 때마다 예외 조건이 잘못 처리된 것입니다."라고 OWASP는 말합니다.

이러한 예외적인 상황으로 인해 시스템이 예측할 수 없는 상태에 빠지면 시스템 충돌, 예기치 않은 동작 및 오래 지속되는 보안 취약점이 발생할 수 있습니다. 이러한 종류의 중단을 방지하는 핵심은 기본적으로 최악의 상황을 예상하고 예상치 못한 상황이 발생할 때마다 대비할 수 있는 계획을 세우는 것입니다.

[동영상 보기]

예외적인 상황과 상위 10위권의 진화

웹 애플리케이션 보안에 가장 심각한 위험을 나타내는 4년에 한 번씩 발표되는 상위 10대 목록의 구성은 수년 동안 상당히 안정적이었으며, 일부 카테고리는 목록에서 이동하고 4년마다 한두 개씩 추가되기도 했습니다. 2025년에는 예외적 조건의 잘못된 처리(10위)를 포함하여 두 가지 항목이 새로 추가되었습니다. 3위를 차지한 소프트웨어 공급망 장애는 이전 카테고리인 취약하고 오래된 구성 요소 (2021년 6위)를 확장한 것으로, 이제 광범위한 소프트웨어 손상을 포함합니다. (점수를 매기는 분들을 위해, 액세스 제어 실패가 여전히 1위의 위험으로 남아 있습니다). 

최신 카테고리를 구성하는 예외적인 조건은 로직 버그, 오버플로, 사기 거래, 메모리, 타이밍, 인증, 권한 부여 및 기타 요인에 대한 문제 등 다양한 취약성을 야기할 수 있습니다. 이러한 유형의 취약점은 시스템 또는 데이터의 기밀성, 가용성, 무결성에 영향을 미칠 수 있습니다. 예를 들어 공격자는 애플리케이션의 결함이 있는 오류 처리를 조작하여 취약점을 악용할 수 있다고 OWASP는 설명합니다. 

예기치 않은 상황을 처리하지 못하는 한 가지 예는 애플리케이션이 서비스 거부 공격 중에 파일이 업로드되는 동안 예외를 식별했지만 이후 리소스를 해제하지 못하는 경우입니다. 이 경우 리소스가 잠겨 있거나 사용할 수 없는 상태로 유지되어 리소스가 고갈됩니다. 공격자가 다단계 금융 거래에 침입하는 경우, 오류가 감지된 후에도 거래를 롤백하지 않는 시스템에서는 공격자가 사용자의 계정을 탈취할 수 있습니다. 거래 도중에 오류가 발견되면 전체 거래를 롤백하고 다시 시작하는 '실패 종료'를 하는 것이 매우 중요합니다. 중간에 트랜잭션을 복구하려고 하면 복구할 수 없는 실수가 발생할 수 있습니다.

실패 닫힘 대 실패 열기

그렇다면 이 두 가지 작업의 차이점은 무엇일까요? 명확히 알아봅시다:

개방 실패: 시스템이 '개방 실패'하면 계속 작동하거나 문제가 발생해도 '개방' 상태로 유지됩니다. 이 기능은 계속 실행하는 것이 매우 중요할 때 유용하지만 보안상 위험할 수 있습니다.

폐쇄 실패: 시스템이 '폐쇄 실패'하면 문제가 발생했을 때 자동으로 종료되거나 보안 상태가 됩니다. 이는 무단 액세스를 방지하는 데 도움이 되므로 보안 측면에서 더 안전합니다.

예기치 않은 오류 처리

이러한 위험을 방지하려면 미지의 상황에 대비하는 것부터 시작해야 합니다. 여기에는 시스템 오류가 발생했을 때 이를 감지하고 문제 해결을 위한 조치를 취할 수 있어야 합니다. 공격자에게 중요한 정보를 노출하지 않고 사용자에게 적절히 알리고, 이벤트를 기록하며, 필요한 경우 경고를 발령할 수 있어야 합니다. 

다음은 인젝션 지점을 식별하는 데 사용할 수 있는 사이트 설치 경로와 함께 SQL 쿼리 오류를 공개하는 예시입니다:

경고: odbc_fetch_array()는 매개 변수 /1이 D:\app\index_new.php의 188줄에 주어진 리소스, 부울일 것으로 기대합니다.

이상적인 시스템에는 모니터링 또는 통합 가시성 도구와 같은 기능과 함께 간과된 오류를 포착하는 글로벌 예외 처리기 또는 진행 중인 공격을 알리는 반복되는 오류나 패턴을 감지하는 기능이 있어야 합니다. 이렇게 하면 기업의 오류 처리 취약점을 이용하려는 공격을 방어하는 데 도움이 될 수 있습니다.

예를 들어 표준 Java 웹 애플리케이션의 경우, 전역 오류 처리기는 web.xml 배포 설명자 수준에서 구성할 수 있습니다(이 경우 Servlet 사양 버전 2.5 이상에서 사용되는 구성).

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

ns="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 

http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

version="3.0">
...
  <error-page>
     <exception-type>java.lang.Exception</exception-type>
     <location>/error.jsp</location>
</error-page>
...
</web-app>

이 작은 코드 블록은 Java 웹 애플리케이션에 백그라운드에서 문제가 발생했을 때 수행해야 할 작업을 알려줍니다. 사용자에게 혼란스러운 오류 메시지나 빈 화면을 표시하는 대신 조용히 문제를 파악하여 사용자 지정 오류 페이지로 전송합니다. 이 경우 해당 페이지는 error.jsp입니다.

일반적인 java.lang.Exception 유형을 처리하도록 설정되어 있기 때문에 전체 앱의 마스터 오류 처리기 역할을 합니다. 즉, 오류가 발생하는 위치에 상관없이 사용자는 원시 기술 세부 정보가 표시되는 대신 친숙하고 일관된 동일한 오류 페이지로 리디렉션됩니다.

예상치 못한 상황 방지

조직은 가능한 한 예외적인 상황이 발생하지 않도록 노력하는 것이 가장 이상적입니다. 예를 들어 속도 제한, 리소스 할당량, 스로틀링 및 기타 제한을 구현하면 서비스 거부 및 무차별 대입 공격을 방지하는 데 도움이 될 수 있습니다. 동일하게 반복되는 오류를 식별하여 자동화된 로깅 및 모니터링을 방해하지 않도록 통계로만 포함할 수 있습니다. 시스템에는 다음과 같은 기능도 포함되어야 합니다:

엄격한 입력 유효성 검사를 통해 올바르게 형성되고 위생 처리된 데이터만 워크플로에 입력되도록 합니다. 이는 데이터 흐름의 초기 단계, 즉 데이터가 수신되는 즉시 이루어져야 합니다.

오류 처리 모범 사례를 통해 오류가 발생한 곳에서 바로 잡을 수 있습니다. 오류는 효율적으로 처리해야 합니다: 사용자에게 로그를 보관하고 필요한 경우 알림을 보내야 한다고 명확히 알려야 합니다. 글로벌 오류 처리기는 놓친 오류를 포착하는 데도 이상적입니다. 

일반적인 거래 안전도 필수입니다. 문제가 발생하면 항상 "실패한 트랜잭션"을 롤백하세요. 트랜잭션을 중간에 수정하려고 하면 더 큰 문제가 발생할 수 있습니다.

중앙 집중식 로깅, 모니터링 및 알림과 함께 글로벌 예외 처리기를 사용하면 사건을 신속하게 조사하고 이벤트를 일관된 프로세스로 처리하는 동시에 규정 준수 요건을 더 쉽게 충족할 수 있습니다.

프로젝트의 설계 단계에서 수행되는 위협 모델링 및/또는 보안 설계 검토.

코드 검토 또는 정적 분석은 물론 최종 시스템에 대한 스트레스, 성능 및 침투 테스트도 수행합니다.

예외적 상황의 잘못된 처리는 새로운 범주일 수 있지만 사이버 보안의 몇 가지 기본 원칙을 포함하며 기업이 반드시 예상하지 못한 상황에 대비해야 하는 이유를 강조합니다. 예외적인 상황이 어떤 형태로 나타날지는 알 수 없지만 반드시 발생한다는 것은 알고 있습니다. 핵심은 모든 상황을 동일한 방식으로 처리할 수 있도록 준비하여 피할 수 없는 상황이 발생했을 때 이러한 상황을 더 쉽게 감지하고 대응할 수 있도록 하는 것입니다. 

SCW 신뢰 점수™ 사용자참고 사항 :

OWASP 상위 10 2025 표준에 맞춰 Learning Platform 콘텐츠를 업데이트함에 따라 풀스택 개발자의 신뢰 점수가 약간 조정될 수 있습니다. 궁금한 점이 있거나 지원이 필요한 경우 고객 성공 담당자에게 문의하시기 바랍니다.

목차

PDF 다운로드
리소스 보기
더 알고 싶으신가요?

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

데모 예약다운로드
공유하세요:
리소스 허브

시작할 수 있는 리소스

더 많은 게시물
리소스 허브

시작할 수 있는 리소스

더 많은 게시물