Les conseils de base pour la sécurité d'un site

[Chark]

Après m'être rendu compte que de nombreuses personnes se font pirater ou recherchent une sécurité maximum pour leurs sites, je lance ce sujet qui a pour but de recenser les "choses à faire et ne pas faire".
Le but de ce post n'est pas de donner les techniques complètes, mais plutôt une sorte d'index. Chacun des points évoqués ici pourront faire l'objet d'autres sujets pour rentrer dans le détail.
Je vais commencer cette liste. j'appelle tout le monde à participer pour que cette liste soit le plus exhaustive possible et je mettrai à jour la liste au fur et à mesure.
Libre à un admin du site de le mettre en post it ou de le laisser sombrer dans les méandres du forum.

LES CHOSES A FAIRE ET NE PAS FAIRE POUR SÉCURISER SON SITE INTERNET :

- Toujours penser qu'un bon pirate trouvera toujours les infos qu'il veut
Par exemple, il y a quelques jours un collègue me disais à propose de son site à propos de ces pages passées en "include" avec une variable GET :"J'ai utilisé url rewriting, changé toutes les variables, il est quasiment impossible de comprendre comment la page est traitée... Bien sur si un pirate le comprends, la c'est vulnérable"...
ERREUR ! Il faut TOUJOURS penser que quelqu'un arrivera à trouver ses infos, donc sécuriser au cas ou.

- Utiliser la politique du "tout interdire sauf..." plutôt que "tout accepter sauf..."
Par exemple, vous faite un formulaire, il y a 6 choix possibles : Lors du traitement de ce formulaire en php, il faut faire des IF qui vont accepter Seulement les 6 choix et interdire tous les autres !

- Bien verrouiller toutes les variables en GET
Si c'est une variable du style machin=55 ( que des chiffres ), penser a voir ce que ca donne si on met des lettres ( très souvent cela donne une erreur, et le navigateur affiche l'erreur avec une partie de ta requête sql = vulnérabilité )

- Désactiver les messages erreur php/sql lors de la mise en ligne
C'est bien pour le codage, mais avoir des messages genre " mysql erreur line 55 near 'query machin from table", c'est pas bon pour la sécurité.

- Bannir les includes par GET
ou alors vraiment les sécuriser en acceptant que vos url avec un code du genre :

$valid_pages = array ('index', 'rechercher', 'downloads', 'liens', 'construction');

if (in_array($_GET['page'], $valid_pages)) { $PAGE = $_GET['page']; return $PAGE; } else { $PAGE='construction'; $FOLDER='construction'; return $PAGE; return $FOLDER; }

- Ne pas mettre de lien vers l'interface administrateur depuis le site accessible coté "client"
L'administration du site se fait par un dossier ou une adresse que l'on tape manuellement dans le navigateur

- Mettre un fichier "index.php" ou "index.html" dans chacun de ses dossiers
Tous les dossiers ! images, photos, etc...
Pour éviter que l'on puisse, en tapant l'adresse du dossier dans le navigateur ( comme w*ww.example.com/images/ ) avoir la liste des pages ou fichiers contenus dans ce dossier.
Cet index peut , au choix, renvoyer vers la page d'accueil du site ou afficher un message d'erreur.

- Utiliser le htmlentities ou des fonctions ereg pour traiter les variables en POST ou GET
Pour éviter l'injection de script par un internaute.

- Protéger ses dossiers sensibles ( commme admin ) avec un htaccess et htpass
Ca peut paraître tout bête mais j'ai connu des personnes qui l’oubliaient.
De plus, nommer son fichier admin d'un autre nom que admin ou administrateur est conseillé.

- Ne passer aucune variable "sensible" ( comme un mot de passe ) en GET, cookie ou en form hidden
Il sera très facile pour un pirate débutant de les récuperer.

- Nommer les fichiers à inclure en .php
Quand vous faites des includes nommez vos fichiers en .php et pas .inc, .txt ou autre sinon un pirate malin pourra lire vos commandes php, vos données et autres!

 

[touftouf]

