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.

Dans un environnement d'entreprise, il peut s'avérer bénéfique de restreindre les applications qu'il est possible d'exécuter sur un système Windows, que ce soit un poste de travail ou un serveur. Voyons si AppLocker, fonctionnalité disponible depuis Windows 7 et 2008 R2, répond à cette attente.

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.