Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2025-02-16 22:18:27 +00:00

Translator workflow 9f40607d8c Translated to Afrikaans

2024-02-11 02:07:06 +00:00

30 KiB

Raw Blame History

Android Toepassingsbeginsels

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

As jy jou maatskappy in HackTricks wil adverteer of HackTricks in PDF wil aflaai, kyk na die SUBSCRIPTION PLANS!
Kry die amptelike PEASS & HackTricks swag
Ontdek The PEASS Family, ons versameling eksklusiewe NFTs
Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.
Deel jou haktruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-repos.

Vind kwesbaarhede wat die belangrikste is sodat jy dit vinniger kan regstel. Intruder volg jou aanvalsoppervlak, voer proaktiewe dreigingsskanderings uit, vind probleme regoor jou hele tegnologie-stapel, van API's tot webtoepassings en wolkstelsels. Probeer dit vandag nog gratis.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

Android-sekuriteitsmodel

Daar is twee lae:

Die BS, wat geïnstalleerde toepassings geïsoleer hou van mekaar.
Die toepassing self, wat ontwikkelaars in staat stel om sekere funksionaliteite bloot te stel en toepassingsvermoëns te konfigureer.

UID-skeiding

Elke toepassing word toegewys aan 'n spesifieke gebruikers-ID. Dit word gedoen tydens die installering van die toepassing sodat die toepassing slegs kan interaksie hê met lêers wat deur sy gebruikers-ID besit word of gedeel word. Daarom kan slegs die toepassing self, sekere komponente van die BS en die root-gebruiker toegang kry tot die toepassingsdata.

UID-deling

Twee toepassings kan gekonfigureer word om dieselfde UID te gebruik. Dit kan nuttig wees om inligting te deel, maar as een van hulle gekompromitteer word, sal die data van beide toepassings gekompromitteer word. Dit is waarom hierdie gedrag ontmoedig word.
Om dieselfde UID te deel, moet toepassings dieselfde android:sharedUserId-waarde in hul manifeste definieer.

Sandboxing

Die Android-toepassingssandbox maak dit moontlik om elke toepassing as 'n afsonderlike proses onder 'n afsonderlike gebruikers-ID uit te voer. Elke proses het sy eie virtuele masjien, sodat 'n toepassing se kode geïsoleerd van ander toepassings uitgevoer word.
Vanaf Android 5.0(L) word SELinux afgedwing. Basies het SELinux alle prosesinteraksies ontken en dan beleide geskep om slegs die verwagte interaksies tussen hulle toe te laat.

Toestemmings

Wanneer jy 'n toepassing installeer en dit vra vir toestemmings, vra die toepassing vir die toestemmings wat gekonfigureer is in die uses-permission-elemente in die AndroidManifest.xml-lêer. Die uses-permission-element dui die naam van die gevraagde toestemming aan binne die name-kenmerk. Dit het ook die maxSdkVersion-kenmerk wat verhoed dat toestemmings gevra word op hoër weergawes as die gespesifiseerde een.
Let daarop dat Android-toepassings nie altyd al die toestemmings aan die begin hoef te vra nie, hulle kan ook dinamies toestemmings vra, maar al die toestemmings moet in die manifest verklaar word.

Wanneer 'n toepassing funksionaliteit blootstel, kan dit die toegang beperk tot slegs toepassings wat 'n spesifieke toestemming het.
'n Toestemmings-element het drie kenmerke:

Die naam van die toestemming
Die permission-group-kenmerk, wat toelaat dat verwante toestemmings gegroepeer word.
Die protection-level wat aandui hoe die toestemmings verleen word. Daar is vier tipes:
Normaal: Gebruik wanneer daar geen bekende bedreigings vir die toepassing is nie. Die gebruiker word nie vereis om dit goed te keur nie.
Gevaarlik: Dui aan dat die toestemming die aanvraagende toepassing verhoogde toegang gee. Gebruikers word gevra om dit goed te keur.
Handtekening: Slegs toepassings wat deur dieselfde sertifikaat as die een wat die komponent uitvoer, onderteken is, kan toestemming kry. Dit is die sterkste tipe beskerming.
HandtekeningOfStelsel: Slegs toepassings wat deur dieselfde sertifikaat as die een wat die komponent uitvoer, onderteken is, of toepassings wat met stelselvlaktoegang uitgevoer word, kan toestemming kry.

