Il testing per le vulnerabilità di SQL injection è ancora rilevante nelle moderne applicazioni web?

9

Prima alcuni sfondi:

Sono un ingegnere infrastrutturale con 5 anni di esperienza principalmente in Virtualization and Networking.

Ho passato l'anno scorso a studiare molto sulla sicurezza, a passare il Security +, a leggere il Manuale degli hacker di applicazioni Web e ho fatto un sacco di soldi trovando bug usando Bugcrowd e Hackerone.

Ogni volta che cerco vulnerabilità, ignoro sempre SQL injection poiché la maggior parte delle applicazioni moderne non mostra alcun segno di debolezza rispetto ai tradizionali metodi di SQL Injection mostrati nei libri o nelle esercitazioni online.

Ora, questo è il caso per gli altri appassionati di sicurezza? Come ti avvicini a questo? Cerco di inviare un sacco di personaggi insoliti, ma il risultato migliore che ho ottenuto finora è stato l'errore 500.

Grazie in anticipo

    
posta Mico 01.05.2015 - 16:24
fonte

9 risposte

18

In realtà secondo OWASP, SQL Injection è in cima alle prime 10 vulnerabilità attraverso le applicazioni Web. link

e ci sono molti articoli, articoli, notizie sulle preoccupazioni in questo argomento e ogni giorno c'è una novità sull'attacco di SQL injection contro famose applicazioni web come ad esempio Joomla, Wordpress o siti Web e così via, quindi non possiamo dire che "l'applicazione moderna non mostra alcun segno di debolezza rispetto ai tradizionali metodi di SQL Injection" perché ogni giorno viene introdotto un nuovo metodo SQL Injection.

    
risposta data 01.05.2015 - 16:40
fonte
4

L'iniezione SQL non è sicuramente qualcosa che salterò durante i test di sicurezza. Secondo il Rapporto sulla violazione dell'Istituto Ponemon , gli account di iniezione SQL per il 30% di violazioni criminali o criminali, la maggior parte di qualsiasi vettore di attacco che ha provocato una violazione.

La mia azienda utilizza una varietà di metodi per trovare le vulnerabilità di SQL injection nelle nostre applicazioni proprietarie. Usiamo una combinazione di scansione del codice sorgente tramite analisi del codice statico e test di penetrazione sull'app in fase di sviluppo, test e produzione. Ciò è accompagnato da controlli tecnici come i sistemi di rilevamento delle intrusioni (IDS) e un firewall per applicazioni Web (WAF).

Fornitori / prodotti di analisi del codice statico:

  • Checkmarx
  • Whitehat

Alcuni fornitori / tecnologie che eseguono test delle penne:

  • Whitehat
  • Spada e scudo
  • Accuvant
  • Nexpose (Rapid7)
  • Hailstorm (Trustwave, ex Cenzic)

Esistono numerosi metodi per rilevare e / o bloccare l'iniezione SQL che puoi esaminare qui: Imperva - Come bloccare SQL Injection . Anche se il blocco potrebbe non essere quello che stai cercando, sicuramente ha alcuni buoni strumenti per determinare se è vulnerabile.

Il metodo più semplice è quello di eseguire alcuni semplici script che lanciano garbage / attacchi sul sito Web, ma ovviamente lo eliminerò, ovviamente.

    
risposta data 01.05.2015 - 16:49
fonte
4

Non sono sicuro di cosa si intenda esattamente con un'applicazione moderna. Sì, molti framework, ORM, Entity Framework, ecc. Scompongono le query e possono applicare alcuni filtri di default. Tuttavia, in scenari più complessi che richiedono la codifica personalizzata, o in cui le funzioni ORM o di libreria non faranno esattamente ciò che si desidera, si aprirà la porta all'iniezione SQL o ad altri attacchi.

Con molti ORM e framework, la parte di sicurezza è integrata. Ciò ha l'impatto di occuparsi automaticamente di alcuni problemi di sicurezza, ma allo stesso tempo, molti sviluppatori potrebbero non capire cosa queste funzioni di libreria facciano per loro, e quando hanno bisogno di creare una soluzione su misura, seguono solo alcuni tutorial e non sanno di dover prendere in considerazione la sicurezza.

Inoltre, quando esci dalle app di tipo CRUD di base per l'utente finale, gli sviluppatori potrebbero aver bisogno di usare librerie meno ben mantenute. Ad esempio, diciamo che hai un'app aziendale in cui qualcuno può caricare un file CSV e che viene elaborato. Forse qualcuno ha scritto una libreria per gestire questo e non ha usato l'ORM, funziona così che i tuoi sviluppatori lo seguano. Il CSV viene quindi letto riga per riga e elaborato nel database, qui è possibile eseguire l'iniezione SQL.

L'iniezione SQL è un sintomo di una mancanza di corretta convalida dell'input, la probabilità di ciò aumenta in scenari meno comuni o più complessi in cui non può essere cotta o è un ripensamento.

Inoltre, le applicazioni "moderne" possono sembrare moderne ma sono costruite su alcune vecchie cianfrusaglie o su alcune strane connessioni legacy che gettano via le aspettative.

    
risposta data 01.05.2015 - 22:33
fonte
3

OWASP ha alcune informazioni su come pinare le iniezioni SQL, per non essere presente. Una recente iniezione di Drupal SQL mostra che non è vero (anche in un ambiente maturo come Drupal).

Il modo in cui trovi queste cose è spesso semplicemente utilizzando fuzzer e l'invio di rifiuti casuali all'app Web.

    
risposta data 01.05.2015 - 16:37
fonte
2

