Wat is iOS App Sandboxing?

iOS-app sandboxing is een kern beveiligingsarchitectuur die elke toepassing beperkt tot zijn eigen speciale container, waardoor het niet toegang krijgt tot systeembestanden, andere app-gegevens of hardwarebronnen zonder uitdrukkelijke toestemming van de gebruiker. Wanneer een app is geïnstalleerd, creëert het besturingssysteem een unieke sandbox-map voor die app, en al zijn code, gegevens, voorkeuren en caches leven in die directory. De app kan niet ontsnappen aan zijn container om bestanden te lezen of te schrijven die behoren tot een andere app of tot het systeem zelf. Dit ontwerp zorgt ervoor dat zelfs als een app wordt gecompromitteerd, de schade is opgenomen aan die ene zandbak.

Het sandbox-model wordt op kernelniveau gehandhaafd, wat betekent dat het van toepassing is op alle apps . . inclusief die verspreid via de App Store, enterprise implementaties, en zelfs systeemapps in grote mate. Het besturingssysteem bemiddelt elke bestandssysteembewerking, netwerkverbinding en hardwareaanroep, waardoor alleen acties die vallen binnen de verleende rechten van de app. Dit maakt iOS een van de meest veilige mobiele besturingssystemen beschikbaar, aangezien het isolatie op andere beveiligingsbeveiligingen zoals code ondertekening en data-encryptie lagen.

De technische architectuur achter Sandboxing

Op kernelniveau maakt iOS gebruik van verplichte toegangscontrole (MAC) die wordt afgedwongen door het Seatbelt sandbox-kader. Seatbelt definieert een reeks regels voor elk appproces, waarbij wordt gespecificeerd welke bestanden, mappen, netwerkeindpunten en systeemdiensten het proces kunnen openen. Deze regels worden samengesteld in een sandbox-profiel dat wordt geladen wanneer de app wordt gestart. Het profiel is uniek voor elke app en kan niet worden overschreven door de app zelf.

Elke app krijgt zijn eigen container directory, meestal gelegen op . Binnen deze container, het systeem verdeelt verder opslag in subdirectories zoals , , en . De app kan vrij lezen en schrijven in zijn eigen container, maar elke poging om paden buiten deze container te openen leidt tot een ontkenning van de kernel. Dit omvat pogingen om andere app containers, systeemframes of hardware apparaten te lezen die niet expliciet worden toegekend.

Sandbox-profielen beperken ook de communicatie tussen processen (IPC). Apps kunnen geen willekeurige systeemservices oproepen of achtergrondprocessen starten zonder specifieke rechten. Dit betekent dat zelfs als een app willekeurige code kan uitvoeren, het bijvoorbeeld geen daemon kan starten die constant op de achtergrond draait of berichten naar het proces van een andere app stuurt. De combinatie van bestandssysteemisolatie en IPC-beperkingen vormt de ruggengraat van iOS-beveiliging.

Kernveiligheidsmaatregelen in iOS

Sandboxen werkt niet in isolatie. Het maakt deel uit van een gelaagd beveiligingsmodel dat meerdere aanvullende maatregelen omvat die zijn ontworpen om gebruikersgegevens en systeemintegriteit op elk niveau te beschermen.

Toestemmingen voor apps en gebruikersbeheer

iOS vereist apps om toestemming te vragen voordat u toegang krijgt tot gevoelige gegevens of hardware. Dit omvat de camera, microfoon, locatieservices, fotobibliotheek, contacten, agenda, Bluetooth en bewegingssensoren. Toestemmingen worden verleend via een runtime prompt die de eerste keer dat de app probeert toegang te krijgen tot de bron verschijnt. Gebruikers kunnen later op elk moment de machtigingen bekijken en intrekken via de instellingen-app.

Apple heeft de toestemmingscontrole bij elke iOS-versie gestaag aangescherpt. Bijvoorbeeld, iOS 14 heeft het delen van een locatie bij benadering toegevoegd en de mogelijkheid om fototoegang te verlenen op een per-image basis. iOS 15 introduceerde het privacyrapport van de App, dat logt welke bronnen elke app heeft geopend. iOS 16 en 17 verdere verfijnde toegang meldingen van klembord, pushboard toestemmingen en lockdown-modus voor gebruikers met een hoog risico. Deze mechanismen zorgen ervoor dat, zelfs als een app goedaardig is, gebruikers de korrelige controle behouden over welke gegevens worden gedeeld.

