동국대학교 국제정보대학원 정보보호학과, 김성현, 2016, 석사학위논문
취약점 분석 및 보완과 코드 생성을 동시에 해주는 LLM을 프로젝트로 진행하려는 중이었다.
frontend로 vscode extension를 개발함과 보안 쪽 담당을 진행할 계획이라 보안 관련 부분을 공부 중에 있는데
웹소켓을 쓰자는 말이 나와서 웹개발 취약점과는 별개로 웹소켓의 취약점을 알아보기 위해 위 논문을 읽었다.
웹소켓 보안 취약점에 대한 설명이 자세하여 이해하기 좋지만 2016년 논문이라 실험 구성 환경이 지금과는 다르다는 점에 유의하며 개념만 쌓는 느낌으로 읽어봤다.
내가 중요하다가 생각하는 챕터는 다음과 같다.
1. CORS로 인한 취약점 <분석 & 대응방안>
2. 기밀성, 무결성 : 이 부분은 넘어가겠다 암호화를 하지 않았을 때, 평문으로 데이터를 주고 받는 것을 문제로 삼고 암호화에 관해 설명했는데 실제로 평문으로 주고 받을 일은 없으니까 이 내용은 지식의 측면으로만 받아들였다.
3. CSWSH와 그에 대한 대응방안 + 문제 ➡️대응방안
XHR을 다른 도메인으로 발생시킬 때, 사용자에게 허가 요청을 하지 않고도 진행이 된다는 점이 이 취약점의 시발점이다.
사용자의 session을 다른 사람이 알고 우회하여 접근한다면 원치 않은 정보를 공격자가 가져가게 된다.
사이트 A와 B가 있고 이 둘의 서로 신뢰 관계라서 CORS이 되어있다고 가정하자.
이 때, A는 xss,csrf와 같은 공격에 대한 예방이 잘 되어있는 반면에 B 서버는 그렇지 못한다면 공격자는 B에서 A로 접속 우회하여 원하는 정보를 가져갈 수 있다. 심지어 사용자는 웹소켓의 특성에 따라 허가 요청을 받지 않기에 자신도 그런 요청을 했는지 안했는지 알 수가 없다.
접근하려는 웹소켓의 URL과 요청자의 origin 속성을 비교해보자.
둘이 다르다면 웹소켓의 URL이 신뢰 관계인 사이트에서 오는 게 아니라는 걸 알 수 있으니까 연결을 닫으면 해결되는 간단한 문제다.
websocket protocol은 서버와 클라이언트의 hand-shake 과정 중에 클라이언트를 인증할 방법을 가지고 있지 않다.
그리고 그 과정 속에서 HTTP의 모든 인증정보를 웹소켓에 넘긴다. 이렇게 되면 CSRF(Cross-Site Request Forgery) 공격에 취약점을 띌 수 있다.
CSRF에 WebSocket Hijacking이 결합된 것을 CSWSH라고 한다. CSRF와 XSS에 웹소켓을 이용하여 쿠키나 HTTP 인증정보를 탈취하는 해킹 방법이다.
websocket 서버를 구축하고 xss,csrf를 시도하는 <script>문에 websocket을 연결하는 코드를 넣어 쿠키,세션을 탈취하는 방법을 이 논문에서는 보여주고 있다. 사실 이 방식은 생각해보지 못해서 확실히 공부할 길이 멀었다고 느꼈다;
A : CORS 기능을 막는 것이기 때문에 웹소켓의 특장점 중 하나를 땅에 버리는 것이다.
B : session 별 임의의 토큰을 사용하게 되면 매번 토큰을 매번 생성하는 것이기 때문에 불필요한 상황에서도 토큰을 생성하는 비효율적인 일이 생길 수 있다.
이 대응방안을 생각하기 위해 많은 시간이 소요됐을 것이라고 생각한다.
Oauth authentication framework를 통한 Access Token을 사용하게 되면 우선 로그아웃을 하지 않는 이상 토큰이 유지되기에 B 대응방안의 문제점인 토큰 생성 프로세스는 실행되지 않을 것이다.
암호화, Oauth 인증 프로세스의 자세한 내용은 이 논문을 참조해서 읽으면 좋을 것 같고
결론만 말하자면 사용자가 세션을 변조해서 들어왔을 때, Access Token을 SHA256 hash function으로 암호화한 값과 탈취한 세션에 저장된 Access Token의 encryption 값을 비교해서 변조의 여부를 파악한다. 두 값이 다르다면 공격자라고 판단하고 Access Token을 없애고 로그아웃 시킨다. (잠복 경찰 느낌)