설계단계 보안설계기준 정리

작성일: 230708

 

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

 

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

 

1. 입력데이터 검증 및 표현

설계항목	1.1 DBMS 조회 및 결과 검증 https://cryptocurrencyclub.tistory.com/89
설명	DBMS 조회 시 질의문(SQL) 내 입력값과 그 조회결과에 대한 유효성 검증방법(SQL 필터링 등) 설계 및 유효하지 않은 값에 대한 처리 방법을 설계해야 한다
보안대책	① 애플리케이션에서 DB연결을 수행할 때 최소권한의 계정을 사용해야 한다.  ② 외부입력값이 삽입되는 SQL질의문을 동적으로 생성해서 실행하지 않도록 해야 한다.     → ORM 프레임워크 사용     → ibatis,mybatis 사용 시 #{variable}로 변수 바인딩     → PreparedStatement로 정적쿼리 사용     → 특수문자: ' " = & | ! ( ) { } $ % @ 사용 확인      (# ^ * _ 빼고 키패드에 있는거 다)  ③ 외부 입력값을 이용해 동적으로 SQL질의문을 생성해야 하는 경우, 입력값에 대한 검증을 수행한 뒤 사용해야 한다.
연관된 구현단계	- SQL 삽입 https://cryptocurrencyclub.tistory.com/110

 

설계항목	1.2 XML 조회 및 결과 검증 https://cryptocurrencyclub.tistory.com/90
설명	XML 조회시 질의문(XPath, XQuery 등) 내 입력값과 그 조회결과에 대한 유효성 검증 방법(필터링 등)과  유효하지 않은 값에 대한 처리방법을 설계해야 한다.
보안대책	① XML문서를 조회하는 기능을 구현해야 하는 경우 XML질의문에 사용되는 파라미터는 반드시 XML쿼리를      조작할 수 없도록 필터링해서 사용하거나, 미리 작성된 질의문에 입력값을 자료형에 따라 바인딩해서      사용해야 한다.     → 구문 변경 가능 입력값: 쿼리예약어, * [ ] / = @
연관된 구현단계	- XML 삽입 https://cryptocurrencyclub.tistory.com/118 - 부적절한 XML 외부개체 참조 https://cryptocurrencyclub.tistory.com/117

 

설계항목	1.3 디렉토리 서비스 조회 및 결과 검증 https://cryptocurrencyclub.tistory.com/91
설명	디렉토리 서비스(LDAP 등)을 조회할 때 입력값과 그 조회결과에 대한 유효성 검증방법 설계 및 유효하지 않은 값에 대한 처리방법을 설계한다.
보안대책	① LDAP 인증서버로 인증을 구현하는 경우 인증요청을 위해 사용되는 외부입력값은 LDAP 삽입 취약점을      가지지 않도록 필터링해서 사용해야 한다.     → 구문 변경 가능 입력값: = + < > # ; \
연관된 구현단계	- LDAP 삽입 https://cryptocurrencyclub.tistory.com/119

 

설계항목	1.4 시스템 자원 접근 및 명령어 수행 입력값 검증 https://cryptocurrencyclub.tistory.com/92
설명	시스템 자원접근 및 명령어를 수행할 때 입력값에 대한 유효성 검증방법 설계 및 유효하지 않은 값에 대한  처리 방법을 설계해야 한다.
보안대책	① 외부입력값을 이용하여 시스템자원(IP, PORT번호, 프로세스, 메모리, 파일 등)을 식별하는 경우       허가되지 않은 자원이 사용되지 않도록 해야 한다. - 경로조작을 일으킬 수 있는 문자(.. / \)를 제거하고 사용하여 지정 경로 내 파일만 접근 가능하도록 시큐어코딩 규칙을 정의한다.  ② 서버프로그램 안에서 셸을 생성하여 명령어를 실행해야 하는 경우 외부입력값에 의해 악의적인 명령어가       실행되지 않도록 해야 한다. - 명령어의 일부로 사용되어야 하는 값들을 목록화하여 목록 내에 있는 값들로만 명령어가 조립되어 실행     → 검증해야 할 특수문자: | & ;
연관된 구현단계	- 코드삽입 https://cryptocurrencyclub.tistory.com/111 - 경로 조작 및 자원 삽입 https://cryptocurrencyclub.tistory.com/112 - 서버사이드 요청 위조 https://cryptocurrencyclub.tistory.com/121 - 운영체제 명령어 삽입 https://cryptocurrencyclub.tistory.com/114

 

