소프트웨어 개발보안 가이드 (제 3장, 분석ㆍ설계단계 SW 보안강화 활동) (5)

SOO·2021년 2월 17일
0

설계보안항목 정의 및 설계시 고려사항

에러처리 설계항목과 세션통제 설계항목은 내용이 길지 않아 한 포스트에 정리하였습니다.

3. 에러처리 설계항목

1) 예외처리

취약점 개요

  • 중요 기능이나 리소스 요청 시 인증이 되었는지를 먼저 확인하지 않고 요청을 처리하여 중요 정보나 리소스가 노출 (적절한 인증 없는 중요기능 허용)
  • 시스템 정보 노출
    시스템, 관리자, DB정보 등 시스템의 내부 데이터가 공개되면 공격자에게 또다른 공격의 빌미를 제공하게 됨

설계 시 고려사항

1) 명시적 예외의 경우 예외처리 블럭을 이용하여 예외 발생 시 수행하야 하는 기능 구현

  • ex) 자바 플랫폼 사용 시
    프로그램에서 발생된 에러 정보를 로깅하는 Logger API를 활용할 수 있도록 시큐어 코딩 규칙 정의

2) 런타임 예외의 경우 입력값의 범위를 체크하여 애플리케이션이 정상적으로 동작할 수 있는 값만 사용되도록 보장

  • 입력값에 따라 예외가 발생 가능한 경우 입력값의 범위를 체크하여 사용하도록 시큐어 코딩 규칙 정의

3) 에러 발생 시 상세한 에러 정보가 사용자에게 노출되지 않도록 해야 함

  • 에러 발생 시 지정된 페이지를 통해 사용자에게 에러 공지

  • ex) web.xml 파일을 이용하여 에러 시 지정된 페이지 응답

<!‐‐ error 페이지 ‐‐>
<error‐page>
<error‐code>404</error‐code>
<location>/WEB‐INF/jsp/common/error/404error.jsp</location>
</error‐page>
<error‐page>
<error‐code>500</error‐code>
<location>/WEB‐INF/jsp/common/error/500error.jsp</location>
</error‐page>
<error‐page>
<exception‐type>java.lang.Throwable</exception‐type>
<location>/WEB‐INF/jsp/common/error/error.jsp</location>
</error‐page>
  • 사용자에게 보내지는 오류메시지에 중요 정보가 포함되지 않도록 함

4. 세션통제 설계항목

1) 세션통제

취약점 개요

  • 불충분한 세션 관리
    인증 시 일정한 규칙이 존재하는 세션 ID가 발급되거나 세션 타임아웃을 너무 길게 설정한 경우 공격자에 의해 사용자 권한이 도용될 수 있는 취약점
  • 잘못된 세션에 의한 정보 노출
    다중 스레드 환경에서는 싱글톤(Singleton)객체 필드에 경쟁 조건(Race Condition)이 발생 가능. 따라서 다중 스레드 환경인 java의 서블릿(Servlet)등에서 정보를 저장하는 멤버변수가 포함되지 않도록 하여 서로 다른 세션간에 데이터를 공유하지 않도록 해야 함
    • (*멀티 쓰레딩: 하나의 프로세스를 다수의 실행 단위로 구분하여 자원을 공유하고 자원의 생성과 관리의 중복성을 최소화하여 수행능력을 향상시키는 것)
    • (*멀티 쓰레드: 하나의 프로그램에 동시에 여러 개의 일을 수행할 수 있도록 해 줌)
    • (*경쟁조건(Race Condition): 병행 프로세스에서의 자원 경쟁. 병행 시스템에서 프로세스가 두 개 이상의 동작을 동시에 수행하려고 할 때 발생하는 비정상적 상태)

설계 시 고려사항

1) 세션 간 데이터가 공유되지 않도록 설계

  • 스레드로 동작하는 웹애플리케이션의 컨트롤러 컴포넌트나, 싱글톤 객체로 생성되는 서비스 컴포넌트를 설계하는 경우 클래스 설계 시 읽고 쓰기가 가능한 변수를 사용하지 않도록 설계

2) 세션이 안전하게 관리되도록 설계

  • 로그아웃을 요청하면 사용자에게 할당된 세션을 완전히 제거하는 API를 사용하도록 개발가이드 구현단계 작성

    Java의 경우 session.invalidate() 메소드를 사용하여 세션에 저장된 정보를 완전히 제거할 수 있다.

  • 웹 브라우저 종료로 인한 세션 종료는 서버 측에서 인지가 불가능. 따라서 일정 시간동안 사용되지 않는 세션 정보는 강제적으로 삭제되도록 아키텍처링

  • 중복 로그인을 허용하지 않는 경우, 새로운 로그인 세션 생성 시 이전에 생성된 로그인 세션을 종료하거나, 새로이 연결되는 세션을 종료하도록 하는 정책을 설계단계에 고려

  • 사용자가 패스워드를 변경하는 경우 현재 활성화된 세션을 삭제하고 다시 할당

3) 세션 ID가 안전하게 관리되도록 설계

  • 세션 ID 생성
    • 세션 ID는 안전한 서버에서 생성하여 사용
    • 세션 ID는 최소 128비트의 길이로 안전한 난수 알고리즘을 적용하여 예측이 불가능한 값을 사용
  • 세션 ID 사용
    • URL Rewrite 기능을 사용하는 경우 세션 ID가 URL에 노출될 수 있으므로 사용하지 않도록 설계
  • 세션 ID 폐기
    • 로그인 성공 시 로그인 전에 할당받은 세션 ID는 파기하고 새로운 값으로 재할당하여 세션 ID 고정 공격에 대응하도록 시큐어 코딩 규칙 정의
    • 장기간 접속의 경우 세션 ID의 노출위험이 커지므로 일정시간 주기적으로 세션 ID를 재할당하도록 설계

1개의 댓글

comment-user-thumbnail
2021년 2월 17일

정리 잘하셨네요 잘보고가요

답글 달기