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

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) … ^^

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 !

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

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).

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.

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

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é.