Sécuriser un site Web

De Memodev.

Aller à : Navigation, rechercher

Security.png La sécurité est primordiale sur un site internet. Il est impératif de comprendre que la sécurité est une mesure, pas une caractéristique. Se demander si sont site est sécurisé est aussi subjectif que de se demander si quelque chose est super. Il faut donc que le niveau de sécurité requis soit en équilibre avec les dépenses (passé du temps pour la sécurité en correspondance avec le niveau de sécurité désiré).

Sommaire

Pelle.png Pré-requis

Tutoriels.png Les meilleurs tutoriels pour sécuriser son site Web

Apprendre les différentes failles

htaccess

Idee.png Bonnes pratiques pour sécuriser son site Web

Bien configurer votre serveur

Pour sécuriser un serveur, vous allez avoir besoin de modifier certaines variables de configuration. Pour connaitre la valeur de tous les paramètres de votre serveur, vous pouvez créer un fichier .php sur votre serveur qui contient ceci : <?php phpinfo();.


Ces paramètres sont appelés des directives et peuvent être modifiées de 3 manières différentes :

Certaines directives ne peuvent pas être modifiées partout. Voici la liste des directives avec leurs affectations possibles. De plus, certain hébergeur ne vous permettrons pas toujours de modifier ces directives.


Voici les paramètres pour sécuriser un serveur PHP :

