Come scrivere un codice sicuro?

Proteggiti dagli attacchi di iniezione!

Ci sto lavorando da alcuni mesi, cercando di capire cosa ha reso vulnerabile il codice e ho ricevuto questa semplice risposta: cattive abitudini di programmazione. Ora ciò potrebbe sembrare abbastanza ovvio, ma un grosso pezzo della comunità di programmatori rimane ancora ignaro di questo fatto.

Capire il problema!

Intendo test di penetrazione e avere team dedicati a prendersi cura della sicurezza dell'applicazione che costruisci è incredibile e sempre encomiabile, ma non è qualcosa che tutti possono permettersi. Le grandi aziende possono vantarsi delle loro pratiche di sicurezza di come hanno team che lavorano 24 ore su 24 per proteggere i dati dei loro clienti, ma per quanto riguarda quelli che non hanno le risorse.

Uno dei maggiori motivi per cui abbiamo questi codici vulnerabili presenti in una delle applicazioni più importanti come banche, aviazione, acquisti online ecc. È a causa dei programmatori.

L'ultima riga deve aver offeso molte persone e lasciami dire che non intendo basarmi su una determinata comunità. Non lo farò perché non è colpa loro, nell'era attuale della programmazione in cui il tempo di esecuzione del codice deve essere il più basso possibile, è del tutto comprensibile che saltino da queste parti per migliorare il loro codice.

Quindi, ho iniziato a prendere appunti che possono aiutare i programmatori a scrivere codice sicuro. Cercherò di coprire diversi tipi di attacchi e le piccole modifiche che i programmatori possono fare per proteggere il loro codice in modo che la loro organizzazione non abbia bisogno di sborsare di nuovo i soldi per proteggere la loro applicazione.

Immagino di aver ingannato abbastanza per oggi, quindi andiamo subito al punto.

Scaviamo!

Vorrei iniziare la mia iniezione di definizione e perché succede. Gli aggressori inseriscono un payload dannoso che può indurre l'interprete a eseguire comandi involontari o ad accedere a dati non autorizzati. I difetti di iniezione si verificano a causa del solo motivo per cui i dati non attendibili vengono inviati direttamente a un interprete come parte di un comando o di una query senza che il payload venga controllato o disinfettato causando tutti i problemi.

In questo articolo passerò attraverso tre diversi tipi di attacchi di iniezione e metodi che puoi usare per prevenire contro di loro: -

1. Iniezione SQL

Questo tipo di attacco si verifica principalmente quando l'attaccante inserisce un segno di spunta (") alla fine dell'istruzione e aggiunge OR all'istruzione seguendo una totalità di verità. In parole semplici, il payload SQL è simile a questo

"O 1 = 1 -

La precedente dichiarazione quando aggiunta a una query può aiutare gli aggressori ad ottenere l'accesso a database completi. Per una migliore comprensione della query seguente che fornirà all'attaccante l'intero database.

SELEZIONA * DAGLI UTENTI DOVE UserName = 'Aditya' O 1 = 1--

Dai un'occhiata al codice qui sotto e prova a capire se è vulnerabile all'iniezione di SQL o meno.

Se ritieni che il codice sopra riportato sia sicuro, dovresti assolutamente continuare a leggere questo articolo.

Il motivo per cui il codice non è sicuro è perché il valore immesso dall'aggressore viene passato direttamente come argomento. Le cose vanno bene fintanto che vengono immessi i valori previsti, ma l'input dell'utente può contenere gli specificatori del formato% 1 $ tm,% 1 $ te &% 1 $ tY.

Se l'attaccante passa il valore% 1 $ tm per args [0], il risultato sarà il seguente.

05 non corrisponde! Suggerimento: è stato rilasciato il 23 di qualche mese.
// 05 è il mese che l'utente deve sapere per verificare se stesso.

Puoi vedere che il programma stesso emetterà il mese della data di scadenza della carta di credito.

Per evitare un simile attacco, un codice come quello qui sotto può essere estremamente utile.

L'unica differenza tra i due codici qui è che nel primo codice il valore inserito dall'aggressore è stato passato direttamente nel programma mentre nel secondo codice invece di passare il valore lo abbiamo stampato immediatamente rendendo inutile l'intero attacco.

La prevenzione contro gli attacchi SQL Injection dovrebbe comportare la validazione dell'input. Dobbiamo verificare il valore che è stato inserito dall'utente e dobbiamo sempre presumere che questi valori non siano attendibili, ovvero che possano danneggiare l'applicazione.

Dobbiamo utilizzare query parametrizzate con variabili di bind ed eseguire la sanificazione per i valori immessi dall'utente.

Codice parametrizzato e sanificato

Nell'immagine sopra possiamo vedere come i valori che vengono passati vengono prima disinfettati prima di essere utilizzati dal codice.

2. Iniezione comandi

