Discussion :

[FirePrawn]

Bonjour à tous !

Je vous propose un article sur le principe des failles de sécurité des applications par Guillaume HARRY : Failles de sécurité des applications web.

N'hésitez pas à faire part de vos remarques, commentaires ou propositions d'améliorations !

Failles de sécurité des applications web

[grunk]

Je me permet d'intervenir sur la partie III-B-3 concernant les injections. Les parades et bonnes pratiques présentées sont incorrectes et ne devraient pas être présentées ainsi dans un document tout public.

1- Htmlspecialchars ne protège en rien des injections sql. On ne l'utilise d'ailleurs par à l'enregistrement mais plus généralement à l'affichage pour se protéger des faille XSS (on lui préfèrera même htmlentities).

2- Le minimum pour la protection des injections est l'utilisation des fonctions de base du sgbd du type mysql_real_escape_string qui va échapper les caractères à risque du type de :

NULL, \x00, \n, \r, \, ', " et \x1a

Dans l'idéal on utilisera des requêtes préparées via PDO ou mysqli , qui sont actuellement la solution la plus sure pour se prémunir des injections sql.

A ces requêtes préparées il faut impérativement ajouter une validation et/ou un filtrage des données utilisateur (c'est précisé dans l'article) via des fonctions telles que filter_input ou intval(), floatval() ...

---edit---

je poursuis ma lecture et tombe sur la partie csrf

Encore une fois la solution proposée est au mieux insuffisante :

Pour se protéger, il faut utiliser uniquement des requêtes POST

POST ou GET c'est tout pareil , si ce n'est que PSOT est un poil plus difficile à modifier.
Pour se protéger des failles csrf il y'a deux actions :

1- Utiliser un token unique pour chaque action à risque. De cette manière un attaquant qui enverrai un formulaire à la place d'un utilisateur n'aurai pas le token qu'aurai du générer l'utilisateur si il avait été effectivement sur la page de formulaire.

2- Demander une validation utilisateur pour chaque action a risque. Au lieu de supprimer directement une valeur , je demande la confirmation à l'utilisateur.

J’arrête ma lecture là pour le moment, mais ce guide me semble un peu léger en solution technique (la présentation des attaques quant à elle est très clair).

[10_GOTO_10]

Dans l'idéal on utilisera des requêtes préparées via PDO ou mysqli , qui sont actuellement la solution la plus sure pour se prémunir des injections sql.

L'idéal ? Pas tout à fait: http://shiflett.org/blog/2006/jan/ad...-escape-string

I can successfully inject a single quote despite your escaping. (...) I'm going to use MySQL 5.0 and PHP's mysqli extension for this demonstration.

[grunk]

L'idéal ? Pas tout à fait: http://shiflett.org/blog/2006/jan/ad...-escape-string

Il utilise pas de requête préparée dans son article, il conseil d'ailleurs de le faire :

To avoid this type of vulnerability, use mysql_real_escape_string(), prepared statements, or any of the major database abstraction libraries.

Après effectivement ce n'est pas l'idéal puisque les requêtes préparées sont sans doute plus consommatrices de ressources et sont à la base conçues pour les requêtes que l'on répète de nombreuses fois avec des paramètres différents.

L'idéal c'est de filtrer , et retyper autant que possible les données reçues de l'utilisateur.

[billharry]

Bonjour,

Je vais apporter quelques précisions suite à la remarque

1- Htmlspecialchars ne protège en rien des injections sql. On ne l'utilise d'ailleurs par à l'enregistrement mais plus généralement à l'affichage pour se protéger des faille XSS (on lui préfèrera même htmlentities).

Dans le document, il n'est pas dit que htmlspecialchars est la solution.
Il est simplement dit que les caractères spéciaux sont une source potentielle de risque et que pour se protéger

il faut transformer au moins les caractères (...) en code HTML avant de les stocker dans la base de données.

Htmlspeciachars est alors une fonction qui permet de le faire et qui n'est pas dépendante du sgbd. mysql_real_escape_string() est certainement mieux indiquée dans le cas de mysql.

[tulipebleu]

Bonjour,

L'état de l'art pour le cryptage des mots de passes, c'est PBKDF2. Il faut mettre au moins 4096 itérations, comme WPA (IOS4 utilise 10.000 itérations).

PBKDF2 à l'épreuve du FBI

[Clorge]

Bonjour,

L'état de l'art pour le cryptage des mots de passes, c'est PBKDF2. Il faut mettre au moins 4096 itérations, comme WPA (IOS4 utilise 10.000 itérations).

PBKDF2 à l'épreuve du FBI

Mais merde, HASHAGE pas cryptage! je vais avoir mon pseudo sur toutes les résultats de google à force de corriger les gens sur ça...

en plus, http://xhtml.developpez.com/tutoriel...plication-web/ est dead (403)

[FirePrawn]

Pour le lien c'est corrigé Une petite coquille oubliée