Merci pour cette petit resumé, en se moment on n'en a besoin, en fait , il s'agit surtout de ceux qui ont un serveur dedié

 

[Chark]

La sécurité est l'affaire de tout le monde , dédié ou mutu
Il y a des techniques différentes mais il y a aussi des techniques communes aux deux.
Le but de ce post est d'essayer de penser à tout le monde :wink:

 

[cmpc2002]

Bonjour,

Si je peut me permettre, moi j'utilise un script de bannissement automatique si dans l'url quelqu'un ajoute un -http://...

Cela, permet de limiter la casse et d'éviter bien des ennuis, puisqu'il est en principe impossible d'inclure une page distante par exemple.

Voici le code :

<?php

if ( (isset($_SERVER['REQUEST_URI'])) && (eregi("http://", $_SERVER['REQUEST_URI']) )
{
	header("HTTP/1.1 401 Unauthorized");
	die('M&ecirc;me pas en r&ecirc;ve.');
	exit;
}

?>

Bon, après, on peut pousser le script et écrire dans le htaccess l'ip de la personne concernée affin qu'elle ne puisse pas revenir tout de suite, chose que je fait.

voila, si ça peut aider quelqu'un.

CMPC2002

 

[Chark]

Si je peut me permettre, moi j'utilise un script de bannissement automatique si dans l'url quelqu'un ajoute un -http://...

Cela, permet de limiter la casse et d'éviter bien des ennuis, puisqu'il est en principe impossible d'inclure une page distante par exemple.

C'est une bonne méthode éffectivement, mais non applicable sur certains sites.
Je pense notemment aux sites qui proposent des upload de fichiers ( ou de photos si le script d'upload n'est pas assez sécurisé )
Rien n'empeche un pirate d'upload un fichier malsain contenant des scripts, puis de taper en url w*ww.example.com?include=/dossier_upload/monfichierhack.php

Voila pourquoi je préconise plutot la méthode de n'accepter que les url prédéfinies.
Bien sur, cette méthode non plus n'est pas applicable tout le temps et ta méthode est alors applicable.

Merci pour ta participation

PS : Je n'ai pas ajouté ton script au message original. Ce n'est pas parce qu'il n'est par interessant, loin de la, mais plutôt car le but de mon post est de donner des "lignes de conduites" et ne pas entrer dans un débat sur tel ou tel script ( qui peuvent faire l'objet d'un sujet très intéressant d'ailleurs ).

 

[thierry8]

dans le cas d'un upload justement quels sont les choses à faire / pas faire ?

dl d'une image / fichier

 

[TOMHTML]

Je rajouterai "eviter de mettre sa partie admin dans le répertoire /admin/"

 

[guicara]

Je rajouterai "eviter de mettre sa partie admin dans le répertoire /admin/"

De plus, nommer son fichier admin d'un autre nom que admin ou administrateur est conseillé.

:roll:

 

[Lord_Coder]

Juste une petite explication , la raison pour laquelle on ne doit pas passer des mots de passe en GET c'est que si un utilisateur se connecte et qu'il clique sur un lien externe , peut être que ce le site externe dispose d'un systéme qui analyse les referers et pourra donc voir l'adresse depuis laquelle le visiteur est parvenu à son site , le mot de passe va alors être affiché !

 

[ckarone]

Salut,

Quand vous faites des includes nommez vos fichiers en .php et pas .inc ou autre sinon un pirate malin pourra lire vos commandes php et autres!

 

[Chark]

Merci ckarone
Je l'ai ajouté à la liste.

 

[Chark]

dans le cas d'un upload justement quels sont les choses à faire / pas faire ?

dl d'une image / fichier

Déja, bien vérifier l'extension du fichier ( dans le cas d'une image, vérifier qu'ils'agit d'un jpg, jpeg, png, gif )
vérifier aussi qu'il ne comporte qu'une seule extension ( pour eviter les fichiers du type fichier.exe.jpg.
Je conseille aussi de renommer le fichier.

 

[mr_go]

- Bien verrouiller toutes les variables en GET
Si c'est une variable du style machin=55 ( que des chiffres ), penser a voir ce que ca donne si on met des lettres ( très souvent cela donne une erreur, et le navigateur affiche l'erreur avec une partie de ta requête sql = vulnérabilité )

J'ajouterai à ceci : TOUJOURS CONTROLER COTE SERVEUR les variables envoyées côté client. Proscrire "javascript only" pour le controle des champs. (Pour les PHPistes, voir du coté de PEAR::Quickform.

Cela revient au même mais toujours utile à préciser..;

 

[thierry8]

dans le cas d'un upload justement quels sont les choses à faire / pas faire ?

dl d'une image / fichier

Déja, bien vérifier l'extension du fichier ( dans le cas d'une image, vérifier qu'ils'agit d'un jpg, jpeg, png, gif )
vérifier aussi qu'il ne comporte qu'une seule extension ( pour eviter les fichiers du type fichier.exe.jpg.
Je conseille aussi de renommer le fichier.

a partir du moment ou il existe une extension "finale" quel est le danger ?

 

[Chark]

a partir du moment ou il existe une extension "finale" quel est le danger ?

Il me semble avoir lu quelque part qu'il y avait un risque ( mais je n'ai pas les détails )
En matière de sécurité d'un site, je suis partisan du :"être paranoïaque est ma devise" :lol:

 

[rog]

un script comportant un fopen suivi d'un eval sur un filename variabilisé serait fatal

surtout avec global a on

néanmoins je trouve assez sympat que le net soit un terrain de jeux


ça c'est de moi :

le net est un ocean ou les ordis sont des ilots remplis de nourriture

tout autour gravite une multitude de prédateurs affamés et boulimiques prets à tout pour s'assouvir

rog

 

[objectifweb]

a partir du moment ou il existe une extension "finale" quel est le danger ?

Il me semble avoir lu quelque part qu'il y avait un risque ( mais je n'ai pas les détails )
En matière de sécurité d'un site, je suis partisan du :"être paranoïaque est ma devise" :lol:

Bonjour

Parceque certains bugs font que c'est la première extention qui sera la bonne pour l'exécution, et le fichier passera car ton script lui se fiera à la dernière

image.exe.jpg sera accepté par ton script qui vérifie si l'extention est bien jpg mais un bug dans certains programme m$ fait que si tu ouvres le fichier en partant de windows, le .exe lui suffit pour démarrer ! (bug probablement corrigé actuellement)

Une certaine Kornikova a fait des dégâts en son temps

Patrick

 

[objectifweb]

Bonjour,

Pour ajouter ma pierre, si vous installez une application genre cms, album photos etc, vérifier sur gg si rien n'est signalé sur les failles.
Si vous êtes hacké quand même, vérifier les logs, vous repèrerez les traces suspectes et vous pourrez déterminer le script et l'application responsable du trou

Patrick

 

[MIMATA]

Bonjour,

Quelqu'un qui s'y connait pourrait-il faire un topo sur la sécurisation de la fonction mail de php ?
Perso, je passe mes variables à stripslashes et la variable du mesage à htmlentities en plus mais est-ce suffisant ?

Merci

 

[absurdia]

J'ai assisté à une conférence sur la sécurité des applications webs.
Les manquements sur la toile sont assez ahurissants.
Le consultant a montré deux outils pour tester son site web:
- Burp proxy: proxy en java à mettre sur votre machine qui intercepte les POST & GET vers le serveurs et vous permet de visualiser et modifier les valeurs transmises.
http://www.portswigger.net/proxy/
- Wikto: Web Server Assessment Tool
Certaines fonctions utilisent même l'API Google
http://www.sensepost.com/research/wikto/index2.html

J'ai testé un de mes sites et ai trouvé des répertoires laissés ouverts (serveur Apache) par mon hébergeur dont je ne connaissais même pas l'existence.

Les recommandations qu'il faisait sont en ligne avec le premier post.

Bon test.

 

[dd32]

Pour se protéger de l'email injection :
http://www.tonyspencer.com/mt/archives/ ... ection.htm

Et aussi :
http://www.securephpwiki.com/index.php/Email_Injection