embebido - ¿Ejemplos de código PHP vulnerable?

php<?= ?>

Question

Bueno, un amigo y yo estamos haciendo una mini presentación sobre la seguridad de PHP (aunque no estoy realmente interesado en PHP) y me pidió que encontrara algunos ejemplos de código PHP vulnerable (uno que sea propenso a las inyecciones de SQL y todos los demás tipos de ataques). ). Me preguntaba si hay sitios web con partes de código buenas y malas que muestren cómo debe y no debe codificar.

Básicamente, los pondré en nuestro sitio web y él intentará piratearlo, luego mostraremos el sitio web "correcto" e intentará piratearlo nuevamente.

Answer 1

CSRF para la victoria.

<?php
$newEmail = filter_input(INPUT_POST, ''email'', FILTER_SANITIZE_EMAIL);
$pdoStatement = $pdoDb->prepare(''UPDATE user SET email=:email WHERE ID=:id'');
$pdoStatement->execute(array('':email''=>$newEmail, '':id''=>$_SESSION[''userId'']));

Te sientes seguro con este tipo de código. Todo está bien: sus usuarios pueden cambiar sus correos electrónicos sin inyectar SQL debido a su código. Pero, imagine que tiene esto en su sitio http: // siteA / , uno de sus usuarios está conectado. Con el mismo navegador, va a http: // siteB / donde algunos AJAX hacen el equivalente de este código:

<form method="post" action="http://site/updateMyAccount.php">
  <p>
    <input name="email" value="badguy@siteB"/>
    <input type="submit"/>
  </p>
</form>

Tu usuario acaba de cambiar su correo electrónico sin que él lo sepa. Si no crees que este tipo de ataque es peligroso, pregúntale a Google sobre ello.

Para ayudar contra este tipo de ataques, puedes:

• Revise su usuario REFERER (lejos de ser perfecto)
• Implemente algunos tokens que tenía en sus formularios y verifique su presencia cuando recupere sus datos.

Otro es el secuestro de sesión. Uno de los métodos para hacerlo es llevar a cuestas. Si su servidor acepta sesiones que no son cookies, puede tener URL como http: // siteA /? PHPSESSID = blabla, lo que significa que su ID de sesión es blabla.

Un atacante puede iniciar una sesión y anotar su ID de sesión, luego dar el enlace http: // siteA /? PHPSESSID = attackerSessionId a otros usuarios de su sitio web. Cuando estos usuarios siguen este enlace, comparten la misma sesión que su atacante: una sesión no registrada. Así que inician sesión. Si el sitio web no hace nada, su atacante y su usuario siguen compartiendo la misma sesión con los mismos derechos. Mala cosa si el usuario es un administrador.

Para mitigar esto, debe usar session_regenerate_id cuando cambien las credenciales de sus usuarios (iniciar y cerrar sesión, ir a la sección de administración, etc.).

Answer 2

Echa un vistazo al proyecto de seguridad de aplicaciones web abiertas. Tienen explicaciones y ejemplos de muchos tipos diferentes de ataques. http://www.owasp.org/index.php/Category:Attack

Answer 3

He visto un código como este escrito en el pasado:

foreach ($_REQUEST as $var => $val) {
    $$var = $val;
}

Es una forma de simular la opción malvada de register_globals . Significa que puedes acceder a tus variables de esta manera:

$myPostedVar

En lugar de lo terriblemente más complicado:

$_POST[''myPostedVar'']

El riesgo de seguridad aparece en situaciones como esta:

$hasAdminAccess = get_user_access();

foreach ($_REQUEST as $var => $val) {
    $$var = $val;
}

if ($hasAdminAccess) { ... }

Ya que todo lo que tendría que hacer es agregar ?hasAdminAccess=1 a la url, y ya está.

Answer 4

La manera INCORRECTA de hacer plantillas.

<?php

  include("header.php");
  include($_GET["source"]); //http://www.mysite.com/page.php?source=index.php
  include("footer.php");

?>

Answer 5

