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

 

  1. #1
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 128
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 128
    Points : 19 197
    Points
    19 197
    Billets dans le blog
    17

    Par défaut La sécurité dans vos applications web

    Encore aujourd'hui, bon nombre de sites web contiennent des failles plus ou moins importantes: du Xss/Css* à l'injection sql* en passant par le Xsrf/Csrf* ou le nullbyte*.

    Certains framework proposent des solutions pour se protéger de quelques une de ses failles (filtres, prepare statement...) mais il faut le plus souvent penser à les utiliser.

    Même si en tant que développeurs on a plus ou moins connaissance de ce type de failles, nous ne sommes pas à l'abris d'un oubli ou d'une exploitation à laquelle on aurait pas pensé.

    Afin de se prémunir de ce genre de faille, vous pouvez selon votre budget :
    1. Demander un audit de sécurité de votre application à une société, celle-ci peut à la fois vérifier l'application sans compte de connexion (pour tenter de forcer l'authentification, le XSS, sql injection...) mais également avec un compte pour tester en plus le XSRF et l'isolation des données. L'infrastructure peut également faire l'objet d'un audit (non affichage des informations sur les versions des serveurs, ports ouverts...)
    2. Utiliser certains outils automatiques (gratuit ou payant) comme Acunetix, Xsser ou Xelenium, malheureusement ceux-ci sont souvent plus ou moins limités et ne permettent pas de tester l'isolation des données*
    3. Spécialiser un ou plusieurs développeurs dans votre service afin que ceux-ci fassent des audits de sécurités sur les applications qu'ils n'ont pas développé.


    Et vous ?

    Quels solutions avez-vous choisi pour sécuriser vos applications web ?

    Notes de bas de page :

    *isolation des données: le compte 1 ne doit pas voir/modifier/supprimer les données du compte 2 en modifiant l'url (toujours vérifié le propriétaire des données affichées/modifiées)
    *Xss/Css : Cross-site Scripting
    *Xsrf/Csrf : Cross-site Request Forgery Cross-site_request_forgery
    *nullbyte injection
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  2. #2
    Membre émérite
    Profil pro
    Inscrit en
    décembre 2003
    Messages
    1 221
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 221
    Points : 2 617
    Points
    2 617

    Par défaut

    Bonjour

    Je suis en plein dedans.

    Je vais devoir mettre en œuvre une nouvelle version d'une vielle application, et le procédure d'audit désormais chez mon client suppose un "penetration test" de l'appli. Pas de compte à fournir mais une interface de staging (préprod) mise à dispo et l'ouverture aux IPs de l'auditeur.

    La solution pour moi qui cumule déjà plein de casquettes (chef de projet, dev, responsable tech...)et qui ne peut être spécialiste en des tas de domaines tous pointus, c'est d’utiliser les outils de pen test proposés ici et là, et de les appliquer de manière systématique sur mon appli en situation de production, et de corriger en fonction des résultats générés.

    En tant que référence il me semble que OWASP est un incontournable :
    https://www.owasp.org

    cette organisation propose un outil de pentest plutôt complet et bien fichu - OSWAP ZED :
    https://www.owasp.org/index.php/OWAS..._Proxy_Project
    (l'interface est en français)

    En complément des outils comme nmap sont intéressants

    Et une recherche sur les "exploit" (terme anglophone : to exploit - exploiter une faille en l'occurence) peut s'avérer très utile.
    Pour cela j'utilise CVE details qui me semble très exhaustif, regroupant les alertes du NIST ou de sources comme exploit-db.com :
    http://cvedetails.com/

    Sur cette base il ne faut pas hésiter à interroger sur tous les composants logiciels que vous mettez en œuvre pour réaliser votre service. Les backdoors sont parfois là où on ne les attend pas, hors de votre propre code.

    Pour mes tests et mes mises à l'épreuve j'utilise un serveur de dev avec des copies complètes de mes bases de production. Pour être dans la mesure du possible le plus proche des conditions réelles : même infra, même serveur, même firewall, mêmes données...

    En principe à la fin de l'audit client, j'aurai un rapport avec un go-no go en fonction de la criticité des exploits, et des demandes de correction pour ce qui peut être traité après la mise en prod.
    je peux représenter mon appli une fois les problèmes corrigés, mais on va espérer que ce ne sera pas nécessaire

  3. #3
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 128
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 128
    Points : 19 197
    Points
    19 197
    Billets dans le blog
    17

    Par défaut

    Bonjour
    Citation Envoyé par fredoche Voir le message
    Pas de compte à fournir mais une interface de staging (préprod) mise à dispo et l'ouverture aux IPs de l'auditeur.
    Bien mais incomplet: la mise à disposition de comptes permet plusieurs choses:
    1. tester l'isolation des données
    2. vérifier la politique de blocage de compte en cas de mauvais login/mot de passe


    Citation Envoyé par fredoche Voir le message
    La solution pour moi qui cumule déjà plein de casquettes (chef de projet, dev, responsable tech...)et qui ne peut être spécialiste en des tas de domaines tous pointus, c'est d’utiliser les outils de pen test proposés ici et là, et de les appliquer de manière systématique sur mon appli en situation de production, et de corriger en fonction des résultats générés.
    C'est bien mais insuffisant (comme expliqué plus haut): les outils automatiques permettent de détecter facilement certaines failles, mais rien ne vaut un "humain" comprenant un minimum l'application pour verifier des failles d'intrusions , des corruptions de données "métier" voir des attaques xsrf (même si pour l'xsrf certaines applications font des tests de rejeu)

    Citation Envoyé par fredoche Voir le message
    En tant que référence il me semble que OWASP est un incontournable :
    https://www.owasp.org
    Effectivement, j'aurai du le cité dans mon topic

    Citation Envoyé par fredoche Voir le message
    cette organisation propose un outil de pentest plutôt complet et bien fichu - OSWAP ZED :
    https://www.owasp.org/index.php/OWAS..._Proxy_Project
    (l'interface est en français)
    En complément des outils comme nmap sont intéressants
    Oui, mais comme dit plus haut: insuffisant pour des audits complets de sécurité

    Citation Envoyé par fredoche Voir le message
    Et une recherche sur les "exploit" (terme anglophone : to exploit - exploiter une faille en l'occurence) peut s'avérer très utile.
    Pour cela j'utilise CVE details qui me semble très exhaustif, regroupant les alertes du NIST ou de sources comme exploit-db.com :
    http://cvedetails.com/
    Bonne initiative en effet, la veille fait partie de la sécurisation

    Citation Envoyé par fredoche Voir le message
    Sur cette base il ne faut pas hésiter à interroger sur tous les composants logiciels que vous mettez en œuvre pour réaliser votre service. Les backdoors sont parfois là où on ne les attend pas, hors de votre propre code.
    En effet, il est pertinent que l'environnement audité soit au plus proche de la situation de production.

    Citation Envoyé par fredoche Voir le message
    En principe à la fin de l'audit client, j'aurai un rapport avec un go-no go en fonction de la criticité des exploits, et des demandes de correction pour ce qui peut être traité après la mise en prod.
    je peux représenter mon appli une fois les problèmes corrigés, mais on va espérer que ce ne sera pas nécessaire
    Selon les détails de la prestations vous pouvez non seulement avoir le rapport avec les failles et leur criticité mais également un rendez-vous pour expliquer en détail la manière utilisée pour exploitée ces failles ainsi (et c'est parfois nécessaire) un deuxième passage post-correction afin de valider la bonne correction des failles
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  4. #4
    Membre émérite
    Profil pro
    Inscrit en
    décembre 2003
    Messages
    1 221
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 221
    Points : 2 617
    Points
    2 617

    Par défaut

    Citation Envoyé par imikado Voir le message
    Bonjour

    Bien mais incomplet: la mise à disposition de comptes permet plusieurs choses:
    1. tester l'isolation des données
    2. vérifier la politique de blocage de compte en cas de mauvais login/mot de passe
    Pour le coup, c'est le client qui paie la boite chargée de l'audit, et qui décide du niveau de vérification.
    Mais pour le point 2, tu as droit à 3 tentatives avant blocage du compte, déblocage seulement par un admin.



    Citation Envoyé par imikado Voir le message
    Bonjour
    C'est bien mais insuffisant (comme expliqué plus haut): les outils automatiques permettent de détecter facilement certaines failles, mais rien ne vaut un "humain" comprenant un minimum l'application pour verifier des failles d'intrusions , des corruptions de données "métier" voir des attaques xsrf (même si pour l'xsrf certaines applications font des tests de rejeu)
    Je l'ai mal exprimé mais c'est un métier en soi que de faire de l'audit de sécurité.
    Donc évidemment tout ceci est insuffisant, mais le cumul de casquettes (ou de fonctions) a aussi ses limites, et je m'improvise pas "expert sécurité" en quelques jours, au moment où on m'annonce cet audit, ou même avant cela.
    Je vois pour mon cas que l'on me demande de cumuler plusieurs fonctions qui pour d'autres boites mieux dotées sont des rôles distincts et spécialisés. C'est difficile d’exceller dans tous domaines quand on te demande d'être un bon généraliste.
    Je prépare et j'anticipe au mieux, en fonction des moyens que l'on me donne.

    Tu noteras que je réponds simplement à ta question : "Et vous, quels solutions avez-vous choisi pour sécuriser vos applications web ?"
    Je n'ai pas la prétention d'être un modèle sur le sujet.

    Cela dit cela fait longtemps que je prends ce problème en considération, puisque je ne peux pas bénéficier de la dilution de responsabilité (c'est pas moi c'est l'autre), je préfère prévenir que guérir, dans la limite des moyens qui me sont accordés.

  5. #5
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 128
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 128
    Points : 19 197
    Points
    19 197
    Billets dans le blog
    17

    Par défaut

    Citation Envoyé par fredoche Voir le message
    Pour le coup, c'est le client qui paie la boite chargée de l'audit, et qui décide du niveau de vérification.
    Mais pour le point 2, tu as droit à 3 tentatives avant blocage du compte, déblocage seulement par un admin.
    Très bien, mais attention avec ce système au DoS (en boucle le hacker fait "exprès" de bloquer le plus de compte possible pour bloquer l'activité


    Citation Envoyé par fredoche Voir le message
    Je l'ai mal exprimé mais c'est un métier en soi que de faire de l'audit de sécurité.
    Donc évidemment tout ceci est insuffisant, mais le cumul de casquettes (ou de fonctions) a aussi ses limites, et je m'improvise pas "expert sécurité" en quelques jours, au moment où on m'annonce cet audit, ou même avant cela.
    Je vois pour mon cas que l'on me demande de cumuler plusieurs fonctions qui pour d'autres boites mieux dotées sont des rôles distincts et spécialisés. C'est difficile d’exceller dans tous domaines quand on te demande d'être un bon généraliste.
    Je prépare et j'anticipe au mieux, en fonction des moyens que l'on me donne.

    Tu noteras que je réponds simplement à ta question : "Et vous, quels solutions avez-vous choisi pour sécuriser vos applications web ?"
    Je n'ai pas la prétention d'être un modèle sur le sujet.
    Je comprends que vous ayez des limitations budgétaires ou de temps, j'indique juste pour rappel que les outils automatiques sont une bonne chose mais qu'ils ne suffisent pas à sécuriser l'application.
    C'est plus un rappel

    Citation Envoyé par fredoche Voir le message
    Cela dit cela fait longtemps que je prends ce problème en considération, puisque je ne peux pas bénéficier de la dilution de responsabilité (c'est pas moi c'est l'autre), je préfère prévenir que guérir, dans la limite des moyens qui me sont accordés.
    C'est une bonne chose, continuez à progresser sur le sujet, si en tant que développeur vous avez déjà bien en tête les recommandations à appliquer c'est déjà des failles qui pourront être évités
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  6. #6
    Membre confirmé Avatar de heid
    Profil pro
    Inscrit en
    mai 2002
    Messages
    385
    Détails du profil
    Informations personnelles :
    Localisation : France, Indre et Loire (Centre)

    Informations forums :
    Inscription : mai 2002
    Messages : 385
    Points : 581
    Points
    581

    Par défaut

    Audit de sécurité fait par un presta externe avant la mep.

    Plus tard tentative d'intrusion technique et sociale.

  7. #7
    Membre averti

    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2013
    Messages
    88
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2013
    Messages : 88
    Points : 444
    Points
    444
    Billets dans le blog
    1

    Par défaut

    Il faut réussir à définir la sécurité en plus de la souhaiter.

    J'ai déjà vu des demandes de la MOA qui passent à travers des consignes de sécurités pourtant évidentes. Les remarques n'y faisant rien face au porte monnaie, les failles existent.

  8. #8
    Membre régulier
    Homme Profil pro
    Développeur .NET
    Inscrit en
    juin 2013
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2013
    Messages : 47
    Points : 111
    Points
    111

    Par défaut

    Bonjour,

    Tout dépend de la charge prévue pour la partie sécurité d'une application.

    Mais de façon générale, la mise en place d'une stratégie de sécurité se compose en diverses étapes :

    Phase de conception -> Analyse des points qui seront les plus sensibles et les plus faillibles (upload de fichier, gestion de compte utilisateur...)

    Phase de développement -> Mise en place de bonnes pratiques (strip tags, quote...)

    Phase de recette -> Test de sécurité avec (acunetix par exemple) ET sans outils.

    Enfin, toujours se souvenir du principe suivant : NTUI (Never Trust User Input)
    Il faut toujours penser à vérifier les saisies utilisateurs (client ET serveur) même sur les champs qui ne sont pas identifiés comme sensibles

Discussions similaires

  1. Réponses: 6
    Dernier message: 27/08/2016, 14h08
  2. Réponses: 1
    Dernier message: 26/01/2015, 17h13
  3. Quelle place occupe la sécurité dans vos applications ?
    Par Hinault Romaric dans le forum Actualités
    Réponses: 20
    Dernier message: 10/08/2013, 14h36

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