PHP: ¿las mejores prácticas de seguridad para la información mostrada?

Question

En PHP, sé que usar parameterized queries es la mejor manera de evitar la inyección de SQL.

Pero ¿qué pasa con la entrada del usuario desinfección que será utilizado para otros fines, tales como:

• Viendo de nuevo a un usuario (potencial de cross-site scripting vector)
• Dirigiéndose a un correo electrónico o rellenando el cuerpo del mensaje

¿Es htmlentities() la mejor manera de desinfectar para el uso sin base de datos? ¿Qué se considera la mejor práctica aquí?

Answer 1

en PHP el mejor filtro XSS es:

htmlspecialchars($_POST['param'],ENT_QUOTES); 

La razón por la que también hay que codificar las citas es becuase que no es necesario <> explotar algunos XSS. Por ejemplo, este es vulnerable a XSS:

print('<A HREF="http://www.xssed.com/'.htmlspecialchars($_REQUEST[xss]).'">link</a>'); 

No es necesario <> para ejecutar Javascript en este caso, porque se puede utilizar onmouseover, aquí es un ataque ejemplo:

$_REQUEST[xss]='" onMouseOver="alert(/xss/)"'; 

los ENT_QUOTES se ocupa de las comillas dobles.

El correo electrónico es un poco diferente, javascript no debe ejecutarse por el cliente de correo, y si es así, su sitio no se verá afectado debido a la Política de Mismo origen. Pero para estar seguro, seguiría usando htmlspecialchars($var,ENT_QUOTES);. SIN EMBARGO, la función de correo de PHP() puede sucumbir a un tipo diferente de vulnerabilidad, se llama inyección CRLF. Aquí hay una vulnerabilidad de ejemplo contra PHP-Nuke. Si tiene una llamada de función como esta: mail($fmail, $subject, $message, $header); Luego debe asegurarse de que un usuario no pueda inyectar \r\n en $ encabezado.

código vulnerable:

$header="From: \"$_GET[name]\" <$ymail>\nX-Mailer: PHP"; 

parcheado:

$_GET[name]=str_replace(array("\r","\n"),$_GET[name]); 
$header="From: \"$_GET[name]\" <$ymail>\nX-Mailer: PHP"; 

Answer 2

Bueno primero puede crear reglas para determinados campos, como el correo electrónico lo único que debe consistir es letras, números, @ (arroba -símbolo, ¿cómo se llama realmente?) y un punto, por lo que no se puede formar un XSS, así que no hay necesidad de desperdiciar recursos usando htmlentities() o htmlspeicalchars().

Answer 3

Es posible que también desee comprobar HTML Purifier, que eliminará cualquier HTML peligroso y lo dejará en una entrada segura. También puede crear sus propias reglas sobre qué HTML permitir/no permitir.

http://htmlpurifier.org/

Answer 4

No,

1) prepararon declaraciones no son una solución para inyección de SQL. En la mayoría de los casos, las declaraciones preparadas implican un enlace variable y, por lo tanto, un escape transparente, que es una forma efectiva de evitar la inyección de SQL.

2) NO desinfecta la entrada - esteriliza salida. Por supuesto, valide la entrada (por ejemplo, asegúrese de que la fecha de inicio sea anterior a la fecha de finalización), pero la representación de los datos solo debe modificarse en el punto donde deja su código PHP. El método para desinfectar los datos escritos directamente en HTML es diferente de cómo desinfectar los datos escritos en una URL es diferente de cómo desinfectar los datos para escribirlos en una variable de cadena de JavaScript es diferente de cómo desinfectar los datos para insertarlos en una declaración SQL. diferente de cómo desinfecta los datos antes de enviarlos al módem es ...

... ¿qué vas a hacer? crear todas las posibles representaciones de los datos? Crear una representación universal de los datos?

http://xkcd.com/327/

C.