SMS 기반 인증의 새로운 취약점

비밀번호만을 사용하는 인증의 기존 취약점을 대부분 해결하지 못하는 것 외에도 SMS를 두 번째 요소로 사용하면 애플리케이션이 추가적인 공격 벡터에 노출됩니다.

물리적 장치의 도난

아마도 소유 기반 인증에 대한 가장 확실한 공격은 물리적 장치의 도난일 것입니다. 휴대전화를 훔친 범죄자는 휴대전화가 잠겨 있어도 알림에 표시된 OTP에 접근할 수 있습니다. 휴대전화 도난 피해자 중 다수가 은행 계좌에 있는 돈을 잃은 적이 있습니다.

SIM(Subscriber Identity Module) 스와핑

범죄자는 문자 메시지로 전송된 OTP에 접근하기 위해 실제로 휴대전화를 소지할 필요는 없습니다. SIM 스와핑은 SIM 하이재킹이나 SIM 포팅이라고도 하며, 공격자는 이를 통해 SMS 기반 인증을 우회할 수 있습니다. SMS 기반 인증은 고객용 앱에서 사용되는 가장 인기 있는 MFA 형태입니다. SIM 스왑 공격에서 사기꾼은 통신 서비스 제공업체가 전화번호를 다른 기기로 전송할 수 있는 기능을 악용합니다. 이 기능은 휴대전화를 분실하거나 도난당했을 때 유용합니다.

사기꾼은 먼저 온라인 조사, 피싱, 사회 공학 등을 통해 피해자의 개인 정보를 수집합니다. 공격자는 이 정보를 이용해 전화 회사를 설득해 피해자의 전화번호를 사기꾼의 SIM으로 전송하게 합니다. 또는 공격자는 자격 증명 채우기, 무차별 대입 추측 또는 사전 공격을 사용하여 서비스 제공자의 사용자 계정을 침해할 수 있습니다.

사기꾼은 피해자의 전화 서비스를 통제함으로써 피해자에게 전송되는 모든 SMS 및 음성 통화를 수신하게 됩니다. 이를 통해 사기꾼은 문자 메시지를 통해 전송된 모든 보안 토큰을 가로챌 수 있습니다.

하드웨어 토큰 장치

하드웨어 토큰 장치는 일반적으로 매우 작은 특수 장치로, 사용자가 인증을 위해 애플리케이션에 입력하는 OTP를 표시합니다. 이러한 장치는 SMS 기반 인증의 주요 취약점 중 하나를 제거하여 애플리케이션에서 사용자와의 통신을 요구하지 않고도 소유권을 증명하는 수단을 제공합니다.

각 로그인마다 사용자에게 OTP를 전송하는 대신, 장치는 초기 시드 값과 알고리즘을 기반으로 OTP 스트림을 생성합니다. 시드 값 자체는 설정 시 장치와 인증 서비스 간에 공유됩니다. 시드 값은 로그인 요청과 같은 이벤트나 60초와 같은 시간 지속 시간에 따라 증가하는 카운터로 증강됩니다 . 이를 각각 이벤트 기반 OTP(EOTP)와 시간 기반 OTP(TOTP)라고 합니다. EOTP와 TOTP는 모두 해시 기반 OTP(HOTP) 유형입니다. 카운터와 시드가 함께 해시 함수에 전달되어 겉보기에 무작위적인 숫자 문자열을 생성하지만 올바르게 구현하면 예측 가능한 패턴이 나타나지 않습니다.

하드웨어 토큰을 사용하면 OTP를 텍스트로 보낼 필요가 없으므로 SIM 스와핑 등의 수단을 통해 OTP가 사용자에게 도달하기 전에 OTP를 캡처하는 것이 불가능합니다. 하지만 사용자는 비밀번호와 동일한 통신 채널을 통해 OTP를 인증 서비스로 전송하는 앱에 OTP를 입력해야 하므로 SMS 기반 인증의 다른 취약점 대부분은 그대로 남아 있습니다. 공격자는 텍스트로 전달된 OTP와 동일한 방식으로 엔드포인트, 네트워크 또는 애플리케이션을 손상시켜 비밀번호와 OTP에 액세스할 수 있습니다.

SMS 기반 인증에 대한 가장 일반적인 공격인 실시간 피싱 프록시는 하드웨어 장치에서 생성된 OTP에도 똑같이 효과가 있는데, 이는 OTP가 휴대전화나 특수 장치에 나타나는지 여부에 관계없이 사용자를 속여 가짜 사이트에 OTP를 입력하게 하기 때문입니다.

