Catégories
Linux Trucs et astuces

Supprimer les tentatives d’accès à phpMyAdmin en utilisant fail2ban

Comme beaucoup de monde il m’arrive d’être « scanné » sur mon serveur Web pour accéder à phpMyAdmin ou en exploiter une faille.

On trouve ce genre d’info dans les mails quotidiens généré par logwatch par exemple.

--------------------- httpd Begin ------------------------ 
 
 Requests with error response codes
   […]
    404 Not Found
       /PMA/scripts/setup.php: 1 Time(s)
       /PMA2005/scripts/setup.php: 1 Time(s)
     […]
       /phpMyAdmin-2.3.0/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.3.1/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.3.2/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.3.3/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.3.4/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.3.5/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.3.6/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.3.7/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.3.8/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.3.9/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.4.0/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.4.1/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.4.2/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.4.3/scripts/setup.php: 1 Time(s)
       /phpMyAdmin-2.4.4/scripts/setup.php: 1 Time(s)
     […]
 
 ---------------------- httpd End -------------------------

Pour y remédier :

  • Ne pas l’installer !
  • N’autoriser que certaines IPs à y accéder
  • Utiliser fail2ban pour limiter et contrer l’effet des scans

Utilisation de fail2ban

J,ai trouvé un script tout fait… alors pourquoi se compliquer la vie ! Il est disponible à l’adresse suivante : http://foosel.org/blog/2008/04/banning_phpmyadmin_bots_using_fail2ban.

Je le reprend ci-dessous avec quelques adaptations :

/etc/fail2ban/filter.d/apache-phpmyadmin.conf

# Fail2Ban configuration file
# Bans bots scanning for non-existing phpMyAdmin installations on your webhost.
#
 
[Definition]
 # Option:  failregex
# Notes.:  Regexp to match often probed and not available phpmyadmin paths.
# Values:  TEXT
#
failregex = [[]client <HOST>[]] File does not exist: .*(PMA|phpmyadmin|myadmin|mysql|mysqladmin|sqladmin|mypma|admin|xampp|mysqldb|mydb|db|pmadb|phpmyadmin1|myadmin2)
 
# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Activer le filtre dans le fichier de configuration : /etc/fail2ban/jail.conf :

[apache-phpmyadmin]
enabled  = true
port     = http,https
filter   = apache-phpmyadmin
logpath  = /var/log/apache/error.log
maxretry = 3
Catégories
PHP

Sessions

Désactiver les identifiants de sessions dans les URLS

En activant « session.use-only-cookies », vous éviterez les attaques qui utilisent des identifiants de sessions dans les URLS.

Le système de gestion des sessions par URL pose un risque supplémentaire de sécurité : un utilisateur peut envoyer son URL avec l’identifiant de session par email à un ami, ou bien le mettre dans ses signets. Cela diffusera alors l’identifiant de session. On le désactive donc.

1
2
3
ini_set('session.use_only_cookies', 1);
ini_set('session.use_trans_sid');', 0);
session_start();

Initialiser les sessions

Session fixation

Quelques explications : http://en.wikipedia.org/wiki/Session_fixation

1
2
3
4
5
6
7
// Session fixation
// On vérifie qu'une valeur connue de nous même (ici "no_fixation") est présente 
// en session, sinon on regénère la session.
if (!isset($_SESSION['no_fixation'])) {
    session_regenerate_id(true); 
    $_SESSION['no_fixation'] = true;
}

Session hijacking

Quelques explications : http://en.wikipedia.org/wiki/Session_hijacking

1
2
3
4
5
6
7
// Session hijacking
$signature = md5($_SERVER['HTTP_USER_AGENT'] .  $_SERVER['HTTP_ACCEPT_CHARSET'] . SALT);
if (!isset($_SESSION['signature'])) {
    $_SESSION['signature' ] = $signature;
} elseif ($_SESSION['signature'] !== $signature) {
    die('Erreur de session ' );
}

Attention !
J’ai remarqué que sous certains navigateurs l’entête Accept n’est pas forcément consistant d’une page à l’autre, notamment en actualisant une page. C’est donc un entête à éviter pour la signature.

Catégories
PHP

CSRF et QuickForm de PEAR

J’utilise encore beaucoup QuickForm de PEAR pour gérer mes formulaires, une classe pour disposer automatiquement d’une « protection » contre les CSRF trouvée à l’adresse : http://shiflett.org/articles/cross-site-request-forgeries#comment-66

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
<?php
 