Code ondertekening en App validatie

Elke app die op iOS draait moet digitaal door Apple worden ondertekend met behulp van een certificaat dat aan de ontwikkelaar is afgegeven. Dit proces, bekend als code ondertekening, garandeert dat de code niet is geknoeid sinds de ondertekening ervan. Wanneer het systeem een app laadt, controleert het de handtekening op de infrastructuur van Apple's publieke sleutel. Als de ondertekening ongeldig is, ontbreekt of is verlopen, zal de app niet worden gestart.

Code ondertekening strekt zich uit voorbij de installatie van de app. Het systeem controleert ook code handtekeningen op runtime voor dynamisch geladen bibliotheken en kaders. Dit voorkomt dat een app niet ondertekende code na de lancering, dat is een veel gebruikte techniek door malware om de eerste controles te omzeilen. Apple's notarisatie service voor macOS dient een vergelijkbaar doel, maar op iOS de handhaving is verplicht voor alle apps, niet alleen die verspreid via de App Store.

Gegevensversleuteling bij rust en in doorvoer

iOS-apparaten gebruiken hardware-backed encryptie om gegevens die zijn opgeslagen op flash-opslag te beschermen. Elk apparaat heeft een speciale AES-engine ingebouwd in het systeem-op-chip, die versleutelt en decodeert gegevens met behulp van een apparaat-specifieke sleutel. Het systeem past verschillende encryptie klassen op verschillende soorten gegevens:

  • klasse A (Volledige bescherming): Gegevens worden gecodeerd met een sleutel die is afgeleid van de gebruikerspascode en is alleen toegankelijk wanneer het apparaat is ontgrendeld.
  • klasse B (Beschermd tot eerste ontgrendeling): Gegevens worden toegankelijk na de eerste ontgrendeling en blijven toegankelijk totdat het apparaat opnieuw wordt gestart.
  • klasse C (Beschermd tenzij Open): Gegevens zijn toegankelijk zolang het bestand geopend is, zelfs als het apparaat vergrendeld is.
  • klasse D (geen bescherming): Gegevens worden versleuteld maar de sleutel is altijd beschikbaar na het opstarten.

Naast de encryptie tegen de rust, dwingt iOS Transport Layer Security (TLS) voor alle netwerkverbindingen die worden gemaakt door systeemservices en vele apps. Apple vereist standaard apps om HTTPS te gebruiken en heeft de verouderde uitzonderingen voor App Transport Security (ATS) in de loop van de tijd. Dit zorgt ervoor dat gegevens die worden verzonden tussen het apparaat en servers worden gecodeerd tijdens het transport, waardoor het voor aanvallers moeilijk is om het verkeer te onderscheppen of te wijzigen.

Veilige opstartketen en hardware wortels van vertrouwen

Wanneer een iOS-apparaat ingeschakeld wordt, voert het code uit vanaf een alleen-lezen Boot-ROM die tijdens de productie in de chip wordt gebrand. Deze Boot-ROM is onveranderlijk en is de hardware-wortel van vertrouwen. Het controleert de handtekening van de volgende opstartlader (iBoot) met behulp van Apple's publieke sleutel. iBoot controleert vervolgens de kernel, en de kernel controleert het besturingssysteem en alle systeemextensies.

Als een component niet in staat is om de handtekening te verifiëren, stopt het bootproces en komt het apparaat in de herstelmodus. Deze vertrouwensketen zorgt ervoor dat alleen Apple-geautoriseerde software kan draaien op het apparaat, vanaf de allereerste instructie. Het voorkomt dat malware blijft bestaan over reboots en maakt jailbreaking steeds moeilijker met elke hardware generatie.

Hoe Sandboxing voorkomt dat de algemene aanval vectoren

