Securi-toile

La faille d'envergure[1][2], découverte par Dan Kaminsky en juillet 2008 et qui a entrainé une série de correctifs pour la grande majorité des serveurs DNS existants n'est pas à prendre à la légère, puisque les impacts potentiels sont importants : En ayant la capacité de corrompre les entrées (le cache) des serveurs DNS, c'est une des clés de voute du SI qui est attaquée.

L'exploitation de cette vulnérabilité ne posant pas de réelle difficulté si le serveur n'est pas patché, il est indispensable de mettre à jour les serveurs DNS, la plupart étant affectés. Cette mise à jour est d'autant plus critique si vous hébergez des serveurs ouverts et permettant d'effectuer des requêtes récursives.

Si votre serveur DNS venait à être corrompu, c'est toutes vos requêtes vers l'extérieur (et vers vous dans une certaine mesure) qui peuvent être interceptées, puisque l'attaquant aura la possibilité de rediriger les internautes de manière totalement transparente vers le site de son choix. Un tel contexte est un catalyseur très important pour les attaques de type phishing, installation de malwares (via les mises à jour automatiques), et aussi Man In The Middle (donc interception de mails entrants/sortants, des connexions vers l'extérieur etc.).

Il faut garder à l'esprit que le correctif n'élimine pas le risque à 100%, mais vise plutôt à rendre l'attaque beaucoup plus difficilement réalisable, en effet on passe de 32,769 paquets nécessaires pour réussir l'attaque à un nombre de tentatives nécessaires compris entre 134,217,728 et 4,294,967,296. Un tel niveau est très raisonnable en sécurité, le risque est réellement minimisé. "

Les SQL Injection sont parmi les failles les plus répandus et dangereux en PHP.
Ce tutorial va expliquer clairement le concept de SQL Injection et comment les éviter, une fois pour toutes.

Il existe deux types d'injection SQL:

• L'injection dans les variables qui contiennent des chaînes.
• L'injection dans les variables numériques.

Ce sont deux types très différents et à éviter, il agira différemment pour chacun de ces types.

1
2

$ pseudo = $ _GET [ 'pseudo'];
$ requete = mysql_query ( "SELECT age FROM membres WHERE pseudo = '$ pseudo'");

Ce script est une grande vulnérabilité par injection SQL. Il suffit qu'une personne malveillante en mettant en place le nom d'utilisateur dans l'URL d'une requête comme ceci :

1

'Password UNION SELECT FROM membres WHERE id = 1

Ceci est juste une demonstration, par exemple le mot de passe le membre ayant l'ID 1.

1

NULL, \ x00, \ n, \ r, \, ', "et \ X1A

Comme vous l'avez remarqué dans l'injection précédente, le pirate utilise la citation (pour fermer la 'Around $ nick): si elle est empêchée de le faire, le pirate iras voir ailleurs. Cela signifie que si l'on applique un mysql_real_escape_string () pour le nom de variable comme ça ...

1
2

$ pseudo = mysql_real_escape_string ($ _GET [ 'pseudo']);
$ requete = mysql_query ( "SELECT age FROM membres WHERE pseudo = '$ pseudo'");

L'application est entièrement sécurisé.

1

'Password UNION SELECT FROM membres WHERE id = 1

Eh bien, si nous appliquons mysql_real_escape_string () à la variable $ nom utilisé dans la requête est ce qui va de l'injection :

1

\ 'Union de passe Sélectionnez membres WHERE id = 1

Cela signifie que nous ne viennent pas même en dehors des quotes autour de $ nick dans la requête car la \ a été ajoutée. Il existe une autre fonction quelque peu semblable à mysql_real_escape_string () est addslashes (), pourquoi ne pas avoir utilisé ? Eh bien récemment, une faille de sécurité a été découvert à ce sujet si il est utilisé sur une installation de PHP 4.3.9 avec magic_quotes_gpc est activé.

Ce type d'injection est moins connue que la précédente, ce qui en fait plus fréquentes, et il commence comme tout à l'heure avec un exemple. Cette fois, c'est affichage de l'âge d'un membre en fonction de son id, et en le faisant passer par un formulaire ($ _POST) à changer:

$ id = $ _POST [ 'id'];
$ requete = mysql_query ( "SELECT age FROM membres WHERE id = $ id");

1

2 UNION DE passe Sélectionnez membres WHERE id = 1

Cette injection fait exactement la même que la précédente, sauf qu'ici, pour l'éviter, il y a deux solutions:

• Changer le contenu de la variable si elle contient uniquement des chiffres
• Vérifiez si la variable contient en réalité un certain nombre avant de l'utiliser dans une requête.

Méthode 1:

Nous allons utiliser une fonction intval () Cette fonction retourne quel que soit le contenu d'une variable sa valeur numérique. Par exemple:

1
2

e10 variable = '1 '; / / $ variable vaut '1 e10'
valeur_numerique $ = intval ($ variable); / / $ vaut valeur_numerique 1

1
2
3

$ id = intval ($ _POST [ 'id']);
$ requete = mysql_query ( "SELECT age FROM membres WHERE id = $ id");
)

$ id = $ _POST [ 'id'];
if (is_numeric ($ id))
(
$ requete = mysql_query ( "SELECT age FROM membres WHERE id = $ id");
)
autre
(
echo "Essayer de me hack ?";

Quelle est la meilleure, en fonction entre intval () et is_numeric () ?

Les deux sont tout aussi efficaces, mais je conseil inval () car avec la fonction is_numeric () écrire plus de code, et si la variable ne contient pas seulement des chiffres, la demande est annulée (en principe, mais bien sûr vous pouvez exécuter la même requête en choisissant une Valeur par défaut de la variable utilisée). Well that's it!

Vous savez tout pour sécuriser vos applications.

Si vous appliquez ces méthodes, il y a absolument aucun risque d'avoir un type de faille d'injection SQL sur son site web (ou PHP).

Le cross site scripting, abrégé XSS, est un type de faille de sécurité des sites Web, que l'on trouve typiquement dans les applications Web qui peuvent être utilisées par un attaquant pour faire afficher des pages web contenant du code douteux. Il est abrégé XSS pour ne pas être confondu avec le CSS (feuilles de style), X étant une abréviation commune pour « cross » (croix) en anglais.

Une démo très pédagogique, simple et en images (une animation flash très jolie en fait) en dessous. La faille illustrée correspond apparemment au second type de faille XSS décrit sous Wikipedia.

Principe :

Les risques

Types de failles XSS

Premier type

Second type

Troisième type