Las operaciones básicas (a menudo sensibles a la seguridad) no funcionan como se esperaba, en su lugar requieren que el programador use una segunda versión "real" para obtener una funcionalidad no rota.

El más grave de estos sería cuando un operador real se ve afectado: el operador "==" no funciona como cabría esperar, en lugar del operador "===" se necesita para obtener una comparación de igualdad real.

Uno de los paquetes grandes del foro de PHP 3 se vio afectado por una vulnerabilidad en su código de "permanecer conectado". La cookie contendría la ID del usuario y su hash de contraseña. La secuencia de comandos de PHP leerá y limpiará el ID, lo usará para consultar el hash correcto del usuario en la base de datos y luego lo comparará con el de la cookie para ver si deberían iniciar sesión automáticamente.

Sin embargo, la comparación fue con ==, por lo que al modificar la cookie, un atacante usa un "valor" de hash de boolean: true, haciendo que la comparación de hash sea inútil. De este modo, el atacante podría sustituir cualquier ID de usuario para iniciar sesión sin una contraseña.

Answer 6

Las vulnerabilidades de XSS son fáciles de mostrar. Simplemente cree una página que ponga el valor de la variable GET "q" en algún lugar de la página y luego presione la siguiente URL:

http://mysite.com/vulnerable_page.php?q%3D%3Cscript%20type%3D%22javascript%22%3Ealert(document.cookie)%3B%3C%2Fscript%3E

Esto hará que las cookies del usuario se muestren en un cuadro de alerta.

Answer 7

Oh chico, no te faltarán ejemplos. Solo el tutorial de PHP de Google y cada uno de ellos tiene los agujeros suficientes para llenar el Albert Hall.

Resultado 1, w3schools. ¿Cuál es su primer ejemplo para incluir la entrada del usuario?

Welcome <?php echo $_POST["fname"]; ?>!<br />

Bzzt. Inyección de HTML, repetida en cada pieza de código de ejemplo. ¿Cuál es su primera consulta de base de datos?

$sql="INSERT INTO Persons (FirstName, LastName, Age) VALUES (''$_POST[firstname]'',''$_POST[lastname]'',''$_POST[age]'')";

Bzzt. Inyección de SQL, se pierde. Siguiente.

Resultado 2, tutorial oficial de PHP. ¿Cuál es el primer ejemplo de salida de una variable?

echo $_SERVER[''HTTP_USER_AGENT''];

Bzzt. Inyección de HTML. No es una práctica fácil de explotar, pero aún así, es una mala práctica que se repite en todos los materiales de aprendizaje de php.net.

Resultado 3, tizag.com. ¿Cuál es el primer ejemplo de eco de la entrada del usuario?

echo "You ordered ". $quantity . " " . $item . ".<br />";

Bzzt.

Resultado 4, freewebmasterhelp.com. Demasiado básico para incluir mucho, pero aún maneja:

print "Hello $name"; // Welcome to the user

Bzzt.

Resultado 5, learnphp-tutorial.com.

<title><?= $greeting ?> World!</title>

Bz ...

Podría seguir.

¿Es de extrañar que la calidad general del código PHP en el mundo salvaje sea tan desastrosa, cuando esta desgracia es lo que los codificadores están aprendiendo?

Answer 8

Otro ejemplo de un script de inicio de sesión vulnerable a la inyección de SQL. Desafortunadamente esto es muy común entre los nuevos programadores.

$username = $_POST["username"];
$password = $_POST["password"];
$query = "SELECT username, password 
          FROM users 
          WHERE (username = ''{$username}'') 
            AND (password = ''{$password}'')";

Answer 9

Permitiendo subir y no comprobar extensión. Observar:

El sitio A permite subir imágenes y las muestra.

Cracker guy carga un archivo y le hace creer que es un archivo de imagen (a través de tipos MIME HTTP). Este archivo tiene extensión PHP y contiene código malicioso. Luego trata de ver su archivo de imagen y, como cada archivo ejecutado por PHP es ejecutado por PHP, se ejecuta el código. Él puede hacer cualquier cosa que el usuario de apache pueda hacer.