설계항목	1.5 웹 서비스 요청 및 결과 검증 https://cryptocurrencyclub.tistory.com/93
설명	웹 서비스(게시판 등) 요청(스크립트 게시 등)과 응답결과(스크립트를 포함한 웹 페이지)에 대한 유효성 검증  방법 설계 및 유효하지 않은 값에 대한 처리 방법을 설계해야 한다.
보안대책	① 사용자로부터 입력받은 값을 동적으로 생성되는 응답페이지에 사용하는 경우 크로스 사이트 스크립트(XSS) 필터링을 수행한 뒤 사용해야 한다. (Reflective XSS)    ② DB조회결과를 동적으로 생성되는 응답페이지에 사용하는 경우 HTML인코딩 또는 크로스 사이트 스크립트 필터링을 수행한 뒤 사용해야 한다.(Stored XSS)
연관된 구현단계	- 크로스사이트 스크립트 https://cryptocurrencyclub.tistory.com/113

 

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

 

설계항목	1.7 HTTP 프로토콜 유효성 검증 https://cryptocurrencyclub.tistory.com/95
설명	비정상적인 HTTP헤더, 자동연결 URL 링크 등 사용자가 원하지 않은 결과를 생성하는 HTTP 헤더,응답결과에 대한 유효성 검증방법 설계 및 유효하지 않은 값에 대한 처리방법을 설계해야 한다.
보안대책	① 외부입력값을 쿠키 및 HTTP 헤더정보로 사용하는 경우, HTTP 응답분할 취약점을 가지지 않도록 필터링해서 사용해야 한다.   ㅇ 응답헤더에 값을 쓰는 기능을 식별하고, 입력값에 포함된 개행문자를 필터링 하는 기능이 설계되어 있는지 확인     → 함수 예: setHeader, addCookie, sendRedirect 등     → 구분자, 개행문자: CR(\r) LF(\n)  ② 외부입력값이 페이지 이동(리다이렉트, 포워드)을 위한 URL로 사용되어야 하는 경우, 해당 값은 시스템에서 허용된 URL 목록의 선택자로 사용되도록 해야 한다.   ㅇ 페이지 이동을 허용하는 URL목록을 소스코드에 하드코딩
연관된 구현단계	- HTTP 응답분할 https://cryptocurrencyclub.tistory.com/122 - 신뢰되지 않은 URL주소로 자동접속 연결 https://cryptocurrencyclub.tistory.com/116

 

설계항목	1.8 허용된 범위내 메모리 접근 https://cryptocurrencyclub.tistory.com/96
설명	해당 프로세스에 허용된 범위의 메모리 버퍼에서 접근하여 읽기 또는 쓰기 기능을 하도록 검증 방법 설계 및 메모리 접근요청이 허용범위를 벗어났을 때  처리방법을 설계해야 한다.
보안대책	① C나 C++같이 메모리를 프로그래머가 관리하는 플랫폼을 사용하는 경우 메모리 버퍼의 경계값을 넘어서 메모리를 읽거나 저장하지 않도록 경계설정 또는 검사를 반드시 수행해야 한다.   ㅇ ASLR(Address Space Layout Randomization), StackGuard와 같은 메모리 보호를 위한 설정을 사용하도록 설계되어 있는지 확인  ② 개발시, 메모리 버퍼오버플로우를 발생시킬 수 있는 취약한 API를 사용하지 않도록 해야 한다.
연관된 구현단계	- 메모리 버퍼 오버플로우 https://cryptocurrencyclub.tistory.com/125 - 포맷 스트링 삽입 https://cryptocurrencyclub.tistory.com/126

 

