웹 애플리케이션 보안: 정찰, 공격, 방어 세 단계로 배우는 웹 애플리케이션 보안의 모든 것

148

1

부

정찰

●

구성 (예: 콘텐츠 보안 정책 (

CSP

))

●

인증/세션 관리 시스템

이 목록을 완성하면 애플리케이션을 해킹하거나 취약점을 찾을 때 우선순위를 설정하는 데 사

용할 수 있다.

일반적인 생각과 다르게 웹 애플리케이션의 취약점 대부분은 부실하게 작성된 메서드보다

는 부적절하게 설계된 애플리케이션 아키텍처에서 생겨난다. 물론 사용자가 제공한

HTML

을

DOM

에 직접 기록하는 메서드는 사용자가 스크립트를 업로드하여 (적절히 정제되지 않는 경

우) 다른 사용자의 머신에서 그 스크립트를 실행(

XSS

)하게 될 수 있어 확실히 위험하다.

하지만 같은 분야의 비슷한 규모의 애플리케이션 중에도 취약점이 거의 없는 것이 있는가 하면

수십 가지

XSS

취약점이 있는 애플리케이션도 있다. 궁극적으로 애플리케이션의 아키텍처와

그 애플리케이션의 모듈·의존성의 아키텍처는 어느 취약점이 발생할 수 있는 약점이 있는지

를 잘 드러내는 지표다.

7.1

보안 아키텍처와 비보안 아키텍처

앞서 언급한 것과 같이

XSS

취약점이 한 가지 있다면 허술하게 작성된 메서드 때문에 생긴 것

으로 볼 수 있다. 하지만 여러 개의 취약점이 발생하는 것은 애플리케이션 아키텍처가 약하기

때문일 수 있다.

사용자 사이에 메시지 (텍스트 )를 보낼 수 있는 간단한 애플리케이션이 두 가지 있다고 상상해

보자. 두 애플리케이션 중 하나는

XSS

에 취약하고 다른 하나는 그렇지 않다.

안전하지 않은 애플리케이션은

API

엔드포인트에 댓글을 저장하는 요청이 만들어질 때 스크립

트를 거부하지