OWASP란??

Open Web Application Security Project의 줄임말로 전 세계 기업, 교육기간 및 개인이 만들어가는 오픈소스 애플리케이션 보안 프로젝트입니다!

OWASP Top Ten이란??

데이터 기반으로 선정되지만 10개 중 2개는 Top 10 커뮤니티 설문조사 결과를 토대로 고른 것이다.

데이터는 상용 보안 테스트 업체, 버그 바운티 플랫폼, 내부 테스트 데이터를 보유한 조직 등으로부터 제공 받는다.
해당 데이터들이 어느 카테고리에 속하는지 분석하고 발생률이 가장 높은 8개 카테고리를 우선적으로 검토한다.

커뮤니티 설문조사를 통해 데이터에 아직 반영되지 않은 항목 중 상위 득표 2개를 추가로 선정하여 총 10개를 완성한다.

해당 표는 2017 결과에서 변동된 내용들입니다. 2021년도 결과로 2025년도는 올해 늦여름 혹은 가을초에 공개될 예상입니다. 그 중에서 Top 5를 알아보자!

1. Broken Access Control

접근 제어 실패를 의미한다. 접근 제어란 사용자가 허용된 범위 내에서만 시스템 리소스에 접근하도록 보장하는 메커니즘이다.

1.1 예시

1.1.1 권한 없는 정보 노출, 수정, 삭제

GET /app/accountInfo?id=1111
DELETE /app/accountInfo?id=1111

PUT /app/accountInfo?id=1111

공격자는 브라우저 주소창에서 id 값을 2222 등 다른 사용자의 계정 번호로 바꾸어 임의의 계정 정보를 획득, 수정, 삭제를 할 수 있습니다.

1.1.2 권한 상승

로그인한 일반 사용자가 관리자 기능을 실행하거나 비로그인 상태에서 기능을 수행하는 경우를 이야기합니다.

1.1.3 인증 인가 체크 우회

URL 조작(URL 인자 변경, force browsing), 내부 상태, html 조작, API 요청 위조/변조 등으로 인증 인가 체크 우회할 수 있습니다.

발급된 토큰에 "role":"user"가 들어 있는데 공격자가 이 값을 "role": "admin"으로 변경하고 이를 서버에 전송했는데 서버가 서명 검증을 건너 뛰고 토큰을 받아들였을 때 관리자 권한을 획득할 수 있습니다. 유사하게 세션 쿠키 변조 또한 예시로 들 수 있습니다.

1.2 방지 대책

1.2.1 서버 사이드에서만 접근 제어를 구현

공격자가 코드 변경이 불가능한 서버 사이드에서 접근 제어 로직을 구현합니다.

1.2.2 기본 거부 정책(Deny by Default)을 적용한다.

공개 리소스를 제외한 모든 엔드포인트에 대한 기본적인 접근을 차단하고, 명시적으로 허용된 권한만 부여한다.

1.2.3 소유권 기반 권한 검증

내 데이터만 CRUD를 허용해야 합니다.

2. Cryptographic-Failures

암호화 실패를 이야기한다.

2.1 예시

2.1.1 평문 전송 여부

HTTP, FTP 등 평문 프로토콜로 외부 트래픽을 주고 받는 경우를 이야기한다. 트래픽을 스니핑할 경우 그대로 노출된다.

2.1.2 구형 알고리즘을 사용

사용자 비밀번호를 sha-256이 아닌 DES 알고리즘으로 암호화하여 DB에 저장할 경우 DB가 노출될 경우 공격자는 키를 brute-force하여 평문 비밀번호를 획득할 수 있다.

2.1.3 키 관리 실패

하드코딩된 대칭키를 그대로 사용할 경우 공격자가 GitHub 등 공개 저장소에서 키를 발견하고 이를 이용해 암호화된 모든 데이터를 복호화해 민감 정보를 수집한다.

2.1.4 암호화 미강제

웹 서버에 HSTS 설정이 빠져 있어 공격자는 중간자 공격을 통해 HTTPS-> HTTP 다운그레이드시키고 민감 데이터를 가로챌 수 있다.

HSTS(HTTP Strict Transport Security)는 웹 사이트 접속 시 HTTPS만 사용하도록 강제하는 기술이다. HSTS가 적용된 웹 사이트의 웹 서버는 클라이언트에게 HTTPS만을 사용할 수 있음을 알려주고 HSTS를 지원하는 브라우저는 이를 해석하고 적용한다.