Vooraf geïnstalleerde toepassings

Hierdie toepassings word gewoonlik in die /system/app of /system/priv-app-gids gevind en sommige van hulle is geoptimaliseer (jy mag dalk nie eers die classes.dex-lêer vind nie). Hierdie toepassings is die moeite werd om te ondersoek omdat hulle soms met te veel toestemmings uitgevoer word (as root).

Diegene wat saam met die AOSP (Android OpenSource Project) ROM versend word
Bygevoeg deur die toestel vervaardiger
Bygevoeg deur die selfoon verskaffer (as dit by hulle gekoop is)

Rooting

Om worteltoegang tot 'n fisiese Android-toestel te verkry, moet jy gewoonlik 1 of 2 kwesbaarhede uitbuit wat gewoonlik spesifiek is vir die toestel en weergawe.
Nadat die uitbuiting gewerk het, word die Linux su binêre gewoonlik gekopieer na 'n ligging wat gespesifiseer is in die gebruiker se PATH-omgewingsveranderlike, soos /system/xbin.

Nadat die su-binêre lêer gekonfigureer is, word 'n ander Android-toepassing gebruik om met die su-binêre lêer te kommunikeer en versoeke vir worteltoegang te verwerk, soos Superuser en SuperSU (beskikbaar in die Google Play Store).

{% hint style="danger" %} Let daarop dat die rooting-proses baie gevaarlik is en die toestel ernstig kan beskadig {% endhint %}

ROM's

Dit is moontlik om die BS te vervang deur 'n aangepaste firmware te installeer. Deur dit te doen, is dit moontlik om die bruikbaarheid van 'n ou toestel uit te brei, sagtewarebeperkings te omseil of toegang tot die nuutste Android-kode te verkry.
OmniROM en LineageOS is twee van die gewildste firmwares om te gebruik.

Let daarop dat **nie altyd nodig is om die toestel te root

Dalvik & Smali

In Android-ontwikkeling word Java of Kotlin gebruik om programme te skep. In plaas daarvan om die JVM soos in bladtoepassings te gebruik, kompileer Android hierdie kode na Dalvik Uitvoerbare (DEX) bytecode. Vroeër het die Dalvik virtuele masjien hierdie bytecode hanteer, maar nou neem die Android Runtime (ART) oor in nuwer Android-weergawes.

Vir omgekeerde ingenieurswese word Smali krities. Dit is die mens-leesbare weergawe van DEX bytecode en tree op soos assambleertaal deur bronkode na bytecode-instruksies te vertaal. Smali en baksmali verwys na die assambleer- en ontassemblagehulpmiddels in hierdie konteks.

Intents

Intents is die primêre manier waarop Android-toepassings kommunikeer tussen hul komponente of met ander toepassings. Hierdie boodskapvoorwerpe kan ook data tussen toepassings of komponente dra, soortgelyk aan hoe GET/POST-versoeke in HTTP-kommunikasie gebruik word.

Dus is 'n Intent basies 'n boodskap wat tussen komponente oorgedra word. Intents kan gerig word aan spesifieke komponente of toepassings, of sonder 'n spesifieke ontvanger gestuur word.
Om dit eenvoudig te stel, kan Intents gebruik word:

Om 'n Aktiwiteit te begin, wat gewoonlik 'n gebruikerskoppelvlak vir 'n toepassing oopmaak
As uitsendings om die stelsel en toepassings van veranderinge in te lig
Om 'n agtergronddiens te begin, stop en kommunikeer
Om toegang tot data te verkry via ContentProviders
As terugroepfunksies om gebeurtenisse te hanteer

