¿Cómo prevenir ataques de inyección de código en PHP?

StackOverflow https://stackoverflow.com/questions/1205889

  •  05-07-2019
  •  | 
  •  

Pregunta

Estoy un poco confundido, hay tantas funciones en PHP, y algunas usan esto, otras usan aquello.Algunas personas usan: htmlspecialchars(), htmlentities(), strip_tags() etc.

¿Cuál es el correcto y cuál usáis habitualmente?

¿Es esto correcto (avíseme uno mejor, si corresponde):

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

¿Esta línea puede prevenir la inyección de MySQL y el ataque XSS?

Por cierto, ¿hay otras cosas a las que debo prestar atención además del ataque XSS y la inyección MySQL?

EDITAR

Para concluir:

Si quiero insertar una cadena en la base de datos, no necesito usar htmlentities, solo usa el mysql_real_escape_string.Al mostrar los datos, utilice htmlentities(), ¿Es eso lo que todos queréis decir?

Resumir:

  • mysql_real_escape_string utilizado al insertar en la base de datos
  • htmlentities() Se utiliza al enviar datos a una página web.
  • htmlspecialchars() usado cuando?
  • strip_tags() usado cuando?
  • addslashes() usado cuando?

¿Alguien puede completar el signo de interrogación?

¿Fue útil?

Solución

  
      
  • mysql_real_escape_string usado cuando se inserta en la base de datos
    •   
  • htmlentities() utilizado al enviar datos a la página web
    •   
  • htmlspecialchars() ¿Cuándo se usa?
    •   
  • strip_tags() ¿Cuándo se usa?
    •   
  • addslashes() ¿Cuándo se usa?
    •   

htmlspecialchars () utilizado cuando?

htmlspecialchars es aproximadamente lo mismo que htmlentities. La diferencia: codificaciones de caracteres.

Ambos codifican caracteres de control como <, >, &, etc., utilizados para abrir etiquetas, etc. entities también codifican caracteres de otros idiomas como diéresis, símbolos euro y otros. Si sus sitios web son UTF, use strip_tags, de lo contrario use <b>.

strip_tags () utilizado cuando?

<=> / <=> codifica los caracteres especiales, por lo que se muestran pero no se interpretan . <=> los quita.

En la práctica, depende de lo que necesite hacer.

Un ejemplo: ha codificado un foro y le da a los usuarios un campo de texto para que puedan publicar cosas. Los maliciosos solo intentan: 

pictures of <a href="javascript:void(window.setInterval(function () {window.open('http://evil.com');}, 1000));">kittens</a> here

Si no hace nada, se mostrará el enlace y una víctima que haga clic en el enlace obtendrá muchas ventanas emergentes.

Si htmlentity / htmlspecialchar su salida, el texto estará allí tal cual. Si lo quita, simplemente elimina las etiquetas y lo muestra: 

pictures of kittens here

A veces es posible que desee una mezcla, deje algunas etiquetas allí, como <=> (<=> puede dejar ciertas etiquetas allí). Esto tampoco es seguro, por lo que es mejor usar una biblioteca completa contra XSS.

addlashes

Para citar un antiguo versión del manual de PHP :

  

Devuelve una cadena con barras invertidas antes de los caracteres que se deben citar en las consultas de la base de datos, etc. Estos caracteres son comillas simples ('), comillas dobles ("), barra invertida () y NUL (el NULL byte).

     

Un ejemplo de uso de addlashes () es cuando ingresa datos en una base de datos. Por ejemplo, para insertar el nombre O'reilly en una base de datos, deberá escapar de él. Se recomienda encarecidamente utilizar la función de escape específica de DBMS (por ejemplo, mysqli_real_escape_string () para MySQL o pg_escape_string () para PostgreSQL), pero si el DBMS que está utilizando no tiene una función de escape y el DBMS usa \ para escapar caracteres especiales, usted puede usar esta función.

La versión actual está redactada de manera diferente.

Otros consejos

Pensé en esta lista de verificación rápida:

  • Siempre use HTTPS, sin HTTPS su sitio no está totalmente encriptado . Y no, el cifrado del lado del cliente y el envío no funcionarán, piénselo. Los certificados HTTPS no válidos también lo hacen vulnerable a un MITM ataque . Simplemente use Let's Encrypt si no puede pagar un certificado.
  • Utilice siempre htmlspecialchars() en cualquier salida de su código PHP, es decir, o contiene un entrada del usuario . La mayoría de los motores de plantillas lo ayudan a hacerlo fácilmente.
  • Use el indicador de solo HTTP en su php.ini para evitar que los scripts accedan a sus cookies
  • Prevenir problemas relacionados con la sesión
    • Nunca exponga al usuario PHPSESSID (ID de sesión) fuera de la cookie , si alguien conoce una ID de sesión de otra persona, simplemente puede usarla para iniciar sesión en su cuenta
    • Tenga mucho cuidado con la función Remember me, tal vez muestre una pequeña advertencia.
    • Actualizar ID de sesión cuando el usuario inicia sesión (o lo que sea apropiado)
    • Tiempo de espera de sesiones inactivas
  • Nunca confíe en una cookie, puede ser cambiada, eliminada, modificada y creada por un script / usuario en cualquier momento
  • Prevenir problemas relacionados con SQL
    • Utilice siempre declaraciones preparadas . Las declaraciones preparadas hacen que la entrada del usuario se pase por separado y evita Inyección SQL
    • Haz que tu código arroje una excepción cuando falla. A veces, su servidor SQL puede estar inactivo por alguna razón, las bibliotecas como PDO ignoran ese error de forma predeterminada y registran una advertencia en los registros. Esto hace que las variables que obtiene de la base de datos sean nulas, dependiendo de su código, esto puede causar un problema de seguridad.
    • Algunas bibliotecas como UTF-8 emular declaraciones preparadas. Apaga eso.
    • Use $myquery = "INSERT INTO mydb.mytable (title) VALUES(" . $user_input . ")" codificación en sus bases de datos, le permite almacenar virtualmente cualquier carácter y evitar ataques relacionados con la codificación
    • Nunca concatene nada con su consulta . Cosas como .php significan que tiene un gran riesgo de seguridad de una inyección SQL.
  • Almacene archivos cargados en nombres de archivo aleatorios, sin extensión. Si un usuario carga un archivo con <=> extensión de archivo, cada vez que su código carga ese archivo, lo ejecuta y permite al usuario ejecutar algún código de fondo
  • Asegúrese de no ser vulnerable a un ataque CSRF .
  • Actualice siempre su copia de PHP para garantizar los últimos parches de seguridad y mejoras de rendimiento

Solo codifique datos en el punto en el que ingresa al sistema; debe codificarse para & # 8212; de lo contrario, se encontrará con situaciones en las que desea manipular los datos reales.

Para inyección SQL: use variables enlazadas como se describe en ¿Cómo puedo ¿evitar la inyección de SQL en PHP? (se trata de declaraciones preparadas, pero es el enlace lo que le brinda protección, no la preparación).

Para XSS: si está escribiendo en HTML en el punto donde se especifica HTML o texto. Use htmlentities en el punto donde genera su documento. Evitaría almacenar los datos de esa forma en la base de datos (excepto posible en un sistema de escritura-lectura-lectura frecuente) en el que el rendimiento de la CPU / los tiempos de acceso al disco se estaban volviendo problemáticos, entonces tendría una versión raw_ y html_ de la columna & # 8230; o simplemente use memcached o similar).

Si permite que los usuarios ingresen URL, debe tener más cuidado, ya que javascript:do_evil() es un URI válido que se ejecutará (por ejemplo, como href para un enlace en el que se hizo clic o (en algunos navegadores) el src de una imagen que acaba de cargar).

htmlspecialchars()vueltas &, ', ", <, y > en un formato de entidad HTML (&amp;, &quot;, etc.)

htmlentities()convierte todos los caracteres aplicables a su formato de entidad HTML.

strip_tags()elimina todas las etiquetas HTML y PHP.

Ambos htmlspecialchars() y htmlentities() tome un parámetro opcional que indique cómo se deben manejar las comillas.Véase el Manual de PHP para detalles.

El strip_tags() La función toma un Parámetro opcional que indica qué etiquetas no debe ser despojado.

 $var = strip_tags ($var, '<p><br />');

El strip_tags() La función eliminará incluso etiquetas HTML no válidas, que pueden causar problemas.Por ejemplo,strip_tags() arrancará todos los código que cree que es una etiqueta HTML, incluso si está mal formado, como

<b I forgot to close the tag.

Solo necesita usar mysql_escape_string () al insertar en una base de datos y htmlentites al mostrar el HTML. Esto es suficiente si desea evitar un ataque de inyección simple, pero no hay duda de que debe tener en cuenta muchos otros problemas de seguridad al desarrollar una aplicación web, otro importante es la falsificación de solicitudes entre sitios.

No usaría htmlentities () al insertar datos en la base de datos o consultar la base de datos. Si los datos en su base de datos se almacenan como entidades, esos datos solo son útiles para algo que comprende las entidades html.

Debe usar diferentes mecanismos de escape para diferentes tipos de salida, p. SQL - mysql_real_escape_string () , HTML - htmlentities () o htmlspecialchars () , shell - escapeshellarg () . Esto se debe a que los caracteres que son 'peligrosos' son diferentes para cada uno: no existe una forma mágica de hacer que los datos sean seguros para cualquier medio de salida.

Eche un vistazo a este sitio PHP Security Consortium . Encontré que es un buen sitio para obtener una descripción general de la seguridad de PHP (inyección de SQL y XSS incluidos).

Sé que es una pregunta antigua, pero hoy en día la respuesta más votada puede ser engañosa para los principiantes.

A partir de 2017

  1. Nunca debes usar mysql_real_escape_string. Incluso mysqli_real_escape_string es demasiado débil para proteger su base de datos de las inyecciones de SQL. En lugar de esto, debe usar PDO y técnicas similares. (consulte esa guía )

  2. XSS (aquí quiero decir: strip_tags(), addslashes(), htmlspecialchars(), htmlentities()) - aquí la respuesta más votada sigue siendo correcta, pero sugeriría leer este artículo

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top