설계항목	1.9 보안기능 입력값 검증 https://cryptocurrencyclub.tistory.com/97
설명	보안기능(인증, 권한부여 등) 입력값과 함수(또는 메소드)의 외부입력값 및 수행 결과에 대한 유효성 검증방법 설계 및 유효하지 않은 값에 대한 처리방법을 설계해야 한다.
보안대책	① 사용자의 역할, 권한을 결정하는 정보를 서버에서 관리해야 한다.    ② 쿠키값, 환경변수, 파라미터 등 외부입력값이 보안기능을 수행하는 함수의 인자로 사용되는 경우, 입력값에 대한 검증작업을 수행한 뒤 제한적으로 사용해야 한다.   ㅇ 입력값에 대한 검증작업은 클라이언트측에서 수행하는 검증방식과 서버에서 수행하는 검증방식이 동일해야한다.  ③ 중요상태정보나 인증, 권한 결정에 사용되는 정보는 쿠키로 전송되지 않아야 하며, 불가피하게 전송하는 경우에는 해당 정보를 암호화해서 전송해야 한다.    ㅇ 중요정보가 포함되는 쿠키는 암호화하여 전송하거나 HMAC(Hash-Based Message Authentication Code)와 같은 메시지인증코드를 이용하여 서버측에서 무결성을 검증한다.
연관된 구현단계	- 보안기능 결정에 사용되는 부적절한 입력값 https://cryptocurrencyclub.tistory.com/124 - 정수형 오버플로우 https://cryptocurrencyclub.tistory.com/123 - Null Pointer 역참조 https://cryptocurrencyclub.tistory.com/149

 

설계항목	1.10 업로드·다운로드 파일 검증 https://cryptocurrencyclub.tistory.com/98
설명	업로드·다운로드 파일의 무결성, 실행권한 등에 관한 유효성 검증방법 설계 및 부적합한 파일에 대한 처리방법을 설계한다.
보안대책	① 업로드되어 저장되는 파일의 타입, 크기, 개수, 실행권한을 제한해야 한다.   ㅇ MultiPartResolver 컴포넌트 속성값을 설정하여 업로드 파일의 크기를 제한할 수 있다.   ㅇ 파일유형의 통제는 서버와 클라이언트가 동일한 정책을 적용, 파일의 MIME‐TYPE과 확장자를 동시에 검사   ㅇ 파일에 실행권한이 주어지지 않도록 시스템설정을 확인한다. 파일이 읽기 권한을 가지고 있기만 해도 서버에서 해당 파일을 읽어서 실행할 수 있으므로 서버 설정으로 업로드 경로의 파일이 실행 되지 않도록 설정  ② 업로드되어 저장되는 파일은 외부에서 식별되지 않아야 한다.   ㅇ URL로 직접적으로 접근 가능하지 않은 디렉터리를 사용, 허가된 파일에 대한 허가된 사용자만 다운로드   ㅇ 파일명은 랜덤하게 생성하여 사용  ③ 파일 다운로드 요청 시, 요청파일명에 대한 검증작업을 수행해야 한다.   ㅇ 파일명에 경로를 조작하는 문자의 포함 여부 확인: .. / \ 문자는 제거  ④ 다운로드 받은 소스코드나 실행파일은 무결성 검사를 실행해야 한다.   ㅇ 실행하는 기능을 구현해야 하는 경우 해당 파일과 파일의 체크섬 값(해시 값 등)을 같이 다운로드 받아 파일에 대한 무결성 검사를 수행
연관된 구현단계	- 위험한 형식 파일 업로드 https://cryptocurrencyclub.tistory.com/115 - 부적절한 전자서명 확인 https://cryptocurrencyclub.tistory.com/137 - 무결성 검사 없는 코드 다운로드 https://cryptocurrencyclub.tistory.com/142

 

2. 보안기능

설계항목	2.1 인증 대상 및 방식 https://cryptocurrencyclub.tistory.com/100
설명	중요정보·기능의 특성에 따라 인증방식을 정의하고 정의된 인증방식을 우회하지 못하게 설계해야 한다.
보안대책	① 중요기능이나 리소스에 대해서는 인증 후 사용 정책이 적용되어야 한다.   ㅇ DN=인증서 주체, 발급자(Issuer) 정보 포함, CN= 인증서 주체(Subject)  ② 안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다.   ㅇ 인증정보는 서버 측에 저장   ㅇ OTP는 중복 및 유추가 불가하도록 6자리 이상의 숫자 및 문자로 구성, 시간적 제한을 설정  ③ 중요기능에 대해 2단계(2-factor)인증을 고려해야 한다.   ㅇ 2단계인증은 Type1(비밀번호/PIN 등 지식기반인증), Type2(토큰/스마트카드 등 소유기반 인증), Type3(지문/홍채 등 생체기반인증) 중 2개 이상의 인증기법을 사용하도록 설계한다.
연관된 구현단계	- 서버사이드 요청 위조 https://cryptocurrencyclub.tistory.com/121 - 적절한 인증 없는 중요기능 허용 https://cryptocurrencyclub.tistory.com/127 - 부적절한 인증서 유효성 검증 https://cryptocurrencyclub.tistory.com/138 - DNS lookup에 의존한 보안 결정 https://cryptocurrencyclub.tistory.com/158

 