하드웨어 장치가 있으면 공격자가 사용자에게 전송되는 OTP를 가로채는 일은 불가능하지만, 이 장치는 손상될 수 있는 시드 값에 의존합니다. 공격자는 장치에 물리적으로 접근하여 시드 값에 접근할 수 있습니다( MFA 해킹을 위한 12가지 이상의 방법 에 대한 전자 현미경 공격 참조), 인증 서비스에서 사용하는 데이터베이스를 손상시키거나, 장치와 인증 서비스 간에 시드 값에 대한 합의가 이루어지는 설정 프로세스를 가로채는 방법 등이 있습니다.

인증 앱

인증기 앱은 하드웨어 토큰과 매우 유사하게 작동하여 초기 시드와 알고리즘을 기반으로 OTP 스트림을 생성하여 취약한 채널을 통해 시드를 전달할 필요성을 방지합니다. 그러나 OTP를 전달하기 위해 대체 채널을 활용하여 한 걸음 더 나아갈 수도 있습니다. 이 시나리오에서는 사용자 이름과 비밀번호의 검증이 성공적으로 완료되면 인증 서비스가 인증자 앱으로 푸시 알림을 보내 사용자에게 요청을 승인하도록 요청합니다. 승인되면, 인증 앱은 사용자가 애플리케이션에 입력할 필요 없이 OTP를 인증 서비스로 직접 전송합니다. 인증 앱과 인증 서비스 간의 통신은 별도의 연결을 통해 이루어집니다.

대체 통신 채널을 사용하면 공격자가 애플리케이션을 손상시켜 OTP에 액세스할 수 없습니다. OTP가 애플리케이션에 입력되지 않기 때문입니다. 비밀번호와 OTP는 서로 다른 보안 채널을 통해 전달되기 때문에, 네트워크 연결을 손상시켜 비밀번호와 OTP를 모두 수집하는 것이 더 어렵습니다. 그러나 엔드포인트가 침해되면 애플리케이션 자체와 인증 앱이 동일한 장치에서 실행되는 경우 공격자가 비밀번호와 OTP에 모두 액세스할 수 있습니다. (Google Authenticator를 손상시키는 맬웨어에 대한 F5 Labs 보고서를 참조하세요.)

안타깝게도 인증 앱은 실시간 피싱 프록시 사용을 방지할 수 없습니다. 사용자는 여전히 피싱 문자 메시지를 통해 가짜 사이트에 사용자 이름과 비밀번호를 입력하도록 속습니다. 자격 증명을 입력하면 애플리케이션이 인증자 앱에 요청을 트리거합니다. 사용자는 신뢰할 수 있는 애플리케이션에 로그인하는 중이라고 생각하기 때문에 요청을 승인할 가능성이 높으며, 그러면 인증이 완료됩니다. 공격자는 OTP를 볼 수 없지만 공격자의 프록시는 인증된 세션을 제어하게 되므로 공격자는 사용자 계정에 접근할 수 있습니다. (RTPP와 푸시 알림 인증에 대한 자세한 내용은 Hacker News의 피싱 플랫폼 관련 기사를 참조하세요.)

게다가 인증 앱의 사용 편의성으로 인해 공격자가 사회 공학을 통해 MFA를 무력화할 수 있는 또 다른 수단이 생겨났습니다. MFA 폭격 또는 MFA 피로 공격에서 공격자는 코드에 대한 여러 가지 사기성 요청을 보내서 대상에게 인증 코드를 제공하도록 속입니다. 공격자는 일반적으로 자동화된 도구를 사용하여 대량의 요청을 생성하고, 피해자에게 과도한 수의 알림이나 인증 코드를 입력하라는 메시지로 압도합니다.

MFA 폭격은 사용자가 SMS 메시지나 하드웨어 장치에서 OTP를 입력하도록 속일 수 있지만, 사용자가 버튼 하나만 눌러 요청 홍수를 쉽게 중단할 수 있기 때문에 인증기 앱에 대해 특히 효과적입니다.

생체 인증

