안드로이드 WebView에서의 CSRF 공격 메커니즘과 방어 전략

초록

본 논문은 Android 애플리케이션에 내장된 WebView가 인증된 사용자를 대신해 임의의 HTTP 요청을 수행함으로써 발생할 수 있는 Cross‑Site Request Forgery(CSRF) 위협을 분석한다. WebView API인 loadUrl, postUrl, shouldOverrideUrlLoading, addJavascriptInterface 등을 이용해 공격자가 쿠키와 세션 정보를 탈취하거나 조작해 피해자 사이트에 악의적인 요청을 전송하는 시나리오를 제시하고, 이를 방지하기 위한 토큰 기반 검증, SameSite 쿠키 설정, WebView 보안 강화 방안을 제안한다.

상세 분석

WebView는 안드로이드 애플리케이션에 브라우저 기능을 삽입하기 위한 UI 컴포넌트로, 기본적으로 모바일 Chrome 엔진을 사용한다. 이 컴포넌트는 WebViewClient 와 WebChromeClient 를 통해 애플리케이션 코드와 웹 페이지 사이에 양방향 통신을 허용한다. 논문은 이러한 통신 경로가 CSRF 공격에 악용될 수 있음을 강조한다.

첫 번째 공격 벡터는 loadUrl 또는 postUrl 메서드를 이용해 피해자가 이미 로그인한 상태인 웹 사이트에 자동으로 GET/POST 요청을 보내는 방식이다. WebView는 쿠키 저장소(CookieManager)를 공유하므로, 사용자가 로그인한 세션 쿠키가 그대로 전송된다. 공격자는 악성 앱 내부에서 loadUrl(“https://victim.com/transfer?amount=1000&to=attacker") 와 같이 파라미터를 조작해 금전 이체, 설정 변경 등의 동작을 수행할 수 있다.

두 번째 벡터는 shouldOverrideUrlLoading 콜백을 활용하는 방법이다. 이 콜백은 웹 페이지가 새로운 URL을 로드하려 할 때 애플리케이션에게 제어권을 넘겨준다. 공격자는 이 메서드에서 의도적인 리다이렉트를 삽입하거나, Intent 를 통해 외부 브라우저를 호출해 동일한 요청을 재전송함으로써 사용자의 인증 정보를 그대로 이용한다.

세 번째는 addJavascriptInterface 를 통한 자바스크립트 인터페이스 노출이다. 안드로이드 4.2 이하에서는 @JavascriptInterface 가 없었기 때문에, 악성 웹 페이지가 window.android.someMethod() 형태로 직접 네이티브 메서드를 호출해 HTTP 요청을 만들 수 있었다. 논문은 이 취약점이 최신 버전에서도 완전히 사라지지 않았으며, 특히 WebView.setAllowUniversalAccessFromFileURLs(true) 와 setJavaScriptEnabled(true) 가 동시에 활성화된 경우 위험이 증폭된다고 지적한다.

또 다른 중요한 포인트는 쿠키를 직접 헤더에 삽입하는 방식이다. CookieManager.getInstance().getCookie(“https://victim.com”) 로 쿠키 문자열을 획득한 뒤, HttpURLConnection 또는 OkHttp 와 같은 네트워크 라이브러리를 사용해 수동으로 Cookie 헤더를 설정한다. 이렇게 하면 WebView와는 별개로 백그라운드 스레드에서 HTTP 요청을 수행할 수 있어, UI 차단 없이 은밀히 공격을 진행한다.

논문은 실험을 통해 위 시나리오가 실제 안드로이드 5.0~9.0 환경에서 정상적으로 동작함을 입증하였다. 특히, WebView 가 HTTPS를 사용하더라도 인증서 검증을 우회하지 않는 한, 세션 쿠키가 그대로 전송되므로 CSRF 방어에 사용되는 SameSite=Lax/Strict 속성이 적용되지 않는다. 이는 서버 측에서 CSRF 토큰을 검증하지 않을 경우, WebView 기반 앱이 사실상 “신뢰할 수 있는 브라우저”로 오인되어 공격이 성공한다는 점을 의미한다.

방어 측면에서 논문은 다음과 같은 전략을 제시한다. 첫째, 서버는 모든 상태 변경 요청에 대해 CSRF 토큰을 검증하고, 토큰을 쿠키가 아닌 HTTP‑Only, SameSite=Strict 속성을 가진 헤더에 포함시켜야 한다. 둘째, 애플리케이션은 WebView 생성 시 setAllowFileAccess(false), setAllowUniversalAccessFromFileURLs(false) 등을 명시적으로 비활성화하고, addJavascriptInterface 사용을 최소화하거나 @JavascriptInterface 어노테이션을 반드시 붙여야 한다. 셋째, shouldOverrideUrlLoading 에서 외부 URL 로드를 차단하고, 허용된 도메인 리스트와 매칭되지 않을 경우 요청을 무시하도록 구현한다. 넷째, CookieManager.setAcceptThirdPartyCookies(webView, false) 와 WebSettings.setMixedContentMode(WebSettings.MIXED_CONTENT_NEVER_ALLOW) 을 적용해 서드파티 쿠키와 혼합 콘텐츠를 차단한다. 마지막으로, 민감한 작업은 WebView 내부가 아닌 별도 네이티브 API를 통해 수행하고, 사용자에게 명시적인 확인 UI를 제공함으로써 “자동화된” 요청을 방지한다.

이러한 방어 조치를 종합하면, WebView가 제공하는 편리함을 유지하면서도 CSRF 공격 표면을 크게 축소할 수 있다. 논문은 또한 향후 안드로이드 플랫폼이 WebView 에 대한 권한 모델을 강화하고, SameSite 속성을 기본적으로 적용하도록 업데이트한다면, 현재와 같은 공격 시나리오가 크게 감소할 것이라고 전망한다.