OOO실태평가등에 적용되는 웹취약점 종류
데이터 평문전송
1. http 프로토콜로만 개인정보(이름, 전화번호, 주소 등) 전송시 취약
2. https 적용하더라도 http로 강제 전송시 서버에서 처리 완료시 취약
해결방안
1. http 프로토콜로 접근시 https로 리다이렉션 처리
2. 중요정보를 송수신하는 서블릿 http 프로토콜 미사용
취약한 세션 및 쿠키*
설명 및 점검방법
Cookie의 JSESSIONID 등 해당 파라미터의 값을 탈취하여 정상적인 로그인 암호 입력없이 해당 사용자의 권한으로 웹페이지 이용가능 중복 로그인*의 개념이아님
보안성을 강화시키는 일환으로 User-Agent 및 IP 등으로 사용자 식별을하지만 100% 막기는 어려움으로 복잡도를 증가시키는 방법으로 강화 필요
* 취약한 세션 및 쿠키 - 하나의 계정으로 1개의 세션이 생성되는데 1개의 세션을 여러사용자가 사용
* 중복로그인 - 하나의 계정으로 2개의 세션이 생성되면 하나의 세션을 종료
해결 방안
1. JSP
* 서버 측 구현 예시로 참고하시길 바랍니다.
1. (최초)사용자 로그인 성공 후 세션 값을 생성
- HttpSession session = request.getSession()
2. (최초)자료구조에 JSESSIONID 값 및 User-Agent 값 등을 저장한다.
- HttpServletRequst 객체에서 Cookie의 JSESSIONID, User-Agent 값 등을 추출
- session.setAttribute(이름, 값)으로 위의 값을 저장
-
3. (반복)사용자가 페이지 요청시 자료구조에 저장된 JSESSIONID 및 User-Agent 정보 등이 상이할 시 세션값을 파기한다
- HttpServletRequst 객체에서 Cookie의 JSESSIONID, User-Agent 값 등을 추출
- session.getAttribute()로 최초 저장된 값과 위의 값 비교
- 상이할시 session.invalidate()로 기존 세션 파기
※ 사용자 세션 검증시 식별할 수 있는 정보(브라우저, OS버전 등)에 대해 추가검증하여 중복된 세션 발생 시
최초 저장된 내용과 비교하여 세션을 파기하거나 공격자의 세션 사용이 불가능 하도록 구현 권고
IP로만 사용자를 구별하지 말 것
외부IP가 같은 사설망에서 해당 취약점이 발생하면 서버에서 특정사용자 구별이 불가
URL/파라미터 변조
설명 및 점검방법
1. 기능 기반으로 점검을 실시한다
2. 예약 조회 페이지에서 특정 파라미터로 사용자 구별을 한다 (ex. mng_no=100)
3. 특정 파라미터를 변경(mng_no=100 -> mng_no=101) 타인의 예약 조회 내용에 개인정보(이름, 주소, 전화번호 등)을 포함하는 페이지가 확인 가능하다.
ex. 모 통신사 입사지원 서류 유출 사건
해결 방안
1. 로그인한 사용자의 세션과 게시글 작성자의 권한을 비교하여 서버측에서 접근제어하도록 구현한다.