Indien kwesbaar, kan Intents gebruik word om verskeie aanvalle uit te voer.

Intent-Filter

Intent Filters definieer hoe 'n aktiwiteit, diens of Uitsendontvanger kan interaksie hê met verskillende tipes Intents. In wese beskryf hulle die vermoëns van hierdie komponente, soos watter aksies hulle kan uitvoer of die soorte uitsendings wat hulle kan verwerk. Die primêre plek om hierdie filters te verklaar, is binne die AndroidManifest.xml-lêer, alhoewel dit ook 'n opsie is om dit vir Uitsendontvangers te kodeer.

Intent Filters bestaan uit kategorieë, aksies en datafilters, met die moontlikheid om addisionele metadata in te sluit. Hierdie opstelling maak dit moontlik vir komponente om spesifieke Intents te hanteer wat aan die verklaarde kriteria voldoen.

'n Kritieke aspek van Android-komponente (aktiwiteite/diens/inhoudverskaffers/uitsendontvangers) is hul sigbaarheid of openbare status. 'n Komponent word as openbaar beskou en kan met ander toepassings interaksie hê as dit uitgevoer word met 'n waarde van waar of as 'n Intent Filter daarvoor in die manifest verklaar word. Daar is egter 'n manier vir ontwikkelaars om hierdie komponente eksplisiet privaat te hou, om te verseker dat hulle nie onbedoeld met ander toepassings interaksie hê nie. Dit word bereik deur die uitgevoer eienskap na vals in hul manifestdefinisies te stel.

Verder het ontwikkelaars die opsie om toegang tot hierdie komponente verder te beveilig deur spesifieke toestemmings te vereis. Die toestemming eienskap kan ingestel word om te verseker dat slegs toepassings met die aangewese toestemming toegang tot die komponent kan verkry, wat 'n ekstra laag van sekuriteit en beheer bied oor wie daarmee kan interaksie hê.

<activity android:name=".MyActivity" android:exported="false">
<!-- Intent filters go here -->
</activity>

Implisiete Intente

Intente word programmaties geskep deur gebruik te maak van 'n Intent-konstrukteur:

Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));

Die Aksie van die voorheen verklaarde voorneme is ACTION_SEND en die Ekstra is 'n mailto Uri (die Ekstra is die ekstra inligting wat die voorneme verwag).

Hierdie voorneme moet binne die manifest verklaar word soos in die volgende voorbeeld:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myapp">

    <application
        ...>

        <activity android:name=".MainActivity">
            ...
            <intent-filter>
                <action android:name="android.intent.action.SEND" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:scheme="mailto" />
            </intent-filter>
        </activity>

    </application>

</manifest>

<activity android:name="ShareActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>

'n Intent-filter moet ooreenstem met die aksie, data en kategorie om 'n boodskap te ontvang.

Die "Intent-oplossing" proses bepaal watter app elke boodskap moet ontvang. Hierdie proses oorweeg die prioriteit atribuut, wat in die intent-filter verklaring ingestel kan word, en die een met die hoër prioriteit sal gekies word. Hierdie prioriteit kan tussen -1000 en 1000 ingestel word en programme kan die SYSTEM_HIGH_PRIORITY waarde gebruik. As 'n botsing ontstaan, verskyn 'n "kieser" venster sodat die gebruiker kan besluit.

Uitdruklike Intents

'n Uitdruklike intent spesifiseer die klassenaam waarna dit mik:

Intent downloadIntent = new (this, DownloadService.class):

In ander toepassings kan jy die voorheen verklaarde voorneme toegang kry deur die volgende te gebruik:

Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);

Hangende Intente

Hierdie maak dit vir ander programme moontlik om aksies namens jou program te neem, met behulp van jou program se identiteit en toestemmings. By die konstruksie van 'n Hangende Intent moet 'n intent en die aksie wat uitgevoer moet word, gespesifiseer word. As die verklaarde intent nie eksplisiet is (dit verklaar nie watter intent dit kan oproep nie), kan 'n skadelike toepassing die verklaarde aksie uitvoer namens die slagoffer-toepassing. Verder, as 'n aksie nie gespesifiseer is nie, sal die skadelike toepassing in staat wees om enige aksie namens die slagoffer uit te voer.

