OWASP Top 10:2025 RC1 요약하기(부제, 안전한 서비스 구축하기)

​해커들이 가장 좋아하는 웹 취약점 10가지, 우리 서비스는 안전할까요?

 

1. A01: 접근 통제 실패, 왜 여전히 1위일까요?

접근 통제 실패(broken access control)는 owasp top 10에서 가장 위험한 취약점 1위를 유지하고 있어요 . 테스트된 모든 애플리케이션, 즉 100%에서 이 문제가 발견되었다는 사실은 정말 충격적이죠 . 이 취약점은 사용자가 본인의 권한을 넘어 다른 사람의 정보에 접근하거나, 데이터를 마음대로 수정하거나 파괴할 수 있게 만들어요 .

 

이러한 접근 통제 실패는 주로 최소 권한 원칙을 지키지 않아서 발생해요 . 예를 들어, 관리자만 볼 수 있어야 하는 페이지를 일반 사용자도 볼 수 있게 되는 것이죠 . 공격자들은 URL을 바꾸거나(매개변수 변조), api 요청을 수정하는 도구를 사용해서 접근 통제 검사를 쉽게 우회할 수 있어요 . 심지어 다른 사람의 고유 식별자만 알면 그 사람의 계정에 접근할 수 있는 경우도 흔해요 .

 

이런 위험을 막으려면 어떻게 해야 할까요? 가장 중요한 것은 접근 통제 로직을 신뢰할 수 있는 서버 측 코드에서 구현하는 것이에요 . 또한, 공개 리소스를 제외하고는 기본적으로 모든 접근을 거부하는 정책을 적용해야 하죠 . 웹 서버의 디렉토리 리스팅을 비활성화하고, 접근 실패가 발생하면 반드시 로깅하고 관리자에게 알림을 보내야 해요 .

 

 

2. A02: 보안 설정 오류, 왜 이렇게 순위가 올랐을까요?

보안 설정 오류(Security Misconfiguration)는 이전 순위 5위에서 2위로 크게 상승했어요 . 이 취약점 역시 테스트된 애플리케이션의 100%에서 발견되었을 정도로 흔한 문제예요 . 요즘은 클라우드 서비스나 복잡한 소프트웨어를 많이 사용하면서 설정할 부분이 많아졌기 때문에, 실수가 발생하기 쉬워진 것이죠 .

 

설정 오류는 시스템, 애플리케이션, 클라우드 서비스가 보안 관점에서 잘못 설정되었을 때 발생해요 . 예를 들어, 불필요한 기능이나 서비스가 활성화되어 있거나 , 기본 계정과 암호가 그대로 남아있는 경우가 많아요 . 또 다른 문제는 오류 처리 시 사용자에게 스택 추적과 같은 너무 많은 정보를 노출하는 것이에요 . 이런 정보는 공격자에게 중요한 힌트가 될 수 있답니다.

 

이 문제를 예방하려면 반복 가능한 보안 강화 프로세스를 자동화해서 구현해야 해요 . 개발, QA, 프로덕션 환경을 동일하게 설정하고, 각 환경에는 다른 자격 증명을 사용해야 하죠 . 또한, 사용하지 않는 기능이나 프레임워크는 제거하여 최소 플랫폼을 유지하는 것이 중요해요 . 클라우드 저장소(예: S3 버킷)의 권한을 정기적으로 검토하는 것도 잊지 말아야 해요 .

 

3. A03: 소프트웨어 공급망 실패, SolarWinds 같은 일이 또 생길까요?

소프트웨어 공급망 실패(Software Supply Chain Failures)는 커뮤니티 설문조사에서 1위를 차지할 만큼 큰 우려를 낳고 있어요 . 이 위험은 우리가 사용하는 타사 코드, 도구, 라이브러리 등 소프트웨어를 만들고 배포하는 과정 전체에서 발생하는 취약점을 모두 포함해요 .

 

