Catégorie: Sécurité web

Si vous cherchiez à vous pénétrer par LFI (Local File Inclusion), inutile de créer une liste de fuzzing, en voila une toute prête.

Un peu de PHP, de grep et de sed, et le tour est joué

J'en parlais il y a quelques mois, le nouveau système de protection anti-XSS de Mozilla trouve maintenant son site officiel.
Ca se passe par ici, avec possibilité de tester son navigateur, ou de télécharger une version de FF intégrant le CSP.

Une XSS découverte (et patchée), chez Twitter. Grâce à l'ajout de rel=nofollow dans leur API, des petits malins pouvait exécuter du Javascript dans un navigateur client grâce à un Tweet bien formé.
Comme d'habitude : vol de cookie, donc vol de session et de compte, etc...

C'est corrigé, enfin on sait pas trop, il semblerait que les techniciens de Twitter soient très mauvais et corrigent à moitié les choses (whouhouuu) ... ^^

Voici un petit billet montrant une XSS dans un en-tête HTTP : le user agent.
En fait cette XSS est destinée à être exécutée au niveau des outils d'analyse de logs, qui souvent se contentent d'afficher simplement leurs résultats à l'écran dans une page Web et hop : XSS.

Rappel : tout ce qui provient du client HTTP doit être validé, c'est à dire tous les en-têtes et le contenu de sa requête. Même le "Host:" peut contenir une XSS cachée et passer dans certains cas. Gare gare !

Voila un petit article bien détaillé de l'exploitation d'une CSRF sur Facebook.
Elle permet à quelqu'un d'accéder aux infos privées d'une personne. Si on joue avec l'en-tête de requête HTTP Referer, on arrive encore plus facilement à tromper le système, qui se base simplement sur un paramètre HTTP absolument non sécurisé et spoofable en un clic sous firefox (même pas besoin de sortir un outils)... Whao.

Tout développeur Web connait le SOP, pour Same Origin Policy. Ces règles qui empêchent notamment un objet XHR de requêter un domaine différent de la page depuis laquelle il est issu, obligeant les développeurs à avoir recours à des proxies ou autres joyeusetés du genre. C'est la même chose avec les cookies, et fort heureusement sinon le Web aurait explosé depuis des lustres.

Malheureusement, la protection SOP ne suffit plus aujourd'hui, et XSS règne en maitre dans le domaine des failles de sécurité sur le Web.
Conscients de ce problème depuis bien longtemps, les ingénieurs de chez Mozilla ont inventé CSP : Content Security Policy.
Les règles basiques sont simples :
- Tout javascript inline, c'est à dire non issu d'un fichier JS est totalement interdit et ignoré par le moteur JS
- Tout javascript issu d'un fichier JS ne pourra être exécuté que si le domaine de provenance du JS fait partie d'une liste blanche établie par le développeur

Tout cela sent bon pour la sécurité car XSS semble définitivement impossible. Enfin presque, car avec cette règle il faudrait alors trouver une faille dans le navigateur - ce qui reste tout à fait faisable et possible : mettez vos navigateurs à jour.
Ou encore spoofer le DNS - ce qui est aussi possible, soit en s'introduisant dans la table de routage de la box de l'utilisateur, la plupart du temps c'est assez simple car ils ne changent pas le mot de passe par défaut de leur box, soit en empoisonnant les cache DNS plus haut, là ça se corse tout de même.

Une fois de plus, la question de la migration :
Mozilla assure que celle-ci sera simplifiée, le processus CSP pouvant être personnalisé et ne se résumant pas aux 2 règles que j'ai citées plus haut ( la page officielle pour plus d'info ). Ils ont étudié beaucoup de pages Web, de complexité plus ou moins grande, et ont assuré que passer à CSP pourra se faire progressivement pour les pages très complexes, et sera simple pour les pages moins complexes.

CSP arrive dans FF 3.5 (c'est à dire très bientot). Quant aux autres navigateurs qui ne supportent pas la technologie : aucun changement pour eux, ils ignoreront les tags HTML et les en-têtes HTTP rajoutés par la technologie CSP (qui d'ailleurs posent des problèmes de confidentialité car les en-têtes utilisés s'approchent grandement du Referer, à suivre ...)

Le blog de Mozilla Security saura vous renseigner d'avantage
La page officielle du CSP, à lire en long, large et travers
Les groupes Mozilla Security

Encore une faille FaceBook (qui semble les collectionner), entre les dumps SQL (lisez ça c'est adorable), les possibles problèmes de leak et le total contrôle des données, les attaques phishing, les failles HTTP et applicatives ... Allez, quand même pas une XSS ou CSRF dans le futur, si ?
Non, ne m'envoyez pas d'invitation par pitié, je serai au regret de la refuser :'-(

Cette faille (comblée) exploite un paramètre de la requête HTTP afin de pouvoir lister les infos d'un membre les ayant rendues privées.
La vidéo est par là

On voit pas grand chose, si ce n'est l'extension tamper data de Firefox en action.

J'adore cette extension, car taper la requête HTTP dans telnet peut vite virer au casse-tête !
De plus, elle possède tout un tas de patterns XSS ou SQLInjection intégrés ainsi que d'autres options sympathiques.

Je rappelle tout de même que l'on teste avec sa propre sécurité sur ses propres serveurs n'est ce pas ? ;-)
Puis enfin concernant la faille, n'hésitez pas à schématiser votre application et tous ses points d'entrée. Validez les tous. Pour cela vous disposez de plusieurs niveaux : serveur (mod_security de Apache, règles htaccess ...) , hook d'entrée CGI comme l'extension ext/filter de PHP et ses paramètres ini, amont applicatif : objet de requête, ou encore dans les contrôleurs individuellement).

