Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 21:53:54 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/mobile-pentesting/android-app-pentesting/android-applications-basics.md
Translator workflow 6c06826974 Translated to Serbian
2024-02-10 13:11:20 +00:00

28 KiB
Raw Blame History

Osnove Android aplikacija

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Pronađite najvažnije ranjivosti kako biste ih brže popravili. Intruder prati vašu površinu napada, pokreće proaktivne pretrage pretnji, pronalazi probleme u celom vašem tehnološkom skupu, od API-ja do veb aplikacija i sistemima u oblaku. Isprobajte ga besplatno danas.

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

Android Security Model

Postoje dva sloja:

  • Operativni sistem (OS), koji drži instalirane aplikacije izolovane jednu od druge.
  • Sama aplikacija, koja omogućava programerima da izlože određene funkcionalnosti i konfigurišu mogućnosti aplikacije.

Odvajanje UID-a

Svaka aplikacija ima dodeljen specifičan User ID. To se radi prilikom instalacije aplikacije kako bi aplikacija mogla da komunicira samo sa datotekama koje su u vlasništvu njenog User ID-a ili deljenim datotekama. Samim tim, samo aplikacija, određeni delovi operativnog sistema i korisnik sa root privilegijama mogu pristupiti podacima aplikacije.

Deljenje UID-a

Dve aplikacije mogu biti konfigurisane da koriste isti UID. Ovo može biti korisno za deljenje informacija, ali ako je jedna od njih kompromitovana, podaci obe aplikacije će biti kompromitovani. Zbog toga se ovo ponašanje odvraća.
Da bi delile isti UID, aplikacije moraju definisati istu vrednost android:sharedUserId u svojim manifestima.

Izolacija

Android Application Sandbox omogućava pokretanje svake aplikacije kao posebnog procesa pod posebnim User ID-om. Svaki proces ima svoju virtuelnu mašinu, tako da kod aplikacije radi izolovano od drugih aplikacija.
Od Androida 5.0(L) SELinux je primenjen. U osnovi, SELinux odbija sve interakcije između procesa, a zatim kreira politike koje dopuštaju samo očekivane interakcije između njih.

Dozvole

Kada instalirate aplikaciju i ona zatraži dozvole, aplikacija traži dozvole konfigurisane u elementima uses-permission u fajlu AndroidManifest.xml. Element uses-permission označava ime tražene dozvole unutar atributa name. Takođe ima atribut maxSdkVersion koji zaustavlja traženje dozvola na verzijama višim od navedene.
Imajte na umu da android aplikacije ne moraju tražiti sve dozvole odmah, mogu dinamički tražiti dozvole, ali sve dozvole moraju biti deklarisane u manifestu.

Kada aplikacija izlaže funkcionalnost, može ograničiti pristup samo aplikacijama koje imaju određenu dozvolu.
Element dozvole ima tri atributa:

  • name dozvole
  • atribut permission-group, koji omogućava grupisanje srodnih dozvola.
  • protection-level koji označava kako se dozvole dodeljuju. Postoje četiri vrste:
  • Normal: Koristi se kada nema poznatih pretnji aplikaciji. Korisniku nije potrebno odobrenje.
  • Opasno: Označava da dozvola daje traženoj aplikaciji povišen pristup. Korisnici su zamoljeni da ih odobre.
  • Potpis: Samo aplikacije potpisane istim sertifikatom kao i ona koja izvozi komponentu mogu dobiti dozvolu. Ovo je najjači tip zaštite.
  • PotpisIliSistem: Samo aplikacije potpisane istim sertifikatom kao i ona koja izvozi komponentu ili aplikacije koje se izvršavaju sa sistemskim pristupom mogu dobiti dozvole.

Preinstalirane aplikacije

Ove aplikacije se obično nalaze u direktorijumima /system/app ili /system/priv-app i neke od njih su optimizovane (možda čak nećete pronaći classes.dex fajl). Ove aplikacije vredi proveriti jer su nekada pokrenute sa previše dozvola (kao root).

  • One koje dolaze sa AOSP (Android OpenSource Project) ROM-om
  • Dodate od strane proizvođača uređaja
  • Dodate od strane provajdera mobilne telefonije (ako ste ih kupili od njih)