Uitsaai Intente

In teenstelling met die vorige intente, wat slegs deur een toepassing ontvang word, kan uitsaai intente deur verskeie toepassings ontvang word. Vanaf API-weergawe 14 is dit moontlik om die toepassing te spesifiseer wat die boodskap moet ontvang deur gebruik te maak van Intent.set Package.

Alternatiewelik is dit ook moontlik om 'n toestemming te spesifiseer wanneer die uitsaai gestuur word. Die ontvangende toepassing sal daardie toestemming nodig hê.

Daar is twee tipes uitsaai: Normaal (asinkronies) en Gereëlde (sinkronies). Die volgorde is gebaseer op die gekonfigureerde prioriteit binne die ontvanger element. Elke toepassing kan die uitsaai verwerk, deurgee of laat val.

Dit is moontlik om 'n uitsaai te stuur met behulp van die funksie sendBroadcast(intent, receiverPermission) van die Context klas.
U kan ook die funksie sendBroadcast van die LocalBroadCastManager gebruik om te verseker dat die boodskap nooit die toepassing verlaat nie. Deur dit te gebruik, hoef u nie eers 'n ontvangerkomponent uit te voer nie.

Plakkerige Uitsaai

Hierdie tipe uitsaai kan lank nadat dit gestuur is, geassesseer word.
Dit is verouderd in API-vlak 21 en dit word aanbeveel om dit nie te gebruik nie.
Dit maak dit vir enige toepassing moontlik om die data te bespioneer, maar ook om dit te wysig.

As u funksies vind wat die woord "plakkerig" bevat, soos sendStickyBroadcast of sendStickyBroadcastAsUser, ondersoek die impak en probeer om dit te verwyder.

Diep skakels / URL-skemas

In Android-toepassings word diep skakels gebruik om 'n aksie (Intent) direk deur 'n URL te inisieer. Dit word gedoen deur 'n spesifieke URL-skema binne 'n aktiwiteit te verklaar. Wanneer 'n Android-toestel probeer om 'n URL met hierdie skema te toegang, word die gespesifiseerde aktiwiteit binne die toepassing geopen.

Die skema moet verklaar word in die AndroidManifest.xml lêer:

[...]
<activity android:name=".MyActivity">
<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="examplescheme" />
</intent-filter>
[...]

Die skema van die vorige voorbeeld is exampleapp:// (merk ook die category BROWSABLE)

Dan kan jy in die data veld die host en path spesifiseer:

<data android:scheme="examplescheme"
android:host="example"
/>

Om dit vanaf 'n web te benader, is dit moontlik om 'n skakel soos die volgende te stel:

<a href="examplescheme://example/something">click here</a>
<a href="examplescheme://example/javascript://%250dalert(1)">click here</a>

Om die kode wat in die App uitgevoer sal word te vind, gaan na die aktiwiteit wat deur die deeplink geroep word en soek die funksie onNewIntent.

Leer hoe om deeplinks te roep sonder om HTML-bladsye te gebruik.

AIDL - Android Interface Definition Language

Die Android Interface Definition Language (AIDL) is ontwerp om kommunikasie tussen klient en diens in Android-toepassings deur middel van interproseskommunikasie (IPC) te fasiliteer. Aangesien direkte toegang tot 'n ander proses se geheue nie toegelaat word op Android nie, vereenvoudig AIDL die proses deur objekte in 'n formaat te verpak wat deur die bedryfstelsel verstaan word, en vergemaklik sodoende kommunikasie tussen verskillende prosesse.

Sleutelkonsepte