2.1.5 비밀번호를 직접 키로 사용

비밀번호를 salting 하지 않고 바로 SHA-256 를 이용해 저장하면 rainbow table을 통해 키를 복원할 수 있다.

2.1.6 난수 시드 문제 (Predictable Random Seed)

CSPRNG 대신java.util.Random(System.currentTimeMillis()) 같은 일반 난수 생성기를 사용한다.

공격자는 서버 시계와 대략적인 요청 시간을 추정해 난수 시드를 예측하고, 생성된 키·IV·토큰 등을 미리 계산해 탈취한다.

2.2 방지 대책

2.2.1 평문 프로토콜은 민감 데이터 전송에 절대 사용하지 않는다.

2.2.2 구식 알고리즘 제거 및 최신, 상력 알고리즘 사용

2.2.3 HSTS 설정을 통해 암호화를 강제한다.

2.2.4 pbkdf2 같은 salt + work factor를 갖춘 키 도출 함수를 이용해, 비밀번호를 안전하게 키나 해시로 변환한다.

2.2.5 시드를 수동 설정하지 말고 암호학적 난수 생성기를 사용한다.

3. Injection

사용자 입력에 의한 취약점을 이야기한다.

3.1 예시

3.1.1 XSS(크로스사이트 스크립팅)

<script>fetch('/steal?c='+document.cookie)</script>

위와 같은 코드를 공격자가 댓글에 넣었을 때 다른 사용자가 페이지를 열면 해당 스크립트가 실행되어 세션 쿠키가 공격자 서버로 전송된다.

3.1.2 SQL Injection

String userInput = "1 OR 1=1";  // 악의적인 입력
String query = "SELECT * FROM users WHERE id = " + userInput;

Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(query);

해당 query는 다음과 같아진다.

SELECT * FROM users WHERE id = 1 OR 1=1 --

이러면 WHERE는 항상 true이기 때문에 모든 유저 정보를 빼오게 된다.

3.1.3 동적 쿼리.명령어.저장 프로시저에 문자열 연결

<?php
  $file = $_GET['file'];  
  // 사용자 입력을 직접 쉘 명령에 연결
  system("cat /var/www/uploads/" . $file);
?>

공격자가 file의 값으로 ../../etc/passwd를 입력하면 system은 전체 비밀번호 파일을 읽는다.

3.2 방지 대책

3.2.1 Positive server-side input validation

허용 목록(allowlist) 기반 검증이라고도 하며 입력값이 이런 값만 들어올 수 있다는 명확한 규칙(패턴, 범위, 값 집합 등)에 부합할 때만 통과시킨다.

반대로 negative(denylist) 방식은 금지된 값만 거부하는데 이는 우회가 쉬워 보안상 권장되지 않는다.

3.2.2 escaping 문자로 변환

HTML 문맥에서 &, <, > 같은 특수문자를 &amp, &lt, &gt으로 변환해준다.

3.2.3 안전한 API 사용하기

대부분의 웹 프레임워크에서 제공하는 내장 escaping 함수를 쓰면 수동 이스케이프 실수를 방지할 수 있다.

Like PreparedStatement

PreparedStatement는 먼저 쿼리 분석을 한 후, 그 다음에 ?에 들어갈 자리에 후처리한 데이터를 끼워넣음으로써 injection을 막는다.

