Aanbevolen beveiligingsprocedures voor ontwikkelaars

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().

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.

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 gebruikersgegevens niet ongecodeerd naar een netwerkbron, tenzij de desbetreffende bron wordt vertrouwd.

• 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.

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.