Nous avons décidé de répéter les travaux de recherche à grande échelle de 2015 et analysé la sécurité des ressources Web des principales banques mondiales. Depuis lors, les services bancaires en ligne sont devenus non seulement plus répandus, mais même répandus. En effet, il est rapide et pratique, mais dans quelle mesure? Les banques suivent-elles les meilleures pratiques?

Comme la dernière fois , dans le processus de recherche, nous avons envoyé des requêtes HTTP et DNS ordinaires sans interférer avec les banques. Autrement dit, toutes les données sont collectées comme un utilisateur normal pourrait le faire en visitant une ressource. Pour l'analyse, nous avons sélectionné 200 banques russes et 400 banques étrangères. Sous extraits de l'étude. Le texte intégral se trouve sur notre site Web.

Cette fois, nous avons élargi le champ de la recherche en ajoutant des ressources en ligne de banques étrangères à la portée. Cela vous permet de comparer l'attitude envers la sécurité Web en Russie et dans d'autres pays du monde.

Pour l'avenir, nous regrettons de noter que les méthodes classiques d'augmentation du niveau de sécurité sont souvent ignorées par les banques, bien qu'elles ne nécessitent pas de ressources financières et techniques mondiales. Manquer des opportunités est volontaire, mais il est complètement différent de les utiliser incorrectement. Par exemple, dans le cas de la politique de sécurité du contenu, un cinquième de toutes les ressources considérées ont des paramètres, et presque toutes ont des erreurs de configuration. Dans le cadre de l'étude, nous avons essayé d'examiner en détail comment travailler correctement avec ce type de paramètres et quelles erreurs sont le plus souvent commises.

Objectif de la recherche

L'objectif principal de l'étude est d'évaluer le niveau de sécurité des ressources bancaires accessibles au public: le site officiel et RBS, conformément aux meilleures pratiques de mise en place des ressources web. Nous avons sélectionné un certain nombre de points, dont la conformité peut être vérifiée, à l'exclusion de tout dommage technique et sans interférer dans le travail de la banque. Il est important de noter que toutes les informations que nous collectons sont du domaine public, et la manipulation de ces données ne nécessite pas de compétences approfondies: si vous le souhaitez, tout utilisateur intéressé peut arriver à de tels résultats.

Objet d'étude

Pour les tests, nous avons pris les banques TOP-200 en Russie. La liste complète peut être consultée sur: http://www.banki.ru/banks/ratings/ (données actuelles en mars 2019).

La première étape, nous avons identifié tous les sites Web officiels et les ressources Internet du RB pour les personnes physiques et morales. Ensuite, pour chaque banque, des vérifications ont été effectuées à l'aide de plusieurs demandes standard utilisant les protocoles HTTP / HTTPS / DNS, similaires aux demandes habituelles des clients des banques. Liste groupée:

1. Paramètres SSL - offrent la possibilité de mettre en œuvre l'une des nombreuses attaques liées à SSL;
2. Paramètres DNS - vous permettent d'obtenir des informations sur les sous-domaines de l'entreprise.

Ce qui suit est une description et les résultats de certains contrôles. Nous accordons une attention particulière à la section consacrée à la politique de sécurité du contenu: nous y avons essayé de mettre en évidence les principales erreurs et de dire comment les éviter. Une description complète et les résultats de tous les contrôles sont dans l' étude .

Test

SSL / TLS

L'un des points les plus importants est la vérification des paramètres SSL / TLS, comme Aujourd'hui, ces protocoles cryptographiques sont la méthode la plus populaire pour fournir un échange de données sécurisé sur Internet. La principale menace potentielle est l'utilisation d'attaques d'interception du trafic.
Les contrôles suivants ont été sélectionnés:

Évaluation

SSL / TLS possède un grand nombre de paramètres et de fonctionnalités qui, à un degré ou à un autre, affectent la sécurité de la connexion elle-même et de ses participants dans leur ensemble. Pour effectuer une évaluation globale de ce paramètre, nous avons utilisé les fonctionnalités fournies par Qualys (www.ssllabs.com). Il permet sur la base de nombreux paramètres de créer une note générale de A à F, où «A +» est le meilleur résultat qui puisse être obtenu en termes de sécurité. Très peu d'entreprises, même les plus grandes sociétés Internet, l'ont. Par conséquent, «F» est le pire résultat. Il peut être obtenu si le serveur est exposé à une vulnérabilité critique, prend en charge des protocoles obsolètes et rencontre d'autres problèmes. Tout comme la note «A +», le pire résultat est rare et est principalement associé à un personnel non professionnel.

Le pourcentage de notes en dessous de «A» s'affiche sur la carte. Plus ce pourcentage est élevé, pire est la situation de la sécurité Web dans le pays.