우리가 사용하는 모든 구성 요소의 버전을 꼼꼼하게 추적하지 않거나 , 취약하거나 오래된 OS, 서버, 라이브러리를 사용하는 경우에 취약해질 수 있어요 . 특히, 개발자나 전문가들이 신뢰할 수 없는 출처에서 구성 요소를 다운로드하여 프로덕션에 사용하는 것이 허용된다면 매우 위험하죠 . 2019년 SolarWinds 침해 사건처럼, 신뢰했던 공급업체가 맬웨어에 감염되어 수많은 조직이 피해를 입은 사례가 대표적이에요 .

 

이러한 위험을 막기 위해서는 SBOM(Software Bill of Materials)을 알고 중앙에서 관리하는 패치 관리 프로세스가 필수적이에요 . 또한, 공식적이고 신뢰할 수 있는 출처에서만 구성 요소를 얻어야 하며, 서명된 패키지를 선호해야 하죠 . CI/CD 파이프라인의 모든 구성 요소를 강화하고, 역할 분리와 접근 통제를 적용하는 것도 중요해요 .

 

4. A04: 암호화 실패, 내 비밀번호는 안전할까요?

암호화 실패(Cryptographic Failures)는 순위가 4위로 내려왔지만, 여전히 매우 중요한 문제예요 . 이 취약점은 암호화가 아예 없거나, 너무 약한 암호화를 사용하거나, 암호화 키가 유출되는 등의 오류를 다루고 있어요 .

 

모든 데이터는 전송 중에 전송 계층에서 암호화되어야 하지만 , 민감한 데이터(암호, 신용카드 번호, 개인 정보)는 저장 시에도 추가적인 암호화가 필요해요 . 만약 오래되거나 취약한 암호화 알고리즘을 사용하거나 , 암호화 키가 소스 코드 저장소에 그대로 체크인되어 있다면 문제가 생길 수 있어요 . 특히, 암호화 요구 사항을 충족하지 못하는 무작위성이 암호화 목적으로 사용되는 경우도 위험하죠 .

 

 

우리의 데이터를 보호하려면 어떻게 해야 할까요? 가장 민감한 키는 HSM(Hardware Security Module)에 저장하고 , 잘 신뢰받는 암호화 알고리즘 구현을 사용해야 해요 . 모든 전송 데이터는 TLS와 같은 보안 프로토콜로 암호화하고, HSTS와 같은 지시문을 사용하여 암호화를 강제해야 하죠 . 그리고 암호는 MD5나 SHA1 같은 오래된 방식 대신, Argon2나 scrypt처럼 강력하고 솔트가 적용된 해싱 함수를 사용해서 저장해야 해요 .

 

5. A05: 인젝션, 해커가 내 시스템에 명령을 내릴 수 있나요?

인젝션(Injection)은 순위가 5위로 하락했지만, 여전히 가장 많이 테스트되는 취약점 중 하나예요 . 인젝션은 공격자가 악성 코드나 명령(예: SQL 코드)을 프로그램의 입력 필드에 삽입하여, 시스템이 그 코드를 시스템의 일부인 것처럼 실행하도록 속이는 심각한 결함이에요 .

 

애플리케이션이 사용자 입력 데이터를 검증, 필터링, 정제하지 않을 때 취약해져요 . 특히, 동적 쿼리나 매개변수화되지 않은 호출이 인터프리터에서 직접 사용되는 경우가 가장 위험하죠 . 흔한 인젝션 유형으로는 SQL 인젝션, OS 명령 인젝션, 크로스 사이트 스크립팅(XSS) 등이 있어요 . XSS는 발생 빈도가 높고, SQL 인젝션은 발생 빈도는 낮지만 피해가 매우 크답니다 .

 