Gebinde Dienste: Hierdie dienste maak gebruik van AIDL vir IPC en stel aktiwiteite of komponente in staat om aan 'n diens te bind, versoeke te maak en antwoorde te ontvang. Die onBind-metode in die diens se klas is krities vir die inisiasie van interaksie, en dit is 'n belangrike area vir sekuriteitsondersoek om kwesbaarhede op te spoor.
Messenger: As 'n gebinde diens fasiliteer Messenger IPC met die fokus op die verwerking van data deur die onBind-metode. Dit is noodsaaklik om hierdie metode noukeurig te ondersoek vir enige onveilige hantering van data of uitvoering van sensitiewe funksies.
Binder: Alhoewel direkte gebruik van die Binder-klas minder algemeen is as gevolg van AIDL se abstraksie, is dit voordelig om te verstaan dat Binder optree as 'n kernelvlakbestuurder wat data-oordrag tussen die geheue-areas van verskillende prosesse fasiliteer. Vir verdere begrip is 'n hulpbron beskikbaar by https://www.youtube.com/watch?v=O-UHvFjxwZ8.

Komponente

Dit sluit in: Aktiwiteite, Dienste, Uitsaai-Ontvangers en Verskaffers.

Beginaktiwiteit en ander aktiwiteite

In Android-toepassings is aktiwiteite soos skerms wat verskillende dele van die toepassing se gebruikerskoppelvlak wys. 'n Toepassing kan baie aktiwiteite hê, elk een wat 'n unieke skerm aan die gebruiker vertoon.

Die beginaktiwiteit is die hoofingang na 'n toepassing en word geloods wanneer jy op die toepassing se ikoon tik. Dit word in die toepassing se manifestlêer gedefinieer met spesifieke MAIN- en LAUNCHER-intente:

<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

Nie alle programme het 'n beginaktiwiteit nodig nie, veral nie dié sonder 'n gebruikerskoppelvlak nie, soos agtergronddienste.

Aktiwiteite kan beskikbaar gestel word vir ander programme of prosesse deur hulle as "uitgevoer" in die manifest te merk. Hierdie instelling maak dit moontlik vir ander programme om hierdie aktiwiteit te begin:

<service android:name=".ExampleExportedService" android:exported="true"/>

Togang tot 'n aktiwiteit vanuit 'n ander app is nie altyd 'n veiligheidsrisiko nie. Die bekommernis ontstaan as sensitiewe data verkeerd gedeel word, wat kan lei tot inligtingslekke.

'n Aktiwiteit se lewensiklus begin met die onCreate-metode, wat die gebruikerskoppelvlak opstel en die aktiwiteit gereed maak vir interaksie met die gebruiker.

Toepassing Subklas

In Android-ontwikkeling het 'n app die opsie om 'n subklas van die Application klas te skep, alhoewel dit nie verpligtend is nie. Wanneer so 'n subklas gedefinieer word, word dit die eerste klas wat binne die app geïnstantieer word. Die attachBaseContext-metode, as dit in hierdie subklas geïmplementeer word, word uitgevoer voordat die onCreate-metode uitgevoer word. Hierdie opset maak vroeë inisialisering moontlik voordat die res van die toepassing begin.

public class MyApp extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// Initialization code here
}

@Override
public void onCreate() {
super.onCreate();
// More initialization code
}
}

Dienste

Dienste is agtergrondoperasies wat in staat is om take uit te voer sonder 'n gebruikerskoppelvlak. Hierdie take kan aanhou loop selfs wanneer gebruikers oorskakel na ander toepassings, wat dienste noodsaaklik maak vir langdurige operasies.

Dienste is veelsydig; dit kan op verskillende maniere geïnisieer word, met Intents as die primêre metode om dit te begin as 'n toepassing se toegangspunt. Sodra 'n diens begin word met die startService-metode, tree sy onStart-metode in werking en bly loop totdat die stopService-metode eksplisiet geroep word. As alternatief, as 'n diens se rol afhanklik is van 'n aktiewe klientverbinding, word die bindService-metode gebruik om die klient aan die diens te bind, en die onBind-metode word gebruik vir data-oordrag.