/**
 * @uses HTML_QuickForm
 * @desc Add automatic CSRF mitigation to all forms by incorporating a token that must be matched in the session and forcing the use of POST method
 */
require_once "QuickForm.php";
class HTML_QuickFormS extends HTML_QuickForm {
 
    /**
     * @property string $_sessionTokenKey The name of the session variable containing the token
     */
    private $_sessionTokenKey;
 
    /**
     * @method HTML_QuickFormS
     * @desc Override the method to always use post and pass it on to the parent constructor. Create a session key for the token based on the form name.
     * @param string $formName
     * @param string $method
     * @param string $action
     * @param string $target
     * @param mixed $attributes
     * @param boolean $trackSubmit
     */
    public function HTML_QuickFormS($formName='', $method='post', $action='', $target='', $attributes=null, $trackSubmit=false){
        $this->_sessionTokenKey = "QuickFormS_".md5($formName);
        parent::HTML_QuickForm($formName, 'post', $action, $target, $attributes, $trackSubmit);
    }
 
    /**
     * @method display
     * @desc Create a token if necessary and place a hidden field in the form before displaying
     * @return void
     */
    public function display(){
 
        //A token hasn't been created so do so
        if(!isset($_SESSION[$this->_sessionTokenKey])){
            $_SESSION[$this->_sessionTokenKey] = md5(uniqid(rand(), true).session_id()); //requires the session id to be known in order to add extra difficulty to compromising
        }
 
        //Hide the token at the end of the form
        $this->addElement("hidden", "qfS_csrf", $_SESSION[$this->_sessionTokenKey]);
        parent::display();
    }
 
    /**
     * @method validate
     * @desc Check if the passed token matches the session before allowing validation
     * @return boolean
     */
    public function validate(){
 
        //The token was not passed or does not match
        if(!isset($this->_submitValues['qfS_csrf']) || $this->_submitValues['qfS_csrf']!=$_SESSION[$this->_sessionTokenKey]){
            $this->setElementError("qfS_csrf", "Anti-CSRF token does not match");
        }
 
        return parent::validate();
    }
 
}
 ?>
Catégories
PHP Trucs et astuces

Protection de vos scripts PHP : validation des données, XSS, CSRF,…

Aujourd’hui je commence une série d’articles sur quelques points de sécurité et de bon sens avec PHP.
Ces articles n’ont et n’auront rien de bien original par rapport à ce que l’on peut glaner de ci de là sur Internet, mais ils pourront me ou vous servir d’aide mémoire ou de piqûre de rappel !

Validation et filtrage des entrées

Un maître mot : « Ne jamais faire confiance aux données étrangères » !
Chaque donnée reçue doit être validée pour s’assurer qu’elle corresponde à ce que l’on attend réellement.

En PHP il existe de très nombreux outils de validation des données :

  1. Les opérateur de comparaison, de taille (chaînes, tableaux),…
  2. L’utilisation de liste de valeurs autorisées (« white-list ») : isset($hash[$var]) ... in_array($var, $allowed)
  3. À l’aide d’expression régulières : preg_match(‘/…/’ , $var);
  4. Extension ctype : ictype_digit($var); qui va vérifier que $var ne contient que des chiffres
  5. Les fonctions is_* : is_scalar($var);
  6. Depuis l’extension PHP 5.2, l’utilisation de l’extension Filter est recommandée.
    Exemple d’utilisation  :

    1
    2
    
    $clean['param1'] = filter_input(INPUT_POST, 'param1', FILTER_VALIDATE_BOOLEAN);
    $clean['email'] = filter_input(INPUT_POST, 'email', FILTER_VALIDATE_EMAIL);
  7. Pour Zend l’utilisation des classes Zend_Validate_* ainsi que la création de vos propres validateurs.

