La problématique de sécurisation des frontaux Web dits “RIA” ou “RDA” (Rich Internet Application ou Rich Desktop Application) entre dans le scope des préoccupations des utilisateurs. Le domaine bancaire est à ce jour l’un des plus attentif aux apports potentiels de ce type de technologie, mais s’attache encore à traiter ses failles de sécurité sur le ton de l’étude ou du Proof of concept.
La maturité opérationnelle n’est donc pas encore atteinte du moins pour envisager sereinement une généralisation significative de ces solutions. Les analyses de risque prennent en compte les différents cas d’utilisation et menaces possibles aux seins du SI bancaire :
- Portails et sites transactionnels bancaires sensibles (exemple : banque en ligne particuliers, professionnels et entreprises)
- Portails et sites vitrines internet peu sensibles
- Applicatifs transactionnels intranet (ou extranet) sensibles
- Applicatifs transactionnels intranet (ou extranet) peu sensibles (site d’information, ..)
et les confrontent aux menaces externes et internes les plus envisagées, parmi lesquelles :
- Phishing, troyens bancaires,
- Fraude internet,
- Denis de service (botnet,..)
- Altération du contenu
- Fraude interne
- Vol de données
Une qualification des risques en termes de probabilité d’occurrence, et de technicité nécessaires à l’exploitation sont les deux sujets les plus envisagés. Ils sont le généralement traités sous forme de recommandations visant au minimum les thèmes suivants :
- Interdits
- Bonnes pratiques
- Contre-mesures et solutions de contournement (outils, configuration, choix de mise en oeuvre, administration.)
- Mesures organisationnelles (formation, sensibilisation, procédure, cloisonnement des responsabilités, …)
La cartographie des attaques potentielles est déjà constituée : elle en identifie au moins deux nouvelles que sont le Cross Site Scripting (XSS) et le Cross Site Request Forgery (CSRF).
Cross Site Scripting (XSS)
La base d’une attaque exploitant une faille XSS, a pour objectif d’injecter des données arbitraires dans un site web. Un tiers peut par exemple poster un commentaire ou écrire un message dans une interface contact client ou encore modifier des paramètres directement dans une URL. Si ces données arrivent telles quelles dans la page web transmise au navigateur (par les paramètres d’URL, un message posté, etc.) sans avoir été vérifiées et assainies, alors il existe une faille : le tiers peut s’en servir pour faire exécuter du code malveillant via un langage de script (du JavaScript le plus souvent).
Trois types de failles XSS existent :
Type 0 (local) : Ce cas survient quand un script JavaScript écrit à la volée une partie de la page avec des paramètres utilisateurs non vérifiés. Cela permet par exemple d’afficher des entrées de formulaires qui ne devraient pas apparaître en temps normal. C’est ce qui arrive lorsqu’on ne vérifie pas que l’utilisateur a le droit d’effectuer telle ou telle action sous prétexte qu’on ne lui propose pas.
Type 1 (non permanent) : Ce cas arrive quand l’entrée utilisateur est affichée telle quelle sur le site. Cela peut arriver par exemple quand un moteur de recherche affiche la requête. Si on peut faire suivre un lien spécial à une victime, on peut voler son cookie de session par exemple. (C’est le type de l’exemple ci-dessus)
Type 2 (persistant) : Ce cas arrive quand le serveur enregistre dans un fichier ou une base de données l’entrée utilisateur sans la vérifier, donc le code injecté est visible par tous les visiteurs.
Ce genre de faille peut permettre de faire à peu près tout ce que peut faire un script ou du HTML, comme par exemple :
- Afficher un contenu non interne au site (publicité, faux article réglementaire)
- Rediriger l’utilisateur vers un site frauduleux (parfois même de manière transparente).
- Voler des informations comme une session ou un cookie.
- Actions sur le site faillible, à l’insu de la victime et sous son identité (envoi de messages, suppression de données, etc.)
- plantage de la page (boucle infinie de pop-up par exemple), et souvent du navigateur.
Les erreurs HTML 404 (Page not found) et 403 (Unauthorized) des sites reprennent souvent l’url demandée dans le texte de la page. Sans les protections adéquates, ces pages sont vulnérables. Google par exemple à été victime d’une telle faille. La technique consistait à jouer sur l’encodage de la page pour contourner certains mécanismes de défense.
Cross Site Request Forgery (CSRF)
Pour qu’un tiers profite d’une faille XSS, il doit amener l’utilisateur à se rendre sur le site compromis avec les bons paramètres ou sur la bonne page. Dans le cas d’une vulnérabilité de type Cross Site Request Forgery, l’attaque est bien plus complexe. L’idée générale consiste à utiliser un site tiers.
Un utilisateur connecté sur son Webmail, est généralement authentifié par un cookie. Tout en laissant sa boite de réception ouverte, il continue de naviguer sur d’autres sites. Cet utilisateur reçoit par ailleurs un mail qui contient un lien cliquable. Cet utilisateur clique sur ce lien et ouvre un site piégé. Le site piégé profite du fait que cet utilisateur (ou tout du moins son navigateur) est authentifié sur le site de mail et fait une requête correspondant à un envoi de mail à destination d’un contact référencé dans son carnet d’adresse… Une superbe démonstration d’usurpation d’identité.
Les risques encourus sont les suivants :
- Tout ce que vous pouvez faire en usurpant une identité (opérations bancaires, ordre d’arbitrage, …)
- Du vol d’informations (carnet d’adresse)
- Préparation d’une attaque plus lourde (en modifiant la configuration d’un routeur par exemple)
- Imprimer des pages de test sur l’imprimante du bureau (ce qui, fait en boucle, peut être assez immobilisant)
(10 votes)
Loading ...