'n Interessante toepassing van dienste sluit in agtergrondmusiekspel of netwerkdata-ophaling sonder om die gebruiker se interaksie met 'n program te belemmer. Verder kan dienste toeganklik gemaak word vir ander prosesse op dieselfde toestel deur uitvoer. Dit is nie die verstekgedrag nie en vereis eksplisiete konfigurasie in die Android Manifest-lêer:

<service android:name=".ExampleExportedService" android:exported="true"/>

Uitsaai-Ontvangers

Uitsaai-ontvangers tree op as luisteraars in 'n boodskapstelsel, wat dit vir verskeie programme moontlik maak om op dieselfde boodskappe van die stelsel te reageer. 'n Program kan 'n ontvanger registreer op twee primêre maniere: deur die program se Manifes of dinamies binne die program se kode deur die registerReceiver API. In die Manifes word uitsendings gefiltreer met toestemmings, terwyl dinamies geregistreerde ontvangers ook toestemmings kan spesifiseer tydens registrasie.

Intent-filters is van kritieke belang in beide registrasiemetodes en bepaal watter uitsendings die ontvanger aktiveer. Sodra 'n ooreenstemmende uitsending gestuur word, word die onReceive-metode van die ontvanger aangeroep, wat die program in staat stel om dienooreenkomstig te reageer, soos om gedrag aan te pas in reaksie op 'n lae batterystatus.

Uitsendings kan óf asinkronies wees, wat al die ontvangers sonder volgorde bereik, óf sinkronies, waar ontvangers die uitsending ontvang op grond van vasgestelde prioriteite. Dit is egter belangrik om die potensiële veiligheidsrisiko in ag te neem, aangesien enige program homself kan prioriteer om 'n uitsending te onderskep.

Om 'n ontvanger se funksionaliteit te verstaan, soek na die onReceive-metode binne sy klas. Die kode van hierdie metode kan die ontvangde Intent manipuleer, wat die noodsaak van data-validering deur ontvangers beklemtoon, veral in Geordende Uitsendings, wat die Intent kan wysig of laat val.

Inhoudsverskaffer

Inhoudsverskaffers is noodsaaklik vir die deel van gestruktureerde data tussen programme en beklemtoon die belangrikheid van die implementering van toestemmings om data-sekuriteit te verseker. Dit maak dit vir programme moontlik om toegang tot data van verskeie bronne te verkry, insluitend databasisse, lêersisteme, of die web. Spesifieke toestemmings, soos readPermission en writePermission, is van kritieke belang vir die beheer van toegang. Daarbenewens kan tydelike toegang verleen word deur middel van grantUriPermission-instellings in die program se manifest, waar gebruik gemaak word van eienskappe soos path, pathPrefix, en pathPattern vir gedetailleerde toegangsbeheer.

Invoer-validering is van uiterste belang om kwesbaarhede, soos SQL-inspuiting, te voorkom. Inhoudsverskaffers ondersteun basiese bewerkings: insert(), update(), delete(), en query(), wat data-manipulasie en -deling tussen programme fasiliteer.

FileProvider, 'n gespesialiseerde Inhoudsverskaffer, fokus op die veilige deling van lêers. Dit word in die program se manifest gedefinieer met spesifieke eienskappe om toegang tot lêers te beheer, aangedui deur android:exported en android:resource wat na lêer-konfigurasies verwys. Voorsoorsigtigheid word aanbeveel wanneer dit kom by die deling van gidslys om die onbedoelde blootstelling van sensitiewe data te voorkom.

Voorbeeld manifest-verklaring vir FileProvider:

<provider android:name="androidx.core.content.FileProvider"
android:authorities="com.example.myapp.fileprovider"
android:grantUriPermissions="true"
android:exported="false">
<meta-data android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/filepaths" />
</provider>

En 'n voorbeeld van die spesifisering van gedeelde lêers in filepaths.xml:

<paths>
<files-path path="images/" name="myimages" />
</paths>

Vir verdere inligting, kyk na:

