SecureM: Sécurisez vos sites !

[Mickaël]

Bonjour tout le monde

Vous avez sûrement pour la plupart, créé un jeu en ligne en PHP. Mais vous êtes-vous préoccupé de sécuriser votre code et votre site ? Généralement non.
Et malheureusement, vous ferez peut-être partie d'un des nombreux sites piratés chaque mois : ça peut être simplement votre jeu qui "déconne" ou qui fonctionne bizarrement, ou bien un joueur qui se retrouve subitement avec un niveau ou des ressources très élevés, voire encore quelque chose de pire : un hacker peut s'introduire discrètement sur votre serveur pour l'utiliser ensuite contre d'autres sites. Et allez raconter au FBI que c'est pas vous qui avez attaqué le site du Pentagone ! (bon là par contre je vais un peu loin XD)

La sécurité d'un site est très importante, et il vous faut acquérir des habitudes de codage plus sûres que celles que vous avez déjà. C'est pour ça que j'ai créé un petit site qui vous permettra de prendre connaissance des failles les plus courantes et de comprendre comment les corriger.
Ce (modeste) site est, sans plus attendre, disponible à l'adresse http://www.securem.eu/ (eh oui, .eu comme Europe)

N'hésitez pas, ça ne pourra que vous aider =D

Nous proposons aussi un audit de sécurité gratuit (pour les plus téméraires d'entre vous ) où votre site sera mis à l'épreuve.
Cependant, la gratuité de l'audit ne vous garantit pas des délais courts ou bien la certitude que personne ne pourra pirater votre site si je vous dis que je n'ai rien trouvé.

Sur ce, amusez vous bien

[Thedeejay]

bonjour!
tres bonne initiative que la prévention!
seul probleme... si tu est si fort en sécuité, comment ai-je pu acceder à cette page => http://www.securem.eu/admin/auth.php (désolé, mauvaix reflexe x) )
Sinon bien documenté, super!
N'oublie pas d'aller te présenter

[wild-D]

seul probleme... si tu est si fort en sécuité, comment ai-je pu acceder à cette page => http://www.securem.eu/admin/auth.php (désolé, mauvaix reflexe x) )

accéder à cette page est sans intérêt temps que tu passe/contourne pas l'authentification. (sans parler que tu n'as pas encore prouver que ce n'était pas un fake^^ -parce que le meilleur moyen de ce débarasser du hackers c'est pas de rien lui mettre sous la dents, il cherchera encore; mais au contraire de lui donner un truc à mordre... qui soit innoffensif :good:-).

[Sephi-Chan]

Le contenu est intéressant. Bonne initiative.

Ça peut pas mal aider les débutants, mais également des gens plus expérimentés (au niveau de XSS et CSRF, notamment).

Quelque chose qui me désole un peu, c'est quand je vois les débutants faire des htmlentities() (et autres fonctions) du genre à tout va en pensant que ça sécurise. Parfois on en voit pour filtrer les données qui entrent en base de données, alors que ce sont plutôt des fonctions destinée à l'affichage. En général, c'est parce qu'ils ont vu ça sur certains sites destinés aux débutants. J'espère que votre site parlera de ça.

Par contre, en lisant un article, j'ai lu des histoires de prises de contrôle. Ce genre de phrase — en plus d'effrayer le lecteur non averti — est un peu cliché, on n'est pas dans James Bond. On peut plutôt parler d'élévation de privilèges ou de vol de sessions.

En somme, je trouve que c'est un bon début et je vous souhaite bonne chance pour la suite.

Concernant l'accès à la page d'administration de Dotclear, ça n'est pas grave. T'authentifier en tant qu'administrateur risque d'être plus difficile. D'autant que dans certains cas, la page peut être un leurre.


Sephi-Chan

[Mickaël]

Merci à tous pour vos commentaires.

Première remarque, comme ça a déjà été dit Thedeejay, accéder à cette page n'est pas du tout une faille de sécurité. Et pis c'est pas moi qui ai créé DotClear je te rappelle ^^... Et niveau mauvais réflexes je te rassure, c'est un très bon réflexe qui m'a permis d'accéder à l'administration de mon lycée >< (et donc de modifier notes, bulletins, absences, de lire les mails de l'administration et autres joyeusetées - pour information j'ai rien touché et j'ai fini par rapporter la faille).

Merci à vous, et pour ce qui est de ce que Sephi-Chan a parlé, je vais peut-être écrire quelque chose à propos des réflexes à avoir lors de l'élaboration d'un site, notamment pour l'utilisation des fonctions sus-citées...

Et personnellement, je suis plus adepte du "Big Brother is watching you" que des leurres : sur mes sites chaque action "étrange" est enregistrée et analysée. Cela constitue parfois un alourdissement du code, mais c'est assez marrant de voir les résultats...

[Thedeejay]

Theddeyaj est daccord avec toi x) (c'est dingue personne ne sait ecrire mon pseudo! j'ai le doit à Deejay, the dee jay TheDJ... mais pas Thedeejay, non!)
mais je sais que ce n'est pas une grande faille de toute facons

