Discussion :

[imikado]

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

[fredoche]

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

[imikado]

Bonjour

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

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)

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

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é

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

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.

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

[fredoche]

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.

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.

[imikado]

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é

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

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

[heid]

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

Plus tard tentative d'intrusion technique et sociale.

[Grimly]

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.

[damienolive]

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