questions d'applications Web sécurisées

Question

Je suis en train d'implémenter une application web qui est alimentée par le backend via une interaction serveur/client. Le site Web fonctionne sur https et l'authentification est fournie par LDAP.

A partir de maintenant, je pousse tous les utilisateurs sans cookie, appelez-le 'userHash' pour référence à la page de connexion. La page de connexion accepte un nom d'utilisateur, passe et vérifie ldap pour vérifier. S'il vérifie, je stocke dans ma session le nom d'utilisateur, l'adresse IP de l'utilisateur et un horodatage.

Enfin je construis une information de cookie et hachage de session:

SESSION['userHash'] = sha1($username.$userip.$timestamp); 
cookie['userHash'] = sha1($username.$userip.$timestamp); 

De cette façon, sur toute demande ultérieure, je vérifie les posses utilisateur le userhash cookie avec une valeur correspondant à la session [ 'userhash']

Cette configuration est-elle sécurisée?

De plus, je veux empêcher les attaques par force brute et j'allais implémenter une simple table DB pour consigner les tentatives échouées. Actuellement, je pense à avoir:

id | username | timestamp | ipaddress | count 

comme un tableau. Est-ce la meilleure approche ou existe-t-il un meilleur moyen? Je vois par exemple avec cette table que si je devais limiter les tentatives ratées à 3 toutes les 24 heures, alors un attaquant a la possibilité d'essayer chaque nom d'utilisateur 3 fois à partir du même Ip. (Remarque: cette application devrait être utilisée sur des laboratoires d'informatique potentiellement scolaires qui peuvent être sur un sous-réseau et ainsi montrer plusieurs connexions à partir de la même adresse IP, donc je dois faire attention quand je bloque en fonction de l'adresse IP. D'autre part, je me demandais s'il y a quelque chose comme "denyhosts" pour l'authentification http?

Answer 1

Le hachage que vous créez $hash = sha1($username.$userip.$timestamp); n'est pas sécurisé, car il peut être calculé à partir des informations publiques. Le nom d'utilisateur, l'adresse IP de l'utilisateur et l'horodatage sont tous publics et disponibles pour un attaquant. Vous devez ajouter une information secrète au hachage, .: par exemple

$hash = sha1($username.$userip.$timestamp.$secret); 

Où $secret est jamais communiqué en dehors de votre script. Si vous le souhaitez, vous pouvez stocker les données publiques au cookie:

$cookie = implode("/", array($username, $timestamp, $hash)); 

Ensuite, lors de la vérification, utilisez $ _SERVER [ 'REMOTE_ADDR'] comme userip $.

Pour votre deuxième question, vous n'avez pas besoin de la colonne count si vous stockez déjà l'horodatage d'une tentative ayant échoué. Si une tentative provient de la même adresse pour un horodatage déjà échoué, vous pouvez le rejeter car les humains ne font pas deux entrées de mot de passe dans une seconde.

Édité pour ajouter: Faire la limite des tentatives échouées rendra vos utilisateurs vulnérables à DOS. Les environnements scolaires en particulier ont beaucoup de gens aventureux, qui ne dérange pas frapper quelques mots de passe pour essayer d'entrer dans un compte. Verrouillez-les après 3 essais, et vous verrouillez aussi les utilisateurs légitimes ...

Answer 2

Eh bien tout ce qui n'a pas vraiment d'importance dans une attaque de type man-in-the-middle. Un Secure Socket Layer est fortement recommandé si vous traitez des informations sensibles.

Utilisez l'extension LDAPv3 Transport Layer Security (TLS) pour une connexion sécurisée.

De même, connectez l'agent d'utilisateur http pour différer entre les ordinateurs du même réseau.

Verrouiller les comptes utilisateur pour éviter la brutalité est toujours une bonne idée. Assurez-vous de refuser la combinaison adresse IP/agent utilisateur et pas seulement l'adresse IP.

Maintenant, ils ne peuvent pas saisir l'information lorsque vous l'envoyez, et ils ne peuvent pas simuler les informations de cookie. Pour cette partie, c'est plutôt sécurisé. Il pourrait y avoir d'autres facteurs cependant, mais comme je ne les connais pas, ce n'est pas pertinent.