설계항목	2.2 인증 수행 제한 https://cryptocurrencyclub.tistory.com/101
설명	반복된 인증 시도를 제한하고 인증 실패한 이력을 추적하도록 설계한다.
보안대책	① 로그인 기능 구현 시, 인증시도 횟수를 제한하고, 초과된 인증시도에 대해 인증제한 정책을 적용해야 한다.   ㅇ 로그인 시도 횟수를 3-5번 이내로 제한   ㅇ 계정정보 입력 시 자동입력방지 문자(CAPTCHA)와 같은 장치를 마련   ㅇ 일정 횟수 이상 연속적으로 로그인 실패 시 사용자 ID와 비밀번호 외의 추가적인 정보를 확인  ② 실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야 한다.
연관된 구현단계	- 반복된 인증시도 제한 기능 부재 https://cryptocurrencyclub.tistory.com/143

 

설계항목	2.3 비밀번호 관리 https://cryptocurrencyclub.tistory.com/102
설명	생성규칙, 저장방법, 변경주기 등 비밀번호 관리정책별 안전한 적용방법을 설계한다.
보안대책	① 비밀번호 설정 시 KISA의 비밀번호 선택 및 이용 안내서의 비밀번호 보안 지침을 적용한다.   ㅇ 두 종류 이상의 문자 구성(알파벳 대·소문자, 특수문자, 숫자)과 8자리 이상   ㅇ 10자리 이상의 길이로 구성된 문자열  ② 네트워크로 비밀번호를 전송하는 경우 반드시 비밀번호를 암호화하거나 암호화된 통신 채널을 이용해야 한다.   ㅇ TLS_키교환알고리즘_WITH_암호알고리즘_메시지인증알고리즘 (TLS_RSA_WITH_AES_256_GCM_SHA384)  ③ 비밀번호 저장 시, 솔트가 적용된 안전한 해시함수를 사용해야 하며 비밀번호에 대한 해시를 서버에서 실행되도록 해야 한다.   ㅇ SHA-2 계열 및 224 이상, 모든 비밀번호가 고유의 솔트를 갖고 솔트의 길이가 32바이트 이상이면 솔트 값이 노출되지 않는 이상 다이제스트를 추측하기 어렵다.  ④ 비밀번호 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.   ㅇ 등록된 이메일 주소를 이용하여 비밀번호를 재설정  ⑤ 비밀번호 관리 규칙을 정의해서 적용해야 한다.   ㅇ 비밀번호 변경주기는 3개월(또는 6개월) 패킷스니핑, 무차별 대입
연관된 구현단계	- 하드코드된 중요정보 https://cryptocurrencyclub.tistory.com/133 - 취약한 비밀번호 허용 https://cryptocurrencyclub.tistory.com/136

 

설계항목	2.4 중요자원 접근통제 https://cryptocurrencyclub.tistory.com/103
설명	중요자원(프로그램 설정, 민감한 사용자 데이터 등)을 정의하고, 정의된 중요자원에 대한 신뢰할 수 있는 접근통제 방법(권한관리 포함) 설계 및 접근통제 실패 시 처리방법을 설계한다.
보안대책	RBAC(Role Based Access Control) 모델을 사용하여 기업, 정부 등 다수의 사용자와 정보객체들로 구성된 조직체계에서 사용자에게 할당된 역할을 기반으로 권한을 부여(접근제어 목록, Access control list)하도록 설계  ① 중요자원에 대한 접근통제 정책을 수립하여 적용해야 한다.    ㅇ 중요자원에 대한 접근권한을 최소 권한, 권한 분리으로 설정한다.  ② 중요기능에 대한 접근통제 정책을 수립하여 적용해야 한다.  ③ 관리자페이지에 대한 접근통제 정책을 수립하여 적용해야 한다.   ㅇ 관리자 페이지 접속 시 암호화 통신 채널(TLS 등)을 사용   ㅇ 관리자 페이지에 접속 가능한 IP를 설정, 80번이 아닌 별도의 포트를 사용 SSI 인젝션, 관리자 페이지 노출
연관된 구현단계	- 부적절한 인가 https://cryptocurrencyclub.tistory.com/128 - 중요한 자원에 대한 잘못된 권한 설정 https://cryptocurrencyclub.tistory.com/130

 