SELECT * FROM users WHERE username = ''' OR ''1''=''1'

쉘 호출 대신, PHP 내장 함수로 파일 읽기 로직을 교체한다.

$file = basename($_GET['file']);  
$path = "/var/www/uploads/".$file;
echo file_get_contents($path);

로 이스케이프를 시켜서 명확히 데이터와 쿼리를 구분 시켜준다.

3.2.4 LIMIT 또는 SQL controls 사용

SELECT * FROM users WHERE id = ? LIMIT 1;

Limit을 추가하여 대량 노출을 방지한다.

4. Insecure Design

설계/아키텍처 단계에서 보안 통제가 누락되거나 효과적으로 설계되지 않은 위험을 이야기한다.

4.1 예시

4.1.1 비즈니스 리스크 프로파일링 미흡

어떤 데이터/기능에 어느 수준의 보호가 필요한지 사전에 분석하지 않아 위험도가 높은 기능에 적절한 통제를 적용하지 않은 것을 이야기한다.

시스템: 전자상거래 사이트의 원클릭 결제 기능
누락된 분석: 고객이 한번 눌러 결제를 확정하는 만큼 높은 금액 거래 시 추가 인증이 필요하다는 리스크를 인지하지 못함
공격: 공격자가 해킹한 사용자로 로그인 후 고가의 상품을 추가 인증없이 결제

4.1.2 위협 모델링 부재

시스템 흐름과 경계를 그려보며 잠재적 공격 벡터를 식별/대응하는 위협 모델링을 하지 않아 내부 서비스 호출·데이터 흐름상의 위험을 놓치는 것을 이야기한다.

영화관 예약 시스템에서 최대 15명까지만 보증금 없이 예약 가능하도록 설계했으나 공격자가 스루풋 자동화로 수백 장을 예약 대규모 금전적 손실 초래하는 것을 예시로 들 수 있다.

4.1.3 보안 요구사항 미반영

기술 요구사항에 “보안”이 빠져, 기능 구현 단계에서 필수적인 보안 검증이 누락되는 것을 이야기한다.

설계 단계에서 “질문-응답” 방식 복구를 도입했으나 금지된 방식이어서 공격자가 공개된 답변으로 계정 탈취한다.

여기서 공개된 답변이란???

• 누구나 알 수 있는 정보
• 소셜미디어, 인터넷 검색 등으로 쉽게 찾을 수 있는 정보
• 일반적으로 많이 쓰이는 흔한 답변

4.2 방지 대책

4.2.1 Secure Development Lifecycle 수립

보안 전문가와 함께 초기 요구사항 단계에서 비즈니스 리스크 프로파일링을 수행하고 고액 거래/환불/환전 등 민감 기능에는 단계별 인증 흐름을 설계에 반영한다.

4.2.2 위협 모델링 수행

시스템, 애플리케이션, 네트워크 등 다양한 IT 자산에 대해 잠재적인 보안 위협과 취약점을 사전에 식별·분석하고, 이에 대한 대응책을 설계하는 체계적인 분석 활동을 수행한다.

4.2.3 서비스별 호출 횟수를 제한한다.

서비스 예약 회출 횟수, 로그인 시도 횟수를 제한하여 자동화 공격을 완화한다.

5. Security Misconfiguration

애플리케이션 스택 전반이나 클라우드 서비스 구성에 대해 적절한 보안 하드닝이 이루어지지 않았거나 불필요한 기능이 활성화된 경우를 이야기한다.

보안 하드닝이란?

컴퓨터 시스템, 네트워크, 애플리케이션 등 IT 환경의 보안을 강화하기 위해 불필요한 요소를 제거하고 취약점을 최소화하며 설정을 최적화하는 일련의 작업을 의미한다.

5.1 예시

5.1.1 기본 계정/비밀번호를 변경하지 않고 그대로 둠

관리자 기본 계정(admin/admin)이 활성화된 채 방치되어 있으면 공격자는 이를 이용하여 로그인할 수 있습니다.

5.1.2 과도하게 상세한 에러 메시지나 스택 트레이스를 사용자에게 노출

내부 SQLException이 발생할 때마다 전체 스택 트레이스를 브라우저에 출력하게 되면 공격자는 데이터베이스 버전, 테이블 구조 등을 확인할 수 있습니다. 이 정보를 기반으로 알려진 취약점을 공략하거나 더 정교한 SQL 인젝션 페이로드 작성을 통해 취약점 공격이 가능합니다.

5.1.3 업그레이드 후 어플리케이션 서버/프레임워크/라이브러리/DB의 설정이 안전하지 않은 값으로 남아 있음

운영 중인 API 서버를 최신 버전으로 업그레이드하면서, 기본 설정 파일이 덮어씌워져 CORS 설정이 Access-Control-Allow-Origin: *로 풀려버렸습니다.

공격자는 이를 이용하여 악성 사이트에 스크립트를 심어 사용자의 세션 정보, 민감 데이터, API 응답 등을 탈취할 수 있다.

5.2 방지 대책

5.2.1 반복 가능한 하드닝 프로세스 수립

5.2.2 보안 지시문 및 예외 처리 정책

사용자에게는 최소한의 에러 메시지만 반환하고 상세 스택 트레이스는 로그로만 남긴다.

참고: OWASP TOP10:2021