Index of /GestionProjetInfo/CCh Web/Securite_web

Icon  Name                        Description
[PARENTDIR] Parent Directory            
[   ] securite_web.indd           
[   ] securite_web.pdf            
<h1><span style="background-color: rgba(255, 238, 221, 0.8); margin: 0 10px;">
   Sécurité WEB   </span></h1> 

<p>
Ce document reprend le travail rendu par Estelle Guignard, 
étudiante en 2011-2012 en licence professionnelle FNEPI à Grenoble INP—Pagora
(<a href="securite_web.pdf">securite_web.pdf</a>).
</p>

<!--==================================================================================-->
<h2>Introduction</h2>
<p>
Comment éviter que le site ne soit utilisé par un «pirate» 
pour qu’il envoie ses spams à partir du compte mail de l’entreprise ? 
Comment éviter le «<span lang="en">defacing</span>», c’est-à-dire l’effacement du site web 
et son remplacement par un autre ? Comment éviter certains trous de sécurité ?
Les serveurs d’hébergement mutualisés ou développés par des professionnels 
devraient être relativement protégés et disposer d’outils 
qui leur permettent de bloquer certains comportements suspects. 
Ces types d’attaques automatiques sont généralement effectués par des «robots». 
Ces logiciels testent chaque URL listée par Google à la recherche des failles.
Le site est souvent «choisi» par hasard et selon ses failles. 
Le document suivant expose des moyens de ne  pas ouvrir de brèche 
concernant les attaques courantes.
</p>

<!--==================================================================================-->
<h2>Les droits d’écriture, de lecture et d’exécution</h2>
<p>
Le «pirate» essaye d’installer un fichier sur le site afin d’en prendre le contrôle 
(pour effacer le site, y placer un script qui envoie du spam, etc.). 
Il cherche des trous de sécurité pour pouvoir «<span lang="en" title="télécharger, en anglais">uploader</span>» 
son fichier de prise de contrôle. 
Si le site a un trou de sécurité, le «pirate» l’exploitera, 
mais comme si le site web n’a que des dossiers et fichiers interdits en écriture, 
il ne pourra rien «<span lang="en" title="télécharger, en anglais">uploader</span>». Son attaque ne marchera pas.
</p><p>
Il est donc conseillé de paramétrer :
</p>
<ul><li> Tous les fichiers ont les droits 404 (ou 444)
</li><li> Tous les dossiers ont les droits 505 (ou 555)
</li><li> Le dossier «www» doit être en chmod 755
</li></ul>

<p>
Modifier les droits d'accès aux fichiers et dossiers sous Linus 
se fait par la commande <tt>chmod</tt>. Les valeurs peuvent être attribuées 
à l'utilisateur propriétaire (owner), au groupe ou à tous (all) sur 3 caractères en octal 
ou explictement avec les lettres <tt>r</tt>,<tt>w</tt>,<tt>x</tt> : 
</p>
<table style="margin:0 auto;">
<tr><th>Octal</th><th>	Droits d’accès </th><th>	Commentaire</th></tr>
<tr><td>0</td><td class="mid">	- - - </td><td>	Aucun droits</td></tr>
<tr><td>1</td><td class="mid">	- - x </td><td>	Exécuter</td></tr>
<tr><td>2</td><td class="mid">	- w - </td><td>	Ecrire</td></tr>
<tr><td>3</td><td class="mid">	- w x </td><td>	Ecrire et éxécuter</td></tr>
<tr><td>4</td><td class="mid">	r - - </td><td>	Lire</td></tr>
<tr><td>5</td><td class="mid">	r - x </td><td>	Lire et exécuter</td></tr>
<tr><td>6</td><td class="mid">	r w - </td><td>	Lire et écrire</td></tr>
<tr><td>7</td><td class="mid">	r w x </td><td>	Lire, écrire et exécuter</td></tr>
</table>

<p>Exemple : chmod 404 concernant les droits des fichiers : lecture seule autorisée à U et O.
<table style="margin:0 auto;">
<tr><th>Utilisateur </th><th>	U : propriétaire du fichier </th><th>	G : groupe du U </th><th>	O : autres utilisateurs </th></tr>
<tr><td>Droits d’accès </td><td class="mid">	r - - </td><td class="mid"> 	- - - </td><td class="mid">	r - - </td></tr>
<tr><td>Octal </td><td class="mid">	4 </td><td class="mid">	0 </td><td class="mid">	4 </td></tr>
</table>
<p>
Attention : <tt>index.php</tt> (ou <tt>.html</tt>), <tt>style.css</tt> 
 et toutes les images sont aussi concernés !