En-têtes HTTP

Les en-têtes de la réponse du serveur Web vous permettent de déterminer le comportement du navigateur dans certaines situations. Leur présence permet d'éviter certaines attaques ou de compliquer leur conduite, tandis que l'ajout d'un en-tête ne nécessite aucune action ou configuration complexe. Cependant, certains paramètres, par exemple CSP, se distinguent par un trop grand nombre d'options, dont l'utilisation incorrecte peut créer l'illusion de sécurité ou même endommager certaines fonctionnalités du site. Nous avons examiné les rubriques suivantes:

Si les dix premiers titres sont de nature «positive» et qu'il est souhaitable (correctement!) De les utiliser, alors les trois derniers «indiquent» à l'attaquant quelles technologies sont utilisées. Naturellement, ces rubriques doivent être supprimées.

Évaluation

La bonne combinaison d'en-têtes HTTP vous permet d'assurer la sécurité du site, tout en les configurant n'est pas du tout difficile. Nous avons collecté des données sur l'utilisation des en-têtes HTTP et basé sur eux, nous avons compilé une note de sécurité pour les ressources Web.
Pour le respect des paramètres suivants, nous avons attribué ou marqué des points:

Notation de «D» à «A +», où «A +» est le meilleur résultat qui puisse être obtenu en termes de sécurité. Le pire résultat était cependant assez rare, comme le meilleur.

Répartition des notes

Le pourcentage de notes en dessous de «A» s'affiche sur la carte. Plus ce pourcentage est élevé, pire est la situation de la sécurité Web dans le pays.

Politique de sécurité du contenu

Une «politique de protection du contenu» ou CSP est l'un des principaux moyens de réduire les risques associés à l'exploitation des attaques XSS. Cet outil permet à l'administrateur du site de déterminer quelles ressources Web sont autorisées à utiliser sur les pages - polices, styles, images, scripts JS, SWF, etc. Découvrez quels navigateurs prennent en charge CSP ici .

Grâce au CSP, vous pouvez empêcher complètement le navigateur de charger, par exemple, des objets flash, ou ajuster la liste blanche des domaines - dans ce cas, le navigateur n'affichera que les fichiers SWF qui se trouvent sur le domaine autorisé. Un autre avantage que la politique CSP fournit est la capacité de se renseigner rapidement sur l'apparition de nouveaux XSS dans l'immensité d'une ressource contrôlée. En utilisant l'option «report-uri», le navigateur de l'attaquant ou de l'utilisateur victime envoie un rapport à l'URL spécifiée dès que le CSP est déclenché.

Parmi les principales erreurs liées à la politique CSP, les catégories suivantes peuvent être distinguées:

1. Configuration incorrecte
   
   • Directives manquantes (script-src | object-src | default-src | base-uri)
   • Options redondantes (unsafe-inline | unsafe-eval | https: | data: | *)
2. Faiblesses des hôtes et liste blanche
   
   • Possibilité de charger des fichiers JS arbitraires
   • Rappels
   • Gadgets de script dans les moteurs de modèles angulaires et similaires
3. Attaques sans JS («sans script»)
   
   • Fuite par des balises non fermées
   • Mettre en œuvre des formulaires de phishing

Des informations plus détaillées, des exemples spécifiques d'erreurs et des moyens de les éviter peuvent être trouvés dans le texte intégral de l' étude .

Le principal objectif du CSP est de réduire la probabilité d'exploiter les attaques XSS, mais, comme la recherche l'a montré, peu parviennent à configurer correctement cette politique: seuls 3% utilisent le CSP.
Le graphique montre les erreurs les plus courantes dans les sites CSP examinés.

Strict-transport-security

La stratégie de sécurité HSTS (HTTP Strict Transport Security) vous permet d'établir une connexion sécurisée au lieu d'utiliser le protocole HTTP. Pour ce faire, utilisez l'en-tête Strict-Transport-Security, qui force le navigateur à forcer l'utilisation de HTTPS. Cela empêche certaines attaques MITM, en particulier les attaques avec un degré de protection inférieur et le vol de cookies. Le principe du mécanisme est le suivant: la première fois que vous visitez un site en utilisant le protocole HTTP (S), le navigateur reçoit l'en-tête Strict-Transport-Security et se souvient que lorsque vous essayez de vous reconnecter à ce site, vous n'avez qu'à utiliser HTTPS.
Cela empêchera un scénario où un attaquant, interceptant les requêtes HTTP, redirige l'utilisateur vers la page de clonage pour obtenir ses données.

Pourcentage de banques utilisant l'en-tête HTTP Strict-Transport-Security

Définir un cookie

Après avoir reçu la requête HTTP, le serveur peut envoyer l'en-tête Set-Cookie avec la réponse.
Les cookies avec l'indicateur Secure sont envoyés au serveur uniquement si la demande est effectuée via SSL et HTTPS. Cependant, les données importantes ne doivent jamais être transmises ou stockées dans un cookie, car son mécanisme est très vulnérable et l'indicateur Secure ne fournit pas de chiffrement supplémentaire ni de mesures de sécurité. Les cookies avec l'indicateur HTTPonly ne sont pas accessibles à partir de JavaScript via les propriétés de l'API Document.cookie, ce qui permet d'éviter le vol du cookie par le client en cas d'attaque XSS. Cet indicateur doit être défini pour les cookies qui n'ont pas besoin d'être accessibles via JavaScript. En particulier, si les cookies sont utilisés uniquement pour prendre en charge la session, alors en JavaScript, ils ne sont pas nécessaires et vous pouvez utiliser l'indicateur HTTPOnly. Sans les indicateurs HTTPOnly et Secure dans l'en-tête de réponse HTTP, vous pouvez voler ou traiter une session d'application Web et des cookies.

Les drapeaux sécurisés et HTTPonly dans cet en-tête ne sont pas trouvés plus souvent que sur chaque deuxième site officiel de la banque en Bosnie-Herzégovine, au Japon, en Chine, au Brésil, en Bulgarie, au Luxembourg, en Finlande, en Israël, en France, en Grande-Bretagne et en Espagne.
Parmi DBO pour physique. personnes - Chine, Irlande, Israël et Japon.
Parmi RBS pour jur. personnes - Bosnie-Herzégovine, Brésil et Chine.

Parmi les banques russes, les statistiques sont les suivantes:
Site officiel de la banque - 42%;
RBS pour physique. personnes - 37%;
RBS pour juridique personnes - 67%.

En-tête de serveur

Cet en-tête vous indique sur quel logiciel le serveur Web s'exécute et peut avoir la signification suivante, par exemple:

Server:Apache/2.4.12 (Unix) mod_wsgi/3.5 Python/2.7.5 OpenSSL/1.0.1l 

La divulgation de ces informations ne constitue pas une menace directe, mais peut réduire la durée de l'attaque. Au lieu de rechercher une vulnérabilité particulière, vous pouvez immédiatement commencer à rechercher des données sur une version spécifique du logiciel. Par exemple, au cours de l'étude, les données suivantes ont été trouvées:

L'étude a montré que 64% des sites des banques signalent une version de serveur, tandis que 24% de ces serveurs sont vulnérables.

Conclusion

Ayant reçu une idée générale de la sécurité des ressources Web des banques, nous sommes arrivés à la conclusion principale: de nombreuses banques négligent même les conseils les plus courants et les plus faciles à mettre en œuvre pour améliorer la sécurité de leurs ressources Web.

Les vulnérabilités et les erreurs que nous avons découvertes permettent aux attaquants de mettre en œuvre des attaques sur les ressources sans dépenser beaucoup d'efforts. Mais les conséquences de ces attaques sont assez graves: pertes de trésorerie des clients, pertes financières et de réputation de la banque, y compris à long terme. Peu confient leur argent à une banque dont la réputation est ternie par des incidents de sécurité.

Bien sûr, suivre la pratique standard d'augmenter le niveau de sécurité - rechercher et fermer les vulnérabilités - est payant et minimise les risques. Cependant, la plupart des développeurs d'applications Web bancaires oublient les recommandations et les méthodes les plus simples qui peuvent réduire considérablement le risque ou compliquer l'exploitation des vulnérabilités (comme, par exemple, cacher aux en-têtes du serveur des informations sur le logiciel utilisé ou installer CSP). Les avantages de l'utilisation de ces technologies ne sont pas immédiatement visibles, mais peuvent ne pas être évidents du tout: les ayant rencontrés, un attaquant ne pourra pas mener une attaque, et ses actions resteront hors de vue des responsables de la sécurité.

Après avoir examiné les ressources Web des banques russes sous différents angles, nous avons découvert que des vulnérabilités et des problèmes de sécurité assez connus sont toujours présents. Cela permet aux attaquants de compter sur la mise en œuvre réussie d'attaques contre ces institutions financières. Et plus il y a de problèmes, plus les risques financiers et de réputation des banques sont élevés.
La situation dans le monde dans son ensemble n'est pas particulièrement différente. Parmi les pays clairement en retard en termes de sécurité, on peut identifier les ressources bancaires en ligne des pays suivants: Chine, Japon, Brésil, Israël, Espagne. Paradoxalement, dans la plupart des cas, les banques étrangères accordent plus d'attention à la sécurité de leurs pages principales qu'au système bancaire. Il convient de noter que la part de l'analyse des banques étrangères dans l'étude n'est pas si étendue et constitue plutôt une familiarisation.