Dovrei aggiungere protezioni dove non capisco come l'hacker può rompere il sistema?

6

Diciamo che esiste un'applicazione AJAX in cui l'utente può inviare articoli: acquistali.

E c'era un codice

IF ($_POST[items] > 20) {
   echo 'error';
}
else {
   do_buy($_POST[items]);
   echo 'success'
}

Qui c'è un controllo se items non è più di 20. Sul lato client, non dovrebbe essere possibile scegliere più di 20 articoli.

Il sistema funzionerebbe senza problemi anche se fossero stati inviati 21 (o più) articoli (l'utente pagherebbe semplicemente per ogni articolo). Mentre mi rendo conto che devi voler gridare non fidarti del client , c'è qualche danno nel farlo se non ci sono conseguenze, come nel caso qui?

Si potrebbe argomentare che sovraccaricare il carrello potrebbe causare instabilità nel sistema, ma sembra che il caso peggiore sarebbe che alcuni script scadono. Se gli errori sono disabilitati, l'utente non riceverà alcuna risposta.

In generale: ha senso codificare le protezioni per un attacco che viola un invariante del tuo sistema?

Aggiornamento:

$ _ POST ['items'] Volevo dire che è array, non un intero. E ogni elemento come propri proprietà - ID e quantità, che vengono controllati in seguito prima di completare l'operazione di acquisto.

Informazioni su SQL injection: di solito utilizzo i framework e si occupano della protezione dell'iniezione.

Aggiorna

Un altro motivo per cui chiedo questo è che voglio tutto il codice pulito possibile e anche quando qualcuno lo legge - penserà perché diavolo è necessario, questo programmatore non sa cosa sta programmando e perché. Quindi per tutto il codice voglio avere una chiara ragione per cui quel pezzo di codice esiste e quindi se non nel commento, almeno io stesso avrei capito bene perché faccio questo controllo in modo da poter spiegare se un altro programmatore chiede.

    
posta Darius.V 13.07.2014 - 09:51
fonte

5 risposte

5

Sì, dovresti aggiungere protezioni, ma devono essere appropriate per la situazione.

Tutti gli input dell'utente devono essere convalidati. Il principio fondamentale è che non si definisce quale input "cattivo" sia, si definisce quale input "buono" è e si rifiuta tutto il resto. Per fare il tuo esempio, hai definito "elementi > 20" come negativi. Ma cosa succede se "items" è -1? Cosa succede se è la quantità );DROP TABLE Orders;-- ?

La tecnica di base è che si guarda a ciascun campo di input dell'utente e si definisce quale sia il valore "buono", tenendo conto sia delle capacità del software sia delle regole aziendali. Ad esempio, "items" potrebbe essere "un numero intero, maggiore di 0, minore di 20 e inferiore o uguale alla quantità in magazzino" - questo rifiuta anche ordini troppo grandi, ordini troppo piccoli e input esotici come SQL injection, senza doversi preoccupare di ciò che un utente malintenzionato potrebbe tentare di fare o di come il tuo software potrebbe reagire.

Questo deve essere fatto lato server. La convalida sul lato client è lì per aiutare l'utente onesto; un utente disonesto può essere arrestato solo dal lato server, dal momento che controlla il client.

Per usare l'analogia della tua casa, tutti gli input dell'utente sono parte della porta.

    
risposta data 13.07.2014 - 10:28
fonte
1

Non puoi sempre sapere come le cose possono davvero andare male. Nell'esempio corrente, l'utente malintenzionato può inviare un valore molto elevato causando un aritmetico o sovraccarico dello stack o un'eccezione non gestita che provoca l'arresto del server e un problema di disponibilità.

Quindi fai sempre i controlli, considera sempre che il peggio può accadere e pensa all'attaccante come a qualcuno che è capace di fare "qualsiasi cosa". Crea sempre liste bianche, non liste nere. Alla lista, considera i metodi di attacco standard (XSS, CSRF, Iniezione, ecc.) E controlla gli intervalli.

Sigilla le porte e le finestre il più strette possibile e rivedi sempre il design, il codice e l'ambiente.

    
risposta data 13.07.2014 - 09:33
fonte
1

Risposta breve: no e fai urgentemente un corso intensivo sulla sicurezza se stai creando un sito web di vendita!

Non dovresti aggiungere restrizioni arbitrarie e controlli e "protezioni" solo perché non sai cosa sta succedendo. Se lo fai, è più probabile che tu aggiunga problemi e lasci aperte le vulnerabilità della sicurezza più di qualsiasi altra cosa. Ovviamente, il motivo per cui ci sono professionisti della sicurezza è perché sono addestrati a identificare le protezioni necessarie.

Inizia definendo le risorse nel tuo sistema , sia tuo che tuo clienti. Hai bisogno di sapere cosa è prezioso perché questo è ciò che gli hacker verranno per. Include dati personali, dati di un valore finanziario (informazioni sul conto bancario, ecc.), Le merci che vendi, i computer dei tuoi clienti (che possono essere utilizzati in una botnet in caso, ad esempio, cross-site scripting attacchi) e anche il proprio server, database e server Web.

Una volta che sai cosa c'è da proteggere, devi definire cosa deve succedere perché il tuo sistema funzioni correttamente. In sostanza, devi elencare ciò che permetti ai tuoi clienti di fare sul tuo sito web. Ad esempio questo limite arbitrario di 20 elementi è completamente ingiustificato .

Il secondo passo sarà capire chi potrebbero essere i tuoi avversari e cosa possono fare . Sii creativo ma resta realistico. È meno probabile che interessi l'NSA piuttosto che un hacker solitario interessato finanziariamente per un sito di vendita. Questo processo è chiamato modellazione delle minacce . Devi:

  • definisci i tuoi avversari per ogni risorsa
  • definisce le loro capacità (che richiede molta conoscenza della sicurezza)
  • definisce le minacce alle tue risorse (quali possono essere le capacità che un pirata informatico ti può fare)

Ora che sai cosa potrebbe accaderti, devi definire le Proprietà di sicurezza che deve conservare le tue risorse e devi quindi scegliere i meccanismi che garantiscono tali proprietà. Quei meccanismi, a loro volta, diventano risorse critiche del tuo sistema che devono essere ugualmente protetti. Questo è indicato come Trusted Computing Base .

Quando sei lì puoi iniziare a pensare di passare alla versione beta. Dovrai valutare la tua sicurezza, attraverso i test di penetrazione solitamente effettuati da una società di terze parti. Ma questo dovrebbe già tenerti occupato;)

