Se connecter avec
S'enregistrer | Connectez-vous

[PHP] Conseils pour sécuriser la session, l'inscription et le site

Dernière réponse : dans Programmation

Bonjour,

Je réalise actuellement le cahier des charges (amateurs par je ne suis pas du métier) sur la sécurité en php sur la session, le formulaire d'inscription, les connexions et compagnie.

J'aimerais si possible l'indispensable (le BaBA) mais aussi des astuces en tout genre;

Voici se que j'ai commencé, vu que je débute c'est un peu brouillon

# Enregistrement de toute tentative d'inscription (établir un log sur les tentatives de connexion raté)
# Bannissement de l'IP après 5 tentatives, proposer de retrouver son identifiant ou mot de passe
# Utilisation de la fonction sleep() pour ralentir le brute force
# sha1() + de rajouter du sel. ex
# Vérification de session (stocker l'adresse IP de la personne qui a ouvert la session dans la session, et ensuite vérifier sur chaque page que l'ip qui utilise la session est bien la même)
# Fichier .htaccess
# Page HTML vierge à chaque dossier
# Redirection si accès interdit
# Connexion avec anti-bot (calcul rapide)
# limiter les login et pass à certains caractères (avec une belle regex) avec par exemple au maximum un seul quote ' : if (preg_match('!^[a-z0-9 _-]+\'?[a-z0-9 _-]+$!', $pseudo_ou_pass))


Comme vous pouvez le voir j'ai pioché un peu partout sur le net, mais j'en connais pas l'efficacité ou si c'est harchi inutile. On débute tous un jour,

Merci de m'aider :) 

Autres pages sur : php conseils securiser session inscription site

Lassé par la pub ? Créez un compte

Ben, ce que tu as fait est déjà pas mal ! Mais certains points semblent redondant...

Moi je mettrais :
- Authentification de connexion via Login/mdp : soit via un fichier htaccess (moi j'aime moyen moyen) soit via des sessions (je préfère)
- Mot de passe crypté dans la base en MD5 (comme mentionné par PetitTigre)
- Au début de chacune des pages (y compris et surtout dans les index.php de tes dossiers), test de session & renvoit vers page d'accueil ou autre si l'utilisateur n'est pas autorisé.
- Stockage de l'adresse IP des utilisateurs avec analyse des logs pour BAN ou blocage de compte si besoin
- Forcer l'utilisation d'au moins 2 chiffres & 2 lettres dans le mot de passe et une longueur min de 8 par exemple...
- Déconnexion auto après un certain temps.
...
Expert Programmation

PetitTigre a dit :
Tu peux rajouter le codage avec md5();


Il est préférable d'utiliser la fonction sha1() + de rajouter du sel. ex 

  1. $sel = '#uiks-|[';
    

  2. sha1($pwdUser.$sel);


Ainsi si ta base est téléchargé, impossible ou presque sans faire du vrai brut de force de retrouver le mot de passe. Un simple appel à md5() est vraiment trop léger actuellement, surtout avec Google maintenant.

Et comment empêcher le force brute, ou comment empêcher que la base de donnée soit accessible ?

J'avais premièrement penser à un sleep() + un catchat anti-bot à chaque connexion;
Enfin comment réellement kill un force brute ?

sans avoir fait un doctorat + Polytechnique en informatique lol
Expert Programmation

Quelques ajouts en plus du ma réponse :

Citation :
# Page HTML vierge à chaque dossier


Inutile si dans la configuration (du serveur ou via un .htaccess) tu as un -Indexes dans le <Directory>

Citation :
# vérifier le référent


Mauvaise idée, tu vas exclure beaucoup de gens sans raison. Beaucoup de proxy d'entreprise retire les referer.

Citation :
Utilisation de la fonction sleep() pour ralentir le brute force


Très très très mauvais ! si tu mets un sleep() alors tu augmentes le temps de connexion entre le client et le serveur et tu surcharges pour rien le serveur.

Citation :
# Connexion admin (?) avec .htacces


Si tu as vraiment accès au serveur, je te conseil de désactiver les .htaccess, normalement danxs l'idéal, si tu as vien les droits sur ton serveur, alors AllowOveride est à None dans le <VirtualHost> et les infos du .htaccess directement dans le <Directory> du Vhost.

Je rajouterais, bien connaitre HTTP. Toutes requêtes modificatrice doit se faire en POST. Ex de faille par XSRF.

  1. <a href="delete?id=765">Pour effacer un message cliquer ici</a>


Très mauvais, suffit qu'une personne mal attentionné fasse une image et qu'un modérateur par ex affiche alors dans ce cas il supprime l'id 765 si une requête GET fonctionne. Donc toujours bien vérifier le type de requête envoyé, POST ou GET. et refuser les GET pour certaine page.

  1. # Redirection si accès interdit


Non, l'erreur 403 est faite pour ca. 403 Access forbidden. Voir toujours le protocole HTTP.

  1. # Connexion admin (?) avec .htacces


Et je rajouterais même si possible sur un sous domaine différent.
Expert Programmation

Absolument pas. Il offre une flexibilité au pris d'une lourdeur très importante. En gros il permet de surcharger (remplacer) les paramètre de configuration par défaut pour un répertoire et cela à chaud, c'est à dire que si tu change le fichier, pas besoin de relancer le serveur. Autant dire que sur de l'hébergement mutualisé c'est plutôt important de pouvoir le faire à chaud :) 

Les IP il faut les bloquer, une couche plus bas (cf les couches réseaux), à savoir au niveau du firewall pour bien faire. Comme ça ils n'arriveront même plus à se connecter.

AU passage, j'avais oublié un point. Il faut régénérer les sessionid régulièrement pour se prémunir du vol de session.
Expert Programmation

Oui. Les sessions ce n'est rien d'autre qu'un cookie envoyé chez le client. A ce cookie, qui est un identifiant unique sont stocké des infos sur le serveur. Si le cookie est volé (par écoute sur le réseau par ex) dans ce cas, il est super simple de se connecter à la place de qqun d'autre.

Genre, si là tu me voles mon cookie de session, alors tu passes admin. Bon, ok, sans doute pas ici, mais sur beaucoup de site ;) 
Lassé par la pub ? Créez un compte

Créer un nouveau sujet

Tom's guide dans le monde