auto_restrict 3.1 : you shall not pass (at least without a token)

Voici une nouvelle version de ce script qu'il suffit d'inclure dans une page php pour en restreindre l'accès au seul admin.

 

Cette nouvelle version accroît la sécurité :

  • en incluant (enfin!) la gestion automatisée des tokens permettant de s'assurer que les données reçues proviennent bien du formulaire prévu et non d'un usurpateur de session.
  • en permettant d'implémenter une sécurité supplémentaire sur les formulaires sensibles.
  • en gérant de façon transparente le bannissement/débannissement des IP et les problèmes de referrer.

 

Si ça intéresse quelqu'un, c'est posé ici


 

De quoi-t-est-ce qu'il s'agit-il ?

J'ai déjà expliqué le fonctionnement de base de la version précédente, je vais donc me contenter de résumer rapidement:

auto_restrict est un script à inclure le plus tôt possible dans une page php, en tout cas avant les parties sensibles de la page (si j'ose dire).

 

C'est lui qui va prendre la main et gérer pour vous toute la sécurisation de l'accès à la page, de la création du passe lors du premier accès jusqu'à la gestion de la connexion/déconnexion en passant par les problèmes de session et de referrer.

 

 

Comment que ça fonctionne, mon bon monsieur ?

Utilisation de base: login/logout

On ajoute simplement <?php include('auto_restrict.php');?> à la page. Oui, c'est tout.

 

Sécuriser les formulaires

Pour sécuriser un formulaire en utilisant les tokens, on ajoute <?php newToken();?> dans le formulaire: le token sera généré, mis en session et ajouté au formulaire dans un input hidden.

Oui, c'est tout...

 

On peut bien entendu sécuriser également des données $_GET de la même façon...

et même se contenter d'ajouter le token sur une URL en passant le paramètre $token_only à true, par exemple: 

<a href="http://www.warriordudimanche.net/url/dune/page/securisee.php?token=<?php newToken(true);?>">Action téméraire !</a>

 

Histoire renforcer encore la sécurité sur les actions sensibles, on peut ajouter <?php adminPassword();?> dans le formulaire afin que l'usager soit obligé de taper le mot de passe pour que le formulaire soit traité.

Oui, c'est tout...

En effet, auto-restrict étant appelé avant le traitement des données sur la page d'origine, il va vérifier le mot de passe avant tout autre chose et stopper le script en cas de problème...

 

 

Autres aspects de sécurité

Le referrer

Auto_restrict bloquera toute action provenant d'une autre origine que celle du serveur sur lequel il est hébergé. Même s'il est possible de changer le referrer, ça ne mange pas de pain.

 

Le bannissement d'IP

Le script gère seul et de façon transparente les bannissements d'IP en cas de problème.

Il incrémente un compteur correspondant à l'IP du visiteur et bloque l'accès si le nombre de connexions frauduleuses a dépassé le quota.

Le débannissement est également automatique au bout d'un certain temps (paramétrable).

 

 

Configuration du script

J'ai prévu une configuration par défaut pour tous les paramètres, mais il est toujours possible de la modifier: il suffit de définir le tableau $auto_restrict avant l'inclusion du script.

$auto_restrict['session_expiration_delay'] // durée de vie de la session en minutes 
$auto_restrict['cookie_expiration_delay'] // durée de vie du cookie en jours
$auto_restrict['IP_banned_expiration_delay'] // durée de bannissement d'IP en secondes
$auto_restrict['max_security_issues_before_ban'])) //nombre maximum de problèmes de sécurité avant bannissement
$auto_restrict['just_die_if_not_logged'] // (défaut: false) si à true, ne charge pas le formulaire de login si aucun utilisateur n'est loggué (pour éviter de voir apparaître le formulaire de connexion lors d'un accès via Ajax à un script php protégé par exemple)
$auto_restrict['just_die_on_errors'] // (défaut: true) si à true, toute action dont la sécurité est compromise génère un simple message d'erreur et bloque le script; à false, la session est fermée et on est redirigé vers le formulaire de login.
$auto_restrict['tokens_expiration_delay'] // durée de vie des tokens en secondes
$auto_restrict['use_GET_tokens_too'] // utiliser également les tokens pour les variables $_GET
$auto_restrict['use_ban_IP_on_token_errors'] // utiliser le système de bannissement lors d'une erreur de token
            

 

 

Améliorations prévues ou possibles

  • Je pense ajouter un fichier log permettent de conserver une trace de toutes les actions provoquant un problème de sécurité (avec pourquoi pas une alerte lors de la connexion de l'admin)
  • je songe aussi à permettre la sécurisation automatique des données $_POST et $_GET (débrayable via la config)

 

 

Téléchargement, démo et tout ça

Pour voir le script en fonctionnement, rendez-vous sur la page de démo, qui permet de se faire une idée de ses différents aspects (login: demo / passe: demo)

 

Pour récupérer le zip, c'est direction le dépôt GitHub.

 

 


Pour terminer, je préciserai une nouvelle fois que je ne suis pas du tout spécialiste de la sécurité et que je serai heureux d'améliorer tout problème que vous me signalerez

Les modifications de cette version découlent d'ailleurs des remarques virulentes d'un utilisateur de GitHub qui m'avait fait un vigoureux retour... (vigoureux mais utile)

 

A+ les copains !

 

✍ Écrire un commentaire

Inutile de poster un commentaire à la con pour vous faire de la pub, ce sera filtré et dégagé direct...

Quelle est la troisième lettre du mot alelt ?