Par un traducteur: nous publions pour vous
un article de Jim Medlock, programmeur et architecte logiciel. Medlock parle des moyens de base pour protéger votre application ou service Web. Il convient de noter que ce matériel est susceptible d'être utile aux programmeurs débutants. Bien que si les pros laissent leurs commentaires, tout le monde en sera reconnaissant.
Pourquoi s'embêter avec quelqu'un qui pirate l'application? Oui, ne serait-ce que parce qu'il y a de plus en plus de gens qui veulent le faire avec le temps. Ce sont des pirates informatiques «ordinaires» pour qui le fait de surmonter la protection d'une personne présente un intérêt sportif, des cybercriminels qui détruisent des services et des sites à but lucratif, des organisations gouvernementales.
Au cours des derniers mois, de nombreuses grandes organisations ont fait la une des journaux après d'énormes fuites d'informations. Parmi eux, Facebook et ses 50 millions de comptes volés, la FIFA avec 3,4 To de données et 70 millions de documents, Google avec 0,5 million de comptes, Marriott Hotels avec les données de
427 millions de clients de l' ensemble du réseau.
Skillbox recommande: Cours pratique de deux ans "Je suis un développeur Web PRO . "
Nous vous rappelons: pour tous les lecteurs de «Habr» - une remise de 10 000 roubles lors de l'inscription à un cours Skillbox en utilisant le code promo «Habr».
SourceNon seulement le nombre d'attaques de pirates informatiques augmente, mais aussi la quantité de dégâts que font les cybercriminels. Selon les experts, la taille moyenne des pertes directes et indirectes causées par les cybercriminels est de 3,86 millions de dollars par piratage réussi. Bien sûr, c'est une moyenne du marché; les nombres réels varient, et à peu près.
Quelques statistiques supplémentaires. Les dommages causés par des cybercriminels peuvent être jugés par les données suivantes:
- 148 $ - le "prix" d'un compte volé;
- 40 millions de dollars - pour 1 million de comptes;
- 350 millions de dollars - pour 50 millions de comptes.
L'argent n'est pas le seul argument: pensez au temps qu'il faudra pour tout mettre en ordre.
Sécurité de l'infrastructure vs sécurité des applications
La plupart des mesures de sécurité visent à protéger la base de l'infrastructure informatique, comme un serveur, un stockage, un centre de données. C'est nécessaire, mais ce ne sont pas seulement eux qui doivent être protégés.
Les mesures de sécurité concernant l'application elle-même sont également extrêmement importantes. Ils fournissent un ensemble complet de méthodes pour trouver, corriger et empêcher l'utilisation malveillante des failles dans votre logiciel. Il convient de souligner ces éléments:
- revue de code réalisée par des spécialistes de la sécurité de l'information, lorsque l'objectif est exclusivement de rechercher des lieux problématiques en termes de cybersécurité
- Audit basé sur Blackbox basé sur le travail avec l'application;
- examen de l'architecture de l'application avant d'écrire la majeure partie du code;
- l'utilisation d'outils automatiques qui aident à évaluer la protection;
- lancement de programmes de primes qui permettent à des spécialistes tiers de trouver les zones problématiques.
Les mesures les plus efficaces reposent sur le concept de sécurité couche par couche. Dans ce cas, chacun des éléments protégés utilise son propre ensemble d'outils.
Vous ne pouvez rien faire avec le côté client
Le problème est qu'il est peu probable que vous soyez en mesure de protéger votre projet côté utilisateur. Les navigateurs modernes sont vulnérables, malgré les efforts de leurs créateurs.
Dans le cas des services Web, la faible composante de l'ensemble du système est la clé nécessaire pour l'autorisation. Par exemple, les applications qui utilisent l'API GitHub doivent prendre en charge l'authentification par jeton. Si le délinquant peut obtenir la clé entre ses mains, alors il aura tout accès au code et aux projets de la victime sur GitHub.
Pour un développeur frontend, le danger est qu'il puisse être sûr de la sécurité complète de son service si des mesures telles que des clés privées et des jetons sont fournies. Tout cela est bien, mais les mêmes navigateurs sont un maillon faible.
Est-il sûr de séparer les données de sécurité comme les clés de l'ensemble du projet?
En règle générale, les variables d'environnement sont utilisées pour extraire des données dans un fichier, telles que .env. Une étape supplémentaire consiste à ajouter le nom de ces fichiers à .gitignore, ce qui empêche l'exécution de commandes git push pour le téléchargement vers des référentiels publics, où le fichier sera ouvert à tous.
Tout cela est bien, mais les fichiers .env ne sont pas chiffrés. Dans le cas de Create React App, ils peuvent être vérifiés à l'aide de l'option Developer Tools du navigateur, dans le répertoire build / static / js. Voici, par exemple, ce que nous trouvons lors de l'examen de 0.chunk.js.
Comme vous pouvez le voir, cette approche ne donne pas d'avantages particuliers, dans certains cas, il est préférable de stocker des éléments de sécurité importants dans le code source. Il existe un autre scénario intéressant où la séparation de code est utilisée pour retarder le chargement de scripts contenant des variables d'environnement jusqu'à ce que l'utilisateur authentifie l'application. Mais si l'ordinateur client est compromis, rien ne fonctionnera - après tout, son système de fichiers est accessible aux intrus.
Solution
Contrairement à la partie client, les applications serveur peuvent être protégées afin que les données importantes ne tombent pas entre les mains des attaquants. Pour ce faire, vous pouvez utiliser Oauth pour obtenir un niveau supplémentaire d'authentification et de contrôle d'accès, de chiffrement et de protocoles comme HTTPS et TLS.
Le dilemme de la sécurisation des secrets d'application peut être résolu en implémentant une API côté serveur. Dans le même temps, il agit comme un serveur proxy pour isoler l'application cliente des fournisseurs de services qu'il utilise. Au lieu d'utiliser des données privées côté client pour les authentifier dans le service, l'API s'authentifie à partir de l'application serveur, exécute les requêtes et renvoie ensuite les résultats au client. Les clés privées ou autres données ne sont en aucun cas communiquées à ce dernier.
Approche intégrée
Oui, la complexité n'est pas que des mots. Afin de donner aux utilisateurs confiance dans la protection fiable de leurs données, une planification minutieuse, une stratégie de sécurité bien pensée, basée sur une protection approfondie et une attention aux détails, sont nécessaires.
Il ne suffit pas de compter sur des «îlots technologiques». Il est nécessaire de connecter tous les éléments ensemble, en comprenant comment le système entier fonctionnera.
Ce n'est que dans ce cas que l'application ou le service sera sûr.