In PHP, ho sempre usato questo per rappresentare input e textareas:
$foo = trim(htmlentities($_POST['foo'], ENT_QUOTES); // the trim is to prevent empty submissions
Può essere valido anche per prevenire attacchi di SQL injection?
In PHP, ho sempre usato questo per rappresentare input e textareas:
$foo = trim(htmlentities($_POST['foo'], ENT_QUOTES); // the trim is to prevent empty submissions
Può essere valido anche per prevenire attacchi di SQL injection?
La tua istruzione sql:
select * from foo where numerical_id=$foo;
La richiesta POST
foo=1;drop%20table%20foobar;
Il valore risultante in $foo
foo=1;drop table foobar;
L'istruzione SQL risultante
select * from foo where numerical_id=foo=1;drop table foobar;
Can it also be valid to prevent SQLIs?
Ovviamente no.
Come per XSS: il tuo PHP:
<?php
$foo = trim(htmlentities($_POST['foo'], ENT_QUOTES));
print "<script>numerical_id=$foo;</script>"
?>
La richiesta POST
foo=10;document.write(...)
Il risultato
<script>numerical_id=10;document.write(...)</script>
Poiché non puoi utilizzare le virgolette in ... puoi costruire le tue stringhe con String.fromCharCode o simili, quindi non è necessario fornire una stringa tra virgolette.
Can this prevent XSS?
Ovviamente anche no, almeno non XSS generico.
In generale: Contesto diverso ha regole di escape diverse .
htmlentities è utile per il contesto HTML, ma non per il contesto URL, contesto JS, contesto CSS, contesto SQL .... E diventa più complesso, ad esempio l'aggiunta dinamica del codice a un attributo onclick ha sia il contesto HTML che JS.