Ces validations doivent s’appliquer sur les données reçues par : $_GET, $_POST, $_REQUEST, $_COOKIES, $_FILES et certaines en provenance de $_SERVER ($_SERVER['PHP_SELF'] par exemple.

Échappement des sorties

Une fois vos données validées, il reste à échapper les sorties afin d’éviter les attaques XSS (Cross-site scripting) : détournement de formulaires, modification de l’affichage, vols de cookies, de sessions, etc.

De même que pour la validation des données PHP contient tout le nécessaire pour effectuer ces opérations :

  • Protéger les caractères sensibles : htmlspecialchars($var);
  • Protéger tous les caractères : htmlentities($var,...) et mb_htmlentities($var,...). Le deuxième paramètre, ENT_COMPAT|ENT_QUOTES|ENT_NOQUOTES est parfois important.
  • Enlever les balises HTML : striptags($text);
  • Encodage spécique pour URL : urlencode($var);
  • L’extension Filter peut non seulement valider comme vu au-dessus, mais aussi filtrer en sortie avec FILTER_SANITIZE_*
  • Pour Zend l’utilisation des classes Zend_Filter_* est tout aussi aisée, avec la possibilité de créer ses propres filtres suivant ses besoins

Attention au jeu de caractères, en particulier pour htmlentities() : problème d’affichage, voire de sécurité.
Pour les charsets multi-octets (comme UTF-8), mb_htmlentities() est plus fiable.

Protection des formulaires

S’assurer que les champs cachés ne sont pas modifiés

Pour cela il suffit d’envoyer en parallèle un hash contrôlant la valeur du champ caché.

1
2
3
4
5
6
<?php $idhash = md5($id . SALT); ?>
<form action="edit.php" method="POST">
<input type="hidden" name="id" value="<?php echo $id ?>" />
<input type="hidden" name="idhash" value="<?php echo $idhash ?>" />
<input type="submit" value="Valider" />
</form>

Et à la réception des données, vérifier que le hash correspont bien à la valeur attendue :

1
2
3
4
5
$id = filter_input(INPUT_POST, 'id', FILTER_VALIDATE_INT);
$idhash = filter_input(INPUT_POST, 'idhash', FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_HEX);
if ($idhash !== md5($id . SALT) {
die('Le formulaire est louche ! ' );
}

Se prémunir des CSRF (Cross-Site Request Forgery)

Les attaques CSRF consistent à faire exécuter des commandes involontaires aux utilisateurs accrédités d’un site.

Quelques astuces pour s’en prémunir ou au moins en limiter grandement la portée, certaines évidentes et facile à mettre en place, d’autres plus subtiles…

Demander des confirmations à l’utilisateur pour les actions critiques

Par exemple systématiquement demander une confirmation du style « Êtes vous certain de vouloir … » sur des actions sensibles comme la suppression, ou redemander de saisir le mot de passe lors de la modification de la configuration de votre site internet.

Utiliser des jetons de validité dans les formulaires

Le principe est simple : lorsqu’un utilisateur affiche un formulaire, on lui génère une clé. Cette clé sera valide pour un certain temps (quelques minutes, le temps de remplir le formulaire), et est liée uniquement au couple utilisateur/formulaire. Cette clé devra automatiquement être transmise avec le formulaire pour que celui ci puisse être validé !

Dans le framework Zend il existe un élément de formulaire dédié à cet usage : Zend_Form_Element_Hash, son utilisation est aisée :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Mon_Formulaire_anti_csrf extends Zend_Form {
  public function init() {
    $this->setMethod('post');
    $this->addElement( 'submit'
                     , 'submit'
                     , array( 'ignore'   => true
                     , 'label'    => 'Soumettre'
                     ,)
                     );
    $form->addElement( 'hash'
                       , 'no_csrf'
                       , array( 'salt' => 'unique')
                       ); 
}

Le hash généré est stocké en session et sera ajouté à la chaîne de validation du formulaire : s’il est différent de celui stocké, il y aura une erreur d’émise.

Éviter d’utiliser des requêtes HTTP GET pour effectuer des actions

Passer systématiquement par POST pour toutes les actions autres que celles de consultation de ressource : insertion, mise à jour ou suppression de données.
Cette mesure va vous prémunir des attaques simples basées sur les images, mais pas de requêtes HTTP POST forgée en JavaScript par exemple.

Quelques liens pour aller plus loin :

  1. http://fr.wikipedia.org/wiki/Cross-site_request_forgery
  2. Zend_Form_Element_Hash
  3. http://bigornot-fr.blogspot.com/2008/07/csrf-sea-surf-and-zend.html
  4. http://truffo.fr/2010/03/les-filtres-php/
  5. http://zendframework.com/manual/fr/zend.filter.html
  6. http://zendframework.com/manual/fr/zend.validate.html
  7. Extension Filter
Catégories
Humeur

Mandelbox…

Comme quoi les mathématiques peuvent servir à faire des choses concrètes … et inutiles !

le Mandelbox, la boîte Mandelbrot

Découvrez les explications complètes à l’adresse suivante : http://images.math.cnrs.fr/Mandelbox.html