Julien Pauli DevPHP blog

L’application Google Docs est victime d’une faille XSS. Le filtre XSS ne semble pas bien gérer l’enclavement de balises, laissant passer une balise <script> dans un <textarea> Le code suivant est faillible : <textarea><a href="http://www.site.com/</textarea><script>alert(‘xss’)</script>"></textarea> On voit bien qu’il est difficile de filtrer les balises lorsqu’on accepte une édition Wysiwyg sur une page. Ici une balise <a> mal fermée permet l’injection. Le code HTML étant très permissif en plus, ca facilite les choses. Le POC […]

C’est un ami qui m’a fournit l’URL, c’est très drole. Via http://www.angela-merkel.de/index.php?mode=ueberzeugungen&page=../../../../../../../../../../../../../../usr/local/apache/conf/httpd.conf%00 il était ( c’est corrigé ) possible d’afficher le httpd.conf du serveur. Une attaque par inclusion de chemin relatif qui nous permet de rappeller que toute entrée dans un script, quelquesoit sa provenance, doit être systématiquement validée. On peut aussi s’apercevoir que l’utilisateur Apache possède les droits en lecture dans le repertoire d’Apache, ce qui est signe d’une grosse faiblesse niveau sécurité. A […]

le site xssed.com archive une impressionnante bibliothèque de hacks XSS en tous genres. Très très impressionnant, on y découvre defense.gouv.fr, yahoo, myspace, msn, youtube, bbc, cnn, aol ; et bien d’autres géants tous aussi vulnérables les uns que les autres. Je rappelle que le Cross Site Scripting est actuellement une des menaces les plus dangereuses qui existe dans le monde du web, elle permet notamment le défacement de sites, le vol d’identité et d’informations personnelles, […]

Phishing, vol d’identité, de coordonnées bancaires, sont autant de problème de sécurité qui émergent de nos jours. Nous utilisons tous Internet tous les jours, et celui-ci est devenu vecteur d’attaques très modernes, visant le plus souvent à soutirer de l’argent, des informations (très) personnelles , ou se faire passer pour quelqu’un d’autre; et ceci sans jamais qu’on puisse s’en apercevoir, à notre insu complètement. La sécurité web affecte aussi la renommée d’une entreprise et peut […]

On le dit souvent en conférence, c’est une recommandation de sécurité importante : Ne laissez pas display_error à On sur un serveur en production. Logguez les erreurs, mais ne les affichez jamais. Regardez un peu le nombre d’informations que vous fournissez sur votre appli quand vous affichez les erreurs, un exemple avec Clubic : Clubic se dévoile à l’exterieur On sait que vous êtes sous Mysql ( du moins en partie ). On aperçoit un […]

Ilia Alshanetsky relaye une info interessante concernant IE et la redirection POST : Tout le monde sait faire une redirection GET. Et bien la même chose peut être faite via la méthode POST, et de manière totallement transparente, sous IE en tout cas. Ce fait ne représente pas en soi une menace, mais associer à un peu de XSS, et là, c’est plus pareil… Imaginons un utilisateur qui envoie un formulaire en POST. Une faille […]

Samy, c’est l’histoire d’un jeune homme de 19ans, qui en Octobre 2005 lançait un ver qui a marqué l’histoire d’Internet. Le premier ver javascript basé sur XHR capable de s’auto propager à une vitesse phénoménale. Depuis,Samy a été jugé et a écopé de 3 années de mise à l’épreuve et de 90 jours de travaux d’intérêts généraux. Il a également été condamné à payer des dommages et intérêts à MySpace et n’a plus le droit […]

Il n’est pas rare de voir trainer sur le web, des formulaires de ce style là : <form method="POST" action="mailing.php"> A: webmaster@monsite.com De: <input type="text" name="expediteur"> Sujet : <input type="text" name="sujet"> Message : <textarea name="message" rows="10" cols="60" lines="20"></textarea> <input type="submit" name="send" value="Envoyer"> </form> <?php // mailing.php : $to="webmaster@monsite.com"; $from=$_POST["expediteur"]; if (mail($to,$_POST["sujet"],$_POST["message"],"From: $from\n")){ echo "Votre mail a bien été envoyé à $to"; }else{ echo "Votre mail n’a pas pu être envoyé."; } ?> Et bien ce […]

Tout le monde connait ( j’espère ), la règle ultime du « never trust foreign data », entendez par là ne faites confiance à aucune donnée externe. On peut aussi falsifier $_SERVER, il n’echappe pas à la règle ( modification de la requête http manuellement par exemple ). Et bien, n’echappe pas à la règle aussi, $_SERVER[‘PHP_SELF’], oui, cette variable est vulnérable, et vous allez voir qu’il n’est pas compliqué de la fausser Prenons un exemple tout […]