Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/mobile-pentesting/android-app-pentesting/android-applications-basics.md

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:

Probeer Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

Android-sekuriteitsmodel

Daar is twee lae:

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

UID-skeiding

Elke toepassing word 'n spesifieke Gebruikers-ID toegewys. Dit word gedoen tydens die installasie van die toepassing sodat die toepassing slegs met lêers wat deur sy Gebruikers-ID besit word of gedeel word, kan interaksie hê. Daarom kan slegs die toepassing self, sekere komponente van die OS en die hoofgebruiker by die toepassingsdata kom.

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. Daarom word hierdie gedrag ontmoedig.
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 te laat loop. Elke proses het sy eie virtuele masjien, sodat 'n toepassing se kode in isolasie van ander toepassings loop.
Van Android 5.0(L) af word SELinux afgedwing. In beginsel het SELinux alle prosesinteraksies ontken en daarna beleid geskep om slegs die verwagte interaksies tussen hulle toe te laat.

Toestemmings

Wanneer jy 'n toepassing installeer en dit om toestemmings vra, vra die toepassing vir die toestemmings wat in die uses-permission elemente in die AndroidManifest.xml-lêer gekonfigureer is. Die uses-permission element dui die naam van die versoekte toestemming binne die naam attribute aan. Dit het ook die maxSdkVersion-attribute wat ophou om toestemmings te vra op hoër weergawes as die gespesifiseerde een.
Let daarop dat Android-toepassings nie al die toestemmings aan die begin hoef te vra nie, hulle kan ook toestemmings dinamies 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 eienskappe:

  • Die naam van die toestemming
  • Die permission-group-attribute, 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 versoekende toepassing 'n sekere verhoogde toegang gee. Gebruikers word versoek 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 hardloop, kan toestemming kry.

Voorafgeïnstalleerde Toepassings

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

  • Diegene wat saam met die AOSP (Android OpenSource Project) ROM versend word
  • Bygevoeg deur die toestel vervaardiger
  • Bygevoeg deur die selfoonverskaffer (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 vir die toestel en weergawe is.
Sodra die uitbuiting gewerk het, word die Linux su binêre gewoonlik gekopieer na 'n ligging wat in die gebruiker se PATH-omgewingsveranderlike gespesifiseer is, soos /system/xbin.

Sodra die su-binêre geconfigureer is, word 'n ander Android-toepassing gebruik om met die su-binêre te koppel 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 OS te vervang deur 'n aangepaste firmware te installeer. Deur dit te doen, is dit moontlik om die nut 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 dit nie altyd nodig is om die toestel te root nie om 'n aangepaste firmware te installeer. Sommige vervaardigers laat die ontgrendeling van hul laarslaaiers op 'n goed gedokumenteerde en veilige manier toe.

Implikasies

Sodra 'n toestel gewortel is, kan enige toepassing toegang as wortel aanvra. As 'n skadelike toepassing dit kry, sal dit toegang tot byna alles hê en dit kan die foon beskadig.

Android Toepassingsbeginsels

  • Die formaat van Android-toepassings word verwys as APK-lêerformaat. Dit is essensieel 'n ZIP-lêer (deur die lêernaamuitbreiding na .zip te verander, kan die inhoud onttrek en besigtig word).
  • APK-inhoud (Nie uitputtend nie)
  • AndroidManifest.xml
  • resources.arsc/strings.xml
  • resources.arsc: bevat vooraf saamgestelde bronne, soos binêre XML.
  • res/xml/files_paths.xml
  • META-INF/
  • Hierdie is waar die Sertifikaat geleë is!
  • classes.dex
  • Bevat Dalvik-bytekode, wat die saamgestelde Java (of Kotlin) kode wat die toepassing standaard uitvoer, verteenwoordig.
  • lib/
  • Huisves inheemse biblioteke, geskei deur CPU-argitektuur in subgidse.
  • armeabi: kode vir ARM-gebaseerde verwerkers
  • armeabi-v7a: kode vir ARMv7 en hoër gebaseerde verwerkers
  • x86: kode vir X86-verwerkers
  • mips: kode vir slegs MIPS-verwerkers
  • bates/
  • Berg verskeie lêers wat deur die toepassing benodig word, moontlik insluitend addisionele inheemse biblioteke of DEX-lêers, soms deur malware-skrywers gebruik om addisionele kode te verberg.
  • res/
  • Bevat bronne wat nie in resources.arsc saamgestel is nie

Dalvik & Smali

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

Vir omgekeerde ingenieurswese word Smali noodsaaklik. Dit is die mens-leesbare weergawe van DEX bytekode, wat soos samestellingskode optree deur bronkode na bytekode-instruksies te vertaal. Smali en baksmali verwys na die samestellings- en ontsameleerhulpmiddels in hierdie konteks.

Intents

Intents is die primêre manier waarop Android-apps kommunikeer tussen hul komponente of met ander programme. Hierdie boodskapvoorwerpe kan ook data tussen programme 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 programme, of sonder 'n spesifieke ontvanger gestuur word.
Om dit eenvoudig te stel, kan Intent gebruik word:

  • Om 'n Aktiwiteit te begin, tipies deur 'n gebruikerskoppelvlak vir 'n app oop te maak
  • As uitsendings om die stelsel en programme van veranderinge in te lig
  • Om 'n agtergronddiens te begin, te stop en mee te kommunikeer
  • Om data via Inhoudsverskaffers te benader
  • As terugroepfunksies om gebeure te hanteer

Indien kwesbaar, kan Intents gebruik word om 'n verskeidenheid aan aanvalle uit te voer.

Intent-Filter

Intent Filters definieer hoe 'n aktiwiteit, diens, of Uitsaai-Ontvanger kan interaksie hê met verskillende tipes Intents. Essensieel 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 vir Uitsaai-Ontvangers ook 'n opsie is om hulle 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/dienste/inhoudsverskaffers/uitsaai-ontvangers) is hul sigbaarheid of publieke status. 'n Komponent word as publiek beskou en kan met ander programme interaksie hê as dit uitgevoer word met 'n waarde van waar of as 'n Intent Filter daarvoor verklaar word in die manifest. Daar is egter 'n manier vir ontwikkelaars om hierdie komponente eksplisiet privaat te hou, om te verseker dat hulle nie onbedoeld met ander programme interaksie hê nie. Dit word bereik deur die uitgevoer kenmerk 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 kenmerk kan ingestel word om te verseker dat slegs programme met die aangewese toestemming die komponent kan benader, 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 'n Intente-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:

<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 die aksie, data en kategorie pas om 'n boodskap te ontvang.

Die "Intent resolution" 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 konflik ontstaan, verskyn 'n "choser" venster sodat die gebruiker kan besluit.

Expliciete Intents

'n Expliciete intent spesifiseer die klassenaam waarna dit mik:

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

In ander toepassings om toegang te verkry tot die voorheen verklaarde voorneme kan jy gebruik:

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

Afwagtende Intente

Hierdie maak dit vir ander toepassings moontlik om optrede namens jou toepassing te neem, met behulp van jou toep se identiteit en regte. Om 'n Afwagtende Intente te konstrueer, moet daar 'n intente en die optrede om uit te voer gespesifiseer word. As die verklaarde intent nie eksplisiet is (dit verklaar nie watter intent dit kan aanroep nie), kan 'n skadelike toepassing die verklaarde optrede uitvoer namens die slagoffer-toep. Verder, as 'n optrede nie gespesifiseer is nie, sal die skadelike toep in staat wees om enige optrede namens die slagoffer uit te voer.

Uitsaai Intente

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

Dit is ook moontlik om 'n toestemming te spesifiseer wanneer die uitsaai gedoen word. Die ontvangende toep sal daardie toestemming moet hê.

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

Dit is moontlik om 'n uitsaai te stuur deur die funksie sendBroadcast(intent, receiverPermission) vanaf die Context klas te gebruik.
Jy kan ook die funksie sendBroadcast van die LocalBroadCastManager gebruik om te verseker dat die boodskap nooit die toep verlaat nie. Deur dit te gebruik, hoef jy nie eers 'n ontvangerkomponent uit te voer nie.

Plakkerige Uitsaaie

