Web Görünümleri – Güvenli Olmayan URI Yükleme
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
OWASP kategorisi: MASVS-CODE: Code Quality (MASVS-CODE: Kod Kalitesi)
Genel Bakış
Güvenli olmayan URI yükleme, bir Android uygulaması URI'yi WebView'e yüklemeden önce geçerliliğini doğru şekilde değerlendiremediğinde meydana gelir.
Bu tür güvenlik açığının temel nedeni, URI'nin birden çok bölümden oluşmasıdır.URI'nin bir WebView'e yüklenmesi veya uygulama tarafından dahili olarak kullanılması için en azından şema ve ana makine (yetkili bölümünün) doğrulanması (ör. izin verilenler listesine eklenmesi) gerekir.
En sık yapılan hatalar şunlardır:
- Şemayı değil ana makineyi kontrol etme. Bu durum, saldırganın kimliği doğrulanmış bir ana makineyle
http://, content:// veya javascript:// gibi şemalar kullanmasına olanak tanır.
- URI'nin özellikle dize olarak alındığı durumlarda doğru şekilde ayrıştırılamaması.
- Şema doğrulanıyor ancak ana makine doğrulanmıyor (ana makine doğrulaması yetersiz).
Son durumda ise bu durum genellikle uygulamanın birincil alanın rastgele alt alanlarına izin vermesi gerektiğinde ortaya çıkar. Bu nedenle, ana makine adı doğru şekilde ayıklanmış olsa bile uygulama, ayıklanan dize bölümünde birincil alan adının varlığını doğrulamak için startsWith, endsWith, veya contains gibi java.lang.String sınıfı yöntemlerini kullanır. Yanlış kullanıldığında bu yöntemler hatalı sonuçlara yol açabilir ve uygulamanın, kötü amaçlı olabilecek bir ana bilgisayara uygunsuz şekilde güvenmesine neden olabilir.
Etki
Ana makinenin kullanıldığı bağlama bağlı olarak etki değişebilir. Bir WebView'da kötü amaçlı bir URI'nin (ör. filtrelemeyi/izin verilenler listesini atlayan) yüklenmesinin hesap ele geçirmeye (ör. kimlik avı kullanma), kod yürütmeye (ör. kötü amaçlı JavaScript yükleme) veya cihazın güvenliğinin ihlaline (köprü kullanılarak teslim edilen exploit kodu) yol açabileceği durumlarda.
Risk azaltma önlemleri
Dize URI'lerini işlerken dizeyi URI olarak ayrıştırmak ve hem şemayı hem de ana makineyi doğrulamak önemlidir:
Kotlin
fun isUriTrusted(incomingUri: String, trustedHostName: String): Boolean {
try {
val uri = Uri.parse(incomingUri)
return uri.scheme == "https" && uri.host == trustedHostName
} catch (e: NullPointerException) {
throw NullPointerException("incomingUri is null or not well-formed")
}
}
Java
public static boolean isUriTrusted(String incomingUri, String trustedHostName)
throws NullPointerException {
try {
Uri uri = Uri.parse(incomingUri);
return uri.getScheme().equals("https") &&
uri.getHost().equals(trustedHostName);
} catch (NullPointerException e) {
throw new NullPointerException(
"incomingUri is null or not well-formed");
}
}
Ana makine doğrulamasında, ilgili URI bölümü ayrıldıktan sonra ana makinenin güvenilir olup olmadığını doğru bir şekilde belirlemek için bu bölümün tamamen (kısmen değil) doğrulanması önemlidir. startsWith veya endsWith gibi yöntemler kullanmaktan kaçınılamadığında doğru söz dizimini kullanmak ve gerekli karakterleri ya da sembolleri gözden kaçırmamak önemlidir (örneğin, endsWith için doğru eşleşme amacıyla alan adından önce "." nokta karakteri gerekir). Bu karakterlerin göz ardı edilmesi, yanlış eşleşmelere ve güvenlik ihlallerine yol açabilir. Alt alan adları sonsuz sayıda iç içe yerleştirilebildiğinden, normal ifade eşleştirme, ana makine adlarını doğrulamak için önerilen bir strateji değildir.
Katkıda bulunanlar: Microsoft Threat Intelligence'dan Dimitrios Valsamaras ve Michael Peck
Kaynaklar
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 2025-07-27 UTC."],[],[],null,["# Webviews – Unsafe URI Loading\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-CODE: Code Quality](https://mas.owasp.org/MASVS/10-MASVS-CODE)\n\n\nOverview\n--------\n\nAn unsafe URI Loading occurs when an Android application fails to correctly\nevaluate the validity of a URI before loading it into a WebView.\n\nThe underlying reason behind this type of vulnerability is that a\n[URI consists of multiple parts](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/URI.html), of which, at a minimum, the scheme and the\nhost (of the authority part) must be verified (e.g. allowlisted) before the URI\ngets loaded to a WebView or is used internally by the application.\n\nThe most common mistakes include:\n\n- Checking the host but not the scheme, allowing an attacker to use schemes like `http://`, `content://` or `javascript://` with an authenticated host.\n- Failing to parse the URI correctly, especially in cases where the URI is received as a string.\n- Validating the scheme but not the host (insufficient host validation).\n\nRegarding the last case, this usually occurs when the application needs to allow\narbitrary subdomains of a primary domain. So, even if the hostname has been\nextracted correctly, the app uses methods such as `startsWith`, `endsWith,` or\n`contains` of the `java.lang.String` class to validate the presence of a primary\ndomain in the extracted string section. Used incorrectly, these methods may lead\nto faulty results and force the application to improperly trust a potentially\nmalicious host.\n\nImpact\n------\n\nDepending on the context in which the host is used, the impact can vary. In\ncases where loading a malicious URI (i.e., one that bypassed\nfiltering/allowlist) in a WebView could potentially lead to account takeover\n(e.g. using phishing), code execution (e.g., loading malicious JavaScript), or\ndevice compromise (exploit code delivered using hyperlink).\n\nMitigations\n-----------\n\nWhen handling string URIs, it is important to parse the string as a URI and\nvalidate both the scheme and the host: \n\n### Kotlin\n\n fun isUriTrusted(incomingUri: String, trustedHostName: String): Boolean {\n try {\n val uri = Uri.parse(incomingUri)\n return uri.scheme == \"https\" && uri.host == trustedHostName\n } catch (e: NullPointerException) {\n throw NullPointerException(\"incomingUri is null or not well-formed\")\n }\n }\n\n### Java\n\n public static boolean isUriTrusted(String incomingUri, String trustedHostName)\n throws NullPointerException {\n try {\n Uri uri = Uri.parse(incomingUri);\n return uri.getScheme().equals(\"https\") &&\n uri.getHost().equals(trustedHostName);\n } catch (NullPointerException e) {\n throw new NullPointerException(\n \"incomingUri is null or not well-formed\");\n }\n }\n\nFor host validation, after isolating the corresponding URI part, it is important\nto validate it entirely (rather than partially) to accurately identify whether\nthe host is trusted or not. When using methods like `startsWith` or `endsWith`\ncan't be avoided, it is important to use the correct syntax and not overlook\nnecessary characters or symbols (for example, `endsWith` requires the \"`.`\" dot\ncharacter before the domain name for an accurate match). Neglecting these\ncharacters may lead to inaccurate matches and compromise security. Since\nsubdomains can be infinitely nested, regular expression matching is not a\nrecommended strategy for validating hostnames.\n\nContributors: Dimitrios Valsamaras and Michael Peck of Microsoft Threat\nIntelligence\n\nResources\n---------\n\n- [getHost() documentation](/reference/java/net/URI#getHost())\n- [getScheme() documentation](/reference/java/net/URI#getScheme())"]]