Het begrijpen van de praktische impact van sandboxing helpt duidelijk te maken waarom iOS als een veilig platform wordt beschouwd. Sandboxen blokkeert actief verschillende gemeenschappelijke aanvalstechnieken:

  • Gegevensexfiltratie tussen apps: Zonder sandboxing kon een besmette app de bestanden van elke andere app op het apparaat lezen. Sandboxing voorkomt dit door ervoor te zorgen dat elke app een eigen geïsoleerd bestandssysteem heeft.
  • Systeembestandsmodificatie: Onheilvolle code kan systeem binaire bestanden, bibliotheken of configuratiebestanden niet overschrijven omdat deze bestanden buiten de app container wonen.
  • Keychain access: iOS biedt een veilige sleutelhanger voor het opslaan van gevoelige tokens en wachtwoorden. Elke app kan alleen toegang krijgen tot zijn eigen Keychain items, en het systeem verplicht dit op kernelniveau.
  • Achtergrondprocesmisbruik: Apps kunnen geen achtergronddaemons of agenten voortbrengen zonder expliciete rechten, die zelden worden toegekend. Dit voorkomt dat malware persistentie kan vaststellen of verborgen processen kan uitvoeren.
  • Hardware resource kaping: Zelfs als een app toegang krijgt tot de camera of microfoon door toestemming te vragen, voorkomt sandboxing dat het toegang krijgt tot andere hardware zoals de NFC controller of de Secure Enclave zonder aparte rechten.

Deze bescherming betekent dat zelfs nul-klik exploits

Implicaties voor ontwikkelaars

Voor iOS-ontwikkelaars legt sandboxing beperkingen op die bepalen hoe apps worden ontworpen en getest. Elke app moet de rechten en mogelijkheden aangeven die ze nodig heeft, en Apple beoordeelt deze verklaringen tijdens het goedkeuringsproces van App Store. Ontwikkelaars moeten alleen de minimumrechten vragen die nodig zijn voor hun app om te functioneren, een praktijk die bekend staat als het principe van de minst privileges.

De belangrijkste gevolgen voor de ontwikkeling zijn onder meer:

  • Bestandssysteemtoegang: Ontwikkelaars kunnen niet aannemen dat ze naar willekeurige mappen kunnen schrijven. Alle door gebruikers gegenereerde inhoud moet worden opgeslagen in de map van de app, en tijdelijke bestanden moeten worden ingevoerd .
  • Inter-app communicatie: Het delen van gegevens tussen apps vereist expliciete mechanismen zoals UIActivityViewController, UIPasteboard, of gedeelde toegangsgroepen voor sleutelhangers, die allemaal configuratie en gebruikersinteractie vereisen.
  • Achtergronduitvoering: Apps kunnen alleen op de achtergrond draaien voor specifieke gebruikscases, zoals audioweergave, locatie-updates of achtergrondophalen. Poging om willekeurige achtergrondwerk uit te voeren zal resulteren in het opschorten van de app.
  • Entitle management: Mogelijkheden zoals push notificaties, Apple Pay en iCloud opslag vereisen provisioning profielrechten. Ontwikkelaars moeten deze configureren in het Apple Developer portal en ervoor zorgen dat ze overeenkomen met het sandbox profiel.
  • Testoverwegingen: Ontwikkelaars moeten hun apps testen op fysieke apparaten om de naleving van de sandbox te controleren, omdat de simulator ontspannen Sandbox-regels heeft die geen echt apparaatgedrag weerspiegelen.

Apple biedt uitgebreide documentatie en tools om ontwikkelaars te helpen werken binnen sandbox beperkingen. Xcode bevat sandbox debugging functies die toegang tot logs schendingen, en de App Sandbox gids schetst beste praktijken voor het ontwerpen van veilige, zandbak-conforme apps.

Implicaties voor gebruikers

Voor alledaagse gebruikers werkt sandboxing stil op de achtergrond, maar begrijpen kan helpen bij het nemen van geïnformeerde beslissingen over app-machtigingen en apparaatgedrag. Wanneer een app toegang vraagt tot de camera, microfoon of locatie, moeten gebruikers overwegen of het verzoek zinvol is voor de functionaliteit van de app. Een zaklamp app die bijvoorbeeld toegang vraagt tot de microfoon, is waarschijnlijk een inbreuk op de privacyverwachtingen.