Rootovanje

Da biste dobili root pristup fizičkom Android uređaju, obično morate iskoristiti 1 ili 2 ranjivosti koje su obično specifične za uređaj i verziju.
Kada iskorišćavanje uspe, obično se Linux su binarni fajl kopira na lokaciju koja je navedena u PATH env promenljivoj korisnika, kao što je /system/xbin.

Kada je su binarni fajl konfigurisan, druga Android aplikacija se koristi za interakciju sa su binarnim fajlom i obradu zahteva za root pristup kao što su Superuser i SuperSU (dostupne u Google Play prodavnici).

{% hint style="danger" %} Imajte na umu da je proces rootovanja veoma opasan i može ozbiljno oštetiti uređaj. {% endhint %}

ROM-ovi

Moguće je zameniti operativni sistem instaliranjem prilagođenog firmvera. Time je moguće proširiti upotrebljivost starog uređaja, zaobići softverska ograničenja ili dobiti pristup najnovijem Android kodu.
OmniROM i LineageOS su dva od najpopularnijih firmvera koje možete koristiti.

Imajte na umu da nije uvek potrebno rootovati uređaj da biste instalirali prilagođeni firmver. Neki proizvođači dozvoljavaju otključavanje nj

Dalvik i Smali

U Android razvoju, koristi se Java ili Kotlin za kreiranje aplikacija. Umesto korišćenja JVM-a kao u desktop aplikacijama, Android kompajlira ovaj kod u Dalvik izvršni (DEX) bajtkod. Ranije je Dalvik virtuelna mašina obrađivala ovaj bajtkod, ali sada Android Runtime (ART) preuzima tu ulogu u novijim verzijama Androida.

Za obrnuti inženjering, ključan je Smali. To je čitljiva verzija DEX bajtkoda koja deluje kao asemblerski jezik prevodeći izvorni kod u instrukcije bajtkoda. Smali i baksmali se odnose na alate za asembliranje i rasklapanje u ovom kontekstu.

Pronađite najvažnije ranjivosti kako biste ih brže popravili. Intruder prati vašu površinu napada, pokreće proaktivne pretnje, pronalazi probleme u celom vašem tehnološkom skupu, od API-ja do veb aplikacija i sistemima u oblaku. Isprobajte besplatno danas.

Intents

Intents su osnovni način komunikacije između komponenti Android aplikacija ili sa drugim aplikacijama. Ovi objekti poruka takođe mogu prenositi podatke između aplikacija ili komponenti, slično kao što se GET/POST zahtevi koriste u HTTP komunikaciji.

Dakle, Intent je u osnovi poruka koja se prenosi između komponenti. Intenti mogu biti usmereni ka određenim komponentama ili aplikacijama, ili mogu biti poslati bez određenog primaoca.
Da bismo bili jednostavni, Intent se može koristiti:

  • Za pokretanje aktivnosti, obično otvaranje korisničkog interfejsa za aplikaciju
  • Kao emitovanje da obavesti sistem i aplikacije o promenama
  • Za pokretanje, zaustavljanje i komunikaciju sa pozadinskom uslugom
  • Za pristup podacima putem ContentProvidera
  • Kao povratni poziv za obradu događaja

Ako su ranjivi, Intenti se mogu koristiti za izvođenje različitih napada.

Intent-Filter

Intent Filteri definišu kako aktivnost, usluga ili prijemnik emitovanja mogu da komuniciraju sa različitim vrstama Intenta. U osnovi, opisuju mogućnosti ovih komponenti, kao što su koje akcije mogu izvršiti ili vrste emitovanja koje mogu obraditi. Glavno mesto za deklarisanje ovih filtera je unutar AndroidManifest.xml fajla, iako je kodiranje za prijemnike emitovanja takođe opcija.

Intent Filteri se sastoje od kategorija, akcija i filtera podataka, sa mogućnošću uključivanja dodatnih metapodataka. Ova postavka omogućava komponentama da obrade određene Intente koji se podudaraju sa deklarisanim kriterijumima.

