설계단계 보안설계기준-웹 기반 중요 기능 수행 요청 유효성 검증

작성일: 230623

 

※ 본 게시글은 학습 목적으로 행정안전부·KISA의 소프트웨어 보안약점 진단 가이드, 소프트웨어 개발보안 가이드를 참고하여 작성하였습니다.

 

정리 내용: 소프트웨어 보안약점 진단 가이드(71~75p)

 

유형	입력데이터 검증 및 표현
설계항목	웹 기반 중요 기능 수행 요청 유효성 검증
설명	비밀번호 변경, 결제 등 사용자 권한 확인이 필요한 중요기능을 수행할 때 웹 서비스 요청에 대한 유효성 검증방법 설계 및 유효하지 않은 값에 대한 처리방법을 설계해야 한다.
보안대책	① 시스템으로 전송되는 모든 요청에 대해 정상적인 사용자의 유효한 요청인지, 아닌지 여부를 판별할 수 있도록 해야 한다.
연관된 구현단계	- 크로스사이트 요청 위조 https://cryptocurrencyclub.tistory.com/120

 

가. 취약점 개요

 

ㅇ 위 내용을 볼 때, 예상 가능한 보안 위협: 이건 모르겠다

    - 공격자는 세션탈취, XSS 등으로 자신이 의도한 행위(수정, 삭제, 등록 등)를 사이트가 신뢰하는 인증된 사용자의 권한으로 실행되게 할 수 있다.

크로스 사이트 요청 위조(출처: 소프트웨어 보안약점 진단 가이드 2021, 행정안전부·KISA)

 

  →  왜 크로스사이트에서의 크로스사이트는 XS고 크로스 사이트 요청 위조에서는 CS?? CSS랑 혼용하면 헷갈려서 그런가?

  →  희생자의 응답값은 무시하고 공격자가 삽입한 기능이 실행되도록 위조하나봄. 위 예시처럼 희생자 P/W변경하거나 송금기능을 실행 시 공격자 계정으로 송금하는 등?

 

 

나. 설계시 고려사항

 

① 시스템에서 전송되는 모든 요청에 대해 정상적인 사용자의 유효한 요청인지 아닌지 여부를 판별할 수 있도록 해야 한다.

• CSRF 토큰 사용: 웹은 URL 기반으로 요청을 처리하는 구조이다. 해당 요청이 특정 사용자의 정상적인 요청인지를 구분하기 위한 정책이 없는 경우, 스크립트나 자동화된 도구에 의해 보내지는 요청이 검증절차 없이 처리될 수 있다. 그래서, 해당 요청이 정상적인 사용자의 정상적인 절차에 의한 요청인지를 구분하기 위해 세션별로 CSRF 토큰을 생성하여 세션에 저장하고, 사용자가 작업페이지를 요청할 때마다 hidden값으로 클라이언트에게 토큰을 전달한 뒤, 해당 클라이언트의 데이터 처리 요청 시 전달되는 CSRF 토큰값과 세션에 저장된 토큰값을 비교하여 유효성을 검사하도록 설계한다. CSRF 토큰값에 대한 검사 방법은 MVC프레임워크의 컴포넌트를 이용하여 데이터 처리 요청 수신 시 자동으로 검사될 수 있도록 설계한다. Spring이나 Struts와 같은 MVC프레임워크의 경우 사용자의 요청을 중간 에 가로채서 값의 유효성을 검사할 수 있는 Interceptor 컴포넌트를 이용하여 파라미터로 전달된 CSRF 토큰값이 세션에 저장된 토큰값과 동일한지를 검사하여 동일한 경우만 요청이 처리될 수 있도록 설계한다.

 

  →  글이 긴데, 주요 내용은 실제 웹서비스 사용자가 웹서비스와 상호작용을 하는게 맞는지 검증하기 위해 CSRF토큰을 삽입해놓고 상호작용할때마다 토큰값을 인터셉터 후 확인하여 삽입한 값과 동일한지 확인(아닌 경우에는 사용자가 정상적으로 보낸 요청이 아니니까 걸러야함.)

  →  신규 세션 오픈마다 세션키 발급하는거랑 비슷한 듯?

 

• 사용자와 상호 처리 기능 적용: CSRF 토큰 방식도 XSS 취약점이 있는 사이트를 공격하게 되면 무력화될 수 있으므로 CAPTCHA와 같은 사용자와 상호 처리 가능한 기법을 적용하여 위조된 요청이 차단될 수 있도록 설계한다.
• 재인증 요구: 중요기능의 경우 재인증으로 안전하게 실제 요청 여부를 확인하도록 설계한다.

  →  여기서 말하는 XSS는 Stored XSS인듯?

 

 

CSRF 방지를 위한 설계 시 고려사항 (출처: 소프트웨어 보안약점 진단 가이드 2021, 행정안전부·KISA)

 

 

다. 진단 세부사항

 

 ① 시스템으로 전송되는 모든 요청에 대해 정상적인 사용자의 유효한 요청인지, 아닌지 판별할 수 있도록 확인하는 절차가 있는지 확인한다.

  ㅇ  데이터 처리 요청(request)에 대한 정상적인 절차에 따른 요청인지를 검증하는 기능의 설계 여부 확인

    → CSRF 토큰 사용

    → CAPTCHA 이용

 

  ㅇ  요청 유효성 점검 기능이 안전하게 적용되도록 설계되어 있는지 확인

    → 모든 데이터 처리 요청에 적용

    → 각 데이터를 처리하는 기능에서 적용

 

  ㅇ  주요 기능에 대해 재인증/재인가 처리 방법과 모듈 설계 여부 확인

  ㅇ  데이터 처리를 요청하는 주요기능이 자동화된 스크립트나 프로그램을 이용한 자동 요청을 식별하여 요청이 차단되는지를 점검할 수 있는 테스트 계획의 수립 여부 확인

 

 

끝.