WebSocket은 단일 TCP 연결에 전이중 채널을 제공하는 HTML5 기능입니다. 지속적인 연결 기능을 통해 B/S 모드에서 실시간 애플리케이션 구축이 가능합니다. 웹소켓은 채팅 기능이 있는 웹 애플리케이션에서 자주 사용됩니다.
다음 그림은 APT 공격에 사용된 웹소켓을 매우 자세히 보여줍니다.
동일 출처 전략( 동일 출처 정책): 동일한 출처는 도메인 이름, 프로토콜 및 포트가 동일하다는 것을 의미합니다. 즉, 브라우저는 동일한 브라우저의 다른 탭을 확인하고 동일한 출처의 스크립트가 여러 탭에서 실행될 수 있음을 의미합니다.
Origin 필드: POST 요청을 보낼 때 브라우저는 Origin 필드를 추가할 수 있습니다. 이 Origin 필드는 주로 초기 요청이 시작된 위치를 식별하는 데 사용됩니다. 브라우저가 원본 위치를 확인할 수 없는 경우 전송된 요청의 원본 필드 값은 비어 있습니다.
IronWASP: 사용자가 Python/Ruby를 사용하여 보안 검색을 사용자 정의하고 플러그인 시스템을 정의할 수 있는 오픈 소스 WEB 테스트 플랫폼입니다. 관련 소개는 http://www.php.cn/
을 참조하세요. ZAP(Zed Attack Proxy): 다양한 도구를 통합하고 WEB 애플리케이션의 취약점을 발견할 수 있는 침투 테스트 프레임워크입니다. 소개, 참조: http://www.php.cn/
최근 우리는 복잡한 메뉴 옵션과 기능을 갖춘 웹 애플리케이션에 대한 보안 평가를 실시했습니다. 이 애플리케이션의 작업 대부분은 웹 소켓을 사용합니다. 이는 대부분의 작업이 http 프록시 로그에 기록되지 않음을 의미합니다.
먼저 홈페이지를 열면 웹사이트에 JS 스크립트와 CSS 파일이 포함된 정적 웹페이지가 로드됩니다. 그 후에는 전체 통신 상호 작용이 웹소켓 모드로 전환되고 브라우저와 서버 간에 웹소켓 연결이 설정되어 웹사이트에 표시되는 모든 HTML 리소스를 로드하게 됩니다. 링크를 클릭하거나 양식을 제출하면 브라우저는 일부 WebSocket 메시지를 서버로 보냅니다. 서버가 이러한 메시지를 처리한 후 WebSocket을 통해 피드백을 보내고 클라이언트 브라우저에 새 HTML 콘텐츠가 표시됩니다.
이때 웹소켓 메시지가 상호작용을 할 때 통신량이 매우 엄청납니다. 매초마다 이들 사이에 하트비트 감지 패킷의 상호작용이 있습니다. 그러나 기존 도구는 내 요구 사항을 충족하지 못했기 때문에 Websocket을 식별하고 취약점을 퍼징할 수 있도록 IronWASP에 Websocket 메시지 분석 장치와 WebSocket 클라이언트를 추가해야 했습니다. 여기에서 자세한 내용을 알아볼 수 있습니다.
이 애플리케이션을 테스트하는 동안 WebSocket 크로스 사이트 WebSocket 하이재킹 취약점(Christian Schneider가 개척)이 있음을 발견했습니다. 물론 테스트 방법을 소개하기 전에 이 취약점이 미치는 영향에 대해 설명하겠습니다. 관련 웹소켓 애플리케이션을 테스트하기 전에 먼저 준비가 필요합니다.
SOP(Same Origin Policy)는 브라우저(동일 브라우저, SSL 보호 페이지, SSL이 아닌 WebSocket은 통과할 수 없습니다.) 테스트한 애플리케이션은 세션 인증으로 http 쿠키를 사용합니다. WebSocket이 브라우저를 통해 보낸 메시지에는 세션 ID나 임의 매개변수가 없습니다.
이런 방식으로 사용자가 취약한 WEB 애플리케이션에 로그인한 후 동일한 브라우저에서 http://www.php.cn/(공격자의 웹사이트)을 열면 http://www.php//www.php .cn/은 이 취약한 애플리케이션을 통해 애플리케이션 서버와의 WebSocket 연결 설정을 시도한 다음 브라우저를 통해 유효한 인증 세션 ID가 포함된 요청 패킷을 보낼 수 있습니다. 따라서 공격자의 웹 사이트에서 설정된 WebSocket 연결은 애플리케이션 자체와 동일한 권한을 갖게 됩니다.
전체 애플리케이션이 웹소켓에서 실행되므로 WebSocket을 하이재킹하는 것은 사용자 세션을 하이재킹하는 것과 같습니다. 따라서 이 취약점은 본질적으로 저장된 크로스 사이트 스크립팅 취약점과 동일합니다.
이것이 나쁘다고 생각한다면, 어떤 경우에는 WebSocket 크로스 사이트 스크립팅이 사용자 시스템에서 원격 코드 실행을 달성할 수도 있다는 말을 들으면 더 놀랄 것입니까? IPython 노트북 예제를 참조하세요.
테스트하기 전에 가장 먼저 해야 할 일은 애플리케이션에 WebSocket이 존재하는지 확인하는 것입니다. 다행히도 다음 세 가지 사항만 알면 매우 간단합니다.
1. WebSocket URL 연결은 일반적으로 ws:// 또는 wss://로 시작합니다.
2. 연결의 Origin 헤더가 감지되어야 합니다. 웹 페이지는 Origin 필드를 통해 설정된 WebSocket 링크일 수 있습니다.
3. 브라우저와 서버 간에 전송되는 메시지를 통해 일반적인 WebSocket 연결의 특성을 확인할 수 있습니다.
아래 그림은 IronWASP 로그를 통해 Origin 필드의 값과 WebSocket의 URL 값을 가져오는 방법을 보여줍니다.
이 정보가 있으면 몇 가지 특별한 방법을 사용하여 사이트 간 WebSocket 하이재킹 취약성을 탐지할 수 있습니다. 다음은 세 가지 간단한 예입니다.
burpsuite가 WebSockets 메시지를 캡처하고 기록할 수 있다는 점을 여기서 언급해야 합니다. ZAP와 IronWASP는 웹소켓 요청을 재생할 수 있는 소프트웨어로 제가 알고 있습니다.
burpsuite에서는 websocket 메시지를 재생할 수 없지만 제한된 조건에서 WebSocket 핸드셰이크 패키지가 성공하는지 여부는 계속 감지할 수 있습니다. 테스트를 위해 웹소켓 업그레이드 요청 패킷을 분석해야 합니다. 이 패킷은 http 또는 https를 통해 전송되므로 재생할 수 있습니다.
다음 스크린샷은 웹소켓 연결의 효과적인 요청과 응답을 보여주는 burpsuite replayer(반복 탭)의 기록입니다.
테스트용 이 취약점의 경우 Origin 헤더를 다시 만든 다른 요청 패킷을 보내야 합니다. 응답 패킷에 "101 Web Socket Protocol Handshake" 표시가 있으면 WebSocket이 성공적으로 설정되었음을 의미합니다.
연결이 성공적으로 설정되지 않으면 애플리케이션이 외부 WebSocket 연결을 거부하므로 이 취약점이 없음을 의미합니다. 설정이 성공적으로 완료되면 다음 테스트 단계를 시작하여 애플리케이션에 WebSocket 교차 사이트 하이재킹 취약점이 있는지 확인할 수 있습니다. 여기에 설명이 필요합니다. 연결이 설정되더라도 Origin에서 일반 연결과 같아야 합니다. 서버가 WebSocket 메시지에 응답하는지 확인한 후에만 애플리케이션이 취약하다는 것이 입증될 수 있습니다. 개발자가 Origin 감지와 연결 권한 인증을 동시에 활성화할 수 있기 때문입니다. 따라서 실험에서 다음과 같은 상황이 발생할 수 있습니다. 설정된 연결은 영원히 유지될 수 있지만 외부 소스가 있는 Origin은 인증을 통과하지 못합니다.
ZAP는 WebSocket 메시지를 재생할 수 있지만 제가 아는 한 Origin 헤더는 변경되지 않습니다. 아래에 소개된 방법은 CSWSH(WebSocket 교차 사이트 하이재킹)를 통해 더 많은 것을 얻는 방법에 대한 대중적인 과학을 제공할 수 있습니다.
테스트가 필요한 웹 애플리케이션을 열고 로그인한 다음 동일한 브라우저에서 새 탭을 열고 http:/를 방문하세요. /www.php .cn/(시뮬레이션된 해커 웹사이트)에 WebSocket의 URL 주소를 입력한 후 웹 페이지에서 연결 버튼을 클릭합니다. 연결이 설정되면 이 페이지를 통해 WebSocket 서버에 메시지를 보낼 수 있습니다. 유효한 세션에서 보낸 메시지를 재생한 다음 서버의 응답 패킷을 확인해야 합니다.
서버의 응답이 이전 유효 세션에서 보낸 일반 패킷과 동일하다면 애플리케이션에 WebSocket 크로스 사이트 하이재킹 취약점이 있을 수 있음을 의미합니다.
IronWASP는 가장 기본적인 탐지 검사에 대해서도 자동화된 스크립트를 제공합니다.
위의 Origin 테스트 방법에 사용된 서버는 http://www.php.cn/입니다. Origin 값을 보다 유연하게 설정하려면 IronWASP의 클라이언트 기능을 사용할 수 있습니다. WebSocket 연결을 테스트하기 위해 Origin 값을 사용자 정의할 수 있습니다.
클라이언트 기능은 다음과 같은 상황에서 사용될 수 있습니다.
1. 애플리케이션은 공개 Origin에서 WebSocket 연결을 허용합니다.
2. 애플리케이션은 로컬 호스트 및 인트라넷 IP의 Origin 필드 값을 허용합니다
이 접근 방식은 개발자와 애플리케이션 내부 테스트를 용이하게 하기 위한 것입니다. IronWASP 클라이언트를 사용하면 인트라넷 IP 또는 로컬 호스트를 Origin으로 적용할 수 있는지 시험해 볼 수 있습니다. 가능하다면 몇 가지 트릭을 사용하여 실제 환경에서 이 취약점을 악용할 수 있습니다. 예를 들어, 응용 프로그램이 http://127.0.0.1:8080을 원본 필드로 허용하는 경우 다음과 같이 할 수 있습니다. 피해자가 우연히 로컬 포트 8080에서 실행 중인 웹 응용 프로그램을 갖고 있고 크로스 사이트가 있는 경우 스크립팅 취약점. 이러한 조건이 충족되면 해커는 먼저 웹 애플리케이션에 대해 사이트 간 공격을 수행한 다음 대상 애플리케이션 서버에 대한 WebSocket 연결을 설정할 수 있습니다.
Origin 헤더를 테스트하기 위해 로컬 호스트 또는 인트라넷 IP를 사용해야 하는 경우 자동 감지를 위한 클라이언트 스크립트를 사용하면 작업이 더 쉬워집니다. IronWASP를 사용하면 Python 또는 Ruby를 사용하여 사용자 정의 스크립팅을 구현할 수 있습니다.
다음 스크립트는 Origin 헤더에 채워진 인트라넷 IP 주소를 독립적으로 감지하고 서버가 이를 인식하는지 테스트할 수 있습니다.
import clr
clr.AddReference("WebsocketClient.exe")
from WebsocketClient import *
def check_conn(origin):
print "Testing origin - " + origin
ws = SyncWebsockClient()
ws.Connect("ws://tatgetapp.com/ws", origin, "SessionID=KSDI2923EWE9DJSDS01212")
ws.Send("first message to send")
msg = ws.Read()
ws.Close()
if msg == "message that is part of valid session":
print "Connection successful!!"
return True
else:
return False
def check_nw():
for nws in ["192.168.0.0/16", "172.16.0.0/12", "10.0.0.0/8"]:
for ip in Tools.NwToIp(nws):
if check_conn("http://" + ip):
break
check_nw()
위 내용은 세션을 완전히 제어하는 방법에 대한 자세한 소개 WebSocket 크로스 사이트 하이재킹의 그래픽과 텍스트 코드를 살펴보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
