En PHP, siempre lo he usado para representar entradas y áreas de texto:
$foo = trim(htmlentities($_POST['foo'], ENT_QUOTES); // the trim is to prevent empty submissions
¿También puede ser válido para evitar ataques de inyección SQL?
En PHP, siempre lo he usado para representar entradas y áreas de texto:
$foo = trim(htmlentities($_POST['foo'], ENT_QUOTES); // the trim is to prevent empty submissions
¿También puede ser válido para evitar ataques de inyección SQL?
Su declaración de SQL:
select * from foo where numerical_id=$foo;
La solicitud POST
foo=1;drop%20table%20foobar;
El valor resultante en $foo
foo=1;drop table foobar;
La declaración SQL resultante
select * from foo where numerical_id=foo=1;drop table foobar;
¿También puede ser válido para prevenir SQLIs?
Obviamente no.
En cuanto al XSS: Tu PHP:
<?php
$foo = trim(htmlentities($_POST['foo'], ENT_QUOTES));
print "<script>numerical_id=$foo;</script>"
?>
La solicitud POST
foo=10;document.write(...)
El resultado
<script>numerical_id=10;document.write(...)</script>
Ya que no puedes usar comillas en ... , puedes construir tus cadenas con String.fromCharCode o similar, por lo que no es necesario dar una cadena entre comillas.
¿Esto puede prevenir XSS?
Obviamente también no, al menos no general XSS.
En general: El contexto diferente tiene reglas de escape diferentes .
htmlentities es útil para el contexto HTML, pero no para el contexto URL, el contexto JS, el contexto CSS, el contexto SQL ... Y se vuelve más complejo, ya que agregar código dinámicamente a un atributo onclick tiene tanto contexto HTML como JS.