설계항목	2.5 암호키 관리 https://cryptocurrencyclub.tistory.com/104
설명	암호키 생성, 분배, 접근, 파기 등 암호키 생명주기별 암호키 관리방법을 안전하게 설계한다.
보안대책	① DB데이터 암호화에 사용되는 암호키는 KISA의 암호이용안내서에서 정의하고 있는 방법을 적용해야 한다.   ㅇ 대칭키: 송신자2년, (송신자 사용기간 +3년) 이내   ㅇ 비대칭키: 암호화 공개키 2년, 개인키 2년, 검증용 공개키 1~3년, 서명용 개인키 키 크기 별 상이   ㅇ 암호키 사용 시 사용 종료 후 메모리를 0으로 초기화  ② 설정파일(xml, Properties) 내 중요정보 암호화에 사용되는 암호키는 암호화해서 별도의 디렉토리에 보관해야 한다.   ㅇ 암호키는 마스터키를 이용하여 암호화하여 물리적으로 분리된 별도의 디렉터리에 보관
연관된 구현단계	- 하드코드된 중요정보 https://cryptocurrencyclub.tistory.com/133 - 주석문안에 포함된 시스템 주요 정보 https://cryptocurrencyclub.tistory.com/140

 

설계항목	2.6 암호연산 https://cryptocurrencyclub.tistory.com/105
설명	국제표준 또는 검증필 암호모듈로 등재된 안전한 암호 알고리즘을 선정하고 충분한 암호키 길이, 솔트, 충분한 난수 값을 적용한 안전한 암호연산 수행방법을 설계한다.
보안대책	① 대칭키 또는 비대칭키를 이용해서 암복호화를 수행해야 하는 경우 KISA의 암호이용안내서에서 정의하고 있는 암호화 알고리즘과 안전성이 보장되는 암호키 길이를 사용해야 한다.   ㅇ  암복호화 기능 설계 시 안전한 암호 알고리즘을 사용하도록 설계되었는지 확인       - 대칭키: SEED, ARIA, AES 등       - 비대칭키: RSA, KCDSA, ECC 등   ㅇ  암복호화 기능 설계 시 안전한 암호키 길이를 사용하도록 설계되었는지 확인       - 대칭키: 128bit 이상       - 비대칭키: 2048bit 이상  ② 복호화되지 않는 암호화를 수행하기 위해 해시함수를 사용하는 경우 안전한 해시 알고리즘과 솔트값을 적용하여 암호화해야 한다.  ③ 난수 생성 시 안전한 난수 생성 알고리즘을 사용해야 한다.   ㅇ FIPS 140-2 인증을 받은 암호모듈의 난수 생성기와 256비트 이상의 시드를 사용       - JAVA: java.security.SecureRandom, java.util.Random       - C: randomize(seed)   ㅇ 이전 난수생성 단계의 결과를 다음 난수생성 단계의 시드로 사용하는 의사난수생성기를 이용
연관된 구현단계	- 취약한 암호화 알고리즘 사용 https://cryptocurrencyclub.tistory.com/131 - 충분하지 않은 키길이 사용 https://cryptocurrencyclub.tistory.com/134 - 적절하지 않은 난수 값 사용 https://cryptocurrencyclub.tistory.com/135 - 부적절한 인증서 유효성 검증 https://cryptocurrencyclub.tistory.com/138 - 솔트 없이 일방향 해쉬함수 사용 https://cryptocurrencyclub.tistory.com/141

 

