flawopen.com/XSS di Swift/loadHTMLString

Apakah WKWebView.loadHTMLString di iOS aman untuk konten tak tepercaya?

Halaman referensi

Jawaban singkat

Tidak otomatis aman: WKWebView mem-parsing string yang diberikan sebagai HTML, sehingga tag dan markup yang dapat menjalankan skrip tetap aktif kecuali kontennya tepercaya atau ditangani sesuai konteks. Teks biasa dan HTML kaya buatan pengguna memerlukan kontrol yang berbeda.

Penggunaan aman

RISKY

let html = "\(untrustedText)"
webView.loadHTMLString(html, baseURL: nil)

SAFER

func escapeHTMLText(_ value: String) -> String {
    value
        .replacingOccurrences(of: "&", with: "&")
        .replacingOccurrences(of: "<", with: "<")
        .replacingOccurrences(of: ">", with: ">")
        .replacingOccurrences(of: "\"", with: """)
        .replacingOccurrences(of: "'", with: "'")
}

let html = "\(escapeHTMLText(untrustedText))"
webView.loadHTMLString(html, baseURL: nil)

Risiko tambahan yang perlu diperiksa

Penangan pesan di page world memberi skrip halaman jalur menuju kode aplikasi. `WKContentWorld` dapat memisahkan lingkungan JavaScript, tetapi skrip halaman dan aplikasi tetap berbagi DOM. Jika HTML tak tepercaya dan bridge digunakan bersama, buka hanya kemampuan minimum, validasi pesan beserta frame-nya, lalu otorisasi tiap operasi; jangan samakan pemisahan world dengan otorisasi.

Yang dikendalikan baseURL

Apple mendokumentasikan `baseURL` sebagai dasar untuk menyelesaikan URL relatif dalam HTML yang diberikan. Parameter ini tidak menyanitasi markup atau menonaktifkan JavaScript halaman. Nilai `nil` bukan perlindungan XSS atau pengaturan sandbox; atur kebijakan resource dan navigasi secara terpisah.

Pilih kontrol untuk setiap batas

Untuk teks biasa di dalam node teks HTML, gunakan encoder khusus konteks seperti contoh di bawah; jangan gunakan ulang untuk atribut, URL, CSS, atau JavaScript. Untuk HTML kaya buatan pengguna, gunakan sanitizer terpelihara dengan allowlist elemen, atribut, dan skema URL yang eksplisit. Kirim nilai ke JavaScript aplikasi melalui argumen `callAsyncJavaScript`, bukan interpolasi ke kode sumber. Jika halaman tidak memerlukan JavaScript, `allowsContentJavaScript` dapat menonaktifkan skrip halaman sebagai pertahanan tambahan; ini tidak menggantikan penanganan output yang benar.

Tanya jawab

Apakah UIWebView yang sudah usang berbeda?

Tidak. Risikonya sama dan tidak ada sanitasi tambahan bawaan. Migrasi ke WKWebView memodernisasi teknologi, tetapi tidak dengan sendirinya memperbaiki keamanan.

Apakah `baseURL: nil` mencegah XSS?

Tidak. Apple mendokumentasikan `baseURL` untuk menyelesaikan URL relatif. Ini bukan sanitizer HTML, sakelar skrip, atau jaminan sandbox.

Apakah `WKContentWorld` mengisolasi DOM halaman?

Tidak. Lingkungan JavaScript dipisahkan, tetapi DOM dibagikan. Perlakukan data DOM dan pesan sebagai tidak tepercaya, lalu otorisasi setiap operasi native secara terpisah.

Referensi

Lihat juga Cross-Site Scripting (XSS, CWE-79): cara kerja dan cara mencegahnya di setiap bahasa — flawopen.com Apa beda XSS reflected, stored, dan DOM-based? Risiko keamanan addJavascriptInterface di Android Perlindungan XSS Angular: default aman dan API bypass XSS akibat MIME sniffing: Content-Type dan nosniff CSP dan output escaping: apakah keduanya diperlukan? Apakah dangerouslySetInnerHTML di React aman?