인젝션을 막는 가장 좋은 방법은 데이터를 명령 및 쿼리와 분리하는 것이에요 . 안전한 api를 사용하거나, ORM(Object Relational Mapping Tools)으로 마이그레이션하여 인터프리터 사용을 피하는 것이 가장 선호되는 방법이죠 . 만약 데이터를 분리할 수 없다면, 긍정적인 서버 측 입력 유효성 검사를 사용하고, 특수 문자를 해당 인터프리터에 맞게 이스케이프해야 해요 .

 

6. A06: 안전하지 않은 설계, 코드가 완벽해도 문제가 될까요?

안전하지 않은 설계(Insecure Design)는 6위를 차지하고 있어요 . 이 범주는 단순히 코딩 실수(구현 결함)가 아니라, 설계 및 아키텍처 단계에서 발생하는 근본적인 결함에 초점을 맞추고 있죠 . 아무리 코드를 완벽하게 구현해도, 설계 자체가 안전하지 않다면 필요한 보안 통제가 애초에 없었기 때문에 취약점을 고칠 수 없어요 .

 

안전한 설계를 위해서는 세 가지 핵심 요소가 필요해요 . 첫째, 데이터의 기밀성, 무결성, 가용성에 대한 보호 요구 사항을 포함하여 비즈니스 요구 사항을 수집해야 해요 . 둘째, 위협 모델링을 설계 과정에 통합하여 잠재적인 위협을 지속적으로 평가해야 하죠 . 셋째, 안전한 개발 수명 주기를 확보해야 해요 .

 

예를 들어, 자격 증명 복구 워크플로우에 "질문과 답변" 방식이 포함되는 것은 안전하지 않은 설계의 대표적인 예시예요 . 이 방식은 신원 증명으로 신뢰할 수 없기 때문에 더 안전한 설계로 대체되어야 하죠 . 또한, 전자 상거래 웹사이트가 봇에 대한 보호 장치가 없어 스캘퍼들이 상품을 대량으로 구매하게 만드는 것도 비즈니스 로직 설계의 결함이랍니다 .

 

7. A07: 인증 실패, 해커가 내 계정을 훔칠 수 있나요?

인증 실패(Authentication Failures)는 7위를 유지하고 있어요 . 이 취약점은 공격자가 시스템을 속여 잘못된 사용자를 합법적인 사용자로 인식하게 만들 때 발생해요 .

 

요즘 흔한 공격으로는 자격 증명 스터핑(credential stuffing)이 있어요 . 이는 유출된 사용자 이름과 암호 목록을 사용하여 자동화된 공격을 시도하는 것이죠 . 심지어 'Winter2025'를 'Winter2026'으로 바꾸는 하이브리드 공격도 사용된답니다 . 또한, 다단계 인증(MFA)이 없거나 비효율적인 경우 , 또는 로그인 후 세션 ID를 재사용하는 경우에도 취약해질 수 있어요 .

 

이 문제를 막으려면 가능한 한 다단계 인증(MFA)을 구현하고 강제해야 해요 . 또한, 기본 자격 증명을 사용하지 않아야 하며 , 새 암호는 알려진 침해된 자격 증명 목록에 대해 검증해야 하죠 . 세션 관리를 위해서는 로그인 후 높은 엔트로피를 가진 새로운 무작위 세션 ID를 생성하는 서버 측 세션 관리자를 사용해야 해요 .

 

8. A08: 소프트웨어 또는 데이터 무결성 실패, 내 데이터가 변조될까요?

소프트웨어 또는 데이터 무결성 실패(Software or Data Integrity Failures)는 8위를 차지하고 있어요 . 이 범주는 소프트웨어, 코드, 데이터 아티팩트의 무결성을 검증하지 못하는 문제에 중점을 둬요 . 즉, 신뢰할 수 없는 코드나 데이터가 신뢰할 수 있는 것처럼 처리되는 것을 막지 못하는 것이죠 .

 