Ključni aspekt Android komponenti (aktivnosti/usluga/content providera/prijemnika emitovanja) je njihova vidljivost ili javni status. Komponenta se smatra javnom i može da komunicira sa drugim aplikacijama ako je exported sa vrednošću true ili ako je za nju deklarisan Intent Filter u manifestu. Međutim, programeri imaju način da eksplicitno zadrže ove komponente privatnim, kako bi se osiguralo da ne komuniciraju sa drugim aplikacijama nenamerno. To se postiže postavljanjem atributa exported na false u njihovim definicijama manifesta.

Osim toga, programeri imaju mogućnost da dodatno obezbede pristup ovim komponentama zahtevanjem određenih dozvola. Atribut permission može biti postavljen da bi se obezbedilo da samo aplikacije sa određenom dozvolom mogu pristupiti komponenti, dodajući dodatni sloj sigurnosti i kontrole nad tim ko može da komunicira sa njom.

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

Implicitni nameni

Namerama se programski kreiraju koristeći konstruktor Intent:

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

Akcija prethodno deklarisane namere je ACTION_SEND, a Dodatno je mailto Uri (Dodatno je dodatne informacije koje namera očekuje).

Ova namera treba da bude deklarisana u manifestu kao u sledećem primeru:

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

Jedan intent-filter mora se podudarati sa akcijom, podacima i kategorijom kako bi primio poruku.

Proces "Razrešenje namere" određuje koja aplikacija treba da primi svaku poruku. Ovaj proces uzima u obzir prioritetni atribut, koji se može postaviti u deklaraciji intent-filtera, i selektuje onu sa većim prioritetom. Ovaj prioritet može biti postavljen između -1000 i 1000, a aplikacije mogu koristiti vrednost SYSTEM_HIGH_PRIORITY. U slučaju sukoba, pojavljuje se prozor "izbora" kako bi korisnik odlučio.

Eksplicitne namere

Eksplicitna namera specificira ime klase koju cilja:

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

U drugim aplikacijama, kako biste pristupili prethodno deklarisanoj nameri, možete koristiti:

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

Pending Intents

Ove dozvoljavaju drugim aplikacijama da preduzmu radnje u ime vaše aplikacije, koristeći identitet i dozvole vaše aplikacije. Prilikom konstrukcije Pending Intenta, treba navesti nameru i radnju koju treba izvršiti. Ako deklarisana namera nije eksplicitna (ne navodi koja namera može da je pozove), zlonamerna aplikacija može izvršiti deklarisanu radnju u ime aplikacije žrtve. Osim toga, ako radnja nije navedena, zlonamerna aplikacija će moći da izvrši bilo koju radnju u ime žrtve.

Broadcast Intents

Za razliku od prethodnih namera, koje prima samo jedna aplikacija, broadcast namera može biti primljena od strane više aplikacija. Međutim, od verzije API 14, moguće je navesti aplikaciju koja treba da primi poruku koristeći Intent.setPackage.

Alternativno, moguće je navesti dozvolu prilikom slanja broadcasta. Aplikacija koja prima broadcast mora imati tu dozvolu.

Postoje dva tipa broadcasta: Normalni (asinhroni) i Poredani (sinhroni). Redosled se zasniva na konfigurisanoj prioritetu unutar elementa koji prima. Svaka aplikacija može obraditi, proslediti ili odbaciti broadcast.

Moguće je poslati broadcast koristeći funkciju sendBroadcast(intent, receiverPermission) iz klase Context.
Takođe se može koristiti funkcija sendBroadcast iz LocalBroadCastManager koja osigurava da poruka ne napusti aplikaciju. Korišćenjem ove funkcije čak nije potrebno izvoziti komponentu koja prima broadcast.

Lepkavi (Sticky) Broadcasti

Ova vrsta broadcasta može se pristupiti dugo vremena nakon što su poslati.
Ovi broadcasti su zastareli od API nivoa 21 i nije preporučljivo koristiti ih.
Dozvoljavaju svakoj aplikaciji da prisluškuje podatke, ali i da ih menja.

