Shape에서는 수많은 의심스러운 JavaScript 코드를 접합니다. 페이지에 악의적으로 삽입된 스크립트를 발견하기도 하고, 고객이 조언을 구하기 위해 보내오기도 하며, 보안 팀이 웹에서 당사 서비스의 특정 측면을 구체적으로 언급하는 듯한 리소스를 찾아내기도 합니다. 일상적인 업무의 일환으로, 저희는 스크립트가 무엇을 하고 어떻게 작동하는지 파악하기 위해 곧바로 분석에 착수합니다. 이러한 스크립트는 대개 최소화되어 있고 난독화된 경우가 많으며, 심층 분석이 가능한 상태로 만들려면 항상 여러 단계의 수정 작업이 필요합니다.
최근까지 이러한 분석을 수행하는 가장 쉬운 방법은 수동 편집이 가능한 로컬 캐시 환경을 사용하거나 프록시를 통해 콘텐츠를 실시간으로 다시 작성하는 것이었습니다. 로컬 방식이 가장 편리하지만, 웹사이트가 다른 환경에서 항상 완벽하게 작동하는 것은 아니어서 실제 작업을 시작하기도 전에 문제 해결에 깊이 빠지는 경우가 많습니다. 프록시는 매우 유연하지만 대개 사용하기 번거롭고 이식성이 떨어집니다. 사람마다 자신의 환경에 맞춘 별도의 설정을 사용하며, 익숙한 프록시도 제각각이기 때문입니다. 저는 요청과 응답이 발생하는 즉시 가로채 실시간으로 수정하기 위해 Chrome과 Chrome의 DevTools 프로토콜을 사용하기 시작했습니다. 이 방식은 Chrome이 설치된 모든 플랫폼에서 사용할 수 있고, 수많은 문제를 우회하며, 일반적인 JavaScript 도구와도 원활하게 통합됩니다. 이 글에서는 Chrome의 DevTools 프로토콜을 사용해 JavaScript를 실시간으로 가로채고 수정하는 방법을 살펴보겠습니다.
여기서는 Node.js를 사용하지만, DevTools 훅에 쉽게 접근할 수 있다면 내용의 상당 부분을 원하는 언어에도 적용할 수 있습니다.
먼저 Chrome 스크립팅을 처음 접한다면 Eric Bidelman이 작성한 훌륭한 헤드리스 Chrome 시작 가이드를 참고하세요. 이 가이드의 팁은 헤드리스 Chrome과 GUI Chrome 모두에 적용됩니다(한 가지 예외는 다음 섹션에서 다루겠습니다).
Chrome 실행하기
간편하게 작업하기 위해 npm의 chrome-launcher 라이브러리를 사용하겠습니다.
chrome-launcher는 여러분이 예상하는 바로 그 기능을 수행하며, 터미널에서 사용하던 것과 동일한 명령줄 스위치를 변경 없이 전달할 수 있습니다( 유용한 목록은 여기에서 관리되고 있습니다). 다음 옵션을 전달하겠습니다:
–window-size=1200,800
- 창 크기를 적절한 크기로 자동 설정합니다.
–auto-open-devtools-for-tabs
- 개발자 도구를 자주 사용하므로 자동으로 엽니다.
–user-data-dir=/tmp/chrome-testing
- 사용자 데이터 디렉터리를 고정된 경로로 설정합니다. (이상적으로는 이렇게 할 필요가 없어야 하지만, Mac OSX의 비헤드리스 모드에서는 이 플래그 없이는 요청을 가로챌 수 없는 것 같습니다. 더 나은 방법을 알고 계시다면 Twitter로 알려주세요!)
스크립트를 실행하여 Chrome이 열리는지 확인해 보세요. 다음과 비슷한 화면이 표시될 것입니다:
Chrome DevTools 프로토콜 사용하기
이는 'Chrome 디버거 프로토콜'이라고도 하며, Google 문서에서는 두 용어가 혼용되는 것으로 보입니다. 먼저 npm을 통해 chrome-remote-interface 패키지를 설치하세요. 이 패키지는 DevTools 프로토콜과 편리하게 상호 작용할 수 있는 메서드를 제공합니다. 더 자세히 알아보려면 프로토콜 문서를 가까이 두고 참고하세요.
CDP를 사용하려면 디버거 포트에 연결해야 합니다. 여기서는 chrome-launcher 라이브러리를 사용하므로 chrome.port를 통해 간편하게 접근할 수 있습니다.
프로토콜의 여러 도메인은 먼저 활성화해야 합니다. 우선 Runtime 도메인부터 활성화하여 콘솔 API에 연결하고 브라우저의 모든 콘솔 호출을 명령줄로 전달하겠습니다.
이제 스크립트를 실행하면 모든 기능을 사용할 수 있는 Chrome 창이 열리고, 콘솔 메시지도 모두 터미널에 출력됩니다. 이것만으로도 훌륭하며, 특히 테스트할 때 매우 유용합니다!
요청 가로채기
먼저 가로채려는 대상을 등록하려면 RequestPatterns 목록을 setRequestInterception에 전달해야 합니다. “Request” 단계 또는 “HeadersReceived” 단계에서 가로챌 수 있으며, 실제로 응답을 수정하려면 “HeadersReceived”까지 기다려야 합니다. 리소스 유형은 개발자 도구의 네트워크 패널에서 흔히 볼 수 있는 유형에 대응합니다.
위에서 Runtime 도메인을 활성화했던 것처럼 Network 도메인도 활성화해야 합니다. 같은 배열에 Network.enable()을 추가하는 것을 잊지 마세요.
이벤트 핸들러를 등록하는 과정은 비교적 간단하며, 가로챈 각 요청에는 요청에 관한 정보를 조회하거나 나중에 요청을 계속 진행하는 데 사용할 수 있는 interceptionId가 포함됩니다. 여기서는 단순히 개입하여 가로채는 모든 요청을 터미널에 기록합니다.
요청 수정하기
요청을 수정하려면 base64 문자열을 인코딩하고 디코딩하는 몇 가지 도우미 라이브러리를 설치해야 합니다. 사용할 수 있는 라이브러리는 많으니 원하는 것을 선택해도 됩니다. 여기서는 atob 및 btoa를 사용하겠습니다.
응답을 처리하는 API는 다소 불편합니다. 응답을 처리하려면 모든 응답 로직을 요청 가로채기 단계에 포함해야 하며(예를 들어 응답 자체를 단순히 가로채는 방식과는 다릅니다), 그런 다음 가로채기 ID를 사용해 본문을 조회해야 합니다. 핸들러가 호출되는 시점에 본문이 아직 준비되지 않았을 수 있기 때문이며, 이 방식을 사용하면 원하는 데이터가 준비될 때까지 명시적으로 기다릴 수 있습니다. 또한 본문이 base64로 인코딩되어 전달될 수도 있으므로, 그대로 넘기기 전에 인코딩 여부를 확인하고 디코딩해야 합니다.
이제 JavaScript를 마음껏 수정해도 됩니다. 작성한 코드는 응답 처리 과정에 개입하므로, 요청된 전체 JavaScript에 접근하고 수정된 응답을 다시 보낼 수 있습니다. 멋지죠! 수정한 코드가 브라우저에서 실행될 때 터미널에 메시지가 표시되도록 JS 끝에 console.log를 추가해 보겠습니다.
콘텐츠가 원본 리소스와 함께 전송된 헤더와 충돌할 수 있으므로 수정된 본문만 그대로 전달할 수는 없습니다. 현재 적극적으로 테스트하고 조정하는 중이므로, 전달해야 할 다른 헤더 정보를 지나치게 신경 쓰기 전에 기본적인 부분부터 시작하는 것이 좋습니다. 필요한 경우 이벤트 핸들러에 전달되는 responseHeaders 를 통해 응답 헤더에 접근할 수 있지만, 지금은 나중에 쉽게 조작하고 편집할 수 있도록 배열에 최소한의 헤더 집합을 직접 구성하겠습니다.
새 응답을 전송하려면 HTTP 상태 줄을 포함한 전체 HTTP 응답을 작성하여 base64로 인코딩한 다음, rawResponse 속성을 통해 continueInterceptedRequest에 전달되는 객체에 포함해야 합니다.
이제 스크립트를 실행하고 인터넷을 탐색하면, 스크립트가 JavaScript를 가로채고 수정된 JavaScript가 브라우저에서 실행되면서 다음과 비슷한 내용이 터미널에 표시됩니다. 또한 console.log() 호출 결과도 튜토리얼 시작 부분에서 만든 후크를 통해 전달됩니다.
기본 예제의 전체 실행 코드는 다음과 같습니다:
다음 단계
먼저 소스 코드를 보기 좋게 정리해 출력해 볼 수 있습니다. 이는 무언가를 리버스 엔지니어링할 때 언제나 유용한 출발점입니다. 물론 대부분의 최신 브라우저에서도 이 작업을 할 수 있지만, 브라우저와 브라우저 버전이 달라도 일관성을 유지하고 소스를 분석하면서 단서들을 서로 연결하려면 수정의 각 단계를 직접 제어하는 편이 좋습니다. 저는 낯설고 난독화된 코드를 파헤칠 때 변수와 함수의 용도를 이해하기 시작하면 그에 맞게 이름을 바꾸곤 합니다. JavaScript를 안전하게 수정하는 일은 결코 간단하지 않으며 그 자체로 별도의 블로그 글감이지만, 지금은 unminify 같은 도구를 사용해 일반적인 최소화 및 난독화 기법을 되돌릴 수 있습니다.
npm을 통해 unminify를 설치하고 새 JavaScript 본문을 unminify 호출로 감싸 실제로 어떻게 작동하는지 확인할 수 있습니다:
다음 게시물에서는 변환에 대해 더 자세히 살펴보겠습니다. 질문이나 의견이 있거나 다른 유용한 팁을 알고 계시다면 Twitter로 연락해 주세요!
작성자 소개
관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.