소지 기반 인증보다 생체 인증을 구현하는 방법이 더 많습니다. 인증 요청을 트리거하고 해당 데이터를 인증 서비스로 다시 전달하는 방법은 다양하며, 지문에서 홍채 스캔까지 다양한 형태의 생체 인식이 있습니다. 스캔을 수행하는 데 필요한 하드웨어는 노트북의 지문 인식 카메라와 같이 애플리케이션을 실행하는 장치에 통합되어 있을 수도 있고 별도의 하드웨어가 필요할 수도 있습니다. 생체 인식 판독기는 운영 체제나 특수 애플리케이션에 의해 제어될 수 있습니다. 이러한 구현상의 차이를 고려하면 모든 취약점을 모델링하는 것은 어렵습니다. 그러나 생체 인증이 보안성이 높다는 평판에도 불구하고 생체 인증에는 여전히 매우 명확한 취약점이 있다는 점을 알아두는 것이 중요합니다.

실제로, 소지 요소를 우회하는 널리 쓰이는 방법 중 하나인 실시간 피싱 프록시는 생체 인식을 우회하는 데에도 똑같이 사용할 수 있습니다. 사용자가 공격자가 제어하는 애플리케이션에 신뢰할 수 있는 애플리케이션이라고 생각하고 로그인하면, 해당 애플리케이션은 자격 증명을 사용하여 사용자를 대신하여 애플리케이션에 로그인하면서 생체 인증 요청이 트리거됩니다. 사용자가 실제 애플리케이션에 인증한다고 믿는 한 생체 인증을 진행할 가능성이 높으며, 공격자는 이를 통해 계정에 접근할 수 있습니다. (W3C에서 만든 FIDO2 표준 WebAuthn에는 피싱에 대한 보호 기능이 포함되어 있지만 아직 웹 애플리케이션에서 널리 채택되지는 않았습니다.)

생체 인증이 엔드포인트, 애플리케이션 또는 네트워크를 손상시켜 무력화될 수 있는지의 여부는 구체적인 구현 방식에 따라 달라집니다. 생체 인증 시스템이 애플리케이션과 동일한 장치에서 실행되는 경우 엔드포인트가 손상되면 인증이 해제될 수 있습니다. 애플리케이션이 생체 인증 프로세스를 관리하는 경우 앱이 손상되면 인증이 해제될 수 있습니다. 생체 인증이 애플리케이션에서 사용하는 것과 동일한 통신 채널을 통해 전송되는 경우 네트워크가 손상되면 인증이 해제될 수 있습니다. 간단히 말해서, 생체 인증에는 구현에 특화된 세부적인 위협 모델링이 필요합니다.

생체 인증은 복제 및 스푸핑이라는 확실한 취약점을 노출합니다. 지문을 생각해 보세요. 우리는 거의 모든 매끄러운 표면에 그것들을 버립니다. 우리는 그것들을 문 손잡이, 레스토랑, 쓰레기통에 버립니다. 이런 표면에서 지문을 수집하는 건 쉬운 일이에요. 우리는 경찰 드라마에서 이런 장면을 수도 없이 봤거든요. 3D 프린터부터 젤리곰 까지, 지문을 복제하는 것도 쉬운 일입니다.

다른 형태의 생체 인식의 경우, 생체 인식을 어떻게 스푸핑할 수 있는지 밝히려는 보안 연구원과 스푸핑 방지 기술을 개발하는 공급업체 간에 지속적인 경쟁이 있습니다. 3D 마스크는 공항의 얼굴 판독기를 속였습니다. 하지만 이러한 마스크는 생체 검사 및 기타 방법을 통해 감지 될 수 있습니다. 마찬가지로 공격자는 딥페이크 음성 합성 기술을 이용한 음성 녹음을 사용해 음성 인식 시스템을 우회하기도 했지만, 녹음 장치에서 미묘한 왜곡을 더해 이러한 스푸핑을 감지하는 것이 가능할 수도 있습니다. 홍채 이미지도 미용용 콘택트 렌즈나 인공 눈을 사용하여 복제하고 위조 할 수 있지만, 인체 조직과 합성 소재를 구별하는 조명을 포함한 다양한 위조 방지 기술을 사용하면 위조를 감지할 수 있습니다. 간단히 말해, 생체 인식 판독기의 보안은 스푸핑과 스푸핑 방지 기술의 현재 상태에 따라 달라집니다.

