$ _GET inyección a través de la URL?

Question

$ _GET inyección a través de la URL?

#1 de Anders (4 votos)
#2 de Tom (2 votos)
#3 de codeur (0 votos)

1

Estoy construyendo un sitio web, y me preguntaba qué pasaría si dejara mi comando $_GET sin supervisión en un caso simple como este:

<?php
if (isset($_GET['example'])) {
    $object_name = $_GET['example'];
}else{
    header( 'Location: ./index.php');
    exit();
}
echo $object_name;
?>

Donde estoy ingresando algo para la url www.example.com/file.php?example=30 ¿Hay algo que pueda reemplazar con 30 que me dé acceso para escribir código directamente en el backend del sitio web u otras cosas malas?

Además, si no hubiera impreso allí pero pasara esa variable a algo más complicado, ¿existe algún riesgo de dejarla sin supervisión? ¿Cuál es el mejor método de saneamiento? ¿ htmlentities() detendría todo?

xss php injection

pregunta Anders 13.02.2017 - 21:44

fuente

3 respuestas

2

Problemática es lo que le sucede a esa variable más adelante en el código.

Si se está utilizando para una consulta SQL, puede ser vulnerable a una inyección SQL.

Si reproduce la variable, la secuencia de comandos podría agregarse a la URL que se está ejecutando.

Recomendaría htmlspecialchars () para el saneamiento de PHP y mysqli_real_escape_string / prepare declaraciones para el saneamiento para consultas de base de datos

respondido por el Tom 13.02.2017 - 21:50

fuente

0

No confíe en la entrada del usuario. De acuerdo con su código, no santificó el valor de $ _GET. Por lo tanto, es altamente vulnerable y puede provocar muchas vulnerabilidades de tipo como LFI, RFI, RCE.

respondido por el codeur 15.02.2017 - 09:33

fuente

Lea otras preguntas en las etiquetas xss php injection

¿Es cierta la historia sobre la visita de la policía a Google para cocinar ollas a presión? [cerrado] ¿Tor puede garantizar el anonimato al descargar torrents?

score 4 · Accepted Answer

Lo que tu ejemplo básicamente hace es devolverle lo que le des. Eso significa que un atacante podría crear un enlace con algo de contenido en la URL, y quien haga clic en el enlace recibirá el contenido que el atacante eligió.

Entonces, ¿cómo puede usarse eso, aparte de para avergonzarte ligeramente? Eso depende del tipo de contenido. Como no se especifica nada más, asumo que es text/html . Si un atacante puede servir HTML, también puede servir scripts que se ejecutarán en el navegador como si fueran de su origen. Esto a su vez significa que la secuencia de comandos podría, por ejemplo, robar cookies de autenticación, contraseñas de registro o realizar acciones en nombre de la víctima. Lo que tienes aquí es un excelente ejemplo de XSS reflejado , y eso es muy , muy mal.

¿Pero el atacante podría ejecutar el código en el backend, es decir, el servidor? No, no directamente. La respuesta se envía al cliente, después de todo. Pero esto podría usarse como un trampolín para una escalada de privilegios que podría llevar fácilmente a eliminar la ejecución del código si existe algún tipo de debilidad en cualquier aplicación web que esté utilizando, por ejemplo. Permite a los administradores modificar el código PHP.

Entonces, ¿cómo sanear? Esa es una pregunta muy amplia para responder en su totalidad aquí, pero permítame decir al menos esto: htmlentities() lo protegerá en algunos casos, pero no todos . Para comprender cuándo es útil y por qué, lea su documentación y OWASP hoja de trucos de prevención de XSS .

Como se señaló en la respuesta de Tom , hacer otras cosas con los datos no saneados dará lugar a otros problemas, por ejemplo. Inyección SQL si lo usa en consultas SQL.