Now, is this the case for other security enthusiasts?

Nelle mie esperienze, No - l'iniezione SQL è ancora prevalente .

Eseguo in media 30-50 valutazioni di applicazioni Web per trimestre e posso garantire che l'iniezione SQL è ancora un problema con le applicazioni moderne.

Detto questo, le mie valutazioni sono automatizzate per circa l'85% con un follow-up / verifica / convalida manuale del 15% (non sono affatto un tester professionista)

Uno scanner automatico ha il vantaggio di trovare la ricerca di un'iniezione SQL nei campi dei parametri che altrimenti sarebbero stati trascurati.

Il rovescio della medaglia è che uno scanner automatizzato non è bravo a sfruttare difetti logici come un essere umano.

    
risposta data 01.05.2015 - 20:16
fonte
2

Molte applicazioni sono cresciute negli anni. A meno che il codice non sia refactored una volta ogni tanto per riflettere le migliori pratiche attuali (per esempio, nel caso di iniezioni SQL: parametrizzazione), molte applicazioni contengono un codice legacy abbastanza grande che non è stato toccato da anni. E le probabilità sono che non sarà toccato in quanto altre parti dipendono da esso. Il refactoring costa tempo e denaro. E onestamente, non c'è bisogno di refactoring finché funziona, giusto?

Ad esempio, se guardi Wordpress, stanno utilizzando una funzione chiamata wp_magic_quotes , che in pratica imita il comportamento delle citazioni magiche di PHP , che era una 'funzione di sicurezza' che scappa automaticamente alcuni caratteri in $_GET , $_POST , $_COOKIE e quindi $_REQUEST . Questa 'caratteristica' è stata deprecata in PHP 5.3.0 e rimossa in PHP 5.4.0 in quanto è stata considerata una cattiva idea per (nota anche i commenti).

Tuttavia, anche se Wordpress dipende e applica le virgolette magiche, ci sono ancora molte Vulnerabilità di SQL injection in plug-in o temi .

Un altro fatto: CWE-89: Neutralizzazione impropria di elementi speciali utilizzati in un comando SQL ('SQL Injection') è posizionato al terzo posto con il 10% tra i punti deboli di tutti i CVE (vedi CWE generale in Dashboard del Database di sicurezza ).

    
risposta data 01.05.2015 - 20:28
fonte
0

Le classiche iniezioni di SQL con'or 1=1 # di vecchia scuola sono finite da tempo; ma quelli sofisticati si insinueranno una volta nel tempo. Questo è un modo in cui TrustWaves guadagna mantenendo i set di regole ModSecurity aggiornati.

La maggior parte delle moderne applicazioni Web passa attraverso una 'checklist per l'implementazione della sicurezza' e viene solitamente testata per vulnerabilità note prima della distribuzione della produzione. Una volta schierati, i cacciatori di taglie compaiono e eseguono i propri test. Il sistema è considerato "sicuro" come potrebbe arrivare in quel momento.

Gli strumenti automatici utilizzati dagli sviluppatori e dai cacciatori di taglie, anche se veloci e utili, anche Manca alcune iniezioni sofisticate che alla fine un determinato attaccante umano potrebbe scoprire.

    
risposta data 01.05.2015 - 19:35
fonte
0

Dipende dalla piattaforma su cui è costruita un'applicazione. Non penso che Drupal o Wordpress saranno la scelta di uno sviluppatore maturo per progettare un'app. E tu come esperto di software engineer nella tua analisi probabilmente non affronteresti applicazioni di bassa qualità come quella. Non voglio dire che se si usa Wordpress otterrà sicuramente un'iniezione SQL o un attacco XSS. Queste piattaforme sono come Windows, l'uso improprio e la popolarità portano alla vulnerabilità.

Sì, le iniezioni SQL sono ancora presenti e devi stare attento a loro. D'altra parte gli sviluppatori più maturi con cui hai a che fare, meno ne devi preoccupare.

    
risposta data 01.05.2015 - 23:10
fonte
0

Trovare le iniezioni SQL oggi è molto semplice e chiunque può farlo.

Ci sono stati molti sviluppatori e ricercatori che prevedono la fine di SQL Injection, tuttavia, anno dopo anno lo vediamo ancora nella Top 10 di OWASP.

L'iniezione SQL è ovunque e la mancanza di istruzione o conoscenza (o forse cattive abitudini) come scrivere codice sicuro è un problema. Ad esempio in questo libro "Head First PHP & MySQL" nel capitolo 6 il lettore viene introdotto in SQL Injection e come contrastarlo con mysqli_real_escape_string (), ma il metodo di sanificazione non viene utilizzato nel resto del libro, lasciando alcun lettore che non leggono da una pagina all'altra vulnerabili. Ovviamente, non utilizzando i servizi igienici adeguati per il resto del libro, gli utenti dimenticheranno ovviamente anche i servizi igienici.

Per le password il libro introduce il metodo SHA () di MySQL, tuttavia, non vengono utilizzati algoritmi o Sali di password appropriati.

Nell'Appendice A (denominata "Tutti gli argomenti non trattati) troviamo un argomento chiamato" Protezione della tua applicazione PHP ". Queste pagine contenevano solo un paio di pagine sulla rimozione degli script phpinfo () e sulla lotta all'XSS.

Quindi sì, l'iniezione SQL è ancora molto pertinente.

    
risposta data 02.05.2015 - 11:41
fonte

Leggi altre domande sui tag