[Mickaël]

Ouuups je suis désolé
Remarque moi avant c'était Micky, j'ai eu le droit à Mickey une fois XD

[tog84]

Tout d'abord merci pour ton site qui m'a permis d'éclaircir quelques points théoriques.
Beaucoup de site disent comment se protéger mais très peu dans un langage clair et accessible.

Cependant, j'aurai deux petites questions :

La première question, c'est sur la fonction mysql_real_escape_string().
Laquelle de c'est deux requêtes est la mieux à faire au niveau sécurite et surtout pourquoi ?

Code PHP :

<?php 

$firstname = 'fred';

$lastname  = 'fox';



$query = sprintf("SELECT firstname, lastname, address, age FROM friends WHERE firstname='%s' AND lastname='%s'",

    mysql_real_escape_string($firstname),

    mysql_real_escape_string($lastname));



$result = mysql_query($query); 

[Mickaël]

Bonsoir

A propos de la fonction mysql_real_escape_string(), les deux utilisations reviennent au même (à moins que sprintf ait un comportement particulier, mais je ne crois pas). Cependant ça peut devenir gênant si tu utilises un jour ce script sur un serveur où les magic_quotes sont activées : tes chaînes seront échappées deux fois et tu te retrouveras avec des "j\\\'ai mangé" au lieu de "j\'ai mangé".
N'oublie pas que tu peux te documenter sur le site officiel de PHP: http://fr2.php.net/manual/fr/function.my...string.php
Il y a des exemples, notamment pour éviter l'effet indésirable dont j'ai parlé.

Pour ce qui est de strip_tags et de htmlentities, personnellement je crois que ça tient la route même si il faudrait connaître le code derrière.
Il faut que lorsque tu stocke la valeur de l'utilisateur, elle soit bien protégée avec les mysql_real_escape_string, sinon tu es vulnérable aux injections SQL. strip_tags te protège contre les injections XSS de base, mais htmlentities reste aussi indispensable et complémentaire.
L'avantage de htmlentities, c'est tu n'as plus à te soucier des problèmes d'encodage

Cordialement

[Sephi-Chan]

Salut Tog,

Concernant les deux scripts PHP, ils sont identiques sur le résultat.
J'ai une préférence pour le premier qui est plus concis tout en étant plus clair et économique.
Par contre, travaille toujours avec les magic_quote à off. Je te laisse te documenter sur le Google, tu trouveras sans soucis.

Concernant l'insertion de données, j'évite généralement de dénaturer les insertions, et donc de n'utiliser les filtres qu'à l'affichage. Donc en l'occurrence, strip_tags() uniquement, puisque le htmlentities() ne sert plus si tu as déjà purgé les balises. A toi de voir si tu veux afficher un balisage qui ne sera pas interprété (ce que l'on obtient en retour de htmlentities()) ou bien des balises supprimées (cas de strip_tags()).

$str = "<balise>Jambon fumé</balise>";



// Affiche <balise>Jambon fumé</balise> dans le code source, ce qui donne "Jambon fumé" à l'écran.

echo '<p>', $str, '</p>'; 



/**

 * Affiche <balise>Jambon fumé</balise> à l'écran (car mes pages sont en 

 * UTF-8 et par défaut, htmlentities retourne une chaîne encodée en ISO-8859-1).

 */

echo '<p>', htmlentities($str), '</p>'; 



// Affiche <balise>Jambon fumé</balise> à l'écran.

echo '<p>', htmlentities($str, null, 'UTF-8'), '</p>';



// Affiche Jambon fumé à l'écran et dans le code source.

echo '<p>', strip_tags($str), '</p>';

Donc pour ma part, et en partie pour des raisons d'esthétique, je préfère strip_tags().

J'en profite quand même pour souligner que contrairement à ce qui est dit, htmlentities() (et htmlspecialchars(), d'ailleurs) doit être utilisé différemment selon l'encodage. C'est également pour ça que je leur préfère strip_tags().


Sephi-Chan