Recommandation Mise en place Explication
Désactivez le safe_mode php.ini : safe_mode = Off En savoir plus sur le safe_mode
Désactivez le sql.safe_mode php.ini : sql.safe_mode = Off En savoir plus sur le sql.safe_mode
Désactiver le expose_php pour que vos visiteur ne puissent pas savoir que vous utilisez PHP php.ini : expose_php = Off En savoir plus sur le magic_quotes_gpc
Désactivez les fonctions les plus sensible que vous n'utilisez certainement pas php.ini :
disable_functions =
"apache_get_modules, apache_get_version, apache_getenv, apache_note, apache_setenv, disk_free_space, diskfreespace, dl, highlight_file, ini_alter, ini_restore, openlog, passthru, phpinfo, proc_nice,shell_exec, show_source, symlink, system, exec, fsockopen, popen, set_time_limit, proc_open, leak, tmpfile"
Pour en savoir plus, voir une explication sur le disable_functions
Désactivez la directive display_errors sur votre environnement de production afin que vos visiteurs ne puissent pas voir les erreurs remontées par PHP (Laissez cette directive activée pour le développement, cela vous permettra de voir les erreurs sans avoir besoin d'aller dans les logs) .htaccess : php_flag display_errors off En savoir plus sur le display_errors
Activez les logs PHP en activant la directive log_errors .htaccess : php_flag log_errors on Il est également possible de définir un chemin pour le fichier de log avec la directive error_log. En savoir plus sur le log_errors
Logger tous les niveaux de log avec la directive error_reporting .htaccess : php_value error_reporting -1 En savoir plus sur le error_reporting
Désactiver la directive magic_quotes_gpc .htaccess : php_flag magic_quotes_gpc Off En savoir plus sur le magic_quotes_gpc
Désactiver la directive session.use_trans_sid pour que les identifiants de session n'apparaissent pas dans l'URL .htaccess : php_flag session.use_trans_sid Off En savoir plus sur le session.use_trans_sid
Activez la directive session.use_only_cookies pour obliger les navigateurs a stocker les identifiants de session dans un cookies (Attention: Le JavaScript sera obligatoire pour vos visiteurs) .htaccess : php_flag session.use_only_cookies On En savoir plus sur le session.use_only_cookies
Désactivez la directive session.cookie_httponly pour empêcher le JavaScript d'accéder au cookies (Attention: si vous avez du JavaScript ou une applet qui utilise des cookies alors ne désactivez pas cette directive .htaccess : php_flag session.cookie_httponly Off En savoir plus sur le session.cookie_httponly
Limitez la directive memory_limit à 8 megas pour éviter des fuites mémoire. .htaccess : php_value memory_limit 8M En savoir plus sur le session.use_only_cookies
Limitez la directive max_execution_time à 30 secondes pour éviter les threads bloquées. .htaccess : php_value max_execution_time 30 En savoir plus sur le session.use_only_cookies

Limitez l'accès à vos fichiers

Vos internaute doivent avoir accès aux images, au JavaScript, au CSS indispensables pour votre site. Mais ils ne doivent pas avoir accès à tous les fichiers PHP liés à vos traitements interne ! Ils doivent seulement avoir accès à vos fichier PHP qui génère des pages HTML. Si vous avez des pages de traitement ou des pages inclus dans d'autres fichiers PHP, l'utilisateur ne les appellera pas directement donc ils ne doivent pas être accessible. Pour cela, mettez tous vos script dans un dossier private par exemple, et interdisez l'accès à ce dossier à l'aide d'un .htaccess contenant seulement : Deny from all.

Autres limitations importantes à faire :

Eviter les erreurs de programmation basique

Toujours utiliser des listes blanches

Il ne faut pas faire confiances au données potentiellement modifiable par un pirate. Il ne faut donc pas faire confiance au données provenant des $_GET, $_POST et $_COOKIES. Lorsque vous utilisez ces variables pour faire un traitement, vous devez controler que la valeur de cette variables appartiennent bien à un liste, préalablement définit, de valeurs acceptées. On appel cette liste une liste blanches. Cette méthode permet d'éviter ce qu'on appele courament la [faille de l'include].

Voici un exemple de script qui utile une liste blanche :

$page = isset($_GET['p']) ? $_GET['p']:'blog';
$page_list = array(
  'blog' => 'include/blog.php',
  'articles' => 'include/articles.php',
);

if (!isset($page_list[$page])) {
  require 'include/notfound.php';
} else {
  require $page_list[$page];
}

Filtrer les données envoyées par le client

Il est impératif de filtrer les données envoyés par le client. C'est à dire les données provenant des variables GET, POST, SERVER, ainsi que les en-têtes HTTP et les cookies. il ne faut jamais les récupérer tel quel. Il faut les filtrer avec les fonctions adéquate php (mysql_escape_string() ou addslashes(), htmlentities(), magic_quotes(), strip_tags(), et utf8_decode() ).

Sans ce filtrage, vous serez exposé au faille de sécurité suivante : [les injections sql], le [Cross-site scripting (XSS)], le [CSRF (Sea surf)], l'[upload de fichier]. Un pirate pourrait donc voler le contenu de votre BDD, la détruire, voler les session de vos utilisateur, prendre la main sur votre serveur ...

Voici un exemple pour filtrer les données du client :

// Encode les entités Html pour éviter les injections Html, SQL, JavaScript
function encodeHtmlEntities($string){
  if(is_array($string)){
     for($i=0;$i<sizeof($string);$i++){
        $string[$i]=encodeHtmlEntities($string[$i]);
     }
     return $string;
  }else{
     return htmlentities($string, ENT_QUOTES, "UTF-8");
  }
}


Dans le cas ou vous utiliser les données utilisateur pour les passer en paramètre d'une requête, il vous faudra aussi supprimer les retours chariots (caractère \r pour CR et \n pour LF) car en injectant ces caractères, l'utilisateur peut modifier les entêtes de la requête HTTP. On appel ça la faille CRLF : voir un [exemple d'exploit de la faille]. Protection contre la faille CRLF (suppression de tous les retours chariots) : preg_replace("/(\r|\n)*/", "", $monParametre);


Cette faille est souvent exploité pour l'envoi de mail. Donc au lieu de simplement supprimer les retours chariots CRLF dans les paramètres du mail, il est préférable de carrément vérifier que les paramètres sont bien des adresses mails. Voir [un exemple de script PHP d'envoi de mail sécurisé].

Imposer un encodage

Filtrer les données du client ne suffit pas, il faut également imposer un encodage. Si cette partie n'est pas effectué, alors il est possible de spécifier l’utilisation de l'encodage UTF-7 et d'exploiter la faille XSS avec l'UTF-7     .

Sécuriser les session de vos utilisateurs

Faille upload de fichier

http://www.vulgarisation-informatique.com/upload-php.php http://forum.coolparadise.org/viewtopic.php?p=40743

Null byte code

\0 ou %00 ou \x00

htaccess

Ne pas utiliser la balise limit

URL rewriting

http://vince.monkeyz.eu/failles.php#Liens%20utiles

Protection des mots de passe

Pour éviter les vols de mot de passe (par écoute sur le réseau) il faut crypter les mots de passe avec la methode GDS (grain de sel) Pour éviter les tentatives de connexion par force brut il faut proposé un capchat pertinent au bout de plusieurs tentative de connection. Pour eviter le vol de session il faut utiliser un systeme de ticket ou la fonction session_regenerate_id( ) :

Utilisation de captcha

L'utilisation des captcha est une problématique complexe. Allez voir la page sur les captcha pour en savoir plus.

Source.png Sources




Lien vers des articles xmcopartners :

Outils personnels
Espaces de noms
Variantes
Actions
Navigation
Catégories
Boîte à outils