</p>

<!--==================================================================================-->
<h2>Le fichier .htaccess</h2>
<p>
Si ce fichier est bien construit, il permet de stopper beaucoup de tentatives de piratages et de combler des failles de sécurité.
</p>
<style>
ul[style='color:red'] em {color:grey;}
</style>
<ul style="color:red"><li> <tt>Register_Globals</tt> sur <tt>OFF</tt> 
       <em>(à vérifier avec l’hébergeur).</em>
</li><li> Interdire l’accès au fichier .htaccess depuis un navigateur web.
</li><li> Interdire de lister le contenu d’un dossier.
</li><li> Exclure les logiciels suspects 
       <em>utilisés par les pirates et certains aspirateurs de site web. 
       Cela évite la plupart des attaques automatiques.</em>
</li><li> Autoriser que l’affichage de certains fichiers, 
       <em>et pas les autres. Le fichier index.php est le fichier par défaut. 
       Si on affiche index.htm, ça ne fonctionne pas. 
       L’intérêt est d’interdire au «pirate» d’afficher sur son navigateur 
       un fichier ou un format de fichier non autorisé.</em>
</li><li> Bloquer les requêtes étranges et des failles potentielles. 
       <em>La plupart des «pirates» utilisent ces moyens pour tester la faiblesse du site. 
       Là, ils sont bloqués avant qu’ils ne pénètrent le site.</em>
</li><li> Empêcher l’exécution de tout script. 
       <em>Les «pirates» installent un script qui leur permettent 
       de prendre les commandes de l’hébergement. 
       Le but est de bloquer la plupart des commandes des scripts.</em>
</li></ul>

<!--==================================================================================-->
<h2>Base SQL réglages et paramètres</h2>
<p>
Pour éviter que la forme d’attaque de type injection SQL soit possible, 
il ne faut pas laisser par défauts tous les paramètres.
</p>
<ul><li> Lors de l’installation, un login «admin» vous est donné et vous demande d’entrer un mot de passe. Il faut alors changer «admin» pour autre chose. Un «pirate» sait que le login par défaut est «admin» et lancera ses scripts uniquement sur le mot de passe. Mais si le login «admin» n’existe pas, il ne peut pénétrer le système.
</li><li> Le premier utilisateur est l’administrateur et il porte toujours le numéro (ou ID) 1. Dans le cas où le login n’est pas «admin», certains scripts peuvent essayer d’avoir le mot de passe de l’utilisateur numéro 1 qui est, dans 99,99% des cas, l’administrateur. 
</li></ul>
<p>
Dans la mesure du possible, il faut «noyer» l’administrateur dans la liste de la base de donnée.
</p>
<ul><li> Changer le préfixe des tables SQL pour plus de sécurité 
(préfixe par défaut : 
  <tt>wp_</tt> pour <b>Wordpress</b>, <tt>g2_</tt> pour <b>Gallery2</b>, 
  <tt>dc_</tt> pour <b>DotClear</b>, <tt>phpbb_</tt> pour <b>phpBB</b>, etc.).
 Le pirate peut chercher la table avec la liste des utilisateurs et leurs mots de passe. 
 Si le préfixe n’a pas été changé, il lui sera facile de trouver la table.
</li></ul>

<!--==================================================================================-->
<h2>Nom des fichiers</h2>
<p>
Les «pirates» se basent sur des habitudes et des conventions utilisées 
pour repérer un fichier contenant des données sensibles 
(adresse mail pour le spam, login, paramètres de connexion aux bases de données etc.).
</p>
<ul><li> Tous les fichiers : ne pas les appeler 
<tt>login.php</tt>, <tt>admin.php</tt>, <tt>download.php</tt>, <tt>contact.php</tt> etc. 
Les robots auront plus de mal à les trouver. 
En règle général, il faut éviter les mots anglais trop répandus.
</li><li> Les attributs des balises contiennent des mots facilement repérables.
</li></ul>
<p>ex : dans un formulaire, la balise <tt>&lt;input&gt;</tt> avec l’attribut «name» 
contient généralement des mots comme <tt>mail</tt>, <tt>subject</tt>, <tt>tel</tt> etc.
<br />Il est préférable de donner leur équivalent en français ou un synonyme.
</p>