이 취약점은 애플리케이션이 신뢰할 수 없는 출처의 플러그인이나 라이브러리에 의존할 때 발생할 수 있어요 . 또한, CI/CD 파이프라인이 코드나 아티팩트를 가져올 때 무결성 검사 없이 사용하는 경우에도 문제가 생기죠 . 특히, 많은 애플리케이션이 업데이트를 다운로드할 때 충분한 무결성 검증 없이 적용하는 자동 업데이트 기능을 가지고 있어 공격자가 악성 업데이트를 배포할 수 있어요 .

 

이러한 위험을 방지하려면 디지털 서명과 같은 메커니즘을 사용하여 소프트웨어 또는 데이터가 변조되지 않았음을 확인해야 해요 . 라이브러리와 종속성은 신뢰할 수 있는 저장소만 사용하도록 보장해야 하죠 . 또한, CI/CD 파이프라인이 적절한 분리, 구성 및 접근 통제를 갖도록 하여 코드의 무결성을 보장해야 해요 .

 

9. A09: 로깅 및 알림 실패, 공격을 당해도 모를 수 있나요?

로깅 및 알림 실패(Logging and Alerting Failures)는 9위를 유지하고 있어요 . 이 범주는 공격을 탐지하고 사고에 대응하는 데 필수적인 로깅 및 모니터링의 중요성을 강조해요 . 로깅과 모니터링이 없으면 공격과 데이터 유출을 감지할 수 없기 때문에 매우 위험하죠 .

 

다음과 같은 경우에 로깅 및 알림 실패가 발생해요 : 로그인 실패나 고가치 트랜잭션과 같은 감사 가능한 이벤트가 일관성 없이 로깅되지 않는 경우 . 로그의 무결성이 변조로부터 제대로 보호되지 않는 경우 . 애플리케이션 로그가 의심스러운 활동에 대해 모니터링되지 않는 경우 . 그리고 적절한 알림 임계값 및 대응 프로세스가 마련되어 있지 않은 경우 .

 

우리는 모든 로그인, 접근 통제, 서버 측 입력 유효성 검사 실패가 충분한 사용자 컨텍스트와 함께 로깅되도록 해야 해요 . 로그 데이터는 인젝션 공격을 막기 위해 올바르게 인코딩되어야 하죠 . 또한, 의심스러운 활동이 탐지되면 SOC 팀이 신속하게 대응할 수 있도록 효과적인 모니터링 및 알림 사용 사례를 확립해야 해요 . 공격자를 위한 함정으로 '허니토큰(honeytokens)'을 애플리케이션에 추가하는 것도 좋은 방법이랍니다 .

 

 

10. A10: 예외 조건 미흡 처리, 예상치 못한 상황이 왜 위험할까요?

예외 조건 미흡 처리(Mishandling of Exceptional Conditions)는 2025년에 새롭게 추가된 범주예요 . 이 문제는 프로그램이 예상치 못한 상황을 제대로 처리하지 못해서 충돌, 예상치 못한 동작, 그리고 보안 취약점으로 이어지는 것을 말해요 .

 

이 취약점은 주로 불완전한 입력 유효성 검사나, 오류가 발생한 함수가 아닌 상위 수준에서 오류를 처리하려고 할 때 발생해요 . 애플리케이션이 다음에 무엇을 해야 할지 확신하지 못할 때 예외 조건이 미흡하게 처리된 것이죠 . 이러한 미흡 처리는 논리적 버그, 경쟁 조건, 사기성 트랜잭션 등 다양한 보안 문제를 유발할 수 있어요 .

 

예외 조건을 제대로 처리하려면 최악의 상황을 예상하고 계획해야 해요 . 오류가 발생한 곳에서 즉시 오류를 '포착'하고 처리해야 하죠 . 특히, 트랜잭션 중간에 오류가 발생하면, 트랜잭션의 모든 부분을 롤백하고 다시 시작해야 해요 (안전하게 실패(failing closed)) . 또한, 예외 조건 발생을 처음부터 방지하기 위해 속도 제한, 리소스 할당량과 같은 제한을 설정하는 것이 중요해요 .