APP STRORE에서는 라이브가 아닙니다. 이 인증서는 애플 내부 도구로 더 이상 포기될 수 없으며, 교체되면 해당 앱이 기본적으로 삭제됩니다.
여기서는 캡처 패키지의 IOS APP HTTPS 패키지에 대해 이야기해 보겠습니다
다운로드 및 설치: CHALESPROXY
http://www.charlesproxy.com/
설립하다
Charles, Menu -> 프록시 -> 프록시 설정에서 HTTP 프록시와 SSL 프록시를 활성화하고 설정하세요. 그림에 나와 같이 있습니다:
HTTP 프록시 설정에 대해 포트 번호가 8888임을 기억해 주세요
앞서 언급했듯이, 교통 납치는 이 글의 초점이 아닙니다트래픽 하이재킹은 어떻게 발생하나요?이 예시에서 찰스는 트래픽을 가로채는 대리인으로 직접 사용됩니다. 그리고 사용SSL 프록시아이폰 기기의 HTTPS 요청에 대한 중간자 공격을 시뮬레이션해 보자. 그래야 모두가 중간자 공격 방식을 생각하고 이해하며, 개발 과정에서 유사한 공격을 방지하는 방법을 이해할 수 있다. 1) 찰스가 요원을 함정에 빠뜨린다 Charles, Menu -> 프록시 -> 프록시 설정에서 HTTP 프록시와 SSL 프록시를 활성화하고 설정하세요. 그림에 나와 같이 있습니다: HTTP 프록시 설정에 대해 포트 번호가 8888임을 기억해 주세요
SSL 프록시 설정에서, locatio{filtering}ns에서 SSL로 사용할 도메인 이름을 설정할 수 있습니다. 여기서는 Baidu의 Baifubao*.baifubao.com 가 시뮬레이션 객체로 사용됩니다.
2) 아이폰 쪽에 HTTP 프록시를 설정하세요 현재 Mac에서 사용 중인 컴퓨터의 IP 주소를 확인하세요: IFCONFIG EN0:
간단한 방법도 있는데, 상단 메뉴 바에서 옵션을 누르고 있으면+WiFi 네트워크 아이콘을 탭하세요:
현재 컴퓨터의 IP 주소는 192.168.199.249입니다. 아이폰을 컴퓨터와 같은 와이파이에 연결하세요. 아이폰 설정에서: Wi-Fi -> 연결된 와이파이 오른쪽에 있는 정보 아이콘 -> HTTP 프록시 -> 매뉴얼 -> HTTP 프록시 설정하기:
설정이 완료되면 Safari를 열고 웹페이지를 방문한 후, 프록시를 처음 설정하면 Charles가 아이폰 프록시 요청 확인 박스를 뜨고 '허용'을 클릭하세요. 그러면 Charles의 아이폰에서 HTTP 요청을 볼 수 있습니다. Mac에서 너무 많은 요청이 프록시 아이폰에서 HTTP 요청 뷰 및 디버깅에 영향을 주는 것을 방지하기 위해, Charles의 메뉴 -> 프록시 ->에서 Mac OS X 프록시를 체크 해제할 수 있습니다. 위임받는 목적지 URL을 방문한다고 가정해 봅시다http://www.baifubao.com그러면 웹페이지를 열 수 없습니다. 아이폰의 HTTPS 요청이 찰스에 의해 가로채졌지만, 아이폰이 찰스의 인증서를 신뢰할 수 없기 때문에 SSL 핸드셰이크가 실패하고 HTTPS 연결이 성립할 수 없습니다.
3) 위조 증명서 위조 아이폰에서 사파리 오픈 프록시 및 접근http://www.charlesproxy.com/getsslCharles 루트 인증서를 포함하는 디스크립터 파일 설치 인터페이스가 나타납니다:
참고: 이 Charles 인증서는 Charles 내장되어 있으며, 도움말 -> SSL 프록시 메뉴에서 직접 저장 및 설치할 수 있습니다. 설치된 프로필은 아이폰 기기의 설정 -> Universal-> 프로필에서 확인할 수 있습니다. 설치가 완료되면 Charles 루트 인증서가 시스템 내 신뢰 인증서 목록에 추가되며, 이 인증서를 사용해 발행된 하위 인증서들도 시스템에서 신뢰받게 됩니다. Charles는 이전 SSL 프록시 설정에서 설정된 도메인 이름에 대해 SSL 인증서를 생성하여 위조된 인증서를 위조할 것입니다. Mac SSL 프록시를 사용해 다음 사항을 확인할 수 있습니다:
4) 결과 검증 바이두 앱을 다운로드한 후 계정에 로그인한 후 My -> My Wallet에서 바이푸바오에 접속할 수 있습니다:
HTTPS 요청 패키지의 내용이 성공적으로 확보되었는지 확인하세요. 여기서 추측할 수 있듯이, 앱이 시스템의 기본 인증 방식을 사용한다는 것입니다: 시스템은 중간자 서버가 반환하는 SSL 인증서를 신뢰하고, 앱이 이 검증을 신뢰하여 SSL 핸드셰이크가 성공합니다; 서버 인증서에 대한 로컬 교차 검증은 없습니다. 이것은 오늘날 많은 앱에서 존재하는 보안 위험입니다.
|