Ako pronađete funkcije koje sadrže reč "sticky" kao što su sendStickyBroadcast ili sendStickyBroadcastAsUser, proverite uticaj i pokušajte da ih uklonite.

Duboke veze / URL šeme

U Android aplikacijama, duboke veze se koriste za pokretanje akcije (Intent) direktno putem URL-a. To se postiže deklarisanjem specifične URL šeme unutar aktivnosti. Kada Android uređaj pokuša pristupiti URL-u sa ovom šemom, pokreće se odgovarajuća aktivnost unutar aplikacije.

Šema se mora deklarisati u datoteci AndroidManifest.xml:

[...]
<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>
[...]

Šema iz prethodnog primera je exampleapp:// (takođe obratite pažnju na category BROWSABLE)

Zatim, u polju podataka, možete navesti host i putanju:

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

Da biste mu pristupili putem veba, moguće je postaviti link kao:

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

Da biste pronašli kod koji će se izvršiti u aplikaciji, idite na aktivnost koju poziva dubinska veza i potražite funkciju onNewIntent.

Saznajte kako pozvati dubinske veze bez korišćenja HTML stranica.

AIDL - Android jezik definicije interfejsa

Android jezik definicije interfejsa (AIDL) je dizajniran za olakšavanje komunikacije između klijenta i servisa u Android aplikacijama putem interprocesne komunikacije (IPC). Budući da direktni pristup memoriji druge procesa nije dozvoljen na Androidu, AIDL pojednostavljuje proces marshalinga objekata u format koji razume operativni sistem, olakšavajući komunikaciju između različitih procesa.

Ključni koncepti

  • Bound servisi: Ovi servisi koriste AIDL za IPC, omogućavajući aktivnostima ili komponentama da se povežu sa servisom, šalju zahteve i primaju odgovore. Metoda onBind u klasi servisa je ključna za pokretanje interakcije, što je važno područje za pregled bezbednosti u potrazi za ranjivostima.

  • Messenger: Kao vezani servis, Messenger olakšava IPC sa fokusom na obradi podataka putem metode onBind. Važno je pažljivo pregledati ovu metodu radi otkrivanja nebezbednog rukovanja podacima ili izvršavanja osetljivih funkcija.

  • Binder: Iako je direktna upotreba klase Binder manje uobičajena zbog apstrakcije AIDL-a, korisno je razumeti da Binder deluje kao drajver na nivou jezgra koji olakšava prenos podataka između memorijskih prostora različitih procesa. Za dalje razumevanje, dostupan je resurs na adresi https://www.youtube.com/watch?v=O-UHvFjxwZ8.

Komponente

To uključuje: Aktivnosti, Servise, Prijemnike emitovanja i Provajdere.

Pokretačka aktivnost i druge aktivnosti

U Android aplikacijama, aktivnosti su kao ekrani koji prikazuju različite delove korisničkog interfejsa aplikacije. Aplikacija može imati mnogo aktivnosti, prikazujući svaka jedinstveni ekran korisniku.

Pokretačka aktivnost je glavni ulaz u aplikaciju, pokreće se kada dodirnete ikonu aplikacije. Definisana je u manifest fajlu aplikacije sa specifičnim MAIN i LAUNCHER namerama:

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

Nisu sve aplikacije potrebne za pokretanje aktivnosti, posebno one bez korisničkog interfejsa, poput pozadinskih usluga.

Aktivnosti mogu biti dostupne drugim aplikacijama ili procesima označavanjem kao "izložene" u manifestu. Ovo podešavanje omogućava drugim aplikacijama da pokrenu ovu aktivnost:

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

Međutim, pristupanje aktivnosti iz druge aplikacije nije uvijek sigurnosni rizik. Briga se javlja ako se osjetljivi podaci dijele na nepravilan način, što može dovesti do curenja informacija.

Životni ciklus aktivnosti počinje s onCreate metodom, postavljanjem korisničkog sučelja i pripremom aktivnosti za interakciju s korisnikom.

Podklasa aplikacije

