Discussion :

[kmdkaci]

Les formulaires des sites web se transforment facilement et souvent aux "portes dérobées" (backdoor). Les pirates informatiques profitent de ces tunnels vers le serveur pour l'attaquer ou prendre son contrôle.
Dans cet article, je vous présente quelques techniques qui vous permettent de cibler des serveurs via des failles vulnérables que véhiculent les formulaires. Le but de cette article n'est pas de vous initier à des pratiques malsaines, mais de vous sensibiliser à devenir vigilant et ne pas négliger le coté sécuritaire du projet, qui est très important à mes yeux.

Vous trouverez dans cet article la description de ces quelques failles et des solutions présentées dans un environnement Java, mais aussi applicables à d'autres environnements.

• Principe des spams, ou comment les créer et se protéger.
• Attaque par Injection SQL
• Attaque par bommbing
• Outrepasser un formulaire d'authentification
• Exemple de décryptage d'un mot de passe via un réseau surveillé.
• Divers

je vous présente aussi quelques outils nécessaires aux développeurs, tels que les plugins de manipulation et traçage de pages web. Ainsi que le fameux programme webgoat afin de suivre des leçons de piratage, afin de mieux se protéger des pirates.

le lien pour l'article est : http://kmdkaci.developpez.com/tutori...s-formulaires/

Vous avez une critique, une suggestion ou tout simplement un commentaire, n'hésitez pas

[tchize_]

III-A-2. Halte au spam via les formulaires
Un exemple du formulaire avec ta classe custom captcha serait bienvenu, en pointant du doigt d'éviter une erreur déjà vue: mettre le texte du captch en champ hidden pour "avoir plus facile" lors de la validation ^^ (mais qui fout en l'air le principe, puisque le bot a juste à lire le champ hidden). Une note aussi concernant le fait que le captcha n'est pas une protection absolue serait bienvenue. Les bots arrivent a lire avec plus ou moins de succès le captcha. Mais c'est un bot, donc c'est pas grave, si il doit faire 500 submits avant de réussir un captcha, il n'hésitera pas à le faire, ca lui prendra une minute max.

Section III-B. Attaque par injection SQL

j'essaie toujours de m'en remettre (mon pauvre coeur). Corrige moi ca tout de suite. Tu présente bien ce qu'est une injection SQL (exemple du mot de passe), mais tu propose d'utiliser la validation (manuelle ou avec framework) comme solution . Et pourquoi par un firewall tant qu'on y est pour ça? La validation est une illusion de sécurité dans ce cas précis. En effet, qui te garantit que tu aura pensé à tout. Ca me fait penser un peu au magic quotes de PHP, ou on a découvert à une époque qu'il n'échappais pas, si je me souviens bien, la quoté ouvrante simple typographique. Et que les serveur SQL microsoft acceptaient ça comme délimiteur de texte. Résultat, la combinaison des deux amenait à une injection possible.

Le pire c'est que je vois mal comment, suivant ton exemple, la validation aurait prévenu l'injection. Comment veux-tu valider un mot de passe? Par définition l'utilisateur y tappe ce qu'il veux! Si mon mot de passe contient des guillemets, pourquoi pas?

Pas une seule trace de la, à peu près, seule méthode valable de se prévenir des injection SQL: quoi qu'il arrive, ne *jamais*,*jamais*,*jamais* concaténer des données entrées par l'utilisateur à une requete SQL. Utilisez toujours des prepared statements