Modifica: ti preghiamo di dedicare un po 'di tempo a leggere i più comuni programmi software che trasformarsi in vulnerabilità . Permettere agli utenti di acquistare più di 20 articoli non è uno di questi.

    
risposta data 13.07.2014 - 17:36
fonte
1

Se alcuni malware sul lato utente fanno acquistare al cliente 2 milioni di elementi sul tuo sito e il tuo sito esegue la transazione senza generare alcun avviso, alcune persone, in particolare il cliente truffato, potrebbero lamentarsi a voce alta e affermare che il tuo server è un po 'trascurato. Si potrebbe obiettare (in tribunale!) Che si sarebbe in colpa per non aver effettuato alcuni controlli "sensibili". Potrebbero esserci anche alcune normative applicabili che impongono di effettuare alcune verifiche sul lato server (almeno le banche effettuano controlli per "attività anormali" sulle carte di credito e transazioni a blocchi che sembrano particolarmente strane).

Nel caso generale, l'aggiunta di controlli extra per situazioni anomale è una sana pratica di programmazione. Sai che il lato client non dovrebbe consentire più di 20 articoli. Se alcuni bug sull'interfaccia lato client consentono a un client di inserire 21 elementi, allora dovrebbe essere corretto, e sarà più facile se vieni avvisato al più presto possibile, ad es. con un controllo sul lato server.

(C'è un lato oscuro ad esso, però: se aggiungi il controllo sul lato server, poi più tardi decidi di aumentare il limite a 25, devi modificare il client e il server, ma dovrebbe essere facilmente rilevato durante i test di pre-distribuzione, quindi non astenersi dall'aggiungere test di sanità).

    
risposta data 13.07.2014 - 16:15
fonte
1

Affrontare solo la prima domanda, che è essenzialmente "Va bene codificare la validazione lato client?".

Sì, è una buona esperienza utente, il feedback immediato è bello. La validazione lato client non è in realtà la sicurezza, ma è più comoda. Il suo scopo è accelerare il processo, mettere il modulo in uno stato che passerà la validazione.

Come probabilmente saprai, la convalida sul lato client dovrebbe sempre essere secondaria rispetto alla convalida sul lato server. Se la mancata corrispondenza della validazione lato client e lato server, il server è in definitiva la fonte della verità. Se il server non lo convalida, non viene realmente convalidato.

Comunque, sì, la validazione lato client è perfettamente legittima ed è un grande miglioramento in UX.

E per le protezioni di SQL injection, sembra che tu stia già trattando l'input dell'utente come materiale pericoloso e lo sfreghi con un framework affidabile e provato, quindi sei a posto. Basta stare attenti a qualsiasi cosa derivata dall'input dell'utente, non solo durante il salvataggio / l'aggiornamento. Anche altre variabili / logica possono essere manipolate dall'input dell'utente se hanno una conoscenza approfondita del tuo sistema.

    
risposta data 15.07.2014 - 16:21
fonte

Leggi altre domande sui tag