U Android razvoju, aplikacija ima mogućnost stvaranja podklase klase Application, iako to nije obavezno. Kada je takva podklasa definirana, postaje prva klasa koja se instancira unutar aplikacije. Metoda attachBaseContext, ako je implementirana u ovoj podklasi, izvršava se prije metode onCreate. Ova postavka omogućava ranu inicijalizaciju prije nego što ostatak aplikacije započne.

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
}
}

Usluge

Usluge su pozadinski operativci sposobni da izvršavaju zadatke bez korisničkog interfejsa. Ovi zadaci mogu nastaviti da se izvršavaju čak i kada korisnici prelaze na druge aplikacije, što čini usluge ključnim za dugotrajne operacije.

Usluge su veoma fleksibilne; mogu se pokrenuti na različite načine, pri čemu su Intents primarni način za njihovo pokretanje kao ulaznu tačku aplikacije. Kada se usluga pokrene koristeći startService metod, njen onStart metod se aktivira i nastavlja sa izvršavanjem sve dok se eksplicitno ne pozove stopService metod. Alternativno, ako je uloga usluge uslovljena aktivnom konekcijom sa klijentom, koristi se bindService metod za povezivanje klijenta sa uslugom, pri čemu se koristi onBind metod za prenos podataka.

Interesantna primena usluga uključuje reprodukciju pozadinske muzike ili preuzimanje mrežnih podataka bez ometanja interakcije korisnika sa aplikacijom. Osim toga, usluge mogu biti dostupne drugim procesima na istom uređaju putem izvoza. Ovo nije podrazumevano ponašanje i zahteva eksplicitnu konfiguraciju u Android Manifest fajlu:

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

Broadcast prijemnici

Broadcast prijemnici deluju kao slušaoci u sistemima za razmenu poruka, omogućavajući više aplikacija da odgovore na iste poruke od sistema. Aplikacija može registrovati prijemnik na dva osnovna načina: putem Manifesta aplikacije ili dinamički unutar koda aplikacije putem registerReceiver API-ja. U Manifestu, emitovanja se filtriraju sa dozvolama, dok dinamički registrovani prijemnici takođe mogu specificirati dozvole prilikom registracije.

Intent filteri su ključni u oba načina registracije, određujući koja emitovanja pokreću prijemnik. Kada se šalje odgovarajuće emitovanje, poziva se metoda onReceive prijemnika, omogućavajući aplikaciji da reaguje adekvatno, kao što je prilagođavanje ponašanja u odgovoru na upozorenje o niskom nivou baterije.

Emitovanja mogu biti ili asinhrona, dosežući sve prijemnike bez redosleda, ili sinkrona, gde prijemnici dobijaju emitovanje na osnovu postavljenih prioriteta. Međutim, važno je napomenuti potencijalni sigurnosni rizik, jer svaka aplikacija može sebe prioritetizovati kako bi presrela emitovanje.

Da biste razumeli funkcionalnost prijemnika, potražite metodu onReceive unutar njegove klase. Kod ove metode može manipulisati primljenim Intentom, što ističe potrebu za validacijom podataka od strane prijemnika, posebno kod uredjenih emitovanja, koja mogu izmeniti ili odbaciti Intent.

Provajder sadržaja

Provajderi sadržaja su ključni za deljenje strukturiranih podataka između aplikacija, naglašavajući važnost implementiranja dozvola kako bi se osigurala sigurnost podataka. Oni omogućavaju aplikacijama pristup podacima iz različitih izvora, uključujući baze podataka, fajl sisteme ili veb. Specifične dozvole, poput readPermission i writePermission, su ključne za kontrolu pristupa. Dodatno, privremeni pristup može biti odobren putem podešavanja grantUriPermission u manifestu aplikacije, koristeći atribute kao što su path, pathPrefix i pathPattern za detaljnu kontrolu pristupa.

Validacija unosa je od suštinskog značaja kako bi se sprečile ranjivosti, poput SQL ubacivanja. Provajderi sadržaja podržavaju osnovne operacije: insert(), update(), delete() i query(), olakšavajući manipulaciju podacima i deljenje među aplikacijama.

