Share
Beveiliging is een belangrijk aspect van softwareontwikkeling. Vrijwel elke mobiele applicatie behandelt gebruikersinformatie of communiceert met een externe server. Hoewel de beveiliging de afgelopen decennia enorm is verbeterd, blijft het een heftig besproken onderwerp.
In dit artikel wil ik een aantal onderwerpen benadrukken die te maken hebben met beveiliging en mobiele ontwikkeling. Onderweg bespreek ik een aantal best practices en suggesties die u mogelijk handig vindt om de applicaties die u schrijft te beveiligen.
Beveiliging is relatief. Security-exploits worden regelmatig ontdekt en gepatcht. Niets is perfect. Dat gezegd hebbende, zijn er een aantal dingen die u kunt doen om de beveiliging van uw mobiele applicaties te verbeteren. Een inbreker is minder geneigd om in te breken in een gebouw dat wordt omringd door een schrikdraad dan een die dat niet is.
Sommige ontwikkelaars zien het feit over het hoofd dat de gebruikers van hun applicaties hen vertrouwen in hun informatie. Als ontwikkelaar bent u verantwoordelijk voor het veilig houden van die informatie. Het maakt niet uit wat die informatie is. Hoewel de informatie mogelijk onbelangrijk voor u lijkt, is het belangrijk voor de gebruiker.
Apple neemt beveiliging en privacy erg serieus. HealthKit is een goed voorbeeld van de inzet van Apple om de privacy van de gebruiker te beschermen. De gebruiker beslist tot welke gezondheidsgegevens een toepassing toegang heeft. Hoewel de toepassing toegang kan vragen tot de gezondheidsgegevens van de gebruiker, geeft HealthKit niet aan tot welke gegevens deze toegang heeft. Met andere woorden, Apple beschouwt de autorisatiestatus van een toepassing als gevoelige informatie waarover ze niet zou moeten weten.
Voordat u beslist hoe of waar u een bepaald gegeven wilt opslaan, moet u zich afvragen of u die gegevens eerst moet opslaan. Is het bijvoorbeeld mogelijk om de gegevens in het geheugen te bewaren in plaats van deze op een schijf te schrijven of naar een externe server te verzenden? Dit kan de architectuur van uw toepassing aanzienlijk vereenvoudigen en de beveiliging ervan verbeteren.
Als u besluit dat het lokaal opslaan van de gegevens uw enige optie is, moet u beslissen waar u die gegevens wilt opslaan. Voor gevoelige informatie, zoals inloggegevens, is de sleutelhanger uw beste optie. Dit is alleen mogelijk voor kleine hoeveelheden gegevens waarvoor uw toepassing geen frequente toegang nodig heeft.
Moeten de gegevens worden geback-upt naar iCloud of iTunes? Als dat niet het geval is, kunt u overwegen om de gegevens op te slaan in de caches map van de sandbox van de toepassing. Van deze map is geen back-up gemaakt naar iCloud en iTunes. Waarom is dat belangrijk? Gegevens die niet bestaan, kunnen niet in gevaar worden gebracht.
Het standaardsysteem, toegankelijk via de NSUserDefaults klasse, is een snelle en handige manier om stukjes gegevens op te slaan. Helaas wordt het standaardsysteem vaak gebruikt door ontwikkelaars. Het gebeurt maar al te vaak dat gevoelige informatie, zoals inloggegevens en toegangstokens, worden opgeslagen in het standaardsysteem.
Een veel betere locatie voor het opslaan van kleine brokken gevoelige informatie is de sleutelhanger van het systeem. Zoals de naam al aangeeft, is het ontworpen met het oog op veiligheid en het bestaat al vele, vele jaren. Hoewel de sleutelhanger wordt beheerd door het besturingssysteem, hebben standaard andere applicaties geen toegang tot de items die uw toepassing in de sleutelhanger opslaat.
Het is waar dat de interface voor toegang tot de sleutelchaindiensten archaïsch is. Gelukkig zijn er verschillende uitstekende bibliotheken die deze hindernis overwinnen. Lockbox is bijvoorbeeld een lichtgewicht bibliotheek voor interactie met de sleutelbosdiensten van het systeem. De interface van Lockbox is gemakkelijk te gebruiken en te begrijpen.
Het is verleidelijk om sleutels, tokens en zelfs inloggegevens op gemakkelijk toegankelijke locaties, zoals de doelwitten, op te slaan Info.plist of een JSON-bestand in de bundel van uw toepassing. De waarheid is dat het kinderspel is om die informatie te extraheren uit een app die is gedownload van de App Store. Door een API-token op te slaan voor een webservice in uw toepassing Info.plist, andere ontwikkelaars kunnen het vinden en gebruiken.
Veiligheid en privacy staan al vele jaren op de agenda van Apple en, samen met andere belangrijke spelers, heeft Apple besloten het goede voorbeeld te geven. Tijdens de WWDC van vorig jaar, introduceerde het bedrijf App Transport Security.
Met App Transport Security wil Apple de beveiliging van zijn platforms en de applicaties die daarop draaien verbeteren. Ongeacht hoeveel Apple investeert in het beveiligen van zijn besturingssystemen, een systeem is alleen zo veilig als zijn zwakste onderdeel en dat omvat applicaties van derden..
App Transport Security dwingt applicaties om netwerkverzoeken via een beveiligde verbinding te verzenden. Als App Transport Security is ingeschakeld voor een toepassing, worden netwerkverzoeken standaard via HTTPS verzonden. Apple benadrukt haar inzet voor veiligheid en privacy door App Transport Security automatisch in te schakelen voor applicaties die met Xcode 7 zijn gebouwd.
U kunt meer lezen over App Transport Security op Envato Tuts +. Hoewel het eenvoudig is om App Transport Security uit te schakelen, moet u er rekening mee houden dat een van de doelen van App Transport Security is om ontwikkelaars het netwerkgedrag van hun applicaties te laten overwegen..
Vrijwel elke mobiele applicatie maakt gebruik van het netwerk. Dit betekent dat mensen met slechte intenties zich sterk richten op dit aspect van applicatiebeveiliging. Netwerken is een complexe zaak en applicaties bouwen bovenop een hele reeks technologieën om de gegevens op te halen waarin ze geïnteresseerd zijn.
Als ontwikkelaar is het belangrijk dat u zich houdt aan een aantal best practices. We hebben al gesproken over App Transport Security en de regels die deze nieuwe technologie afdwingt. Daar stopt het echter niet. Misschien wilt u ook geavanceerdere onderwerpen bekijken, zoals het vastzetten van certificaten, zodat de server waarmee uw toepassing communiceert niet frauduleus is. Moderne bibliotheken, zoals Alamofire, maken dit veel gemakkelijker.
De meeste toepassingen gebruiken gevoelige gebruikersinformatie of slaan deze op. Mobiele apparaten hebben toegang tot een breed scala aan gebruikersinformatie die vaak persoonlijk en gevoelig van aard is, zoals locatie, adresboek en gezondheidsinformatie.
Zoals ik eerder in dit artikel al zei, is de eerste vraag die je jezelf moet stellen, of je toegang tot deze informatie nodig hebt en, nog belangrijker, of je die informatie moet opslaan.
Als u toegang hebt tot de informatie die u nodig hebt via een native framework, zoals HealthKit, hoeft u die informatie niet te dupliceren en op te slaan. Apple zal bijvoorbeeld apps weigeren die de gezondheidsinformatie van de gebruiker opslaan in iCloud.
Ervan uitgaande dat u een aantal gevoelige informatie moet opslaan, moet u overwegen of die informatie lokaal moet worden bewaard. Is het nodig om gevoelige informatie naar een externe server te verzenden?
Het opslaan van gevoelige informatie wordt met een waarschuwing verzonden. Als de server waarop u gevoelige informatie opslaat, in het gedrang komt, bent u mogelijk verantwoordelijk voor het blootstellen van die informatie aan andere partijen.
De online veiligheid is de afgelopen decennia enorm geëvolueerd. Verificatieprotocollen, zoals OAuth, hebben de communicatie met webservices veiliger en transparanter gemaakt.
Als uw toepassing met een veilige server moet praten, overweeg dan hoe uw toepassing inloggegevens beheert. Houdt het ze in het geheugen of bewaart ze op schijf? Als u de gebruikersnaam en het wachtwoord van de gebruiker vraagt om een toegangstoken op te halen, is het goed om dat toegangstoken op te slaan. Maar moet u ook uw gebruikersnaam en wachtwoord opslaan? Het antwoord is nee in de meeste situaties.
Voor toepassingen die te maken hebben met zeer gevoelige gegevens, zoals gezondheids- of financiële informatie, kan het zelfs beter zijn om het toegangstoken in het geheugen te bewaren en niet op schijf op te slaan. Door het in het geheugen te bewaren, is het veel veiliger, waardoor uw toepassing veel minder een verplichting is. De kans is groot dat het toegangstoken hoe dan ook een korte levensduur heeft.
De beveiliging van een applicatie is een fundamenteel aspect van softwareontwikkeling. Overweeg tot welke gegevens uw toepassing toegang heeft en of deze informatie moet worden opgeslagen. Als u besluit om gevoelige informatie op te slaan, houd dan de bovenstaande tips en praktische tips in gedachten. Zorg ervoor dat u de informatie van de gebruiker met respect behandelt. Ook al lijkt de informatie misschien onbelangrijk voor u, het is belangrijk voor de gebruiker.
Accentsconagua