¿htmlspecialchars y mysql real escape string mantienen mi código PHP a salvo de la inyección?

Además de la excelente respuesta de Cheekysoft:

• Sí, te mantendrán a salvo, pero solo si se usan correctamente. Si los usa incorrectamente, seguirá siendo vulnerable y puede tener otros problemas (por ejemplo, corrupción de datos)
• Por favor, utilice consultas parametrizadas en su lugar (como se indicó anteriormente). Puede usarlos a través, por ejemplo, de PDO o a través de una envoltura como PEAR DB
• Asegúrese de que magic_quotes_gpc y magic_quotes_runtime estén desactivados en todo momento, y nunca accidentalmente se encendió, ni siquiera brevemente. Estos son un intento temprano y profundamente equivocado por los desarrolladores de PHP para evitar problemas de seguridad (que destruye los datos)

No hay realmente una bala de plata para prevenir la inyección de HTML (por ejemplo, cross site scripting), pero es posible que pueda lograrlo más fácilmente si está utilizando una biblioteca o un sistema de plantillas para generar HTML. Lea la documentación para eso para saber cómo escapar de las cosas apropiadamente.

En HTML, las cosas deben ser escapó de manera diferente dependiendo del contexto. Esto es especialmente cierto de las cadenas que se colocan en Javascript.

Definitivamente estaría de acuerdo con los mensajes anteriores, pero tengo una pequeña cosa que agregar en respuesta a la respuesta de Cheekysoft, específicamente:

Cuando se trata de consultas de base de datos, siempre trate de usar preparado consultas parametrizadas. El mysqli y Las bibliotecas PDO soportan esto. Esto es infinitamente más seguro que usar escape funciones tales como mysql_real_escape_string.

Sí, mysql_real_escape_string es efectivamente solo una cadena de escape función. No es una magia bala. Todo lo que hará es escapar peligroso personajes para que puedan ser seguro de usar en una sola cadena de consulta. Sin embargo, si usted no desinfecta su entradas de antemano, entonces usted será vulnerable a ciertos vectores de ataque.

Imagine el siguiente SQL:

Result result = " SELECCIONAR campos DE LA tabla DONDE id = ".mysql_real_escape_string($_POST['id']);

Usted debe ser capaz de ver que esto es vulnerable a la explotación. Imagine la identificación parámetro contener el ataque común vector:

1 O 1=1

No hay caracteres riesgosos allí para codificar, por lo que pasará recto a través del filtro de escape. Dejar nosotros:

SELECCIONE campos DE LA tabla DONDE id = 1 O 1 = 1

Codifiqué una pequeña función rápida que puse en mi clase de base de datos que eliminará cualquier cosa que no sea un número. Utiliza preg_replace, por lo que hay prob un poco más función optimizada, pero funciona en un pizca...

function Numbers($input) {
  $input = preg_replace("/[^0-9]/","", $input);
  if($input == '') $input = 0;
  return $input;
}

Así que en lugar de usar

Result result = "SELECCIONAR campos DE LA tabla DONDE id = ".mysqlrealescapestring("1 or 1=1");

Usaría

Result result = "SELECCIONAR campos DE LA tabla DONDE id = ".Números ("1 O 1=1");

Y ejecutaría con seguridad la consulta

SELECCIONE campos DE LA tabla DONDE id = 111

Seguro, que sólo dejó de mostrar la fila correcta, pero no creo que es un gran problema para quienquiera que esté tratando de inyectar sql en su sitio;)

Una pieza importante de este rompecabezas son los contextos. Alguien que envía "1 O 1=1" como ID no es un problema si cita cada argumento en su consulta:

SELECT fields FROM table WHERE id='".mysql_real_escape_string($_GET['id'])."'"

Que resulta en:

SELECT fields FROM table WHERE id='1 OR 1=1'

Que es ineficaz. Dado que está escapando la cadena, la entrada no puede salir del contexto de la cadena. He probado esto hasta la versión 5.0.45 de MySQL, y usar un contexto de cadena para una columna entera no causa ningún problema.

$result = "SELECT fields FROM table WHERE id = ".(INT) $_GET['id'];

Funciona bien, incluso mejor en sistemas de 64 bits. Sin embargo, tenga cuidado con las limitaciones de sus sistemas para abordar grandes números, pero para los ID de base de datos esto funciona muy bien el 99% del tiempo.

También debe usar una sola función/método para limpiar sus valores. Incluso si esta función es solo una envoltura para mysql_real_escape_string (). ¿Por qué? Porque un día, cuando se encuentra un exploit para su método preferido de limpieza de datos, solo tiene que actualizarlo en un lugar, en lugar de un sistema en todo el sistema buscar y reemplazar.

¿Por qué, oh POR QUÉ, usted no incluiría comillas alrededor de la entrada del usuario en su sentencia sql? ¡parece una tontería no hacerlo! incluir comillas en su sentencia sql haría que "1 o 1 = 1" fuera un intento infructuoso, ¿no?

Así que ahora, dirás, "¿qué pasa si el usuario incluye una comilla (o comillas dobles) en la entrada?"

Bueno, solución fácil para eso: simplemente elimine las comillas de entrada del usuario. eg: input =~ s/'//g;. ahora, me parece de todos modos, que la entrada del usuario estaría asegurada...