FileProvider, specijalizovani Provajder sadržaja, fokusira se na sigurno deljenje fajlova. Definiše se u manifestu aplikacije sa specifičnim atributima za kontrolu pristupa fasciklama, označenim sa android:exported i android:resource koji pokazuju na konfiguracije fascikli. Oprez se preporučuje prilikom deljenja direktorijuma kako bi se izbeglo slučajno otkrivanje osetljivih podataka.

Primer deklaracije manifesta za 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>

I primer za specificiranje deljenih foldera u filepaths.xml datoteci:

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

Za dodatne informacije pogledajte:

WebViews

WebViews su kao mini web pregledači unutar Android aplikacija, koji prikazuju sadržaj sa weba ili lokalnih datoteka. Oni se suočavaju sa sličnim rizicima kao i obični pregledači, ali postoje načini da se smanje ovi rizici putem određenih postavki.

Android nudi dva glavna tipa WebView-a:

  • WebViewClient je odličan za osnovni HTML, ali ne podržava JavaScript alert funkciju, što utiče na testiranje XSS napada.
  • WebChromeClient se ponaša više kao puna Chrome pregledačka iskustvo.

Ključna stvar je da WebView pregledači ne dele kolačiće sa glavnim pregledačem uređaja.

Za učitavanje sadržaja dostupne su metode poput loadUrl, loadData, i loadDataWithBaseURL. Važno je osigurati da su ovi URL-ovi ili datoteke sigurne za upotrebu. Postavke sigurnosti mogu se upravljati putem klase WebSettings. Na primer, onemogućavanje JavaScript-a sa setJavaScriptEnabled(false) može sprečiti XSS napade.

JavaScript "Bridge" omogućava Java objektima da komuniciraju sa JavaScript-om, zahtevajući da se metode obeleže sa @JavascriptInterface radi sigurnosti od Android verzije 4.2 nadalje.

Dozvoljavanje pristupa sadržaju (setAllowContentAccess(true)) omogućava WebViews da pristupe Content Providerima, što može predstavljati rizik osim ako se URL-ovi sadržaja ne verifikuju kao sigurni.

Da biste kontrolisali pristup datotekama:

  • Onemogućavanje pristupa datotekama (setAllowFileAccess(false)) ograničava pristup datotečnom sistemu, sa izuzecima za određene resurse, osiguravajući da se koriste samo za neosetljiv sadržaj.

Ostale komponente aplikacija i upravljanje mobilnim uređajima

Digitalno potpisivanje aplikacija

  • Digitalno potpisivanje je neophodno za Android aplikacije, osiguravajući da su autentično autorisane pre instalacije. Ovaj proces koristi sertifikat za identifikaciju aplikacije i mora biti verifikovan od strane upravljača paketa uređaja prilikom instalacije. Aplikacije mogu biti samopotpisane ili sertifikovane od strane eksternog CA, čime se štite od neovlašćenog pristupa i osigurava da aplikacija ostane nepromenjena tokom isporuke na uređaj.

Provera aplikacija za poboljšanu sigurnost

  • Počevši od Android 4.2, funkcija nazvana Provera aplikacija omogućava korisnicima da provere sigurnost aplikacija pre instalacije. Ovaj proces provere može upozoriti korisnike na potencijalno štetne aplikacije ili čak sprečiti instalaciju posebno zlonamernih aplikacija, poboljšavajući sigurnost korisnika.

Upravljanje mobilnim uređajima (MDM)

  • MDM rešenja pružaju nadzor i sigurnost za mobilne uređaje putem Device Administration API-ja. Ona zahtevaju instalaciju Android aplikacije radi efikasnog upravljanja i osiguranja mobilnih uređaja. Ključne funkcije uključuju nametanje politika lozinki, obavezno šifrovanje skladišta i dozvolu za daljinsko brisanje podataka, obezbeđujući sveobuhvatnu kontrolu i sigurnost nad mobilnim uređajima.
// 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);
}

Pronađite najvažnije ranjivosti kako biste ih brže popravili. Intruder prati vašu površinu napada, pokreće proaktivno skeniranje pretnji, pronalazi probleme u celom vašem tehnološkom sklopu, od API-ja do veb aplikacija i sistemima u oblaku. Isprobajte besplatno danas.

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

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u: