Application .net (1.1) et thread.sleep + securité

fabrice a écrit :

Bonjour à tous.

J'ai une application nécessitant faisant de l'identification basée sur
formulaire.
J'utilise System.Threading.Thread.Sleep pour améliorer ou plutôt gêner les
tentatives frauduleuses de connexion.

par exemple si la saisie est erronée je fais une pause de 10 secondes.
si le compte saisi est inconnu je bloque pendant 20 secondes.

Je voudrais savoir si cela peut avoir des effets sur la plateforme .net et
votre avis sur un tel usage de thread.sleep.

merci de votre aide
fabrice

Bonjour,

Je ne pense pas que se soit judicieux, pour plusieurs raisons :
- en faisant cela tu bloques le thread qui fait le traitement de la
requête en cours, mais potentiellement un utilisateur peut voir une
autre requête traitée par un autre thread du serveur ce qui ne sert pas
à grand chose dans ton cas. Rien que de faire un refresh de la page, va
provoquer une autre requête, et si ton thread est en train de dormir
officiellement pour le serveur il travail, donc n'est pas disponible
donc va utiliser un autre thread
- si un thread est en cours de traitement (même si un sleep ne consomme
pas de temps machine), le serveur va devoir en créé d'autres pour
répondre aux autres requêtes, si tu as une attaque en règle tu va avoir
plusieurs requêtes simultanées, donc une création de threads en
augmentation, le souci c'est qu'un serveur va limiter le nombre de
threads, résultat tu va avoir un semblant de DOS (deny of service), où
ton serveur ne répondra plus car tous ces threads seront en train
d'attendre.
- ce que tu fais n'est pas une bonne approche, tu oublies qu'une
application web est client/serveur, je demande quelque chose à mon
serveur, il me répond, mais pendant ce temps là moi le client je peux
faire autre chose. Dans un système client/serveur on essaye au maximum
de répondre à une règle fondamentale : "répondre le plus rapidement
possible à un requête". Ce n'est pas pour faire plaisir aux
utilisateurs, c'est pour que le système soit capable de traiter le plus
de requêtes possibles simultanément.

Bref perso je te le déconseille fortement. Pour répondre à ton problème,
j'opterais par exemple pour une variable en session de type DateTime à
l'heure où la session à le droit à nouveau de se reconnecter et que tant
le délai n'est pas passé je lui retourne une page blanche ou une page
"bloquée" disant "Connexion en cours" qui se rafraichi toute les X
secondes jusqu'à ce qu'il puisse se reconnecter.

Tu peux aussi détecter que ça fait X tentatives erronées et là tu
blackliste carrément l'adresse IP par exemple pour une durée de quelques
heures, dés qu'il fait une requête, il se retrouve sur une page blanche,
ou une redirection quelconque en dehors de ton site.

A++

Yanos

Bonjour merci

de ta réponse.
Pourrais je oser te demander si tu as des méthodes pour blacklister des IP ?
Je voudrais éviter des connexions inutiles à la base de données. L'idée
alors de passer par une hashtable en objet session est elle saugrenue ?
C'est à dire vérifier l'existence d'une adresse dans cette table chaque fois
que le "bouton" connexion est pressé avant d'entamer une vérification de
bdd...

merci
fabrice


"Yanos El Guerilleros" <yeg_retirer@ceci_ygrenier.com> a écrit dans le
message de news: edv%23hFmiIHA.1164@TK2MSFTNGP02.phx.gbl...

fabrice a écrit :

Bonjour à tous.

J'ai une application nécessitant faisant de l'identification basée sur
formulaire.
J'utilise System.Threading.Thread.Sleep pour améliorer ou plutôt gêner
les tentatives frauduleuses de connexion.

par exemple si la saisie est erronée je fais une pause de 10 secondes.
si le compte saisi est inconnu je bloque pendant 20 secondes.

Je voudrais savoir si cela peut avoir des effets sur la plateforme .net
et votre avis sur un tel usage de thread.sleep.

merci de votre aide
fabrice

Bonjour,

Je ne pense pas que se soit judicieux, pour plusieurs raisons :
- en faisant cela tu bloques le thread qui fait le traitement de la
requête en cours, mais potentiellement un utilisateur peut voir une autre
requête traitée par un autre thread du serveur ce qui ne sert pas à grand
chose dans ton cas. Rien que de faire un refresh de la page, va provoquer
une autre requête, et si ton thread est en train de dormir officiellement
pour le serveur il travail, donc n'est pas disponible donc va utiliser un
autre thread
- si un thread est en cours de traitement (même si un sleep ne consomme
pas de temps machine), le serveur va devoir en créé d'autres pour répondre
aux autres requêtes, si tu as une attaque en règle tu va avoir plusieurs
requêtes simultanées, donc une création de threads en augmentation, le
souci c'est qu'un serveur va limiter le nombre de threads, résultat tu va
avoir un semblant de DOS (deny of service), où ton serveur ne répondra
plus car tous ces threads seront en train d'attendre.
- ce que tu fais n'est pas une bonne approche, tu oublies qu'une
application web est client/serveur, je demande quelque chose à mon
serveur, il me répond, mais pendant ce temps là moi le client je peux
faire autre chose. Dans un système client/serveur on essaye au maximum de
répondre à une règle fondamentale : "répondre le plus rapidement possible
à un requête". Ce n'est pas pour faire plaisir aux utilisateurs, c'est
pour que le système soit capable de traiter le plus de requêtes possibles
simultanément.

Bref perso je te le déconseille fortement. Pour répondre à ton problème,
j'opterais par exemple pour une variable en session de type DateTime à
l'heure où la session à le droit à nouveau de se reconnecter et que tant
le délai n'est pas passé je lui retourne une page blanche ou une page
"bloquée" disant "Connexion en cours" qui se rafraichi toute les X
secondes jusqu'à ce qu'il puisse se reconnecter.

Tu peux aussi détecter que ça fait X tentatives erronées et là tu
blackliste carrément l'adresse IP par exemple pour une durée de quelques
heures, dés qu'il fait une requête, il se retrouve sur une page blanche,
ou une redirection quelconque en dehors de ton site.

A++

Yanos

Perso je resterais plutôt sur une table en base de données.

Dans ta session ce n'est pas une bonne idée toujours dans l'optique de
multiple requête, donc multiple sessions, donc répétition de ta
hashtable qui pour le coup ne servirait à rien entre deux sessions, le
type essayes, ferme son navigateur le rouvre et hop il n'est plus
blacklisté.

Donc a la rigueur une hastable en données d'application, mais pareil si
ton appli est redémarrée tu perds toutes tes infos de blacklistage.

Autre point lors d'une attaque il est bon d'avoir des infos, dans une
base tu peux te permettre d'avoir un historique et lorsqu'une IP ou une
plage d'IP revient régulièrement, tu peux carrément mettre une règle sur
un firewall ou autre système de protection.

A++

Yanos

fabrice a écrit :

Bonjour merci

de ta réponse.
Pourrais je oser te demander si tu as des méthodes pour blacklister des IP ?
Je voudrais éviter des connexions inutiles à la base de données. L'idée
alors de passer par une hashtable en objet session est elle saugrenue ?
C'est à dire vérifier l'existence d'une adresse dans cette table chaque fois
que le "bouton" connexion est pressé avant d'entamer une vérification de
bdd...

merci
fabrice


"Yanos El Guerilleros" <yeg_retirer@ceci_ygrenier.com> a écrit dans le
message de news: edv%23hFmiIHA.1164@TK2MSFTNGP02.phx.gbl...

fabrice a écrit :

Bonjour à tous.

J'ai une application nécessitant faisant de l'identification basée sur
formulaire.
J'utilise System.Threading.Thread.Sleep pour améliorer ou plutôt gêner
les tentatives frauduleuses de connexion.

par exemple si la saisie est erronée je fais une pause de 10 secondes.
si le compte saisi est inconnu je bloque pendant 20 secondes.

Je voudrais savoir si cela peut avoir des effets sur la plateforme .net
et votre avis sur un tel usage de thread.sleep.

merci de votre aide
fabrice

Bonjour,

Je ne pense pas que se soit judicieux, pour plusieurs raisons :
- en faisant cela tu bloques le thread qui fait le traitement de la
requête en cours, mais potentiellement un utilisateur peut voir une autre
requête traitée par un autre thread du serveur ce qui ne sert pas à grand
chose dans ton cas. Rien que de faire un refresh de la page, va provoquer
une autre requête, et si ton thread est en train de dormir officiellement
pour le serveur il travail, donc n'est pas disponible donc va utiliser un
autre thread
- si un thread est en cours de traitement (même si un sleep ne consomme
pas de temps machine), le serveur va devoir en créé d'autres pour répondre
aux autres requêtes, si tu as une attaque en règle tu va avoir plusieurs
requêtes simultanées, donc une création de threads en augmentation, le
souci c'est qu'un serveur va limiter le nombre de threads, résultat tu va
avoir un semblant de DOS (deny of service), où ton serveur ne répondra
plus car tous ces threads seront en train d'attendre.
- ce que tu fais n'est pas une bonne approche, tu oublies qu'une
application web est client/serveur, je demande quelque chose à mon
serveur, il me répond, mais pendant ce temps là moi le client je peux
faire autre chose. Dans un système client/serveur on essaye au maximum de
répondre à une règle fondamentale : "répondre le plus rapidement possible
à un requête". Ce n'est pas pour faire plaisir aux utilisateurs, c'est
pour que le système soit capable de traiter le plus de requêtes possibles
simultanément.

Bref perso je te le déconseille fortement. Pour répondre à ton problème,
j'opterais par exemple pour une variable en session de type DateTime à
l'heure où la session à le droit à nouveau de se reconnecter et que tant
le délai n'est pas passé je lui retourne une page blanche ou une page
"bloquée" disant "Connexion en cours" qui se rafraichi toute les X
secondes jusqu'à ce qu'il puisse se reconnecter.

Tu peux aussi détecter que ça fait X tentatives erronées et là tu
blackliste carrément l'adresse IP par exemple pour une durée de quelques
heures, dés qu'il fait une requête, il se retrouve sur une page blanche,
ou une redirection quelconque en dehors de ton site.

A++

Yanos

fabrice avait soumis l'idée :

Je voudrais éviter des connexions inutiles à la base de données.

Normalement, seul les connexions locales sont à autoriser si IIS se
trouve sur le même serveur que le SGBD. AU pire, tu peux utiliser un
firewall mais je ne vois pas l'intérêt de le faire côté code.

--
Delf