Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

Failles de sécurité des applications web


Sujet :

Sécurité

  1. #1
    Expert éminent sénior
    Failles de sécurité des applications web
    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

    Avant toute chose : lire le mode d'emploi du forum et ses règles.
    Je ne réponds pas aux questions techniques en MP.

  2. #2
    Modérateur

    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).
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  3. #3
    Membre expérimenté
    Citation Envoyé par grunk Voir le message
    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/addslashes-versus-mysql-real-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.

  4. #4
    Modérateur

    Citation Envoyé par 10_GOTO_10 Voir le message
    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.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Membre habitué
    Bonjour,

    Je vais apporter quelques précisions suite à la remarque
    Citation Envoyé par grunk Voir le message

    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.
    Guillaume HARRY
    Expertise bases de données et Java/J2EE

  6. #6
    Membre régulier
    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

  7. #7
    En attente de confirmation mail
    Citation Envoyé par tulipebleu Voir le message
    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/tutoriels/securite/failles-securite-application-web/ est dead (403)

  8. #8
    Expert éminent sénior
    Pour le lien c'est corrigé Une petite coquille oubliée
    Avant toute chose : lire le mode d'emploi du forum et ses règles.
    Je ne réponds pas aux questions techniques en MP.