Renforcer la sécurité d’un site ou une appli web

alt="StickOfCelery (Deviantart) - SQL Wifejection"

Ci-après, les développeurs web et webmestres trouveront une liste sélective et concise ((Pour plus d'informations, consulter les sources au bas de l'article.)) de pratiques et recommandations permettant de renforcer la sécurité des sites et applications web. Le respect de ces principes ne suffit pas (un hackeur vaillant obtient souvent ce qu'il convoite), mais permet à tout le moins de ne pas laisser la porte grand ouverte...

CMS, forums, frameworks et autres outils "prêts à l'emploi"

  • Mise à jour constante de l'outil et de ses plugins / librairies.
  • Éviter de préfixer les tables avec leurs abréviations habituelles (wp_ pour Wordpress, jml_ pour Joomla, etc.).
  • Cacher autant que possible l'outil utilisé, en particulier dans la barre d'adresse.

.htaccess

Attention, le .htaccess est sensible ! Il convient de faire des sauvegardes du fichier au préalable, de tester une modification à la fois, et de veiller au fonctionnement de l'intégralité du système après avoir opéré chaque changement. L'altération du .htaccess mène vite à une "Internal server error" (500).

  • Register_globals à 0 / OFF / False pour empêcher l'accès aux superglobales telles que $_POST, $_GET, etc.
  • Interdiction de lister le contenu des dossiers et d'accéder à des fichiers spécifiques (éviter impérativement de faire ceci dans le fichier robots.txt qui passe plus volontiers en clair !)
  • Utilisation de la dernière version de PHP.

Fichiers et dossiers

  • CHMOD : Attribution de permissions d'accès restrictives aux dossiers (705/755) et fichiers (604/644) présents sur le FTP, dans la mesure du possible. Accès encore plus restrictif aux fichiers principaux tels que l'index du site et le style CSS (404/444).
  • Emploi de noms surprenants ((Cela va un peu à contre-sens des préceptes liés au code "propre" et aux lois du référencement, mais les robots spammeurs seraient paramétrés pour visiter des adresses comprenant certains termes.)) en particulier pour les pages qui comprennent des formulaires : éviter login, admin, contact, etc. (cela vaut également pour les attribut "name" des inputs : éviter name, (e)mail, subject, etc.).

Mots de passe

  • Les bons mots de passe comprennent au minimum 8 caractères, et présentent des lettres, des chiffres ainsi que des caractères spéciaux.
  • Scrupuleusement veiller à utiliser des mots de passe différents pour le FTP, la base de données, l'administration du site, l'authentification, etc.

Identifiants

  • Les CMS proposent souvent "admin" ou "administrateur" en guise d'identifiant. À éviter.
  • Éviter l'ID 1 pour l'administrateur.

Base de données et requêtes SQL

Cryptage

Pour un hashage sûr – de mots de passe en particulier –, préférer password_hash() et crypt() à MD5, SHA1 et SHA256.

  • Crypter le fichier de configuration ((Sécurité supplémentaire par rapport au CHMOD, au .htaccess qui en réduit l'accès et à l'extension .php qui ne permet pas d'afficher le fichier en texte brut.)).
  • Crypter les mots de passe.
  • Crypter les adresses e-mail.

Sessions

Plusieurs techniques permettent de prévenir les détournements de sessions :

  • Lier une adresse IP à une session peut-être une bonne pratique, à condition que les utilisateurs n'utilisent pas un logiciel comme Tor pour préserver leur anonymat :
$ IP = getenv ("REMOTE_ADDR");
  • Invalider l'ID de session après connexion de l'utilisateur (ou même après chaque demande) avec session_regenerate_id ().
  • Attribuer des tokens lors de la complétion des formulaires (ne jamais stocker les tokens dans des cookies !)

Vérification et validation

⚠ Principe fondamental : NE JAMAIS faire confiance aux données saisies par l'utilisateur ((Retenez que les fichiers, valeurs de session, données des cookies et données provenant de services tiers sont aussi des entrées étrangères !)).

  • Vérifier l'origine (émetteur) pour les envois de messages.
  • Vérifier le typage de ce qui est envoyé (is_string, is_int, is_bool, is_array...).
  • Vérifier si le contenu est autorisé (in_array).
  • Pour les comparaisons, recourir à l'identité (===) et non à l'égalité (==).
  • Limiter le nombre de caractères des données envoyées (varchar (x) et validation).
  • Échapper les contenus pour éviter les balises – <script> et <iframe> en particulier –, ainsi que ces signes ((Pour ce faire, abuser des fonctions PHP htmlentities, htmlspecialchars, strip_tags, addslashes et dérivées et/ou utiliser des RegExp. Attention, la fonction mysql_real_escape_string n'est visiblement pas sûre !)) :
< > : ; " ' & $ ! ? ~ ^ | @ # ( ) [ ] { }  _ - / \

php.ini

Moult paramètres peuvent être modifiés de manière à rendre le site plus opaque et plus sécure :

display_errors = Off
display_startup_errors = Off
error_reporting = E_ALL
log_errors = On
disable_functions

Toutefois, certains hébergements ne permettent pas de modifier ce fichier. Le .htaccess peut y subvenir en tout ou partie.

Surveillance

Les logs permettent de retracer les événements qui ont eu lieu sur le site ou l'application en ligne. Il peut s'avérer nécessaire de les analyser de temps en temps. Il est primordial d'y revenir après un désastre.

Tester la vulnérabilité de vos sites


Sources