<!--==================================================================================-->
<h2>Les mots de passe</h2>
<p>
Les «pirates» peuvent essayer de pénétrer l’hébergement du site 
ou des fonctionnalités de celui-ci en devinant le mot de passe FTP ou SQL. 
Plus il sera complexe, moins les robots pourront le trouver rapidement.
</p>

<ul><li> Un mot de passe doit avoir au minimum 8 caractères.
</li><li> Il ne doit jamais être un mot qu’on trouve dans le dictionnaire d’aucune langue. 
Les logiciels pour cracker des mots de passe ont des dictionnaires 
de centaines de milliers de mots de toutes les langues et cherchent toutes les combinaisons. 
Cela prend entre quelques minutes à quelques petites heures pour cracker 
ces mots de passe très facilement.
Pour vérifier si le mot de passe existe, il suffit de faire une recherche avec Google par exemple.
</li><li> Un bon mot de passe contient des lettres en majuscule et minuscule et des chiffres.
</li><li> Ne pas utiliser (dans la mesure du possible) le même mot de passe 
pour le FTP, base SQL, e-mail, interface d’administration du site web etc. 
Le «pirate» sait que s’il trouve le mot de passe, 
il a de fortes chances que ce soit le même mot de passe ailleurs !
</li></ul>

<!--==================================================================================-->
<h2>Cryptage</h2>

<p>
Si malgré ces précaution, le «pirate» pénètre le site, 
il est possible de lui compliquer la tâche en cryptant les données sensibles. 
Le serveur web pourra lire ces informations facilement, 
mais elles ne seront pas lisibles directement par un œil humain. 
Cela permet de protéger les informations concernant les paramètres de connexion.
</p>
<p>
Exemple :
</p>
<pre class="code" style="width:80%;margin:0 auto;">&lt;?php
$db_server   = "serveursql";
$db_name     = "nombasesql";
$db_username = "loginsql";
$db_password = "motdepasse";
?&gt;</pre>
<p>
Donnera :
</p>
<p class="code" style="width:80%;margin:0 auto;"><tt style="word-wrap:break-word;">&lt;?php
eval(gzuncompress(gzinflate(base64_decode(‘AW4Akf942k3LTQqAIBQE4H3QHQZp5cYDRDeoRXSAMHyIkFo+K7p9f5t2w3wzSkmJ7hz6Fkw5u2AZUipVFpWZRqa0UwLQQLx5S7zOov40aE/ApyH6STP9dLsP7+LWOVoXfrZo5iMm85iP2dBTkKgv8oMsVg==’)))); 
?&gt;</tt></p>

<p>
Ces sites permettent de crypter le code qu’on leur donne. 
Rien ne garanti que le code d’origine n’est pas enregistré à notre insu ! 
Pour des raisons de sécurité il est donc préférable de le crypter soi-même avec du PHP. 

Attention : il faut que le cryptage soit réversible 
car sinon le navigateur ne pourra pas l’interpréter. 
Cette technique sert surtout à «ralentir» le «pirate». 
Il vaut mieux protéger le site en amont.
</p>


<!--==================================================================================-->
<h2>Références</h2>

<dl>

<dt>Cours de Julien Pauli pour le site <a href="http://developpez.com/">Developpez.com</a></dt>
<dd><a href="http://julien-pauli.developpez.com/tutoriels/securite/developpement-web-securite">
         http://julien-pauli.developpez.com/tutoriels/securite/developpement-web-securite</a></dd>

<dt>Page sur les <tt>.htaccess</tt></dt>
<dd><a href="http://ralph.davidovits.net/">http://ralph.davidovits.net/</a></dd>

<dt>Site de cryptage de code</dt>
<dd><a href="http://www.rightscripts.com/phpencode/">
             http://www.rightscripts.com/phpencode/</a></dd>

<dt>Site de cryptage de code</dt>
<dd><a href="http://www.mobilefish.com/services/php_obfuscator/php_obfuscator.php">
             http://www.mobilefish.com/services/php_obfuscator/php_obfuscator.php</a></dd>

</dl>


<!--==================================================================================-->