설계항목	2.7 중요정보 저장 https://cryptocurrencyclub.tistory.com/106
설명	중요정보(비밀번호, 개인정보 등)를 저장,보관하는 방법이 안전하도록 설계한다.
보안대책	① 중요정보, 개인정보는 암호화해서 저장해야 한다.   ㅇ 중요정보가 다뤄지는 "안전 영역"을 설정   ㅇ 클라이언트 언어인 HTML 코드는 사용자에게 공개되어 있는 것과 마찬가지이므로 중요한 로직 및 주석처리는 서버 측 언어에서만 처리  ② 불필요하거나 사용하지 않는 중요정보가 메모리에 남지 않도록 해야 한다.   ㅇ 개인정보, 인증정보 등이 영속적인 쿠키(Persistent Cookie)에 저장된다면, 공격자는 쿠키에 접근   ㅇ 중요정보 사용 후 메모리 초기화를 수행
연관된 구현단계	- 암호화되지 않은 중요정보 https://cryptocurrencyclub.tistory.com/132 - 사용자 하드디스크에 저장되는 쿠키를 통한 정보 노출 https://cryptocurrencyclub.tistory.com/139

 

설계항목	2.8 중요정보 전송 https://cryptocurrencyclub.tistory.com/107
설명	중요정보(비밀번호, 개인정보, 쿠키 등)를 전송하는 방법이 안전하도록 설계한다.
보안대책	① 인증정보와 같은 민감한 정보 전송 시 안전하게 암호화해서 전송해야 한다.    ② 쿠키에 포함되는 중요정보는 암호화해서 전송해야 한다.   ㅇ 부득이 쿠키에 중요정보가 포함되어야 하는 경우 반드시 세션쿠키로 설정되어야 하며, 전달되는 중요정보는 반드시 암호화해서 전송
연관된 구현단계	- 암호화되지 않은 중요정보 https://cryptocurrencyclub.tistory.com/132

 

3. 에러처리

설계항목	3.1 예외처리 https://cryptocurrencyclub.tistory.com/108
설명	오류메시지에 중요정보(개인정보, 시스템 정보, 민감 정보 등)가 노출되거나, 부적절한 에러 및 오류처리로 인해 의도치 않은 상황이 발생하지 않도록 설계한다.
보안대책	① 명시적인 예외의 경우 예외처리 블럭을 이용하여 예외 발생 시 수행해야 하는 기능이 구현되어야 한다.   ㅇ Logger API를 활용   ② 런타임 예외의 경우 입력값의 범위를 체크하여 애플리케이션이 정상적으로 동작할 수 있는 값만 사용되도록 보장해야 한다.  ③ 에러가 발생한 경우 상세한 에러 정보가 사용자에게 노출되지 않게 해야 한다.
연관된 구현단계	- 오류 메시지 정보노출 https://cryptocurrencyclub.tistory.com/146

 

4. 세션통제

설계항목	4.1 세션통제 https://cryptocurrencyclub.tistory.com/109
설명	다른 세션간 데이터 공유금지, 세션ID 노출금지, (재)로그인 시 세션ID  변경, 세션종료(비활성화, 유효기간 등) 처리 등 세션을 안전하게 관리할 수 있는 방안을 설계해야 한다.
보안대책	다중 스레드 환경에서는 싱글톤(Singleton)객체 필드에 경쟁조건(Race Condition) 발생할 수 있다. 따라서, 다중 스레드 환경인 java의 서블릿(servlet) 등에서는 정보를 저장하는 멤버변수가 포함되지 않도록 하여, 서로 다른 세션 간에 데이터를 공유하지 않도록 해야 한다.  ① 세션 간 데이터가 공유되지 않도록 설계해야 한다.   ㅇ 클래스 멤버 변수나 클래스변수는 세션 간에 공유되는 데이터가 되므로 클래스 설계시 읽고 쓰기가 가능한 변수를 사용하지 않도록 설계  ② 세션이 안전하게 관리되도록 해야 한다.   ㅇ 로그아웃 시 사용자에게 할당된 세션을 완전히 제거 session.invalidate()   ㅇ 세션ID가 포함된 쿠키에 대해 HttpOnly 속성을 설정, 자바스크립트로 조회할 수 없도록 만들어 XSS공격에 대응   ㅇ 중요기능은 2~5분, 위험도가 낮은 경우 15~30분  ③ 세션ID가 안전하게 관리되도록 해야 한다.   ㅇ 세션ID는 서버에서 생성, 최소 128비트의 길이로 생성되어야 하며, 안전한 난수 알고리즘을 적용   ㅇ URL Rewrite 기능을 사용하는 경우 세션ID가 URL에 노출될 수 있으므로, 사용하지 않는다
연관된 구현단계	- 잘못된 세션에 의한 데이터 정보 노출 https://cryptocurrencyclub.tistory.com/154