IV-D-1. Exemple d'utilisation : Décryptage d'un mot de passe
Tu suggère que faire l'identification en hashant le mot de passe est un gage de sécurité, c'est faux! Ce texte manque de détails, ca n'en sera un que si ça garantit la non reproductibilité du flux de données. Sinon, moi, méchant pirate, j'ai juste a reprendre ce que j'ai capté sur le flux réseau, le reproduire à l'identique et hop, je suis authentifié (dans le cas présenté, je désactive javascript, j'utilise firebug pour rendre mes champs hidden éditables et je met directement dans les champs md5 le hash que j'ai capté sur le flux, aucune sécurité rajoutée, juste l'illusion de la sécurité) Au minimum, il faut concaténer au mot de passe une clé de hashage qui varie a chaque requete.

Une précision aditionnelle sur le fait que le https avec un certificat valide est le seul protocole qui te garantira que tu cause bien au bon serveur et plus de ne pas être écouté serait bienvenue.


Dans l'ensemble je trouve que l'article a beaucoup de code par rapport au texte et que, d'aspect général, ca manque de rigueur (cf points ci-dessus). En sécurité, tenter d'enseigner des bonnes pratique sans rigueur c'est risquer de faire passer un développeur de "j'ai rien fait pour sécuriser mon application" à "je suis persuadé que mon application est sécurisée alors que je l'ai fait de travers", et ça c'est dangereux.

Intéressant, au passage, la présentation d'outils pour s'auto pirater

[kmdkaci]

Bonjour,
Je vais essayer de répondre à quelques points que tu as décris.

III-A-2. Halte au spam via les formulaires
Un exemple du formulaire avec ta classe custom captcha serait bienvenu

Un exemple complet ? J’ai relaté les bases d’un captcha, après c’est au développeur de creuser d’avantage pour optimiser les choses. Le tutoriel est plus pédagogique qu’autre choses.

Une note aussi concernant le fait que le captcha n'est pas une protection absolue serait bienvenue

C’est dit dans l’article, à deux reprises, voici une phrase : Mais cela contribue à freiner efficacement ce genre d'attaque. Réduire les spams via les formulaires est possible, mais dire qu'on peut les anéantir complètement est un mythe.

si il doit faire 500 submits avant de réussir un captcha

Pour ne pas faire les 500 submits, il faut poursuivre l’article. Voir Eviter les attaques par bombing, notamment la phrase : il suffit d'autoriser uniquement quelques envois de formulaire pour chaque session donnée.

Section III-B. Attaque par injection SQL
la validation (manuelle ou avec framework) comme solution………….
La validation est une illusion de sécurité dans ce cas précis

Et non ! Je ne suis pas d’accord avec toi, ni dans le fond, ni dans la forme…IoI
La validation par les framworks, notamment Struts que j’utilise est relativement (Je précise) sécurisée comme indiqué dans l’article. Voici un exemple de validation d’un champ Password avec Struts… et explique-moi comment tu peux injecter une expression sql dans un cas pareil avec une validation en utilisant cette expression régulière.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<field property="password" 
	 depends="required,mask">
 	 <arg0 key="error.password"/>
 		<var>
			<var-name>password</var-name>
			<var-value>^[0-9a-zA-Z]*$</var-value>
		</var>
</field>

IV-D-1. Exemple d'utilisation : Décryptage d'un mot de passe……..

Dans l’exemple du mot de passe, j’ai présenté un exemple, mais si tu vas plus loin la rubrique solution présente plusieurs solutions.
Quand je lis tes suggestions, je me mis en doute, tu parles de JavaScript comme étant une solution peu efficace, et c’est ce que j’ai écris et il s’agit du premier point présenté dans les solutions.
quand au https, je pense que tu as repris à des exceptions près ma phrase : Il reste la solution d'utilisation du protocole HTTPS qui demeure la méthode la plus sécurisée

Dans l'ensemble je trouve que l'article a beaucoup de code par rapport au texte et que, d'aspect général, ca manque de rigueur (cf points ci-dessus). En sécurité, tenter d'enseigner des bonnes pratique sans rigueur c'est risquer de faire passer un développeur de "j'ai rien fait pour sécuriser mon application" à "je suis persuadé que mon application est sécurisée alors que je l'ai fait de travers", et ça c'est dangereux.

S’il y a beaucoup de code que de texte, c’est parce que je ne suis pas un journaliste, je n’écris pas de news, je suis plutôt technique.
Tu as le droit de dire que ça manque de rigueur, mais si tu as lu l’article tranquillement- avec rigueur - tu vas te rendre compte que la plus part de ce que tu avances est dans l’article.

Cordialement

[tchize_]

Bonjour,
Je vais essayer de répondre à quelques points que tu as décris.

Un exemple complet ? J’ai relaté les bases d’un captcha, après c’est au développeur de creuser d’avantage pour optimiser les choses. Le tutoriel est plus pédagogique qu’autre choses.

Non, juste ce genre de note ou d'exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<img src="/servletCaptcha.png"/>

afin d'éviter ce genre de contre fonctionnalité que j'ai déjà vu régulièrement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<img src="/servletCaptcha.png?captcha=AE23X"/>

où le bot a juste a regarder l'url pour savoir quel est le captcha

C’est dit dans l’article, à deux reprises, voici une phrase : Mais cela contribue à freiner efficacement ce genre d'attaque. Réduire les spams via les formulaires est possible, mais dire qu'on peut les anéantir complètement est un mythe.

J'avais justement lu à plusieurs reprise que ca freine de moins en moins efficacement, le bot faisant maintenant de la reconnaissance de caractère approximative réussissant dans plus ou moins 30% des cas, il leur suffit de 4/5 submit pour arriver passer le captcha. Ou alors faut compliquer le captcha, mais alors c'est l'humain qui a tendance à de moins en moins y arriver

Pour ne pas faire les 500 submits, il faut poursuivre l’article. Voir Eviter les attaques par bombing, notamment la phrase : il suffit d'autoriser uniquement quelques envois de formulaire pour chaque session donnée.

D'accord avec toi, j'allais justement suggérer de faire explicitement le lien. Ton attaque par bombing est plutot présentée comme un moyen de deviner les mots de passe, alors qu'elle devrait être présentée aussi comme un moyen de contourner les captcha, d'ou l'intérêt de les combiner.

La validation par les framworks, notamment Struts que j’utilise est relativement (Je précise) sécurisée comme indiqué dans l’article. Voici un exemple de validation d’un champ Password avec Struts… et explique-moi comment tu peux injecter une expression sql dans un cas pareil avec une validation en utilisant cette expression régulière.

pourquoi présenter une solution approximative qui n'est qu'un emplatre (limiter les mots de passe en qualité!) alors qu'il existe une solution sure pour empecher l'injection SQL et qui relève des bonne pratique en gestion de base de donnée? L'utilisation de prepared statements. De plus c'est déporter dans l'interface graphique un travail qui aurait du déjà être fait du coté buisness. J'ai rien contre proposer d'utiliser la validation, mais il n'est pas normal de ne pas mentionner le B-A-BA des bonnes pratiques dans les SGBD dans ce domaine en priorité. De plus filtrer un mot de passe est facile (même si personnellement tous mes mots de passe utilisent alègrement des caractères absents de ton range imposé), filtrer un champ complexe (comme le champ de soumission de texte dans ce même forum) relève de l'impossible, hors l'injection SQL peut très bien avoir lieu ailleurs que sur le login.

Quand je lis tes suggestions, je me mis en doute, tu parles de JavaScript comme étant une solution peu efficace, et c’est ce que j’ai écris et il s’agit du premier point présenté dans les solutions.

Je ne suis pas d'accord sur le peu efficace. C'est peu efficace si bien implémenté en étant non reproductible (ce que tu ne mentionne pas) car ca reste toujours attaquable en man in the middle ou (comme dans le forum de developpez) ca tombe si le javascript ne s'exécute pas pour certaines raisons. C'est par contre totalement inefficace et de la simple poudre aux yeux si tu te contente de toujours faire correspondre le même hash au même mot de passe. Hors, pour le lecteur, cette distinction n'es pas innée.

quand au https, je pense que tu as repris à des exceptions près ma phrase : Il reste la solution d'utilisation du protocole HTTPS qui demeure la méthode la plus sécurisée

Je suis d'accord que le HTTPS est plus sécurisé, mais ca manque de précision. Plus particulièrement, le lecteur est intéressé à savoir "en quoi" c'est plus sécurisé

S’il y a beaucoup de code que de texte, c’est parce que je ne suis pas un journaliste, je n’écris pas de news, je suis plutôt technique.

L'ennui c'est qu'on parle de sécurité et, personnellement, je suis assez tatillons là dessus (ce qui explique que j'ai un peu "sauté" sur l'article) Pour que des bonne pratiques de sécurités soient bien suivies et mises en place par ton lecteur il faut bien détailler le pourquoi de ces pratiques, leurs limites et le moyen de les contourner, afin qu'il saisse bien ce qu'il fait et pourquoi.

Tu as le droit de dire que ça manque de rigueur, mais si tu as lu l’article tranquillement- avec rigueur - tu vas te rendre compte que la plus part de ce que tu avances est dans l’article.

J'ai précisé mes points plus haut. Je suis d'accord quand tu dis que beaucoup de choses sont présentes dans l'article. Un bon programmeur qui lit ton article comprendra sans soucis les implications et fera les liens entre les différentes techniques (et haussera un sourcil voir deux sur le javascript). L'ennui, c'est qu'on parle de sécurité, et un mauvais programmeur, risque de comprendre ton article de travers

- j'ai filtré les mot clé SELECT, FROM et " du password et du username -> pas d'injection possible
- je convertit mon password avec md5(password) -> pas possible d'intercepter le mot de passe
- j'ai mis un captcha avec <img src="/servletCaptcha?1AX2P"/> -> relativement protégé contre les bots

Et il aura tout faux!

Hors je préfère, personnellement, avoir dans mon équipe quelqu'un qui sait ne rien y connaitre en sécurité (ce qui m'obligera à l'épauler et le former à ce sujet) que d'avoir quelqu'un qui pense savoir a la lecture de l'article mais qui n'a pas fait les recherche ad-hoc pour bien comprendre et va tout faire de travers (comme juste ici au dessus) ce qui est le plus grave a mon avis.

Désolé si je parait agressif là dessus. Mais j'ai peut qu'à la lecture de ton article, en plus de donner de bonne base à une partie des lecteur, on en donne de mauvaise à d'autre, et que ca mette à terme des système en production en danger.

Sur ce, bonne nuit à tous

[waddle]

Bonsoir,

Ce n'est pas le sujet de l'article, mais ma gestion des exceptions dans le code me pique les yeux.

Ok c'est sur la sécu, mais pas la peine de diffuser de mauvaise pratiques sur les exceptions :-)

Il ne faut tracer (si on peut appeler un SOP ou un printStackTrace tracer) puis ne rien faire dans le cas d'une exception, quelle qu'elle soit.

Pour ce qui est de faire un catch global pour éviter de montrer une stacktrace à l'utilisateur, déjà il faudrait logger l'exception avant de rediriger vers une 404. Mais même dans ce cas, ce n'est pas si simple. Une redirection vers une "page 404" retournera un code 200, or c'est précisément ce qu'il ne faut pas faire. (au passage, pour tout catcher, il faut catcher Throwable et non Exception)

Et puis, il y a des outils pour ça, comme le serveur HTTP devant le serveur d'app !

Dernière remarque, merci d'essayer de respecter la norme d'écriture Java lorsque vous rédiger un article (espaces, retour à la ligne, position des accolades, casse de nommage des variables, etc.).

Ah oui, aussi, il y a un risque de NPE dans votre méthode authentifier dans l'exemple de limitation de tentatives d'authentification. Il suffit de ne pas poster de paramètre HTTP password par exemple. Quand on compare une variable à une chaine de caractère on met la chaine avant le equals puisqu'elle ne peut pas être null ;-)

[rushtakn]

Salut,

Pas une seule trace de la, à peu près, seule méthode valable de se prévenir des injection SQL: quoi qu'il arrive, ne *jamais*,*jamais*,*jamais* concaténer des données entrées par l'utilisateur à une requete SQL. Utilisez toujours des prepared statements

L'interet d'un preparedStatement par rapport à une requete normale est juste qu'il echappe tout seul les caracteres spéciaux ou y'a autre chose ?

[tchize_]

il n'échappe rien du tout! Tes paramètres sont géré séparément de la requete par ton driver, ce qui rend impossible, de fait, de faire de l'injection (en plus de ses autres avantages comme la lisibilité des requetes dans ton code et les performances quand une meme requete doit etre faite souvent). Ca facilite aussi le boulot de ton SGBD de l'autre coté puisque la requete qu'il recois est alors plus facile a analyser (a moins de le marteler de requetes, cette optimisaiton là est cependant négligeable)

Il n'est pas impossible que ton driver fasse de la concaténation avec de l'échappement en arrière plan, mais la pluspart des SGBD du marché, dans leur protocole réseau, savent traiter des requetes paramétrées sans soucis. Autre avantage, pour des dates, tu n'a pas a te soucier du format utiliseé par le SGBD, tu transmet un java.sql.Date et c'est tout. Mais ce n'est pas le sujet de l'article

[kmdkaci]

waddle
Ce n'est pas le sujet de l'article, mais ma gestion des exceptions dans le code me pique les yeux.

Merci waddle pour tes remarques.
Mis à part la rubrique "III-B-1. Bien gérer les exceptions" où on parle vraiment des exceptions, les autres programmes ne traitent pas de ce point. C'est juste pour démontrer comment le "flux" de données est reçu coté serveur.

Je voudrais ajouter une précision majeure à mes yeux. Je l'ai dit dans l'article que c'est impossible de traiter toutes les exceptions, mais aussi impossible de définir toutes les facettes d'UNE exception. Un livre de 500 pages ne sera pas suffisant. Les codes décrits dans l'article montrent les grandes lignes d'un problème donné. je donne un exemple : les classes GenerProbab et Probabilite sont simplifiées le plus possible afin de ne pas encombrer le lecteur. Toutefois, ces deux classes montrent comment réaliser les probabilités. C'est le but de l'article. Les classes correspondantes que j'ai développées pour moi, contient des dizaines de pages avec plusieurs paramètres, packages et fichiers intermédiaires. C'est clair qu'il est impossible de décrire tous le code dans cet article. Ce qu'il faut (à mon avis) voir c'est que chaque classe décrite dans l'article accentue sur un point donnée. Si j'ai mis un simple (try catch) dans le programme génération de Captcha, ce n'est pas dans le but de diffuser de mauvaises pratiques sur les exceptions, mais juste donner un aperçu général de génération d'une image déformée suite à la validation des formulaires.

[eric1970]

je commence à m'amuser avec webgoat. Il est utile pour apprendre à devenir méchant
je n'ai pas beaucoup compris comment ça marche avec md5. Est ce que quelq'un connait un lien vers cette fonction, je suis preneur.

Cela fait longtemps que je me posais la question sur le comment des Captcha, et là merci j'ai la réponse. Finalement c'est simple, il suffit d'y penser