04 - Insecure Design

https://owasp.org/Top10/A04_2021-Insecure_Design/

개요

OWASP Top 10 2021 중 4위로 올라간 Insecure Design (안전하지 않은 설계) 이다.

• 필요한 보안 제어가 설계 단계에서 바쪘거나 효과적으로 설계되지 않은 취약점을 포괄하는 개념이다.
• 다른 Top10 항목들의 원인은 아니다. 설계와 구현은 다르며, 원인과 해결책도 다르다.
• 코드 작성 단계에서의 실수와 달리, 설계 단계에서 필요한 보안 제어가 아예 없거나 잘못 정의된 경우 문제가 생긴다.
• 보안 제어가 존재하지 않는 상태에서 구현을 시작하면, 나중에 고치기 매우 어렵다. 그렇기에 코드 단계 에서는 막을 수 없는 경우가 많다.

발생 원인

• 데이터 민감도, 노출 범위 등을 설계 단계에서 제대로 분석,반영하지 않은 경우.
• 보안 요구사항 (기밀성, 무결성, 기용성, 진위성 등)이 기술 요건에 포함되지 않을 경우.
• 위협 모델링(시슽템을 설계할 때, 어떤 공격이 가능한지 미리 생각하고 분석해 대책을 세우는 과정) 과 같은 사전 활동이 부족하거나, 유지보수,변경 시 위협 모델이 갱신되지 않을 경우.
• 예산이나 자원의 미확보로 설계 단계에서 보안 활동이 배제된 경우.

공격 예시

• 비밀번호 회복 (Q&A 방식)
  • 질문에 답을 하면 비밀번호를 제공하는 방식은 신뢰할 수 없다.
  • 타인이 답을 알고있거나 소셜엔지니어링을 통할 경우 계정 탈취가 가능하다.
• 대량 예약/ 자원 소모
  • 예를들어 10명이상 단체 예약 시 20%를 할인해 주는 이벤트 중, 1만명 분의 예약을 시도할 경우이다.
  • 예약 최대 인원이 없고, 한 사람이 여러번 예약할 수 있을 때 발생한다.
  • 실제 결제를 하지 않더라도, 시스템 상 정상 고객들의 예약이 어려워진다.
  • 코드에서 버그가 발생한 것이 아닌, 설계 단계에서 보안규칙을 정하지 않았기 때문에 생긴 문제이다.
• 스칼퍼 봇 (자동화된 비정상 구매)
  • 온라인 쇼핑몰같은 아커머스 사이트에서 자동으로 상품을 빠르게 대량구매하는 프로그램이다.
  • 한정판, 신상품, 인기 있는 상품을 사람보다 훨씬 빠르게 구매해서 정당한 소비자의 구매 기회를 뺏는다.

권고사항

• 애플리케이션의 비즈니스 요구사항을 수집하고, 데이터 자산의 기밀성,무결성,가용성,진위성 보호 수준을 협의해야 한다.
• 시스템의 노출 정도 및 테넌트 격리(하나의 서버를 여러 고객이 동시에 사용하는 멀티테넌트 완경에서 다른 사용자나 조직의 데이터와 기능이 섞이지 않도록 분리하는 것) 필요 여부를 고려해야 한다.
• 기능적 요구사항뿐 아니라 비기능적(보안) 요구사항도 문서화 해야하며, 보안 활동을 위한 예산 계획도 포함해야 한다.

방지 방법

• 초기부터 보안 고려
  • 기획/요구수집 단계부터 보안 전문가와 함께 설계한다.
  • 요구서에 보안 요구사항을 정확히 명시한다.
• 위협 모델링 필수화
  • 인증,권한,핵심 비즈니스 로직 흐름에 대해 정기적으로 위협 모델링을 수행한다.
  • 예상 실패 시나리오까지 문서화한다.
• 보안 설계 패턴/구성요소 재사용
  • 검증된 보안 설계 패턴과 사내,공식 라이브러리를 사용해 '잘못된 설계'를 줄인다.
