Aanbevolen beveiligingsprocedures voor ontwikkelaars

Adobe AIR 1.0 of hoger

AIR-toepassingen zijn weliswaar gebaseerd op webtechnologieën maar ontwikkelaars mogen niet vergeten dat ze niet in de beveiligingssandbox van de browser werken. Dit betekent dat het mogelijk is om AIR-toepassingen te ontwikkelen die bedoeld of onbedoeld schade kunnen toebrengen aan het systeem. AIR probeert dit risico tot het minimum te beperken maar er zijn altijd wel manieren om kwetsbaarheden te genereren. In dit onderwerp worden belangrijke potentiële kwetsbaarheden besproken.

Risico bij het importeren van bestanden in de toepassingsbeveiligingssandbox

Bestanden in de toepassingsmap zijn toegewezen aan de toepassingssandbox en beschikken over alle toegangsrechten van de runtime. Toepassingen die naar het lokale bestandssysteem schrijven, wordt aangeraden naar app-storage:/ te schrijven. Aangezien deze directory apart van de toepassingsbestanden op de computer van de gebruiker is geplaatst, zijn de bestanden niet toegewezen aan de toepassingssandbox en vormen ze een kleiner veiligheidsrisico. Ontwikkelaars wordt aangeraden het volgende in acht te nemen:

  • Neem alleen indien nodig een bestand op in een AIR-bestand (in de geïnstalleerde toepassing).

  • Neem alleen een scriptbestand op in een AIR-bestand (in de geïnstalleerde toepassing) als het gedrag ervan volledig begrepen en vertrouwd wordt.

  • Schrijf niet naar de toepassingsmap en wijzig de inhoud ervan niet. De runtime genereert een SecurityError-fout om te zorgen dat toepassingen geen bestanden en mappen via het URL-schema app:/ kunnen wijzigen of ernaar schrijven.

  • Gebruik geen gegevens van een netwerkbron als parameters voor AIR API-methoden die tot de uitvoering van code kunnen leiden. Dit geldt onder andere voor het gebruik van de methode Loader.loadBytes() en de JavaScript-functie eval() .

Risico bij het gebruiken van een externe bron voor het bepalen van paden

Een AIR-toepassing kan in gevaar worden gebracht door het gebruik van externe gegevens of inhoud. Daarom moet extra worden opgelet bij het gebruik van gegevens van het netwerk of het bestandssysteem. De verantwoordelijkheid voor het geven van vertrouwen ligt uiteindelijk bij de ontwikkelaars en de netwerkverbindingen die ze maken, maar het laden van externe gegevens is altijd gevaarlijk en kan beter niet worden gedaan voor het invoeren van gegevens bij bewerkingen met vertrouwelijke gegevens. Ontwikkelaars wordt het volgende afgeraden:

  • gegevens van een netwerkbron gebruiken om een bestandsnaam te bepalen;

  • gegevens van een netwerkbron gebruiken om een URL te definiëren die door de toepassing wordt gebruikt om persoonlijke informatie te verzenden.

Risico bij het gebruiken, opslaan of verzenden van onveilige gebruikersgegevens

Het opslaan van gebruikersgegevens in het lokale bestandssysteem van de gebruiker brengt altijd het risico met zich mee dat deze gegevens door een kwaadwillige persoon zijn gewijzigd. Ontwikkelaars wordt aangeraden het volgende in acht te nemen:

  • Als gebruikersgegevens lokaal moeten worden opgeslagen, moeten ze worden gecodeerd bij het schrijven naar het lokale bestandssysteem. Via de klasse EncryptedLocalStore biedt de runtime unieke gecodeerde opslag voor elke geïnstalleerde toepassing. Zie Lokale gegevens gecodeerd opslaan voor meer informatie.

  • Verzend niet-gecodeerde aanmeldingsgegevens voor een gebruiker alleen naar een netwerkbron als deze betrouwbaar is en als de verzending gebruik maakt van het HTTPS- of TLS-protocol (Transport Layer Security).

  • Stel nooit een standaardwachtwoord in bij het creëren van gebruikersgegevens. Laat de gebruiker zijn of haar eigen wachtwoord instellen. Gebruikers die de standaardinstellingen niet wijzigen, stellen hun referenties bloot aan een hacker die het standaardwachtwoord kent.

Risico van een downgradeaanval

Tijdens de installatie van een toepassing controleert de runtime of de toepassing momenteel niet is geïnstalleerd. Als de toepassing al is geïnstalleerd, vergelijkt de runtime het versienummer met dat van de geïnstalleerde versie. Als beide versies niet hetzelfde nummer hebben, kan de gebruiker desgewenst de bestaande installatie upgraden. De runtime garandeert echter niet dat de nieuwe versie recenter is dan de geïnstalleerde versie, alleen dat het een andere versie is. Een aanvaller kan de gebruiker een oudere versie sturen om gebruik te maken van deze kwetsbaarheid. Daarom wordt de ontwikkelaar aangeraden een versiecontrole uit te voeren bij het starten van de toepassing. Het is een goed idee om toepassingen het netwerk te laten doorzoeken op eventuele updates. Op die manier wordt onmiddellijk een verouderde versie gedetecteerd, zelfs als een aanvaller erin geslaagd is de gebruiker een oude versie te laten installeren. Ook het gebruik van een duidelijk versieschema voor uw toepassing maakt het moeilijk om gebruikers onbedoeld een oudere versie te laten installeren.