Bonzour,
J'ai un formulaire sur un site qui aurait un souci de sécurité.
Je reçois le contenu du formulaire par mail.
Tous les champs sont remplis par une même adresse e-mail du genre
"him4456@mondomaine.be".
J'en reçois plusieurs par semaine.
D'où viendrait le problème?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric Belhomme
mdnews wrote in news::
D'un automate spameur ou autre casse pied. Deux solutions courantes contre cela: - Mettre une regex sur chaque champ qui vérifie la cohérence des données entrée (ex: pas d'email dans un champ nom), limite de longueur etc
dans tous les cas :
* un minimum de javascript (donc coté client) afin d'analyser le contenu de _chaque_ zone de saisie permet d'assurer un minimum de cohérence dans les données envoyées (genre un champs "nom" ne contient que des lettres, un champ téléphone contient 10 chiffres, etc.)
* les mêmes controles coté serveur (en php, perl, jsp,...) voire en plus poussés !
Pour des développements web, le controle des 2 cotés est indispensable. Après les systèmes antispamm comme les caractères bruités à saisir manuellement, ca assure que c'est bien un humain qui a posté, mais c'est une contraite pour l'utilisateur (personellement ce genre de formulaire me fait c**** ;)
-- Rico
mdnews <mdnews@mail.invalid> wrote in news:jeljrv9xc2fn.dlg@mdfqdn.invalid:
D'un automate spameur ou autre casse pied.
Deux solutions courantes contre cela:
- Mettre une regex sur chaque champ qui vérifie la cohérence des données
entrée (ex: pas d'email dans un champ nom), limite de longueur etc
dans tous les cas :
* un minimum de javascript (donc coté client) afin d'analyser le contenu de
_chaque_ zone de saisie permet d'assurer un minimum de cohérence dans les
données envoyées (genre un champs "nom" ne contient que des lettres, un
champ téléphone contient 10 chiffres, etc.)
* les mêmes controles coté serveur (en php, perl, jsp,...) voire en plus
poussés !
Pour des développements web, le controle des 2 cotés est indispensable.
Après les systèmes antispamm comme les caractères bruités à saisir
manuellement, ca assure que c'est bien un humain qui a posté, mais c'est
une contraite pour l'utilisateur (personellement ce genre de formulaire me
fait c**** ;)
D'un automate spameur ou autre casse pied. Deux solutions courantes contre cela: - Mettre une regex sur chaque champ qui vérifie la cohérence des données entrée (ex: pas d'email dans un champ nom), limite de longueur etc
dans tous les cas :
* un minimum de javascript (donc coté client) afin d'analyser le contenu de _chaque_ zone de saisie permet d'assurer un minimum de cohérence dans les données envoyées (genre un champs "nom" ne contient que des lettres, un champ téléphone contient 10 chiffres, etc.)
* les mêmes controles coté serveur (en php, perl, jsp,...) voire en plus poussés !
Pour des développements web, le controle des 2 cotés est indispensable. Après les systèmes antispamm comme les caractères bruités à saisir manuellement, ca assure que c'est bien un humain qui a posté, mais c'est une contraite pour l'utilisateur (personellement ce genre de formulaire me fait c**** ;)
-- Rico
Erwan David
Eric Belhomme <{rico}+no/ écrivait :
mdnews wrote in news::
D'un automate spameur ou autre casse pied. Deux solutions courantes contre cela: - Mettre une regex sur chaque champ qui vérifie la cohérence des données entrée (ex: pas d'email dans un champ nom), limite de longueur etc
dans tous les cas :
* un minimum de javascript (donc coté client) afin d'analyser le contenu de _chaque_ zone de saisie permet d'assurer un minimum de cohérence dans les données envoyées (genre un champs "nom" ne contient que des lettres, un champ téléphone contient 10 chiffres, etc.)
Là ce n'est que de la commodité pour l'utilisateur, on peut faire l'hypothèse qu'un attaquant simulra le comportement d'un javascript qui dit "pas de défaut" (puisqu'il contrôle le browser).
* les mêmes controles coté serveur (en php, perl, jsp,...) voire en plus poussés !
Et seuls ceux là sont sécuritaires.
-- Si vous embauchez, voici mon CV http://www.rail.eu.org/cv/cv.pdf
Eric Belhomme <{rico}+no/spam@ricospirit.net> écrivait :
mdnews <mdnews@mail.invalid> wrote in news:jeljrv9xc2fn.dlg@mdfqdn.invalid:
D'un automate spameur ou autre casse pied.
Deux solutions courantes contre cela:
- Mettre une regex sur chaque champ qui vérifie la cohérence des données
entrée (ex: pas d'email dans un champ nom), limite de longueur etc
dans tous les cas :
* un minimum de javascript (donc coté client) afin d'analyser le contenu de
_chaque_ zone de saisie permet d'assurer un minimum de cohérence dans les
données envoyées (genre un champs "nom" ne contient que des lettres, un
champ téléphone contient 10 chiffres, etc.)
Là ce n'est que de la commodité pour l'utilisateur, on peut faire
l'hypothèse qu'un attaquant simulra le comportement d'un javascript
qui dit "pas de défaut" (puisqu'il contrôle le browser).
* les mêmes controles coté serveur (en php, perl, jsp,...) voire en plus
poussés !
Et seuls ceux là sont sécuritaires.
--
Si vous embauchez, voici mon CV
http://www.rail.eu.org/cv/cv.pdf
D'un automate spameur ou autre casse pied. Deux solutions courantes contre cela: - Mettre une regex sur chaque champ qui vérifie la cohérence des données entrée (ex: pas d'email dans un champ nom), limite de longueur etc
dans tous les cas :
* un minimum de javascript (donc coté client) afin d'analyser le contenu de _chaque_ zone de saisie permet d'assurer un minimum de cohérence dans les données envoyées (genre un champs "nom" ne contient que des lettres, un champ téléphone contient 10 chiffres, etc.)
Là ce n'est que de la commodité pour l'utilisateur, on peut faire l'hypothèse qu'un attaquant simulra le comportement d'un javascript qui dit "pas de défaut" (puisqu'il contrôle le browser).
* les mêmes controles coté serveur (en php, perl, jsp,...) voire en plus poussés !
Et seuls ceux là sont sécuritaires.
-- Si vous embauchez, voici mon CV http://www.rail.eu.org/cv/cv.pdf
Eric Belhomme
Erwan David wrote in news::
Là ce n'est que de la commodité pour l'utilisateur, on peut faire l'hypothèse qu'un attaquant simulra le comportement d'un javascript qui dit "pas de défaut" (puisqu'il contrôle le browser).
le javascript n'est pas là pour empêcher le vilain warl0rd d'agir, mais
pour emchêcher de valider (au sens GET de la chose) des formulaires erronés
* les mêmes controles coté serveur (en php, perl, jsp,...) voire en plus poussés !
Et seuls ceux là sont sécuritaires.
bien sur, mais ca ne rend pas pour autant inutiles les controles coté
client.
on va dire que les controles coté serveur sont sécuritaires _et_ fonctionnels, alors que les controles coté client ne sont _que_ fonctionnels.
-- Rico
Erwan David <erwan@rail.eu.org> wrote in
news:87r74cuyxu.fsf@nez-casse.depot.rail.eu.org:
Là ce n'est que de la commodité pour l'utilisateur, on peut faire
l'hypothèse qu'un attaquant simulra le comportement d'un javascript
qui dit "pas de défaut" (puisqu'il contrôle le browser).
le javascript n'est pas là pour empêcher le vilain warl0rd d'agir, mais
pour emchêcher de valider (au sens GET de la chose) des formulaires erronés
* les mêmes controles coté serveur (en php, perl, jsp,...) voire en
plus poussés !
Et seuls ceux là sont sécuritaires.
bien sur, mais ca ne rend pas pour autant inutiles les controles coté
client.
on va dire que les controles coté serveur sont sécuritaires _et_
fonctionnels, alors que les controles coté client ne sont _que_
fonctionnels.
Là ce n'est que de la commodité pour l'utilisateur, on peut faire l'hypothèse qu'un attaquant simulra le comportement d'un javascript qui dit "pas de défaut" (puisqu'il contrôle le browser).
le javascript n'est pas là pour empêcher le vilain warl0rd d'agir, mais
pour emchêcher de valider (au sens GET de la chose) des formulaires erronés
* les mêmes controles coté serveur (en php, perl, jsp,...) voire en plus poussés !
Et seuls ceux là sont sécuritaires.
bien sur, mais ca ne rend pas pour autant inutiles les controles coté
client.
on va dire que les controles coté serveur sont sécuritaires _et_ fonctionnels, alors que les controles coté client ne sont _que_ fonctionnels.
-- Rico
Paul Gaborit
À (at) 05 Apr 2006 15:46:18 GMT, Eric Belhomme <{rico}+no/ écrivait (wrote):
on va dire que les controles coté serveur sont sécuritaires _et_ fonctionnels, alors que les controles coté client ne sont _que_ fonctionnels.
Il faut alors ajouter qu'un contrôle côté client n'est fonctionnel _que_ pour le client. Lorsque le serveur reçoit la requête, il n'a _aucune_ garantie que ces tests ont bien été effectués (le cas du vilain pirate ou plus simplement le cas du navigateur dont le javascript est désactivé, bogué ou absent). Le serveur _doit_ donc effectuer systématiquement les tests sécuritaires _et_ fonctionnels _complets_.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 05 Apr 2006 15:46:18 GMT,
Eric Belhomme <{rico}+no/spam@ricospirit.net> écrivait (wrote):
on va dire que les controles coté serveur sont sécuritaires _et_
fonctionnels, alors que les controles coté client ne sont _que_
fonctionnels.
Il faut alors ajouter qu'un contrôle côté client n'est fonctionnel
_que_ pour le client. Lorsque le serveur reçoit la requête, il n'a
_aucune_ garantie que ces tests ont bien été effectués (le cas du
vilain pirate ou plus simplement le cas du navigateur dont le
javascript est désactivé, bogué ou absent). Le serveur _doit_ donc
effectuer systématiquement les tests sécuritaires _et_ fonctionnels
_complets_.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 05 Apr 2006 15:46:18 GMT, Eric Belhomme <{rico}+no/ écrivait (wrote):
on va dire que les controles coté serveur sont sécuritaires _et_ fonctionnels, alors que les controles coté client ne sont _que_ fonctionnels.
Il faut alors ajouter qu'un contrôle côté client n'est fonctionnel _que_ pour le client. Lorsque le serveur reçoit la requête, il n'a _aucune_ garantie que ces tests ont bien été effectués (le cas du vilain pirate ou plus simplement le cas du navigateur dont le javascript est désactivé, bogué ou absent). Le serveur _doit_ donc effectuer systématiquement les tests sécuritaires _et_ fonctionnels _complets_.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
