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.

Résumé des épisodes précédents : le XSS tend à devenir une composante importante de scénarios d'infection massive exploitant des vecteurs d'attaques combinées visant, entre autres, à constituer des réseaux de machines zombies. La parenté du XSS avec des techniques d’attaques applicatives par débordement de tampon permet de bien comprendre la diversité et la puissance des attaques que le XSS rend possibles. Nous allons maintenant nous interroger sur les raisons susceptibles d’expliquer le relatif échec de la lutte anti-XSS aujourd’hui et illustrerons notre propos en essayant d’évaluer le risque réel de différents scénarios d’attaques, tirant notamment parti des trois erreurs les plus fréquemment commises à propos du XSS.

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.