Questo è il tipo più pericoloso di attacco per iniezione che è ancora prevalente nello scenario attuale e non ha ricevuto molta attenzione. Questo attacco sfrutta la vulnerabilità in cui l'autore dell'attacco può immettere ed eseguire comandi non previsti dall'applicazione.

Consentitemi di condividere un esempio con voi per mostrare un'implementazione di base dell'attacco con comando di iniezione.

Nell'immagine sopra osserviamo che esiste una casella di testo in cui è necessario inserire il nome host / IP e i dettagli relativi all'indirizzo IP verranno recuperati e quindi presentati a noi.

L'intera applicazione sembra piuttosto semplice ma è vulnerabile all'iniezione di codice. Per capire che dobbiamo prima capire come funziona l'app e poi possiamo provare a capire quindi possiamo capire come funziona l'iniezione di codice.

Quando immettiamo il nome host / IP, l'app effettua effettivamente una chiamata al terminale e l'output viene quindi visualizzato da lì in poi. Coloro che hanno lavorato con il terminale lo sanno che possiamo usare && nel terminale per passare due comandi diversi contemporaneamente.

Pertanto, l'immagine sopra mostra esattamente come potrebbe funzionare un'iniezione di codice. Per evitare tale attacco, l'app deve eseguire la convalida del percorso (canonicalizzare quindi eseguire il controllo del percorso assoluto), l'applicazione deve anche eseguire la convalida dell'input e elencare i comandi che consente all'utente di immettere ed eseguire.

enum {dir, cd, cls}

3. Iniezione JSON

Questo è un importante attacco di iniezione e quello in aumento visto il frequente uso di API in questi giorni. L'iniezione JSON funziona quando iniettiamo il nostro payload nella query JSON che viene trasmessa mentre l'API effettua richieste e risposte.

Questo esempio è semplice da capire, questa applicazione ha un menu a discesa da cui è necessario selezionare un'opzione che è uno strumento PenTest e l'applicazione presenterà i dettagli dello strumento PenTest selezionato.

Quindi, proviamo a capire come funziona questa applicazione. Accendiamo burp-suite e intercettiamo la richiesta fatta dall'applicazione.

Quindi, nell'immagine sopra possiamo vedere che ToolId viene inviato nella query di richiesta, aggiungiamo il nostro payload a ToolId solo per verificare se ci viene riflesso nella query di risposta.

Riceviamo il payload indietro a quello che abbiamo iniettato nella query di richiesta e quindi possiamo assicurarci che i nostri attacchi di iniezione passeranno. Eseguiamo il payload dell'attacco e confermiamo se gli attacchi funzionano in modo sicuro.

Vedendo la risposta che abbiamo ricevuto in precedenza, passiamo questo valore per ottenere il valore del cookie.

“}}); Alert (document.cookie); //

Prima di passare il valore così com'è nel parametro, lo codifichiamo in URL per evitare eventuali restrizioni di caratteri speciali che potrebbero essere state inserite.

Possiamo vedere chiaramente che il valore del cookie ci è stato restituito nella casella di avviso e conferma che l'attacco è passato.

Dobbiamo controllare come appare effettivamente l'attacco nel browser e se i dettagli dei cookie sono stati visualizzati come desiderato.

Valori dei cookie

Il modo più efficace per prevenire l'attacco di iniezione JSON è eseguire la tecnica di codifica su JavaScript. OWASP presenta anche un disinfettante JSON che può essere utilizzato a scopo di convalida delle stringhe.

String someValidation = JsonSanitizer.sanitize (myJsonString);

Morale

La cosa più importante che possiamo fare per evitare che si verifichino attacchi di iniezione è credere che qualsiasi input da parte dell'utente possa essere un attacco. I programmatori danno per lo più per scontato che l'input fatto dall'utente non sarà dannoso per l'applicazione che è ciò che causa la maggior parte della vulnerabilità nell'applicazione. Ogni input dal lato d'uso deve essere disinfettato e l'input deve essere convalidato prima di essere utilizzato dall'applicazione. Il valore inserito dall'utente non deve mai essere passato direttamente nel programma.

Se i programmatori tengono a mente queste poche cose, possono sicuramente difendersi dalla maggioranza se l'iniezione attacca.

Leggi il mio altro articolo su "Pratiche di codifica sicure"

~ Broken Auth & Session Management - https://bit.ly/2uutoUO
~ Cross Site Scripting - https://bit.ly/2TcpU2Y

Se ti è piaciuto, applaudisci e collaboriamo. Prendi, imposta, hack!

Sito Web: aditya12anand.com | Dona: paypal.me/aditya12anand

Telegram: https://t.me/aditya12anand

Twitter: twitter.com/aditya12anand

LinkedIn: linkedin.com/in/aditya12anand/

E-mail: [email protected]

Segui Infosec Write-up per ulteriori fantastici write-up.