* 민감한 데이터의 종류
① 각종 개인정보 (주민등록번호, 카드 정보뿐만 아니라 건강 정보, 종료, 정치 성향, 가족 구성원 등 모든 사생활 관련 정보 포함)
② 패스워드, 세션 ID, 세션 토큰 등과 같은 로그인에 사용되는 정보
③ 업무상 기밀 등 비공개로 관리되는 정보
- 데이터가 적절히 암호화되지 않거나 평문으로 저장되어 노출되는 경우 위험!
* 민감한 데이터 노출 리스크
① HTTP 프로토콜을 사용하여 민감한 데이터가 전송되는 경우
② 민감한 데이터가 평문으로 저장되는 경우
③ 안전하지 않은 암호화 방식을 사용하는 경우
1. HTTP 프로토콜에 의한 노출
- HTTP 프로토콜로 전달되는 요청/응답 메시지는 네트워크 스니핑 기법을 통한 도청 위험 있음
* 네트워크 스니핑 : 네트워크에 전송되는 데이터를 모니터링하는 기술 ex) tcpdump, 와이어샤크
* tcpdump 사용 예시
① -n : IP 주소나 포트 숫자를 호스트 네임이나 서비스 이름으로 변경하지 않고 숫자 그대로 표시
②- -i : 인터페이스를 지정하는 옵션. -i eth1을 하면 eth1 인터페이스를 통해 전달되는 트래픽을 스니핑
③ -A : 사람이 알아볼 수 있는 아스키 형태의 문자열 출력
④ -s <숫자> : 표시할 내용의 길이 지정. -s 0은 길이 제한 없이 출력하는 옵션
⑤ tcp : TCP 프로토콜만 출력하도록 필터링
⑥ port 80 : 80번 포트에 대해서만 출력하도록 필터링
<bWAPP – Clear Text HTTP (Credentials)>
- 로그인 폼을 통해 사용자 정보를 입력하면 입력한 값이 HTTP 프로토콜을 통해 전달됨
2. 웹 스토리지를 통한 노출 실습
* HTML5 이후 웹 스토리지 기능이 추가됨
- 웹 스토리지(web storage) : 웹 애플리케이션이 사용자의 웹 브라우저에 데이터를 저장
① 세션 스토리지 : 세션이 종료되면 데이터도 함께 삭제
② 로컬 스토리지 : 세션이 종료되어도 따로 삭제 요청을 하기 전까지는 데이터가 계속 남아있음
- HTML5 이전 쿠키를 이용해서 데이터 저장할 경우 제약 사항
① 쿠키는 요청 메시지가 전달될 때 자동으로 전송되기 때문에 요청이 일어날 때마다 데이터가 전송되어 성능 저하 발생
② 각 쿠키의 최대 길이는 모든 웹 브라우저를 지원하기 위해서는 최대 4093바이트로 제한됨
-> 웹 스토리지 기능으로, 더 큰 데이터 저장과 꼭 필요한 데이터가 아니라면 매번 서버로 전달되지 않아도 됨
But, 웹 스토리지에 저장된 데이터는 자바스크립트를 사용하여 읽을 수 있기 때문에 웹사이트 내에 크로스 사이트 스크립팅 취약점이 존재하면 자바스크립트를 실행할 수 있기 때문에 유출된 위험성 존재 (쿠키는 HttpOnly 속성을 이용하여 막을 수 있음)
<bWAPP – HTML5 Web Storage (Secret)>
- 웹 스토리지에 저장된 정보는 개발자 도구(F12) 기능을 이용하여 확인 가능
- 개발자 도구 – Storage – Local Storage 에서 확인
-> 웹사이트 어딘가에 크로스 사이트 스크립팅 취약점이 존재하기 때문에 접근 가능!
<bWAPP - Cross Site Scripting – Reflected (GET)>
- 크로스 사이트 스크립팅 공격 시도를 위해 Cross Site Scripting – Reflected (GET) 요청
<script>alert('secret: '+localStorage.getItem('secret'))</script>
와 같은 자바스크립트 코드 입력 시 localStorage.getItem(‘secret’) 함수가 호출되어 secret 키의 값을 읽을 수 있음
3. 평문으로 된 패스워드 노출 실습
<bWAPP – Text Files (Accounts)>
- 간단한 회원 가입 페이지이며, 아무 값이나 입력하여 계정을 생성 시,
- 계정이 추가되었으며, 실습용으로 계정 정보가 저장된 파일 확인 가능
- 패스워드가 평문으로 노출되고 있는 것 확인 가능
-> 시스템 운영자나 내부 직원, 공격자에게 패스워드 정보 노출됨
4. Base64 인코딩
- Base64 인코딩 : 이진 데이터를 아스키 텍스트 문자열로 변환하는 방법
-> 파일 전송과 같이 텍스트로 표현할 수 없는 바이너리 데이터 전송할 때 Base64로 인코딩
(ex. 전자우편, HTTP 메시지 전송)
- Base64 인코딩 방법
① 각 문자를 아스키 값으로 변환
② 변환한 아스키값을 2진수 8비트로 표현
③ 6비트씩 4개로 나누어 각각 10진수로 변환
④ 각각을 인덱스로 하여 Base64 인코딩 테이블에서 해당을 찾음
- Base64 디코딩은 인코딩 과정의 반대로 진행되면 되고, 리눅스의 base64 명령어로 간단하게 인코딩과 디코딩 가능
-> 쉽게 디코딩 가능!
<bWAPP – Base64 Encoding (secret)>
- 버프스위트로 해당 웹 페이지의 HTTP history 확인
- Cookie 항목에서 secret 쿠키가 추가되어 전송되는 것 확인 가능
* 처음 실습 페이지를 요청할 때 secret 쿠키가 Set-cookie 헤더를 통해 전달되어 쿠키가 추가되기 때문에, 새로 고침 등으로 다시 요청해야 secret 쿠키가 표시됨!
- Base64로 인코딩된 QW55IGJ1Z3M%2F를 디코딩하기 위해 마우스 우클릭 메뉴 중 ‘Send to Decoder’ 선택
- 이 때, %2F는 ‘/’가 URL 인코딩된 것이므로 base64 디코딩 전에 / 문자로 변경 후, Decode as를 base64로 선택하여 디코딩
-> 인코딩 방식은 쉽게 다시 디코딩 될 수 있는 방식이기 때문에 암호화와 구분하여 적절한 암호화 사용!
5. 민감한 데이터 노출 대응 방안
<HTTPS 프로토콜>
- 로그인과 같은 중요한 기능은 HTTPS 프로토콜을 이용하여 데이터가 암호화되어 전송되도록 구현
- HTTP와 HTTPS를 같이 사용하는 웹사이트의 경우 HTTPS에서 HTTP로 전환될 때 민감한 정보가 전송되지 않도록 주의
<웹 스토리지 보호 대책>
- 민감한 데이터를 로컬 스토리지에 저장하는 건 위험하므로, 민감한 데이터를 클라이언트로부터 전달받아야 하는 경우, 쿠키를 통해 전달하고, 해당 쿠키에 HttpOnly 플래그 추가
<검증된 암호화 사용>
'웹해킹' 카테고리의 다른 글
웹해킹 #12 XXE(XML 외부 엔티티) 공격 (0) | 2020.04.15 |
---|---|
웹해킹 #11 접근 통제 취약점 공격 (1) | 2020.04.15 |
웹해킹 #9 파일 업로드 공격 (0) | 2020.04.08 |
웹해킹 #8 파일 인클루전 공격 (0) | 2020.04.08 |
웹해킹 #7 취약한 인증 공격 (0) | 2020.03.24 |