Answer 10

Permitir que las personas carguen archivos, ya sea que la API deba ser utilizada por los usuarios o no. Por ejemplo, si un programa carga algunos archivos en un servidor, y ese programa nunca cargará un archivo malo, está bien.

Pero un hacker podría rastrear lo que se está enviando y hacia dónde. Podría descubrir que está permitiendo que se carguen archivos.

A partir de ahí, él podría fácilmente subir un archivo php. Una vez hecho esto, se acabó el juego. Ahora tiene acceso a todos sus datos y puede destruir o cambiar lo que quiera.

Otro error común es permitir inundaciones. Debe poner algunos límites sanos a sus datos. No permita que los usuarios ingresen datos sin sentido. ¿Por qué el nombre de un usuario tiene 2 MB de longitud? Cosas como esas hacen que sea tan fácil para alguien inundar su base de datos o sistema de archivos y bloquear el sistema debido a errores de espacio.

Answer 11

Un error muy común de un principiante es olvidar terminar la ejecución del script después de una redirección.

<?php
if ($_SESSION[''user_logged_in''] !== true) {
    header(''Location: /login.php'');
}

omg_important_private_functionality_here();

La solución:

if ($_SESSION[''user_logged_in''] !== true) {
    header(''Location: /login.php'');
    exit();
}

Esto se puede perder cuando se realiza la prueba en un navegador normal, ya que los navegadores generalmente siguen el encabezado de la Location sin presentar ningún resultado de la secuencia de comandos.

Answer 12

La inyección de SQL es fácil:

$var = $_POST[''var''];
mysql_query("SELECT * FROM sometable WHERE id = $var");

Esto es fácilmente resuelto por:

$var = mysql_real_escape_string($_POST[''var'']);

El otro común es XSS (secuencias de comandos entre sitios) :

$var = $_POST[''var''];
echo "<div>$var</div>/n";

le permite inyectar Javascript que se ejecuta desde su sitio. Hay varias maneras de lidiar con esto, por ejemplo:

$var = strip_tags($_POST[''var'']);

y

$var = filter_var($_POST[''var''], FILTER_SANITIZE_STRING);

Answer 13

DailyWTF de hoy :

if(strstr($username, ''**'')) {

    $admin = 1;
    $username = str_replace(''**'', '''', $username);
    $_SESSION[''admin''] = 1;

} else {

    $admin = 0;

}

Answer 14

Los ataques de inyección de encabezado de correo electrónico son un dolor mucho mayor en el cuello del que puede sospechar (a menos que haya tenido que lidiar con ellos).

Esto es muy malo:

$to = ''[email protected]'';
$subject = $_POST["subject"];
$message = $_POST["message"];
$headers = "From: ".$_POST["from"];
mail($to,$subject,$message,$headers);

(código copiado de la segunda referencia anterior.)

Answer 15

Ataque de división de respuesta HTTP

Si la aplicación web está almacenando la entrada de una solicitud HTTP en una cookie, digamos

<?php setcookie("author",$_GET["authorName"]); ?>

Es muy propenso a un ataque de división de respuesta HTTP si la entrada no se valida correctamente para los caracteres "/ r / n".

Si un atacante envía una cadena maliciosa, como "AuthorName / r / nHTTP / 1.1 200 OK / r / n ..", la respuesta HTTP se dividirá en dos respuestas de la siguiente forma:

HTTP / 1.1 200 OK
...
Set-cookie: author = AuthorName

HTTP / 1.1 200 OK ...

Claramente, la segunda respuesta está completamente controlada por el atacante y puede construirse con cualquier encabezado y contenido de cuerpo.

Answer 16

Mesas de bobby

Bobby Tables es una página dedicada a detallar las formas en que un script puede ser vulnerable a través de la inyección de SQL . Esto no es exclusivo de PHP, sin embargo, la inyección de SQL es la causa de muchas vulnerabilidades de las páginas web.

Puede ser algo que quieras incluir en tu presentación.