IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

    Avatar de FirePrawn
    Homme Profil pro
    Consultant technique
    Inscrit en
    Mars 2011
    Messages
    3 179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Consultant technique

    Informations forums :
    Inscription : Mars 2011
    Messages : 3 179
    Points : 19 374
    Points
    19 374
    Par défaut 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
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 690
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 690
    Points : 20 211
    Points
    20 211
    Par défaut
    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é Avatar de 10_GOTO_10
    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    885
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2004
    Messages : 885
    Points : 1 522
    Points
    1 522
    Par défaut
    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/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.

  4. #4
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 690
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 690
    Points : 20 211
    Points
    20 211
    Par défaut
    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é
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Avril 2007
    Messages
    135
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études

    Informations forums :
    Inscription : Avril 2007
    Messages : 135
    Points : 193
    Points
    193
    Par défaut
    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
    Profil pro
    Inscrit en
    Mars 2003
    Messages
    138
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2003
    Messages : 138
    Points : 120
    Points
    120
    Par défaut
    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
    Homme Profil pro
    Inscrit en
    Février 2013
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Février 2013
    Messages : 35
    Points : 37
    Points
    37
    Par défaut
    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/tutoriel...plication-web/ est dead (403)

  8. #8
    Expert éminent sénior

    Avatar de FirePrawn
    Homme Profil pro
    Consultant technique
    Inscrit en
    Mars 2011
    Messages
    3 179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Consultant technique

    Informations forums :
    Inscription : Mars 2011
    Messages : 3 179
    Points : 19 374
    Points
    19 374
    Par défaut
    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.

Discussions similaires

  1. Réponses: 1
    Dernier message: 23/02/2015, 10h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo