[Pregunta]: ¿Anti-XSS y Anti-Inject?

[Leguim]

Buenos días,
¿Qué funciones me recomiendan para poder "limpiar" datos que serán usados en consultas SQL? (Evitar inyecciones SQL)
Uso las consultas "prepare" tengo entendido que ya al usar consultas prepare lo que hace es evitar inyecciones, pero no soy alguien que me guste ahorrar en términos de seguridad.

¿Qué funciones me recomiendan para poder "limpiar" código HTML? (Evitar ataques XSS)

Mi función Clearn_Data($data) la uso siempre tanto cuando guardo datos en las bases de datos (consultas) o cuando voy a expulsar código HTML.

Código (php) [Seleccionar] Expandir


function Clearn_Data($data)
{
$data = htmlspecialchars($data);
$data = trim($data);
$data = stripslashes($data);

return $data;
}


En post pasado me dijeron que mi función clearn data no es muy buena que digamos o segura que digamos..el post es de Julio acá se los dejo para poder meterlos en contexto:
https://foro.elhacker.net/php/pregunta_iquestcomo_pasar_utf8_datos_php-t497595.0.html;msg2199671

Gracias.

[WHK]

Hola, muchas personas cometen el mismo error, tu función tiene vulnerabilidades.

Las inyecciones SQL se previenen escapando los caracteres cuando son ejecutadas las consultas sql, los xss se previenen utilizando htmlentities, pero cuando unes ambas cosas, por ejemplo, un filtro de inyección sql para evitar un xss o un filtro de xss para evitar una inyección sql abre agujeros de seguridad porque las funciones no están diseñadas para eso.

Debes utilizar cada función de filtro en su caso en particular. Cuando vayas a consultar vía SQL debes escapar caracteres con mysql_real_escape_string() o parametrizar, cuando vayas a exponer información hacia afuera en una pagina html debes usar htmlepecialchars(), si vas a escapar en una dirección url debes usar urlencode() y así.

Saludos.

[Leguim]

Hola, muchas personas cometen el mismo error, tu función tiene vulnerabilidades.

Las inyecciones SQL se previenen escapando los caracteres cuando son ejecutadas las consultas sql, los xss se previenen utilizando htmlentities, pero cuando unes ambas cosas, por ejemplo, un filtro de inyección sql para evitar un xss o un filtro de xss para evitar una inyección sql abre agujeros de seguridad porque las funciones no están diseñadas para eso.

Debes utilizar cada función de filtro en su caso en particular. Cuando vayas a consultar vía SQL debes escapar caracteres con mysql_real_escape_string() o parametrizar, cuando vayas a exponer información hacia afuera en una pagina html debes usar htmlepecialchars(), si vas a escapar en una dirección url debes usar urlencode() y así.

Saludos.

¡Hola, WHK!

Código (php) [Seleccionar] Expandir


function Clearn_Data($data) // Inyecciones SQL
{
      mysql_real_escape_string($data);
      trim($data);

      return $data;
}

function Clearn_HTML($html) // Cuando vaya a expulsar código HTML (XSS)
{
      $html = htmlspecialchars($html);
      $html = trim($html);
      $html = stripslashes($html);
     
      return $html;
}

function Clearn_URL($url) // Cuando vaya a guardar una URL en una base de datos
{
    $url = urlencode($url);
    return $url;
}


Así está esto bien aplicado?

[WHK]

Hola, si en parte, porque usas stripslashes? antiguamente php lo necesitaba pero eso ya no se hace, las versiones de php 5 en adelante ya no agregan los backslashes en los parámetros.

Ojo, usa el trim en cada situación, no de manera genérica, por ejemplo si usas trim para guardar el valor binario del hash de una contraseña puede que elimine algunos bytes.

Mejor usa cada función de manera directa en cada caso en ves de crear una función que retorna otra función, así te acostumbras a utilizar las funciones nativas de php.

Si vas a usar php puedes probar codeigniter y active record, de esa manera no necesitarás crear las consultas sql de manera manual y tu aplicación será compatible con distintos tipos de bases de datos.

Saludos.

[Leguim]

Lo que hago con las passwords es

Código (php) [Seleccionar] Expandir


$password = Clearn_Data ($_POST ['password']);

$password = cifrar ($password);


Primero limpio la contraseña, que por el momento no está cifrada... Después la cifro..

¿Así no habría problema? ¿no?

[WHK]

Pues ahi tienes un problema ya que estas escapando o limpiando la contraseña y luego creando el hash, eso quiere decir que el hash equivale a la contraseña limpiada y eso puede provocar problemas al momento de intentar acceder después.

Saludos.

[Leguim]

Lo puse en pastebin por que me da error en el foro, acá esta mi respuesta:

https://pastebin.com/LVBANWfB

[@XSStringManolo]

Lo puse en pastebin por que me da error en el foro, acá esta mi respuesta:

https://pastebin.com/LVBANWfB

Si la función que usas para parsesr es segura, hacer eso solo parseas 1 vez por caracter.

Yo haría un bucle de parsear mientras el resultado del parseo tenga algo que parsear. Si solo parseas una vez, en ciertos casos se pueden meter codificaciones dobles.

También ten cuidado con palabras clave, no solo con caracteres. Y también en donde escribes el resultado.

De todas formas hay tantos tipos de inyecciones y vulns... Nadie te va a dar la solucción a todas ellas.

Lo mejor es que saques una versión alfa de tu web con datos falsos de cuentas, etc. Y establezcas un programa atractivo de bughunting para que usuarios random te reporten los bugs en tu aplicación web antes de hacer deployment. En vez de pagar, puedes añadir un easteregg, funcionalidades exclusivas, más opciones de configuración, etc. Con el objetivo de premiar y agradecer a quienes reporten vulnerabilidades en tu sitio.

Después anúncialo por varios sitios.

Yo haría algo tipo:
example.com/alfa/bughunting.html

Bievenido blablabla
...
...

Recompensas:
Fallos muy graves:
Mención en - example.com/honor.html
Medalla diamante en - example.com/Miperfil.html
Funcionalidades extra en - example.com/Miperfil.html
...

Fallos graves:
...


Fallos a buscar:
Todos los fallos de seguridad en aplicación.
Comportamientos extraños o indevidos.
...

Cómo buscar:
No utilizar herramientas o realizar tareas que consuman muchos recursos del servidor o banda ancha.
...

Reporta los fallos a:
seguridad@example.com

Sugerencias a:
sugerencias@example.com

También puedes testear tú la applicación.
En dudas generales hay un post llamado libros para principiantes con libros de hacking y seguridad web que puedes usar como referencia.

Yo de vez en cuando voy leyendo libros y cada vez me encuentro un montón de fallos de seguridad que no tenía ni la menor idea de que podían suceder.
Y más de lo mismo para el servidor o las redes.