Iniezione SQL ASP.NET

Question

Iniezione SQL ASP.NET

#1 da (4 voti)
#2 da (2 voti)

3

Ho un sistema di autenticazione personalizzato sul mio sito Web ASP.NET che può aiutarmi a registrare utenti dalle mie applicazioni Windows (desktop) e mobili (Android). Significa che non utilizzo la configurazione di ASP.NET.

Ho questo codice quando l'utente preme il pulsante di accesso.

    SqlConnection con = new SqlConnection();
    con.ConnectionString = ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString;
    SqlCommand com = new SqlCommand();
    con.Open();
    com.Connection = con;
    com.CommandText = "SELECT * FROM [Users-Users] WHERE (Password=@Password) AND (Username=@Username) ";
    com.Parameters.AddWithValue("Password", System.Web.HttpUtility.HtmlEncode(PasswordTextBox.Text));
    com.Parameters.AddWithValue("Username", System.Web.HttpUtility.HtmlEncode(UsernameTextBox.Text));
    SqlDataReader data = com.ExecuteReader();
    if (data.Read())
    {
        //Logged in successfully here I have redirect options
    }

Puoi vedere che ho qui la codifica HTML che può fare questi:

    &amp;  → & (ampersand, U+0026)
    &lt;   → < (less-than sign, U+003C)
    &gt;   → > (greater-than sign, U+003E)
    &quot; → " (quotation mark, U+0022)
    &apos; → ' (apostrophe, U+0027)

Quindi possiamo accedere senza password usando Sql Injection? per esempio →

username textbox :admin
password textbox :pass" OR 1=1

sql-injection

posta 06.08.2013 - 12:08

fonte

2 risposte

2

When accessing a content provider, use parameterized query methods such as query(), update(), and delete() to avoid potential SQL injection from untrusted sources. Note that using parameterized methods is not sufficient if the selection argument is built by concatenating user data prior to submitting it to the method. (Android Security Tips)

Per impedire l'iniezione SQL:

All queries should be parametrized.
All dynamic data should be explicitly bound to parametrized queries.
String concatenation should never be used to create dynamic SQL.

utilizzando le istruzioni parametrizzate il database è in grado di distinguere tra ciò che si intende essere dati e ciò che si intende essere un comando, quindi anche se un utente malintenzionato inserisce un input malevolo, questo input verrà considerato come dati e non interpretato come un comando.

risposta data 06.08.2013 - 13:57

fonte

Leggi altre domande sui tag sql-injection

È corretto generare un token per una carta di credito senza il permesso dell'utente? È compatibile con PCI? Sono necessari firewall locali

score 4 · Accepted Answer

Stai utilizzando le query parametrizzate in modo coerente per tutti i valori delle variabili, quindi non c'è attacco SQL injection.

Tuttavia, la memorizzazione dei valori del database nel formato con codifica HTML è un antipattern. Sarà difficile elaborare i dati a livello SQL (poiché un carattere da 1 db non equivale più a un carattere in-page), producerai output codificati in modo non appropriato per i formati non HTML (ad esempio, l'invio di posta), e tu Non riuscirò a codificare in HTML correttamente tutti i dati che entrano nel database con altri mezzi (o che non tocchino affatto il database, ad esempio un output di Parameter direttamente sulla pagina).

Il tempo per la codifica HTML è quando si rilascia del testo in una pagina HTML. Nei modelli ASP.NET ottieni il tag <%: ... %> per farlo automaticamente, così come gli attributi di WebForm che fanno la cosa giusta (attenzione: non sempre ). La codifica HTML non dovrebbe essere eseguita come un processo di elaborazione di input o di creazione di query di database perché questi luoghi non hanno nulla a che fare con HTML.

Ovviamente dovresti anche memorizzare le password usando un hash salato (idealmente un strong come bcrypt) e non in chiaro come implicito nel confronto Password=@Password .