우리가 은둔자처럼 살며 표면을 직접 만지는 것을 피하더라도 공격자는 우리의 생체 데이터를 훔칠 수 있습니다. 공격자들은 악성 소프트웨어, 소셜 엔지니어링 및 패치되지 않은 취약점을 악용하여 수십억 개의 사용자 이름과 비밀번호를 훔쳤습니다. 공격자가 우리의 비밀번호를 저장하는 데이터베이스를 뚫을 수 있다면, 그들은 확실히 우리의 생체 인식 정보를 저장하는 데이터베이스도 뚫을 것입니다. 그리고 단 한 번의 침해로 인해 생체 인식 정보가 노출되면 스푸핑이 감지되는지 여부에 따라 인증에 사용하는 것이 안전하지 않을 수 있습니다.

복제 및 스푸핑으로 인한 보안 위험을 더욱 키우는 것은 생체 인식으로 측정되는 특성을 쉽게 변경할 수 없다는 사실입니다. 공격자가 비밀번호를 훔치면 우리는 비밀번호를 변경할 수 있습니다. 공격자가 OPT 동글이나 휴대전화를 훔친 경우, 우리는 그것을 교체하고 시드를 재설정할 수 있습니다. 그러나 공격자가 우리의 지문, 손바닥 무늬, 얼굴 이미지 또는 다른 생물학적 특징에 접근하여 이를 효과적으로 위조하는 방법을 알게 되면, 우리는 상당한 고통 없이 이러한 신체적 특징을 바꿀 수 없습니다.

MFA 보안 강화

MFA는 단일 요소 기반 비밀번호 인증보다 개선된 방식이기는 하지만, 적어도 현재 널리 사용되는 구현 방식에서는 여전히 취약합니다. 따라서 MFA를 보안 여정의 끝으로 생각하기보다는 새로운 시작으로 생각해보세요. 위협 모델링, 코드 검토, 취약성 스캐닝, 침투 테스트, 레드팀을 포함한 앱 보안 모범 사례는 그 어느 때보다 관련성이 높습니다. 위협 모델링에서는 ID 저장소부터 물리적, 네트워크 및 데이터 보안까지 다양한 공격 지점을 고려하여 인증 및 세션 관리 프로세스의 각 측면을 살펴봅니다. 사이버공격은 가장 약한 연결고리를 노릴 가능성이 높다. 특히, MFA의 취약성은 더 많은 주의가 필요한 몇 가지 주요 우려 사항을 나타냅니다. 즉, 자동화 완화, JavaScript 공급망 공격에 대한 보호, 위험 맥락 고려입니다.

네트워크에서 봇 제거

범죄자는 자격 증명 채우기, 실시간 피싱 프록시, MFA 폭격을 포함하여 MFA에 대한 몇 가지 주요 공격을 확장하기 위해 봇을 사용합니다. 즉, 봇을 완화하는 것이 모든 형태의 MFA를 보호하는 데 중요합니다.

OWASP 에서 정의한 자격 증명 채우기 공격의 경우, 범죄자는 일반적으로 다크 웹에서 구매하여 이전 침해로부터 도용한 자격 증명을 얻고 해당 자격 증명을 다른 애플리케이션의 로그인과 테스트합니다. 침해로 인해 수십억 개의 자격 증명이 노출되었기 때문에 범죄자는 봇을 사용하여 테스트를 자동화하고 엄청난 수의 자격 증명을 테스트하여 수익을 극대화합니다. 연방수사국 , 증권거래위원회 , 뉴욕 검찰총장은 신임장 정보 유출로 인한 재정적 위험에 대해 경고했으며, 130개 이상의 규제 기관으로 구성된 글로벌 프라이버시 어셈블리는 신임장 정보 유출을 전 세계 개인정보 보호에 대한 위협으로 선언했습니다.

MFA의 경우, 자격 증명 채우기를 방지하는 것이 비밀번호만 사용하는 인증의 경우만큼 중요합니다. MFA의 핵심은 두 개 이상의 요소를 사용하는 것이지만, 첫 번째 요소를 보호하지 못하면 하나의 요소만 남게 됩니다. 공격자가 사용자의 비밀번호를 발견하면 2단계 인증이 1단계 인증으로 바뀌고 심층 방어가 사라집니다.