Hierdie tipe Uitsaaie kan lank nadat hulle gestuur is, benader word.
Hierdie is verouder in API-vlak 21 en dit word aanbeveel om hulle nie te gebruik nie.
Hulle laat enige toepassing toe om die data te bespeur, maar ook om dit te wysig.

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

Diep skakels / URL-skemas

In Android-toepassings word diep skakels gebruik om 'n optrede (Intente) 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 benader, 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 kategorie 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 in 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 Toepassing uitgevoer sal word te vind, gaan na die aktiwiteit wat deur die deeplink geroep word en soek die funksie onNewIntent.

Leer hoe om diep skakels 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 interproses kommunikasie (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 marshal wat deur die bedryfstelsel verstaan word, en sodoende kommunikasie oor verskillende prosesse te vergemaklik.

Sleutelkonsepte

  • Gebinde Dienste: Hierdie dienste maak gebruik van AIDL vir IPC, wat aktiwiteite of komponente in staat stel om aan 'n diens te bind, versoek te maak, en antwoorde te ontvang. Die onBind-metode in die diens se klas is krities vir die inisieer van interaksie, en dit is 'n belangrike area vir sekuriteitsondersoek op soek na kwesbaarhede.

  • Bode: Terwyl dit as 'n gebinde diens optree, fasiliteer Bode IPC met 'n fokus op die verwerking van data deur die onBind-metode. Dit is noodsaaklik om hierdie metode noukeurig te ondersoek vir enige onveilige datahantering 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 as 'n kernelvlak drywer optree wat data-oordrag fasiliteer tussen die geheue-areas van verskillende prosesse. 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.

Aanloopaktiwiteit en ander aktiwiteite

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

Die aanloopaktiwiteit is die hoofingang na 'n toepassing, wat geopen word 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 benodig 'n aanloopaktiwiteit nie, veral nie dié sonder 'n gebruikerskoppelvlak nie, soos agtergronddienste.

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

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

Egter, die toegang tot 'n aktiwiteit van 'n ander program is nie altyd 'n veiligheidsrisiko nie. Die bekommernis ontstaan as sensitiewe data op 'n onvanpaste manier gedeel word, wat tot inligtingslektes kan lei.

Die lewensiklus van 'n aktiwiteit begin met die onCreate metode, wat die UI opstel en die aktiwiteit gereed maak vir interaksie met die gebruiker.

Aansoek Subklas

In Android-ontwikkeling het 'n program die opsie om 'n subklas van die Aansoek klas te skep, alhoewel dit nie verpligtend is nie. Wanneer so 'n subklas gedefinieer word, word dit die eerste klas wat binne die program geïnstantieer word. Die attachBaseContext metode, indien geïmplementeer in hierdie subklas, word uitgevoer voor die onCreate metode. Hierdie opstelling maak vroeë inisialisering moontlik voordat die res van die aansoek 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 agtergrondoperateurs wat in staat is om take uit te voer sonder 'n gebruikerskoppelvlak. Hierdie take kan voortgaan selfs wanneer gebruikers na verskillende toepassings oorskakel, wat dienste noodsaaklik maak vir langdurige operasies.

Dienste is veelsydig; hulle kan op verskeie maniere geïnisieer word, met Intents as die primêre metode om hulle te begin as 'n toepassing se toegangspunt. Wanneer 'n diens begin word met die startService metode, tree sy onStart metode in werking en bly loop totdat die stopService metode eksplisiet geroep word. Alternatiewelik, as 'n diens se rol afhanklik is van 'n aktiewe kliëntverbinding, word die bindService metode gebruik om die kliënt aan die diens te bind, wat die onBind metode betrek vir data-oordrag.

'n Interessante toepassing van dienste sluit agtergrondmusiekspel of netwerkdata ophaling in sonder om die gebruiker se interaksie met 'n toepassing 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 boodskapsisteem, wat dit vir meerdere toepassings moontlik maak om op dieselfde boodskappe van die sisteem te reageer. 'n Toepassing kan 'n ontvanger registreer op twee primêre maniere: deur die toepassing se Manifest of dinamies binne die toepassing se kode via die registerReceiver API. In die Manifest word uitsendings gefiltreer met toestemmings, terwyl dinamies geregistreerde ontvangers ook toestemmings tydens registrasie kan spesifiseer.

Intent-filters is noodsaaklik in beide registrasiemetodes, wat bepaal watter uitsendings die ontvanger aktiveer. Sodra 'n ooreenstemmende uitsending gestuur word, word die ontvanger se onReceive metode aangeroep, wat die toepassing in staat stel om dienooreenkomstig te reageer, soos om gedrag aan te pas in reaksie op 'n lae batteryalarm.

Uitsendings kan of asinkronies wees, wat al die ontvangers sonder orde bereik, of sinkronies, waar ontvangers die uitsending op grond van vasgestelde prioriteite ontvang. Dit is egter belangrik om die potensiële sekuriteitsrisiko te let, aangesien enige toepassing homself kan prioritiseer om 'n uitsending te onderskep.

Om 'n ontvanger se funksionaliteit te verstaan, soek na die onReceive metode binne sy klas. Hierdie metode se kode kan die ontvangende Intent manipuleer, wat die behoefte aan data-validasie deur ontvangers beklemtoon, veral in Gereëlde Uitsendings, wat die Intent kan wysig of laat val.

Inhoudsverskaffer

Inhoudsverskaffers is noodsaaklik vir die deel van gestruktureerde data tussen toepassings, wat die belangrikheid beklemtoon van die implementering van toestemmings om data-sekuriteit te verseker. Hulle maak dit vir toepassings moontlik om data van verskeie bronne, insluitend databasisse, lêersisteme, of die web, te benader. Spesifieke toestemmings, soos readPermission en writePermission, is noodsaaklik vir die beheer van toegang. Daarbenewens kan tydelike toegang verleen word deur grantUriPermission instellings in die toepassing se manifest, wat eienskappe soos path, pathPrefix, en pathPattern benut vir gedetailleerde toegangsbeheer.

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

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

Voorbeeld manifestverklaring 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:

WebViews

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

Android bied twee hoof WebView-tipes aan:

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

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

Vir die laai van inhoud, metodes soos loadUrl, loadData, en loadDataWithBaseURL is 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, deaktivering van JavaScript met setJavaScriptEnabled(false) kan XSS-aanvalle voorkom.

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

Die toelaat van inhoudstoegang (setAllowContentAccess(true)) laat WebViews toe om Inhoudsverskaffers te bereik, wat 'n risiko kan wees tensy die inhoud-URL's geverifieer word as veilig.

Om lêertoegang te beheer:

  • Deaktivering van lêertoegang (setAllowFileAccess(false)) beperk toegang tot die lêersisteem, met uitsonderings vir sekere bates, wat verseker dat hulle slegs gebruik word vir nie-sensitiewe inhoud.

Ander Toepassingskomponente en Mobiele Toestelbestuur

Digitale Ondertekening van Toepassings

  • Digitale ondertekening is 'n moet vir Android-toepassings, wat verseker dat hulle eg geskryf is voor installasie. Hierdie proses gebruik 'n sertifikaat vir toepassingsidentifikasie en moet geverifieer word deur die toestel se pakkettebestuurder tydens installasie. Toepassings kan self-onderteken of gesertifiseer word deur 'n eksterne CA, wat teen ongemagtigde toegang beskerm en verseker dat die toepassing ongeskonde bly tydens aflewering na die toestel.

Toepassingsverifikasie vir Verhoogde Sekuriteit

  • Vanaf Android 4.2, 'n funksie genaamd Verifieer Toepassings laat gebruikers toe om toepassings vir veiligheid te laat nagaan voor installasie. Hierdie verifikasieproses kan gebruikers waarsku teen potensieel skadelike toepassings, of selfs die installasie van uiters skadelike eenhede voorkom, wat gebruikers se sekuriteit verhoog.

Mobiele Toestelbestuur (MDM)

  • MDM-oplossings bied toesig en sekuriteit vir mobiele toestelle deur die Toesteladministrasie-API. Dit vereis die installasie van 'n Android-toepassing om mobiele toestelle effektief te bestuur en te beveilig. Sleutelfunksies sluit in afdwinging van wagwoordbeleide, voorskryf van stoorversleuteling, en toelaat van afstandswisiging van data, 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);
}

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

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

Ander maniere om HackTricks te ondersteun: