반응형
https://www.kisa.or.kr/public/laws/laws3.jsp
분석∙설계단계 SW 보안강화 - 설계보안항목 정의 및 설계 시 고려 사항 - 세션 통제
- 세션은 클라이언트와 서버의 논리적인 연결이다. 이미 연결이 종료된 클라이언트의 정보가 삭제되지 않고 사용가능한 상태로 방치되는 경우 해당 연결을 탈취한 허가되지 않은 사용자에 의해 시스템의 기능이 사용되거나 다른 개인의 중요정보에 접근하는 침해사고를 발생시킬 수 있으므로 안전한 세션 통제 정책이 적용되어야 한다. 또한 사용자를 구분하기 위한 세션ID를 안전하게 관리하지 않으면 세션하이재킹과 같은 공격으로 허가되지 않은 사용자가 시스템을 사용할 수 있게 되므로 반드시 안전 하게 관리해야 한다.
설명
- 다른 세션 간 데이터 공유 금지, 세션 ID 노출 금지, (재)로그인 시 세션 ID 변경, 세션 종료(비활성화, 유효기간 등) 처리 등 세션을 안전하게 관리할 수 있는 방안을 설계해야 한다.
설계항목내용
- 세션 간 데이터가 공유되지 않도록 설계해야 한다.
- 세션이 안전하게 관리되도록 해야 한다.
- 세션 ID가 안전하게 관리되도록 해야 한다.
가. 취약점 개요
사례 1: 불충분한 세션 관리
- 인증 시 일정한 규칙이 존재하는 세션 ID가 발급되거나 세션 타임아웃을 너무 길게 설정한 경우 공격 자에 의해 사용자 권한이 도용될 수 있는 취약점이다.
사례 2: 잘못된 세션에 의한 정보 노출
- 다중 스레드 환경에서는 싱글톤(Singleton) 객체 필드에 경쟁조건(race Condition)이 발생할 수 있다. 따라서 다중 스레드 환경인 java의 서블릿(servlet) 등에서는 정보를 저장하는 멤버 변수가 포함되지 않도록 하여, 서로 다른 세션 간에 데이터를 공유하지 않도록 해야 한다.
나. 설계 시 고려사항
1. 세션 간 데이터가 공유되지 않도록 설계해야 한다.
- 스레드로 동작하는 웹 애플리케이션의 컨트롤러 컴포넌트나, 싱글톤 객체로 생성되는 서비스 컴포넌트를 설계하는 경우 클래스 멤버 변수나 클래스 변수는 세션 간에 공유되는 데이터가 되므로 클래스 설계 시 읽고 쓰기가 가능한 변수를 사용하지 않도록 설계해야 한다
2. 세션이 안전하게 관리되도록 설계해야 한다.
- 시스템 내의 모든 페이지에 대하여 로그아웃이 가능하도록 UI를 설계하고, 로그아웃을 요청하면 사용자에게 할당된 세션을 완전히 제거하는 API를 사용하도록 개발 가이드 구현 단계를 작성한다. Java의 경우 session.invalidate() 메소드를 사용하여 세션에 저장된 정보를 완전히 제거할 수 있다.
- 세션 타임아웃 시간은 중요 기능의 경우 2~5분, 위험도가 낮은 애플리케이션의 경우에는 15~ 30분으로 설정하고, 이전 세션이 종료되지 않은 상태에서 새로운 세션이 생성되지 않도록 해야 한다.
- 웹 브라우저 종료로 인한 세션 종료는 서버 측에서 인지할 수 없기 때문에, 일정 시간 동안 사용되지 않는 세션 정보는 강제적으로 삭제되도록 아키텍처링 한다.
- 중복 로그인을 허용하지 않는 경우, 새로운 로그인 세션 생성 시 이전에 생성된 로그인 세션을 종료하거나, 새로이 연결되는 세션을 종료하도록 하는 정책이 설계단계에 고려되어야 한다.
- 세션 ID가 포함된 쿠키에 대해 HttpOnly 속성을 설정하여 자바스크립트로 조회할 수 없도록 만들어 XSS 공격에 대응하도록 설계한다. - 사용자가 패스워드를 변경하는 경우 현재 활성화된 세션을 삭제하고 다시 할당한다.
3. 세션 ID가 안전하게 관리되도록 해야 한다.
(ㄱ) 세션ID 생성
- 세션 ID는 안전한 서버에서 생성해서 사용되어야 한다.
- 세션 ID는 최소 128비트의 길이로 생성되어야 하며, 안전한 난수 알고리즘을 적용하여 예측이 불가능한 값이 사용되어야 한다.
(ㄴ) 세션ID 사용
- URL Rewrite 기능을 사용하는 경우 세션 ID가 URL에 노출될 수 있으므로, 사용하지 않도록 설계한다
(ㄷ) 세션 ID 폐기
- 로그인 성공 시 로그인 전에 할당받은 세션 ID는 파기하고 새로운 값으로 재할당하여 세션 ID 고정 공격에 대응하도록 시큐어코딩 규칙을 정의한다.
- 장기간 접속되어 있는 경우 세션 ID의 노출 위험이 커지므로, 일정 시간 주기적으로 세션 ID를 재할당 하도록 설계한다.
참고자료
- CWE‐488 Exposure of Data Element to Wrong Session, MITRE,
http://cwe.mitre.org/data/definitions/488.html - 2013 OWASP Top 10 – A6 Sensitive Data Exposure, OWASP,
https://www.owasp.org/index.php/Top_10_2013 - WASC Threat Classification Credential and Session Prediction, WASC,
http://projects.webappsec.org/w/page/13246918/Credential%20and%20Session%20Prediction - 2016 OWASP Application Security Verification Standard, OWASP, Session Management Verification Requirements,
http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project - Session Management Cheat Sheet, OWASP,
http://www.owasp.org/index.php/Session_Management_Cheat_Sheet - "HTTP State Management Mechanism", RFC 6265, IETF,
http://tools.ietf.org/html/rfc6265 - Unauthenticated Session Fixation Attacks, Christian Schneider,
http://www.christian-schneider.net/UnauthenticatedSessionFixationAttacks.html#main - Session Fixation Attacks and Protections in Web Applications, Raul Siles,
http://media. blackhat.com/bh-eu11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf - Insufficient Session-ID Length, OWASP,
http://www.owasp.org/index.php/Insufficient_Session-ID_Length
반응형
'공부 > KISA' 카테고리의 다른 글
경로 조작 및 자원 삽입 - KISA 소프트웨어 개발 보안 가이드 (0) | 2020.07.18 |
---|---|
SQL 삽입 - KISA 소프트웨어 개발 보안 가이드 (0) | 2020.07.17 |
예외처리 - KISA 소프트웨어 개발 보안 가이드 (0) | 2020.07.17 |
중요정보 전송 - KISA 소프트웨어 개발 보안 가이드 (0) | 2020.07.17 |
중요정보 저장 - KISA 소프트웨어 개발 보안 가이드 (0) | 2020.07.17 |
댓글