WebViews

WebViews is soos mini-webblaaier binne Android-programme wat inhoud trek van die web of van plaaslike lêers. Hulle loop soortgelyke risiko's as gewone blaaier, maar daar is maniere om hierdie risiko's te verminder deur spesifieke instellings.

Android bied twee hoof WebView-tipes:

WebViewClient is goed vir basiese HTML, maar ondersteun nie die JavaScript-waarskuwingsfunksie nie, wat die toetsing van XSS-aanvalle beïnvloed.
WebChromeClient werk meer soos die volledige Chrome-blaai-ervaring.

'n Sleutelpunt is dat WebView-blaaiers nie koekies deel met die toestel se hoof-blaaier nie.

Vir die laai van inhoud is metodes soos loadUrl, loadData, en loadDataWithBaseURL beskikbaar. Dit is noodsaaklik om te verseker dat hierdie URL's of lêers veilig is om te gebruik. Sekuriteitsinstellings kan bestuur word deur die WebSettings-klas. Byvoorbeeld, deur JavaScript met setJavaScriptEnabled(false) uit te skakel, kan XSS-aanvalle voorkom word.

Die JavaScript "Bridge" laat Java-objekte met JavaScript interaksie hê en vereis dat metodes gemerk word met @JavascriptInterface vir sekuriteit vanaf Android 4.2 en later.

Deur inhoudstoegang toe te laat (setAllowContentAccess(true)), kan WebViews by Inhoudsverskaffers uitkom, wat 'n risiko kan wees tensy die inhoud-URL's geverifieer word as veilig.

Om lêertoegang te beheer:

Deur lêertoegang uit te skakel (setAllowFileAccess(false)) word toegang tot die lêersisteem beperk, met uitsonderings vir sekere bates, om te verseker dat hulle slegs vir nie-sensitiewe inhoud gebruik word.

Ander App-komponente en mobiele toestelbestuur

Digitale ondertekening van programme

Digitale ondertekening is 'n vereiste vir Android-programme om te verseker dat hulle egte outeurskap het voordat dit geïnstalleer word. Hierdie proses maak gebruik van 'n sertifikaat vir programidentifikasie en moet deur die toestel se pakkettebestuurder geverifieer word tydens installasie. Programme kan self-onderteken of deur 'n eksterne CA gesertifiseer word, wat teen ongemagtigde toegang beskerm en verseker dat die program onveranderd bly tydens aflewering aan die toestel.

Programverifikasie vir verbeterde sekuriteit

Vanaf Android 4.2 maak 'n funksie genaamd Verifieer Programme dit vir gebruikers moontlik om programme vir veiligheid te laat nagaan voordat dit geïnstalleer word. Hierdie verifikasieproses kan gebruikers waarsku teen potensieel skadelike programme, of selfs die installasie van besonder kwaadwillige programme voorkom, wat gebruikers sekerheid verbeter.

Mobiele toestelbestuur (MDM)

MDM-oplossings bied toesig en sekuriteit vir mobiele toestelle deur middel van die Toesteladministrasie-API. Dit vereis die installasie van 'n Android-program om mobiele toestelle doeltreffend te bestuur en te beveilig. Sleutelfunksies sluit in die afdwing van wagwoordbeleide, verpligte bergversleuteling, en toelaat van afstandsdata-uitvee, wat omvattende beheer en sekuriteit oor mobiele toestelle verseker.

// Example of enforcing a password policy with MDM
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName adminComponent = new ComponentName(context, AdminReceiver.class);

if (dpm.isAdminActive(adminComponent)) {
// Set minimum password length
dpm.setPasswordMinimumLength(adminComponent, 8);
}

Vind kwesbaarhede wat die belangrikste is sodat jy dit vinniger kan regmaak. Intruder volg jou aanvalsoppervlak, voer proaktiewe dreigingsskanderings uit, vind probleme regoor jou hele tegnologie-stapel, van API's tot webtoepassings en wolkstelsels. Probeer dit vandag gratis.