Gebruikers moeten zich er ook van bewust zijn dat jailbreaking sandbox beschermingen verwijdert door het uitschakelen van de kernel-level handhaving. Een jailbroken apparaat niet langer isoleert apps van elkaar of van het systeem, waardoor het kwetsbaar voor malware die gegevens kan stelen, spyware kan installeren of blijvende systeem instabiliteit veroorzaken. Apple sterk ontmoedigt jailbreaking, en het bedrijf heeft het steeds moeilijker gemaakt met elke iOS-versie door het verharden van de Secure Boot Chain en het toevoegen van kernel integriteit beschermingen.

De beste praktijken voor gebruikers zijn onder meer:

  • Bekijk app-machtigingen regelmatig in Instellingen > Privacy & Beveiliging.
  • Alleen toestemmingen die nodig zijn voor de primaire functie van de app.
  • Houd iOS op de hoogte om de nieuwste beveiligingspatches en sandbox verbeteringen te ontvangen.
  • Vermijd sideloaden apps van onbetrouwbare bronnen, omdat deze Apple's code ondertekening en beveiligingsbeoordeling omzeilen kunnen.
  • Activeer gezichts-ID of Touch-ID om de encryptiesleutels die sandboxed gegevens beschermen te beschermen.

De evolutie van iOS-beveiliging

Apple heeft de sandboxing en beveiligingsmaatregelen continu versterkt sinds iOS het model voor het eerst introduceerde met iPhone OS 2.0. Vroege sandboxprofielen waren relatief eenvoudig en lieten meer flexibiliteit toe, maar naarmate iOS gerijpt werd, werden de profielen restrictiever en korreliger.De introductie van het -systeem gaf ontwikkelaars een manier om specifieke mogelijkheden te vragen en de standaard sandbox zo strak mogelijk te houden.

Belangrijke mijlpalen zijn onder meer:

  • iOS 6: Ingevoerde VPN per app en verbeterde gegevensbeschermingsklassen.
  • iOS 9: Standaard apptransportbeveiliging ingeschakeld, waardoor apps HTTPS moeten gebruiken.
  • iOS 12: Er is strengere zandbak voor Safari Web Content toegevoegd en USB-beperkte modus ingevoerd.
  • iOS 14: Alle apps moesten toestemming vragen om gebruikers te volgen via apps en websites (apps die transparantie volgen).
  • iOS 16: Introduceerde de sluismodus voor gebruikers die geconfronteerd worden met geavanceerde bedreigingen, waardoor het aanvalsoppervlak ernstig werd beperkt.
  • iOS 17: Uitgebreide vergrendelingsmodus en verbeterde Link Tracking- en communicatieveiligheidskenmerken toegevoegd.

Elke iteratie sluit aanvalsvectoren die door security onderzoekers zijn ontdekt of in het wild worden geëxploiteerd. Apple onderhoudt ook een bug premie programma dat onderzoekers beloont voor het vinden van kwetsbaarheden, waaronder sandbox escapes. Deze feedback lus helpt Apple te identificeren zwakheden en patch hen voordat ze kunnen worden op grote schaal worden geëxploiteerd.

Conclusie

Het sandboxen van iOS-app is een fundamenteel beveiligingsmechanisme dat elke toepassing in zijn eigen container isoleert, waardoor ongeoorloofde toegang tot systeembronnen en andere appgegevens wordt voorkomen. Wanneer het gecombineerd wordt met code ondertekening, gegevensversleuteling, de Secure Boot Chain en korrelige gebruikersrechten, creëert het een gelaagde verdediging die iOS een van de veiligste mobiele platforms ter beschikking stelt. Voor ontwikkelaars vereist sandboxing een zorgvuldig ontwerp en naleving van Apple's richtlijnen, maar het beschermt uiteindelijk gebruikers en bouwt vertrouwen op in het ecosysteem. Voor gebruikers versterkt het begrijpen van sandboxing het belang van het beheren van machtigingen en het bijhouden van apparaten. Naarmate bedreigingen evolueren, blijft Apple sandboxprofielen verharden en nieuwe beschermingen invoeren, zodat het beveiligingsmodel effectief blijft tegen geavanceerde aanvallen.

Om meer te weten te komen over iOS-beveiligingsarchitectuur, verwijzen we naar Apple's iOS Security Guide en de Secure Coding Guide.