• 검색 결과가 없습니다.

(1) 패스워드 정책 구현

10. 전송 시 개인정보 노출 취약점

가. 설명

주로 회원정보 변경 모듈에 사용자의 key값(예: id)를 hidden form 필드로 전송한 후, 이를 다시 받아서 update에 사용하는 경우가 있는데, 공격자가 이 값을 변경할 경 우 다른 사용자의 정보를 변경할 수 있는 취약점이 존재한다.

아래 그림과 같이 회원정보 변경하는 페이지는 HTTPS로 접근하도록 되어있으며 자 동으로 이름, 아이디, 메일 주소 등이 자동으로 화면에 나타나며, 해당 값이 hidden form 필드로 전송되어 있음을 소스를 통해 알 수 있다.

◆ 주로 회원정보 변경 모듈에 사용자의 key값(예 : id)을 hidden form 필 드로 전송한 후, 이를 다시 받아서 updat에 사용하는 경우

◆ 공격자가 이 값을 변경할 경우 다른 사용자의 정보를 변경할 수 있는 취 약점이 존재한다.

취 약약 점점 요요 약약

[그림 55] 회원정보변경 페이지 화면 및 소스

홈 페 이 지 보 안 가 이 드

하지만, HTTPS가 아닌 HTTP로 접근이 가능한 것을 확인하고, 다음 그림과같이 HTTP로 다시 접속할 때에 Paros 툴의 Response를 Trap하여 hidden form 필드로 전송된 ID와 이름 부분을 공격대상자의 ID와 이름으로 변경한다.

다시 접근한 회원정보 변경 페이지를 보면, 다음 그림과 같이 공격대상자의 ID와 이 름으로 변경된 것을 볼 수 있다.

[그림 56] Paros 툴을 이용한 hidden form 내용 변경

[그림 57] Paros 툴을 이용하여 ID 및 이름으로 변경된 화면

. 웹 취 약 점 별 대 응 매 뉴 얼

다른 사용자로 접근된 페이지에서 비밀번호를 변경 후 확인 버튼을 누르면 다음 그 림과 같이 사용자 정보가 수정되었음을 볼 수 있다.

이는 회원정보 변경 시 ID와 이름값이 존재할 경우에 다른 인증절차 없이 변경을 할 수 있었으며, 회원정보 페이지와 같은 중요 정보를 다루는 페이지가“HTTPS”로 사용 하지 않아 Paros 툴을 이용하여 변경할 수 있다.

나. 진단방법

HTML 소스에서 FORM 필드 확인 후, 해당 값이 어떻게 사용되는지를 소스에서 확 인해야 한다.

중요 정보 전달 FORM ACTION에 사용된 프로토콜이 "HTTPS"로 되어 있는지 확인한 다. 또한“HTTPS”로 되어있는 URL에서“HTTP”로 바꾸어도 접근이 가능한지 확인한 다. “HTTPS”로 접근하도록 되어있는 페이지는“HTTP”로 접근이 불가능하여야 한다.

다. 대응방안

① 사용자에게 전달된 값(HIDDEN form 필드, parameter)를 재사용할 경우 신뢰 해서는 안 된다.

해당 값의 무결성을 검사할 수 있는 루틴(예, 해쉬값 비교)의 추가 또는 서버 세션 을 사용한다.

[그림 58] 공격대상자의 비밀번호 변경을 성공한 화면

홈 페 이 지 보 안 가 이 드

서버에서 클라이언트로 전송하는 정보를 제한하여, 불필요하게 비밀번호나 주민 번호와 같은 정보를 전송하는 것을 피하여야 한다. 비밀번호확인과 같은 부분은 클라이언트에서 처리하는 게 아니라 서버 측에서 처리하도록 하여야 한다.

② 웹 상에서 스니핑이 가능해서 로그인, 회원가입, 전자상거래의 이용 시 입력 정보 를 안전하게 주고 받기 위하여, SSL(Secure Socket Layer)이라는 암호화 전송 규약을 정하고 인터넷 브라우저와 웹 서버 사이에 암호화 통신이 가능함. SSL서 버는 대부분의 웹사이트에서 선택사항이 아니라 필수 항목이 되었으며 SSL서버 를 통해 개인정보 및 상거래 정보를 보호할 수 있다.

③ 중요 정보를 보여주는 페이지는 캐쉬를 사용하지 못하도록 설정한다.

중요 정보를 보여주는 화면에 no-cache 설정을 하지 않을 경우, 로그아웃을 한 이후에도 [뒤로가기] 버튼을 사용해서 해당 내용을 볼 수 있는 위험이 존재한다.

no-cache 설정을 위해서 HTML HEAD 부분에 아래 내용을 추가한다.

④ 적절한 방법으로 암호화한다.

자체 개발한 암호화 알고리즘 사용을 지양하며, 공인된 암호화 알고리즘(3DES, SEED, AES등)을 사용하는 것을 고려해야 한다. 암호화키를 사용하지 않는 알고 리즘은 암호화 알고리즘이 아니라, 단순 인코딩 알고리즘으로 기밀성을 보장할 수 없다. 암호화키는 소스에 hard-coding되어서는 안되며, 제한된 사람만이 접 근이 가능하도록 해야 한다.

<meta HTTP-EQUIV="Pragma" CONTENT="no-cache">

. 웹 취 약 점 별 대 응 매 뉴 얼

1) 사용자에게 전달된 값(HIDDEN form 필드, parameter)를 재사용할 경우 신 뢰해서는 안 된다.

2) 웹 상에서 스니핑이 가능해서 로그인, 회원가입, 전자상거래의 이용 시 입력 정보를 안전하게 주고 받기 위하여, SSL(Secure Socket Layer)이라는 암호화 전송규약을 정하고 인터넷 브라우저와 웹 서버 사이에 암호화 통신이 가능하다.

SSL서버는 대부분의 웹사이트에서 선택사항이 아니라 필수 항목이 되었으며 SSL서버를 통해 개인정보 및 상거래 정보를 보호할 수 있다.

3) 중요 정보를 보여주는 페이지는 캐쉬를 사용하지 못하도록 설정한다.

4) 적절한 방법으로 암호화한다.

요 약 약

관련 문서