SQL injection<\/strong><\/p>\n\n\n\n Cos\u2019\u00e8 l\u2019 SQL injection (SQLi)?<\/strong><\/p>\n\n\n\n SQL injection (SQLi) \u00e8 una vulnerabilit\u00e0 della sicurezza Web che consente a un utente malintenzionato di interferire con le query che un\u2019applicazione effettua al proprio database. Generalmente consente a un utente malintenzionato di visualizzare dati che normalmente non \u00e8 in grado di recuperare. Ci\u00f2 potrebbe includere dati appartenenti ad altri utenti o qualsiasi altro dato a cui l\u2019applicazione stessa \u00e8 in grado di accedere. In molti casi, un utente malintenzionato pu\u00f2 modificare o eliminare questi dati, causando modifiche persistenti al contenuto o al comportamento dell\u2019applicazione.<\/p>\n\n\n\n In alcune situazioni, un utente malintenzionato pu\u00f2 intensificare un attacco SQL injection per compromettere il server sottostante o un\u2019altra infrastruttura back-end oppure eseguire un attacco denial-of-service.<\/p>\n\n\n\n Qual \u00e8 l\u2019impatto di un attacco SQL injection riuscito?<\/strong><\/p>\n\n\n\n Un attacco SQL injection riuscito pu\u00f2 comportare l\u2019accesso non autorizzato a dati sensibili, come password, dettagli della carta di credito o informazioni personali dell\u2019utente. Molte violazioni dei dati di alto profilo negli ultimi anni sono state il risultato di attacchi SQL injection, che hanno portato a danni alla reputazione e multe normative. In alcuni casi, un utente malintenzionato pu\u00f2 ottenere una backdoor persistente nei sistemi di un\u2019organizzazione, portando a una compromissione a lungo termine che pu\u00f2 passare inosservata per un periodo prolungato.<\/p>\n\n\n\n Come rilevare le vulnerabilit\u00e0 di SQL injection<\/strong><\/p>\n\n\n\n La maggior parte delle vulnerabilit\u00e0 di SQL injection pu\u00f2 essere trovata in modo rapido e affidabile utilizzando lo scanner di vulnerabilit\u00e0 Web di Burp Suite<\/a>.<\/p>\n\n\n\n L\u2019SQL injection pu\u00f2 essere rilevata manualmente utilizzando una serie sistematica di test su ogni punto di ingresso nell\u2019applicazione. Ci\u00f2 comporta in genere:<\/p>\n\n\n\n SQL injection in diverse parti della query<\/strong><\/p>\n\n\n\n La maggior parte delle vulnerabilit\u00e0 di SQL injection si verifica all\u2019interno della clausola WHERE <\/em>di una query SELECT<\/em>. Questo tipo di SQL injection \u00e8 generalmente ben compreso dai tester esperti.<\/p>\n\n\n\n Ma le vulnerabilit\u00e0 di SQL injection possono in linea di principio verificarsi in qualsiasi posizione all\u2019interno della query e all\u2019interno di diversi tipi di query. Le altre posizioni pi\u00f9 comuni in cui si verifica l\u2019iniezione SQL sono:<\/p>\n\n\n\n Esempi di iniezione SQL<\/strong><\/p>\n\n\n\n Esiste un\u2019ampia variet\u00e0 di vulnerabilit\u00e0, attacchi e tecniche di SQL injection, che si verificano in situazioni diverse. Alcuni esempi comuni di SQL injection includono:<\/p>\n\n\n\n Recupero di dati nascosti<\/strong><\/p>\n\n\n\n Considera un\u2019applicazione per lo shopping che mostra i prodotti in diverse categorie. Quando l\u2019utente fa clic sulla categoria Regali, il browser richiede l\u2019URL:<\/p>\n\n\n\n https:\/\/insecure-website.com\/products?category=Gifts<\/em><\/p>\n\n\n\n Ci\u00f2 fa s\u00ec che l\u2019applicazione esegua una query SQL per recuperare i dettagli dei prodotti rilevanti dal database:<\/p>\n\n\n\n Questa query SQL chiede al database di restituire:<\/p>\n\n\n\n La restrizione released = 1<\/em> viene utilizzata per nascondere i prodotti che non sono stati rilasciati. Per i prodotti non rilasciati, presumibilmente released = 0<\/em>.<\/p>\n\n\n\n L\u2019applicazione non implementa alcuna difesa contro gli attacchi SQL injection, quindi un utente malintenzionato pu\u00f2 costruire un attacco come:<\/p>\n\n\n\n https:\/\/insecure-website.com\/products?category=Gifts\u2019–<\/em><\/p>\n\n\n\n Ci\u00f2 si traduce nella query SQL:<\/p>\n\n\n\n La cosa fondamentale qui \u00e8 che la sequenza di doppio trattino —<\/strong><\/em> \u00e8 un indicatore di commento in SQL e significa che il resto della query viene interpretato come un commento. Ci\u00f2 rimuove efficacemente il resto della query, quindi non include pi\u00f9 AND released = 1<\/em>. Ci\u00f2 significa che vengono visualizzati tutti i prodotti, inclusi i prodotti non rilasciati.<\/p>\n\n\n\n Andando oltre, un utente malintenzionato pu\u00f2 fare in modo che l\u2019applicazione visualizzi tutti i prodotti in qualsiasi categoria, comprese le categorie di cui non \u00e8 a conoscenza:<\/p>\n\n\n\n <\/a>https:\/\/insecure-website.com\/products?category=Gifts\u2019+OR+1=1–<\/em><\/p>\n\n\n\n La query modificata restituir\u00e0 tutti gli elementi in cui la categoria \u00e8 Regali o 1 \u00e8 uguale a 1. Poich\u00e9 1=1 \u00e8 sempre vero, la query restituir\u00e0 tutti gli elementi.<\/p>\n\n\n\n Avvertimento<\/strong><\/p>\n\n\n\n Prestare attenzione quando si inserisce la condizione OR 1=1<\/em> in una query SQL. Anche se questo pu\u00f2 essere innocuo nel contesto iniziale in cui stai effettuando l\u2019iniezione, \u00e8 normale che le applicazioni utilizzino i dati di una singola richiesta in pi\u00f9 query diverse. Se la tua condizione raggiunge un\u2019istruzione UPDATE <\/em>o DELETE<\/em>, ad esempio, ci\u00f2 pu\u00f2 comportare una perdita accidentale di dati.<\/p>\n\n\n\n Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data<\/a><\/p>\n\n\n\n (torna su<\/a>)<\/p>\n\n\n\n Sovvertire la logica dell\u2019applicazione<\/strong><\/p>\n\n\n\n Considera un\u2019applicazione che consente agli utenti di accedere con un nome utente e una password. Se un utente invia il nome utente wiener<\/em> e la password bluecheese<\/em>, l\u2019applicazione controlla le credenziali eseguendo la seguente query SQL:<\/p>\n\n\n\n Se la query restituisce i dettagli di un utente, l\u2019accesso ha esito positivo. In caso contrario, viene rifiutato.<\/p>\n\n\n\n In questo caso, un utente malintenzionato pu\u00f2 accedere come qualsiasi utente senza password semplicemente utilizzando la sequenza di commenti SQL, per rimuovere il controllo della password dalla clausola WHERE <\/em>della query. Ad esempio, inviando il nome utente administrator\u2019–<\/em> e una password vuota si ottiene la seguente query:<\/p>\n\n\n\n Questa query restituisce l\u2019utente il cui nome utente \u00e8 administrator<\/em> e fa accedere correttamente l\u2019attaccante come quell\u2019utente.<\/p>\n\n\n\n Lab: SQL injection vulnerability allowing login bypass<\/a><\/p>\n\n\n\n (torna su<\/a>)<\/p>\n\n\n\n Recupero di dati da altre tabelle di database<\/strong><\/p>\n\n\n\n Nei casi in cui i risultati di una query SQL vengono restituiti all\u2019interno delle risposte dell\u2019applicazione, un utente malintenzionato pu\u00f2 sfruttare una vulnerabilit\u00e0 di SQL injection per recuperare i dati da altre tabelle all\u2019interno del database. Questa operazione viene eseguita utilizzando la parola chiave UNION<\/em>, che consente di eseguire un\u2019ulteriore query SELECT <\/em>e aggiungere i risultati alla query originale.<\/p>\n\n\n\n Ad esempio, se un\u2019applicazione esegue la seguente query contenente l\u2019input dell\u2019utente \u201cGift<\/em>\u201d:<\/p>\n\n\n\n quindi un utente malintenzionato pu\u00f2 inviare l\u2019input:<\/p>\n\n\n\n Ci\u00f2 far\u00e0 s\u00ec che l\u2019applicazione restituisca tutti i nomi utente e le password insieme ai nomi e alle descrizioni dei prodotti.<\/p>\n\n\n\n Per saperne di pi\u00f9<\/strong><\/p>\n\n\n\n SQL injection UNION attac<\/a>k<\/a>s<\/a><\/p>\n\n\n\n Vulnerabilit\u00e0 di blind SQL injection<\/strong><\/p>\n\n\n\n Molte istanze di SQL injection sono vulnerabilit\u00e0 cieche. Ci\u00f2 significa che l\u2019applicazione non restituisce i risultati della query SQL o i dettagli di eventuali errori del database all\u2019interno delle sue risposte. Le vulnerabilit\u00e0 cieche possono ancora essere sfruttate per accedere a dati non autorizzati, ma le tecniche coinvolte sono generalmente pi\u00f9 complicate e difficili da eseguire.<\/p>\n\n\n\n A seconda della natura della vulnerabilit\u00e0 e del database interessato, \u00e8 possibile utilizzare le seguenti tecniche per sfruttare le vulnerabilit\u00e0 della blind SQL injection:<\/p>\n\n\n\n Per saperne di pi\u00f9<\/strong><\/p>\n\n\n\n Blind SQL injection<\/a><\/p>\n\n\n\n Iniezione SQL di secondo ordine<\/strong><\/p>\n\n\n\n L\u2019iniezione SQL di primo ordine si verifica quando l\u2019applicazione prende l\u2019input dell\u2019utente da una richiesta HTTP e, nel corso dell\u2019elaborazione di tale richiesta, incorpora l\u2019input in una query SQL in modo non sicuro.<\/p>\n\n\n\n Nell\u2019iniezione SQL di secondo ordine (nota anche come iniezione SQL archiviata), l\u2019applicazione riceve l\u2019input dell\u2019utente da una richiesta HTTP e lo archivia per un utilizzo futuro. Questo di solito viene fatto inserendo l\u2019input in un database, ma non si verifica alcuna vulnerabilit\u00e0 nel punto in cui i dati sono archiviati. Successivamente, durante la gestione di una richiesta HTTP diversa, l\u2019applicazione recupera i dati archiviati e li incorpora in una query SQL in modo non sicuro.<\/p>\n\n\n\n L\u2019iniezione SQL di secondo ordine si verifica spesso in situazioni in cui gli sviluppatori sono a conoscenza delle vulnerabilit\u00e0 dell\u2019iniezione SQL e quindi gestiscono in modo sicuro il posizionamento iniziale dell\u2019input nel database. Quando i dati vengono successivamente elaborati, sono considerati sicuri, poich\u00e9 sono stati precedentemente inseriti nel database in modo sicuro. A questo punto, i dati vengono gestiti in modo non sicuro, perch\u00e9 lo sviluppatore li ritiene erroneamente attendibili.<\/p>\n\n\n\n Esame del database<\/strong><\/p>\n\n\n\n Alcune funzionalit\u00e0 principali del linguaggio SQL sono implementate allo stesso modo su piattaforme di database popolari e cos\u00ec tanti modi per rilevare e sfruttare le vulnerabilit\u00e0 di SQL injection funzionano in modo identico su diversi tipi di database.<\/p>\n\n\n\n Tuttavia, ci sono anche molte differenze tra i database comuni. Ci\u00f2 significa che alcune tecniche per rilevare e sfruttare l\u2019iniezione SQL funzionano in modo diverso su piattaforme diverse. Per esempio:<\/p>\n\n\n\n Per saperne di pi\u00f9<\/strong><\/p>\n\n\n\n SQL injection cheat sheet<\/a><\/p>\n\n\n\n Dopo l\u2019identificazione iniziale di una vulnerabilit\u00e0 SQL injection, \u00e8 generalmente utile ottenere alcune informazioni sul database stesso. Queste informazioni possono spesso aprire la strada a un ulteriore sfruttamento.<\/p>\n\n\n\n \u00c8 possibile interrogare i dettagli della versione per il database. Il modo in cui ci\u00f2 viene fatto dipende dal tipo di database, quindi puoi dedurre il tipo di database da qualsiasi tecnica funzioni. Ad esempio, su Oracle puoi eseguire:<\/p>\n\n\n\n \u00c8 inoltre possibile determinare quali tabelle di database esistono e quali colonne contengono. Ad esempio, sulla maggior parte dei database \u00e8 possibile eseguire la seguente query per elencare le tabelle:<\/p>\n\n\n\n Per saperne di pi\u00f9<\/strong><\/p>\n\n\n\n SQL injection in diversi contesti<\/strong><\/p>\n\n\n\n In tutti i laboratori finora, hai utilizzato la stringa di query per iniettare il tuo payload SQL dannoso. Tuttavia, \u00e8 importante notare che \u00e8 possibile eseguire attacchi SQL injection utilizzando qualsiasi input controllabile elaborato come query SQL dall\u2019applicazione. Ad esempio, alcuni siti Web accettano input in formato JSON o XML e lo utilizzano per interrogare il database.<\/p>\n\n\n\n Questi diversi formati possono persino fornire modi alternativi per offuscare gli attacchi (obfuscate attacks<\/a>) che altrimenti sarebbero bloccati a causa di WAF e altri meccanismi di difesa. Le implementazioni deboli spesso cercano solo parole chiave SQL injection comuni all\u2019interno della richiesta, quindi potresti essere in grado di aggirare questi filtri semplicemente codificando o eseguendo l\u2019escape dei caratteri nelle parole chiave proibite. Ad esempio, la seguente SQL injection basata su XML utilizza una sequenza di escape XML per codificare il carattere S<\/em> in SELECT<\/em>:<\/p>\n\n\n\n Questo verr\u00e0 decodificato sul lato server prima di essere passato all\u2019interprete SQL.<\/p>\n\n\n\n Lab: SQL injection with filter bypass via XML encoding<\/a><\/p>\n\n\n\n Come prevenire l\u2019SQL injection<\/strong><\/p>\n\n\n\n La maggior parte delle istanze di SQL injection pu\u00f2 essere prevenuta utilizzando query con parametri (note anche come istruzioni preparate) anzich\u00e9 la concatenazione di stringhe all\u2019interno della query.<\/p>\n\n\n\n Il seguente codice \u00e8 vulnerabile all\u2019iniezione SQL perch\u00e9 l\u2019input dell\u2019utente \u00e8 concatenato direttamente nella query:<\/p>\n\n\n\n Questo codice pu\u00f2 essere facilmente riscritto in modo da impedire all\u2019input dell\u2019utente di interferire con la struttura della query:<\/p>\n\n\n\n Le query con parametri possono essere utilizzate per qualsiasi situazione in cui l\u2019input non attendibile viene visualizzato come dati all\u2019interno della query, inclusi la clausola WHERE<\/em> e i valori in un\u2019istruzione INSERT<\/em> o UPDATE<\/em>. Non possono essere utilizzati per gestire l\u2019input non attendibile in altre parti della query, come i nomi di tabelle o colonne o la clausola ORDER BY<\/em>. La funzionalit\u00e0 dell\u2019applicazione che inserisce dati non attendibili in quelle parti della query dovr\u00e0 adottare un approccio diverso, ad esempio inserire nella whitelist i valori di input consentiti o utilizzare una logica diversa per fornire il comportamento richiesto.<\/p>\n\n\n\n Affinch\u00e9 una query con parametri sia efficace nel prevenire l\u2019iniezione SQL, la stringa utilizzata nella query deve essere sempre una costante hardcoded e non deve mai contenere dati variabili di alcuna origine. Non essere tentato di decidere caso per caso se un elemento di dati \u00e8 attendibile e continua a utilizzare la concatenazione di stringhe all\u2019interno della query per i casi considerati sicuri. \u00c8 fin troppo facile commettere errori sulla possibile origine dei dati o che le modifiche in altro codice violino le ipotesi su quali dati sono contaminati.<\/p>\n\n\n\n Per saperne di pi\u00f9<\/strong><\/p>\n\n\n\n Find SQL injection vulnerabilities using Burp Suite\u2019s web vulnerability scanner<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" PortSwigger Academy – SQL injection Ho seguito il percorso di apprendimento suggerito da “PortSwigger Academy” per essere indirizzato nella giusta direzione. Consiglio di iscriversi alla piattaforma, seguire le lezioni e soprattutto svolgere e completare i lab \ud83d\ude42 SQL injection Cos\u2019\u00e8 l\u2019 SQL injection (SQLi)? SQL injection (SQLi) \u00e8 una vulnerabilit\u00e0 della sicurezza Web che consente … Leggi tutto “SQL injection”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":4,"footnotes":""},"categories":[5,15],"tags":[],"class_list":["post-1078","post","type-post","status-publish","format-standard","hentry","category-burp-suite","category-ethical-hacking"],"_links":{"self":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/1078","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/comments?post=1078"}],"version-history":[{"count":23,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/1078\/revisions"}],"predecessor-version":[{"id":2021,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/1078\/revisions\/2021"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=1078"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=1078"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=1078"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![](\"https:\/\/lh6.googleusercontent.com\/BZ5qG8T-TTZfn61P_t2cyuDZ-aDJmNki7wchpa5AMqDEK0NdkVkfb9Seud7EGmhyPGGJ7oRdzxw_ZtvCHNBTzaLJu5LYAaBLpIb4hYGLn_H3nWnI0rcq1uGDSEHx0l3JKFDfl8aadiUkedywkIjbsVo\")
\n
\n
\n
SELECT * FROM products WHERE category = \u2019Gifts\u2019 AND released = 1<\/em><\/code><\/pre>\n\n\n\n\n
SELECT * FROM products WHERE category = \u2019Gifts\u2019--\u2019 AND released = 1<\/em><\/code><\/pre>\n\n\n\nSELECT * FROM users WHERE username = \u2019wiener\u2019 AND password = \u2019bluecheese\u2019<\/em><\/code><\/pre>\n\n\n\nSELECT * FROM users WHERE username = \u2019administrator\u2019--\u2019 AND password =\u2019\u2019<\/em><\/code><\/pre>\n\n\n\nSELECT name, description FROM products WHERE category = \u2019Gifts\u2019<\/em><\/code><\/pre>\n\n\n\n\u2019 UNION SELECT username, password users--<\/em><\/code><\/pre>\n\n\n\n\n
![\"\"](\"https:\/\/lh4.googleusercontent.com\/fPk9g3qPtjjbwJCWP-DLtZwtI1dKvJeC9vVS4LwU6jmPXK-mpH3mdT4zwtsv7fo5VlWCQKAKkSGfYo4H-fmkOQ8Xqx1S6ut7E3Jiq3-iYXz9selu7BcppIiKuZNXZzSFvJgosokilWQIEzs2B3ZDpNg\")
\n
SELECT * FROM v$version<\/em><\/code><\/pre>\n\n\n\nSELECT * FROM information_schema.tables<\/em><\/code><\/pre>\n\n\n\n\n
<stockCheck>\n\t<productId>\n\t123\n\t<\/productId>\n\t<storeId>\n\t999 SELECT * FROM information_schema.tables\n\t<\/storeId>\n\t<\/stockCheck><\/code><\/pre>\n\n\n\nString query = \"SELECT * FROM products WHERE category = '\"+ input + \"'\";\n Statement statement = connection.createStatement();\n ResultSet resultSet = statement.executeQuery(query);<\/code><\/pre>\n\n\n\nPreparedStatement statement = connection.prepareStatement(\"SELECT * FROM products WHERE category = ?\");\n statement.setString(1, input);\n ResultSet resultSet = statement.executeQuery();<\/code><\/pre>\n\n\n\n