• 입증 가능한 설계 작성
  • 각 핵심 흐름에 대해 단위/통합 테스트와 오용 케이스 테스트를 작성한다.
• 계층 분리 및 테넌트 격리 설계
  • 노출 범위에 따라 네트워크/애플리케이션 계층을 분리하고, 멀티테넌시 설계시 강력한 격리를 적용한다.
  • 계층을 분리하면 하나가 공격받아도 다른 계층은 공격받지 않도록 방어선을 여러 겹 쌓는 효과가 있다.
• 리소스,요청 제한 설계
  • 요청 빈도,자원 사용을 제한해 논리적 오용을 막는다.
• 문서화와 주기적 검토
  • 설계 가정, 실패 흐름을 문서로 남기고 정기적으로 검토한다.

안전한 설계 (Secure Design)

• 안전한 설계는 단순히 도구를 추가하는 게 아니라, 지속적으로 위협을 평가하고 코드가 공격에 강하게 설계되도록 하는 문화와 방법론이다.
• 위협 모델링은 User Story 리파인먼트 단계 (요구사항을 개발 가능한 수준으로 세분화하는 과정) 에 통합되어야 하고, 데이터 흐름이나 접근 제어 변화가 있을때마다 이를 반영해야 한다.

실습 환경

PortSwigger Web Security Academy - Lab: Excessive trust in client-side controls
(https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-excessive-trust-in-client-side-controls)

문제 설명

이 랩은 사용자의 입력을 제대로 검증하지 않는다. 논리적 결함을 악용하여 의도치 않은 가격으로 상품을 구매할 수 있다.
'가벼운 133t 가죽 재킷' 을 구매하시오.

공격 과정 요약

1. 주어진 아이디/비밀번호로 로그인을 한다. wiener:peter
2. 현재 계정의 크레딧은 $100 가 있다. 가죽 재킷의 원가는 $1337.00 로, 구매할 수 없는 상황이다. 따라서 재킷의 가격을 조작하여야 함을 유추해볼 수 있다.
3. Burp 를 실행하여 주문 과정을 살펴 보았다.
4. 장바구니에 상품울 추가할 때 해당 요청에 price=133700 이 포함되어 있는걸 확인할 수 있다.
   
5. price 가격을 $100d 이하의 임의의 정수로 변경한 후 요청을 전송한다.

6. 장바구니를 확인해 보니 가격이 $0.01 로 변경된걸 확인할 수 있다.

7. 성공적으로 주문을 완료하였다.

발생한 보안 문제

• 서버가 클라이언트의 입력값을 신뢰하였다. 따라서 공격자가 가격을 임의로 조작이 가능하였다.
• 이는 클라이언트 신뢰 문제이며, 서버측에서 가격,권한,유효성 검증 등을 적절히 설계,구현하지 않은 것이 원인이다.
• 비즈니스 로직이 설계 단계부터 "클라이언트가 보내는 가격 값을 신뢰하지 않고, 서버에서 가격을 다시 검증,계산해야 한다'는 요구사항이 누락된 상황이다.
• 즉, 필수적인 보안 검증 절차가 설계에 포함되지 않아 논리적 결함이 발생하였다.

배운 점

• 보안은 설계 단계부터 확실하게 반영되어야 함을 배웠다. 특히 비즈니스 로직의 핵심 요소는 설계 요구사항에 반드시 포함되어야 하며, 설계가 부실할 경우 코드 수정만으로는 해결이 어렵다는 것을 배웠다.
• 단순한 코드 오류로 보안 사고가 발생할 수도 있지만, 시스템 동작 원리 자체에 보안 문제가 있을 수 있으므로 비즈니스 로직 분석과 위협 모델링이 필수라는 것을 배웠다.
• 설계와 구현단계는 당연하고, 운영 단계에서도 지속적인 보안 모니터링이 필요함을 배웠다.
• 보안은 단순한 추가 기능이 아닌, 개발 전반적으로 꼭 고려되어야 할 필수불가결한 요소임을 배웠다.