게다가, 범죄자들은 비밀번호 이외의 공격에도 봇을 활용하기 때문에 봇을 완화하는 것이 중요합니다. 실제로 봇은 MFA를 무력화하는 가장 일반적인 메커니즘인 실시간 피싱 프록시 공격을 성공적으로 실행하는 데 중요한 도구입니다. 사용자가 가짜 사이트에 자격 증명을 입력하도록 유인하는 피싱 이메일의 희생자가 될 때마다 공격자는 MFA 요청을 생성하기 위해 대상 애플리케이션으로 해당 자격 증명을 전달해야 합니다. 이 요청에는 SMS, 인증 앱 또는 정교한 생체 인식이 포함될 수 있습니다. 요청을 신속하고 대규모로 전달하려면 범죄자는 프로세스를 자동화해야 합니다. 즉, 요청이 봇에서 애플리케이션으로 전달되는 것입니다. (OTP를 우회하기 위해 봇을 사용하는 서비스에 대한 개요는 Krebs on Security 게시물 '일회용 비밀번호 가로채기 봇의 증가'를 참조하세요. ) 즉, 원치 않는 봇이 자격 증명을 제출하지 못하도록 차단함으로써 조직은 실시간 피싱 프록시의 효과를 약화시키고 소유 및 고유 인증 요소를 보다 효과적으로 보호할 수 있습니다.

범죄자들이 봇을 이용해 MFA를 공격하는 또 다른 확실한 방법은 MFA 폭격입니다. 이 맥락에서 폭탄 공격은 사용자가 실수로 또는 귀찮음을 멈추기 위해 인증 요청을 수락하도록 하기 위해 대량의 로그인 요청을 생성하는 것을 의미합니다. 많은 사용자에게 충분히 많은 수의 요청을 생성하여 공격이 수익성을 갖추려면 범죄자는 자동화가 필요하며, 이는 다시 말해 사이트에 도달하는 로그인 요청이 봇에 의해 생성된다는 것을 의미합니다.

이러한 예에서 알 수 있듯이 MFA에 대한 모든 공격은 대규모로 성공하려면 봇이 필요합니다. 즉, MFA를 구현하는 조직은 봇 완화를 심각하게 받아들여야 합니다.

안타깝게도 많은 기업이 봇의 정교함과 범죄자들이 감지를 피하기 위해 봇을 매우 빈번하게 개조하려는 의지를 인식하지 못합니다. 오히려 너무 많은 기업이 CAPTCHA, IP 주소 거부 목록, HTTP 헤더 지문 등 더 이상 효과가 없는 봇 완화 기술에 의존하고 있습니다.

CAPTCHA는 봇이 기계 학습과 클릭 팜에 의존하는 저렴한 CAPTCHA 해결 서비스를 사용하여 퍼즐을 우회할 수 있기 때문에 실제 고객을 짜증나게 하는 것 외에는 봇 보호에 별다른 효과가 없습니다. CAPTCHA 해결 서비스 에 대한 웹 검색을 해보면 가격과 속도 면에서 경쟁하는 회사가 최소 12개는 나옵니다. 이러한 서비스에 대해 자세히 알아보려면 F5 정보부 책임자인 댄 우즈가 쓴 ' 나는 인간이었다(I Was a Human CAPTCHA Solver)' 라는 글을 읽어보세요. 더욱 흥미로운 점은 ChatGPT가 사회 공학적 기법을 사용하여 사용자가 자신을 대신하여 CAPTCHA를 풀도록 함으로써 CAPTCHA를 우회하는 데 성공했다는 것입니다.

봇을 완화하기 위해 WAF 기반 IP 차단 목록에 의존하는 조직의 경우, 그 작업은 똑같이 어렵습니다. 봇 감지를 우회하기 위해 봇 생성자에게 수천만 개의 주거용 IP 주소를 제공하는 서비스 가 있습니다. 이러한 서비스는 회전형 주거용 프록시로 광고됩니다. 봇은 많은 기업용 브라우저가 포워드 프록시를 통해 요청을 보내는 것과 매우 유사하게 프록시에 HTTP 요청을 보내고, 서비스는 웹사이트나 API에 요청을 보내는 데 사용된 공개 IP 주소를 지속적으로 회전합니다. 과거에 봇은 일반적으로 클라우드 서비스의 데이터 센터 프록시를 사용했는데, 이는 잘 알려져 있고 식별하기 쉽습니다. 그러나 이러한 새로운 프록시 서비스는 고객과 동일한 지역의 주거용 IP 주소를 사용합니다. 인터넷 서비스 제공자(ISP)의 NAT로 인해 각 IP 주소가 동시에 봇과 일반 고객을 나타낼 수 있으므로, 실제 고객을 차단하지 않고 이러한 모든 IP 주소를 차단하는 것은 불가능합니다. (이러한 서비스가 IP 주소를 얻는 방법에 대한 연구는 Your Phone is My Proxy라는 논문을 참조하세요.)

