Share
Het Android-besturingssysteem heeft veel ingebouwde beveiligingsfuncties, zoals sandboxing van toepassingen, bescherming tegen buffer en integer overflow-aanvallen, en gescheiden geheugengebieden voor programma-instructies en gegevens. Dientengevolge kunnen eenvoudige Android-apps die geen bestandssystemen of netwerkbewerkingen uitvoeren, vaak als veilig worden beschouwd.
Als u echter een complexere app aan het ontwikkelen bent, is het uw verantwoordelijkheid om deze te beveiligen en de privacy van uw gebruikers te beschermen. In dit artikel zal ik enkele van de best practices opsommen die u kunt volgen om een veilige Android-app te bouwen die geen gegevens of machtigingen lekt, en over het algemeen minder kwetsbaar is voor kwaadaardige apps die mogelijk op de Android-app zijn geïnstalleerd. apparaat van de gebruiker.
Elke Android-app heeft een bijbehorende interne opslagdirectory waarvan het pad is gebaseerd op de pakketnaam van de app. Bestanden in deze map zijn erg veilig omdat ze de MODE_PRIVATE bestands creatie modus standaard. Dit betekent dat de bestanden niet toegankelijk zijn voor andere apps op het apparaat. Daarom is het de beste plaats om alle gevoelige gegevens van uw app op te slaan in de interne opslagdirectory.
Om het absolute pad van de interne opslagdirectory van uw app te bepalen, is het raadzaam om de. Te gebruiken getFilesDir () methode. Als u eenmaal weet wat het pad is, is het verwijzen naar bestanden erin net zo eenvoudig als het verwijzen naar bestanden in een andere map. Hier ziet u bijvoorbeeld hoe u kunt verwijzen naar een bestand met de naam myfile.dat in de interne opslagdirectory van uw app:
Bestand myFile = nieuw bestand (getFilesDir (), "myfile.dat");
De interne opslagcapaciteit van een Android-apparaat is vaak beperkt. Daarom hebt u soms geen andere keuze dan gevoelige gegevens op externe opslagmedia op te slaan, zoals een verwisselbare SD-kaart.
Omdat gegevens op externe opslagmedia direct toegankelijk zijn voor zowel gebruikers als andere apps op het apparaat, is het belangrijk dat u deze opslaat in een gecodeerde indeling. Een van de meest populaire coderingsalgoritmen die tegenwoordig worden gebruikt door ontwikkelaars is AES, kort voor Geavanceerde versleutelingsstandaard, met een sleutelgrootte van 256 bits.
Code schrijven om de gegevens van uw app te coderen en decoderen met behulp van de javax.crypto pakket, dat is opgenomen in de Android SDK, kan verwarrend zijn. Daarom geven de meeste ontwikkelaars de voorkeur aan het gebruik van bibliotheken van derde partijen, zoals de Conceal-bibliotheek van Facebook, die meestal veel gemakkelijker te gebruiken zijn.
Ervaren programmeurs die nog niet bekend zijn met de ontwikkeling van Android-apps, proberen vaak om sockets, named pipes of gedeelde bestanden te gebruiken om asynchroon te communiceren met andere apps die op een Android-apparaat zijn geïnstalleerd. Deze benaderingen zijn niet alleen moeilijk en onelegant, maar ook vatbaar voor bedreigingen. Een gemakkelijkere en veiligere benadering van communicatie tussen processen op het Android-besturingssysteem is om intenties te gebruiken.
Als u gegevens naar een specifiek onderdeel van een app wilt verzenden, moet u een nieuw exemplaar van de app maken voornemen klasse en gebruik het setComponent () methode om zowel de pakketnaam van de app als de naam van het onderdeel op te geven. U kunt dan gegevens toevoegen met behulp van de putExtra () methode.
Hier ziet u bijvoorbeeld hoe u de tekenreeks kunt verzenden Hallo Wereld aan een Activiteit riep Mijn activiteit, die hoort bij een app waarvan de pakketnaam is my.other.app:
Accentsconagua
// Maak een intentie Intent opzet = new Intent (); // Specificeer de componentnaam intent.setComponent (nieuwe ComponentName ("my.other.app", "my.other.app.MyActivity")); // Voeg data intent.putExtra toe ("DATA", "Hello World!"); // Stuur de intentie naar de activiteit startActivity (intent);Als u gegevens naar meerdere apps tegelijk wilt verzenden, kunt u de intentie als een uitzending verzenden met behulp van de sendBroadcast () methode. Standaard kan een uitzending echter worden gelezen door elke app met een juiste configuratie Uitzending ontvanger.
Daarom, als u gevoelige informatie als een uitzending wilt verzenden, moet u een aangepaste toestemming gebruiken waarvan beschermingsniveau ingesteld op handtekening. Op deze manier zorgt het Android-besturingssysteem ervoor dat alleen apps die zijn ondertekend met uw handtekeningsleutel de uitzending kunnen ontvangen.
Hier is een codefragment dat laat zien hoe de string moet worden verzonden Hallo Wereld als beveiligde uitzending:
// Maak een intentie Intent opzet = new Intent (); // Voeg data intent.putExtra toe ("DATA", "Hello World"); // Specificeer een actienaam voor // intent-filter intent.setAction ("my.app.receive") van de ontvanger; // Verzenden als een uitzending met een aangepaste toestemming sendBroadcast (intent, "my.custom.permission");Merk op dat de bovenstaande code alleen werkt zoals verwacht als de aangepaste machtiging wordt gedeclareerd en gebruikt in de manifestbestanden van zowel de zender- als de ontvanger-apps.
Alle communicatie tussen uw app en uw servers moet via een HTTPS-verbinding verlopen, bij voorkeur met behulp van de HttpsURLConnection klasse. Als je denkt dat het gebruik van HTTP voor gegevens die niet vertrouwelijk zijn prima is, denk dan opnieuw.
Veel Android-gebruikers maken dagelijks verbinding met verschillende open Wi-Fi-hotspots in openbare ruimtes. Sommige van die hotspots kunnen kwaadaardig zijn. Een kwaadwillende hotspot kan de inhoud van HTTP-verkeer gemakkelijk wijzigen om ervoor te zorgen dat uw app zich onverwacht gedraagt, of nog erger advertenties of exploits erin invoegen.
Door HTTPS te gebruiken, zolang de server is geconfigureerd met een certificaat dat is uitgegeven door een vertrouwde certificeringsinstantie, zoals DigiCert of GlobalSign, kunt u er zeker van zijn dat uw netwerkverkeer beveiligd is tegen afluisteren en man-in-the-middle-aanvallen.
Als uw app veel netwerkcode heeft en u bent bang dat u ongewild wat gegevens als cleartext verzendt, moet u overwegen om nogotofail te gebruiken, een open source-tool die door Google is gebouwd om dergelijke fouten te vinden.
Toen GCM, een afkorting van Google Cloud Messaging, nog niet bestond, gebruikten veel ontwikkelaars SMS om gegevens van hun servers naar hun apps te pushen. Vandaag is deze praktijk grotendeels verdwenen.
Als u een van die ontwikkelaars bent die nog steeds niet de overstap van SMS naar GCM heeft gemaakt, moet u weten dat het sms-protocol noch is gecodeerd noch veilig is voor spoofing-aanvallen. Bovendien kan een sms worden gelezen door elke app op het apparaat van de gebruiker met de READ_SMS toestemming.
GCM is een stuk veiliger en is de voorkeursmanier om berichten naar een app te pushen omdat alle GCM-communicatie versleuteld is. Ze worden geverifieerd met behulp van regelmatig vernieuwde registratietokens aan de clientzijde en een unieke API-sleutel aan de serverzijde. Voor meer informatie over GCM kunt u deze zelfstudie over pushmeldingen raadplegen.
Gebruikersprivacy wordt tegenwoordig veel belangrijker. In feite zijn er wetten, zoals de Richtlijn Gegevensbescherming van de Europese Unie en de Canadese Wet Bescherming Persoonsgegevens en Elektronische Documenten, die de bescherming van de privacy van een gebruiker verplicht stellen. Daarom, tenzij u een goede reden en een zeer veilige infrastructuur hebt om persoonlijke gebruikersinformatie te verzamelen, op te slaan en te verzenden, moet u voorkomen dat u er rechtstreeks om vraagt in uw apps..
Een betere benadering van gebruikersauthenticatie en gebruikersprofielinformatie opzoeken op Android is via het Google Identity Platform. Met Google Identity Platform kunnen gebruikers zich snel aanmelden bij uw app met hun Google-account. Na een succesvolle aanmelding via het platform kan uw app, indien nodig, gemakkelijk verschillende details over de gebruiker opzoeken, zoals de naam van de gebruiker, het e-mailadres, de profielfoto, contactpersonen en meer. U kunt ook gratis services gebruiken, zoals Firebase, die gebruikersverificatie voor u kunnen beheren.
Als u zelf gebruikersreferenties moet verwerken, is het raadzaam deze op te slaan en te verzenden in de vorm van veilige hashes. De meest eenvoudige manier om verschillende soorten hashes te genereren met behulp van de Android SDK is door de MessageDigest klasse.
Hier is een klein codefragment dat je laat zien hoe je een hash van de string maakt Hallo Wereld met behulp van de SHA-256 hashing-functie:
// Initialiseer MessageDigest om SHA-256 MessageDigest md = MessageDigest.getInstance ("SHA-256") te gebruiken; // Converteer de tekenreeks naar een hash-byte [] sha256Hash = md.digest ("Hello World" .getBytes ());Op Android leidt ongeldige gebruikersinvoer meestal niet tot beveiligingsproblemen zoals bufferoverschrijdingen. Als u echter gebruikers toestaat om te communiceren met een SQLite-database of een inhoudsprovider die intern een SQLite-database gebruikt, moet u de invoer van gebruikers strikt saneren of gebruik maken van geparametriseerde zoekopdrachten. Als u dit niet doet, zijn uw gegevens kwetsbaar voor aanvallen met SQL-injecties.
Op dezelfde manier is validatie en desinfectie van gebruikersinvoer ook erg belangrijk als u gebruikersinvoer gebruikt om code dynamisch te genereren voor gebruik op een ingesloten scriptengine, zoals Mozilla Rhino.
Beveiligingsmaatregelen die in een Android-app zijn ingebouwd, kunnen ernstig worden aangetast als aanvallers in staat zijn de broncode te bemachtigen. Voordat u uw app publiceert, wordt aangeraden om een tool genaamd ProGuard te gebruiken, die is opgenomen in de Android SDK, om de broncode te verbergen en te verkleinen.
Android Studio neemt ProGuard automatisch op in het bouwproces als het buildType ingesteld op vrijlating. De standaard ProGuard-configuratie beschikbaar in de Android SDK's ProGuard-android.txt bestand is voldoende voor de meeste apps. Als u aangepaste regels aan de configuratie wilt toevoegen, kunt u dat doen in een bestand met de naam proguard-rules.pro, die deel uitmaakt van elk Android Studio-project.
Ik hoop dat je nu een beter begrip hebt van hoe je je Android-apps kunt beveiligen. De meeste praktische tips die ik in dit artikel noemde, zijn alleen van toepassing als u de Android SDK gebruikt om uw apps te ontwikkelen. Als u in plaats daarvan de Android NDK gebruikt, moet u veel voorzichtiger zijn, omdat u tijdens het programmeren in de C-taal wordt verwacht dat u zelf low-level details, zoals pointers en geheugentoewijzing, beheert.
Voor meer informatie over beveiliging op Android, kunt u de beveiligingsdocumenten van AOSP raadplegen.
