MISC 49

Réfléchissons quelques minutes à l'évolution des fameux systèmes d'information. Ils sont entourés de moult protections, dont le marketing explique bien souvent le prix de la licence (notez que j'ai écrit « explique » et non « justifie »). Du coup, quand on cible une entité, de l'extérieur, les points d'accès sont généralement connus et limités : un webmail, un VPN, un serveur de messagerie, un pseudo-serveur web.

L'accès aux données d'un back-end SQL est souvent considéré comme le point final d'un pentest sur une application web, mais avec des back-end SQL de plus en plus riches en termes de fonctionnalités et l'essor des web services, les bases de données ne sont plus cantonnées au fond du SI dans une dmz isolée, mais sont devenues de véritables nœuds d'interconnexion entre SI. Il ne faut donc plus considérer l'accès au SGBD comme une fin en soi, mais comme un point d'appui pour pénétrer en profondeur dans les SI.Nous verrons comment un attaquant partant d'une simple injection SQL peut rapidement transformer une base de données Oracle en un proxy http, ainsi que les outils qui sont à sa disposition pour faciliter cette tâche. Nous terminerons par quelques recommandations pour pallier de tels risques.

Résumé de l’épisode précédent : le XSS, en tirant notamment parti de l’API DOM, permet de réaliser des attaques si puissantes que Jeremiah Grossman sous-titrait son livre XSS Attacks paru en avril 2007 « XSS is the New Buffer Overflow, JavaScript Malware is the New Shell Code »2. Il est important d’examiner de plus près cette analogie entre XSS et attaques applicatives classiques afin de bien comprendre toute l’étendue des possibilités offertes par le XSS à un attaquant, notamment à travers l’injection de différents types de codes JavaScript malveillants. Dans la troisième partie de cet article, nous essaierons d’évaluer le risque réel de différents scénarios d’attaques, tirant notamment partie des trois erreurs les plus fréquemment commises à propos du XSS.