헤더 순서의 차이에 따라 봇을 감지하려는 시도 역시 더 이상 효과가 없습니다. 봇이 그 요령을 알아챘기 때문입니다. 실제로 stealth-puppeteer 와 undetected-chromedriver 를 비롯한 몇몇 오픈소스 프로젝트는 헤더 순서를 올바르게 조정하여 이러한 인기 있는 자동화 프레임워크를 사용하면서 감지를 쉽게 우회할 수 있도록 해줍니다.

오늘날 고급 봇을 감지하려면 고급 신호 수집, 24시간 연중무휴 모니터링, 머신 러닝, 봇 재구성에 대한 신속한 대응이 필요합니다. 전담 봇 관리 솔루션이 없고 재조정을 신속하게 감지하고 대응하는 방어 수단이 없다면 범죄자는 봇을 이용해 MFA에 대한 공격을 효과적으로 확장할 수 있습니다.

JavaScript 공급망 공격으로부터 보호하세요

상상할 수 있는 거의 모든 형태의 MFA는 신청 과정에서 문제가 생기면 실패하게 됩니다. 공격자가 애플리케이션에 코드를 삽입하면 게임 종료입니다. 공격자는 자격 증명 및 기타 MFA 입력을 캡처하고, 세션 식별자를 훔쳐 세션을 인수하거나, 애플리케이션에서 직접 데이터를 빼낼 수 있습니다. 현대적 웹 애플리케이션은 일반적으로 20개가 넘는 JavaScript 파일 로 구성되고, 대부분은 타사에서 제공하며 조직의 애플리케이션 보안 팀에서 검토하지 않기 때문에 JavaScript 공급망 공격을 통해 애플리케이션이 손상될 위험이 흔히 생각하는 것보다 더 높습니다.

기존의 클라이언트 측 보안 프로토콜은 오늘날의 동적 웹 앱을 방어하기에는 너무 정적입니다. CSP(콘텐츠 보안 정책)는 JavaScript 공급망 공격을 방지할 수 있는 방식으로 스크립트의 동작을 제한하지만, 타사 공급업체가 CSP 제한에 반하는 방식으로 스크립트를 동적으로 업데이트하는 경우 CSP가 사이트의 기능을 너무 쉽게 손상시킬 수 있습니다. 보안 정책을 위반하여 스크립트가 실패하는 것을 원할 수도 있지만, 프로덕션에서 그러한 실패가 발생하면 고객에게 엄청난 영향을 미칠 수 있습니다. ( CSP가 실패하는 이유는 무엇입니까?를 참조하세요.) 또 다른 웹 보안 프로토콜인 하위 리소스 무결성(SRI)은 스크립트가 변경될 때마다 해시 값으로 스크립트 태그를 업데이트해야 하기 때문에 타사 동적 콘텐츠에는 더욱 적합하지 않습니다 . 이는 변경 사항이 사전 통지 없이 발생하는 경우 불가능합니다. 실제로 SRI는 대부분의 최신 애플리케이션이 의존하는 유형의 스크립트 업데이트를 방지하기 위한 것입니다.

JavaScript 공급망의 취약점을 제거하기 위한 명확한 통제 수단이 없다면, 조직에서는 최소한 위험을 모니터링할 수단을 찾는 데 창의적이어야 합니다. 조직에서는 사이트의 스크립트를 보다 효과적으로 문서화하고 변경의 출처와 빈도에 따라 위험 순위를 매길 수 있습니다. 태그 관리자를 통해 추가된 스크립트는 위험성을 평가하기 위해 정기적인 검토를 거쳐야 합니다. 합성 모니터링, 보고 모드의 CSP 또는 브라우저에서 실행되는 JavaScript 기반 에이전트를 사용하여 스크립트의 동작을 추적하는 모니터링 도구를 얻을 수 있습니다.

타사 스크립트는 매우 빈번하게 변경되고 보안 검토 기회도 없기 때문에, 조직에서는 스크립트가 민감한 데이터를 읽고 신뢰할 수 없는 도메인으로 유출하는 등의 의심스러운 동작이 있는지 지속적으로 애플리케이션을 모니터링하는 것이 중요합니다. JavaScript 공급망 공격에 대한 모니터링이 없다면 어떠한 형태의 MFA도 사용자를 안전하게 보호할 수 없습니다.