Voila une jolie injection SQL de type UNION.
Très classique, elle permet de découvrir peu à peu les champs d'une base, et de dumper des données d'une table qui n'était pas prévue dans la requête (à l'aide de CONCAT() ou ses amies).
Les screenshots sur la page parlent d'eux-mêmes, la source est http://www.generation-nt.com/orange-photo-mystere-piratage-faille-actualite-745141.html

Comme toute injection SQL, c'est très douloureux, et c'est clairement la preuve de négligence tant sur l'architecture Web que sur les requêtes SQL elles-mêmes.
Piqûre de rappel : je valide systématiquement toutes les entrées (pour PHP, on parle alors de $_GET, POST, COOKIE, FILES, et tout ce qui vient de HTTP dans $_SERVER).
Pour les requêtes SQL, on doit bien sûr valider/echapper les données d'entrée, ou carrément plus simplement utiliser des requêtes préparées qui interdisent toute injection, notamment des UNION.

l'OWASP Appsec conference s'est déroulée en Pologne récemment.

Je rappelle qu'il s'agit de conférences sur la sécurité du Web, voici plus d'infos sur l'OWASP (Open Web Application Security Project)

Bref, un repère de gourous de la sécurité, j'aimerai bien participer à leurs conférences un de ces quatre, quoiqu'il en soit, leurs slides sont désormais en ligne
Comme d'habitude, un vrai régal ;-)

Stephan Esser nous parle d'une faille d'inclusion de fichiers distants dans PHPBB.

Ca se passe ici pour les curieux

Bon ça parle de register globals et de trucs qu'on utilise plus depuis des années ...

Cependant, si vous suivez ce lien, vous verrez comment une petite (bon aller, une grosse certes) faille dans le code PHP peut mener à la catastrophe absolue : vol d'emails, dumps de tables SQL, récupération de mots de passes, tout y passe.

Il faut bien se souvenir que PHP + Apache est une porte d'entrée vers TOUT le système, via le port 80, si celui-ci est mal sécurisé.
Vous ouvrez vraiment une porte (80) de votre serveur vers l'extérieur, et vous faites tourner un programme derrière, ceci DOIT immédiatement vous faire poser la question "mais qu'est ce que le monde peut faire via cette porte 80 au juste ?"

Et PHP a du pouvoir : il possède des centaines de fonctions pouvant ouvrir la porte à n'importe qui, surtout lorsque le pirate a la source du script.
Evidemment, c'est sécurisable (Stephan Esser donne des solutions), encore faut-il le faire, et surtout évitez des scripts à risque comme celui incriminé.

Point de CSRF niveau sécurité ici, mais plutôt une évolution majeure du Web, et du protocole HTTP.
Aujourd'hui, un objet javascript ne peut accéder à tout ou partie d'une page hebergée sur un domaine différent de celui pour lequel l'objet a été crée.

C'est une règle de sécurité que l'on comprendra, mais qui bloque pas mal de développeurs "Web2.0", dont le but est justement un échange plus large de données.
On appelle cela le Same-Domain Policy (lisez ça si vous savez pas ce dont il s'agit).
Il existe évidemment plein d'astuces pour passer outre cette règle ( et créer des gros trous de sécurité, quoi vous n'êtes pas au courant?) : un proxy HTTP tout bête (c'est fait en 5 lignes de code ZendFramework, un peu plus en utilisant Apache directement), des fois même basés sur flash ou Silverlight

Le W3C a entendu l'appel et planche actuellement sur la modification des normes afin d'autoriser le cross site request, mais sous certaines conditions seulement. Le document intitulé "Access Control for Cross-Site Requests" est encore en version draft (brouillon), mais disponible ici et intéressera, à n'en point douter, tous les développeurs Web qui veillent, et aussi tous les aficionados de la sécurité du Web.

Scalp! est un analyseur de logs Apache qui sert dans la recherche de problèmes de sécurité et de tentatives d'intrusions, il est basé sur des requêtes du même style que celles du utilisées dans le projet PHP-IDS
Pour donner une idée, la commande ressemble à ca :

./scalp-0.4.py -l /var/log/httpd_log -f ./default_filter.xml -o ./scalp-output --html

Vous trouverez tout ce qu'il faut ici concernant ce projet