Come gestire i dati inviati - sanitizzazione o validazione o entrambi?

-2

Mentre stavo lavorando sull'aggiornamento delle dichiarazioni deprecate di ereg_replace () in una soluzione di e-carrello, sono stato improvvisamente perplesso da domande su come gestire i dati inviati con cui stavo lavorando.

Stavo lavorando con la funzione add to card, che dal punto di vista del backend riceve un intero per quanti prodotti aggiungere al carrello. Poiché questo numero viene inviato dal sito Web, è aperto per la manomissione, quindi i dati sono stati disinfettati prima di passare alla funzione. Grande - nessuna preoccupazione. Tuttavia, mi stavo chiedendo ...

Treno del pensiero ... nessuna sanificazione necessaria!

Siamo tutti brave persone e non desideriamo nuocere agli altri. Sono il creatore di questo sito di e-commerce, quindi ho consegnato l'HTML per il modulo che restituirà sempre un numero, questo significa che non dovrei aver bisogno di disinfettare il numero per nulla potrei anche eliminare il valore del ritaglio - qualcosa che ho avere una cattiva abitudine di fare di default. Tuttavia ... non viviamo in Utopia ...

E se ci fosse un problema con i dati, nel caso in cui? Dovrei assicurarmi che i dati siano corretti in modo da non rovinare tutto ciò che mi farebbe sembrare stupido. Non dovrei farlo comunque, penso? Dopo tutto il mondo non funziona come sta andando questo treno ...

Train of thought ... validating is the answer

In un ambiente di produzione le cose funzionano, almeno si suppone che debbano fare e devono farlo perché qualsiasi altra cosa lo renderebbe instabile. Questo credo sia crutiale per la funzionalità aggiungi al carrello , quindi penso di poter pensare in bianco e nero.

Posso assumere due possibili stati del sistema, o funziona o è rotto. Se il numero inviato non è uguale a un numero che posso essere convertito in un intero per misure sicure dopo il rilevamento, devo presumere che il sistema sia stato manomesso. L'unica altra supposizione per me deve essere il sistema è pieno di errori e per la stessa ragione non dovrebbe funzionare affatto.

Allenamento di se ... 410 Gone

Non sarebbe meglio interrompere o uccidere l'intera sessione / IP se tale scenario esiste? Qual è la pratica aziendale in giro per la gestione degli errori durante la sanificazione dei dati? È questo quando accendi il honeypot-collector e proxy la sessione utente sul tuo dev-server per l'analisi diretta?

Non ci può essere alcuna ragione per continuare Sto pensando Se rilevo qualcosa di diverso da un numero nella stringa inviata? Il sistema rotto non ha motivo di continuare a pensare?

Concludendo i treni di pensiero

Chiaramente uno non può e deve non presupporre che i dati inviati siano corretti, pertanto è necessario eseguire una convalida di qualche tipo. Ma se nessuno sta tentando di hackerare il sistema, nessuno sta provando ad alterare i valori, allora non dovrebbe mai essere una situazione in cui i dati che rappresentano la quantità non sono un numero positivo (im usando aggiungi al carrello come esempio) - cioè a meno - il il browser sta incasinando i dati o maby qualche codifica produce dati errati o, beh, non lo so davvero.

Quali sono le pratiche comuni da fare quando si rileva qualcosa che deve essere considerato una violazione della sicurezza? O semplicemente disinfetto i dati e faccio finta che nulla sia sbagliato, cercando di sfruttare al meglio i dati ricevuti, supponendo che sia stato ben concepito.

Questo è il motivo per cui mi chiedo se potrei anche chiudere la sessione, perché qualsiasi circostanza normale non finirebbe mai con dati sbagliati. Se fosse il prezzo di un prodotto, certamente non si consentirebbe un tale errore e il sistema non potrebbe continuare a funzionare? Cioè - qual è lo scopo di continuare quando viene rilevato un tale errore?

Grazie in anticipo:)

Aggiornamento, chiarimenti sulle persone che sono così estremamente gentili e disponibili: D

Non credo affatto che tutte le persone siano carine o ben educate, e dal punto di vista della sicurezza hai solo bisogno di sbagliare per mandare in crash il sistema. Ho anche l'impressione di essere onesto sul fatto che ci sono molti sistemi automatici che esplorano il web per exploit. Scaricamento di compendi di tattiche di hacking su siti web con targeting a -z 24/7 per l'eccitazione di poter deturpare il sito che compare nel registro giornaliero della colazione di possibili siti sfruttabili. Ho imparato a conoscere Netsparker in questo modo.

Credo di non aver fatto correttamente la mia domanda, posso vederlo dalle risposte date in modo aggiunto nell'ultimo punto chiamato "concludere i treni ..."

    
posta Kim Steinhaug 17.04.2018 - 21:13
fonte

3 risposte

1

La risposta giusta dipende dalle politiche del cliente. Potrebbe essere un'app mission critical dove, se qualcosa va storto, le persone muoiono (cioè sistemi medici, controllo del volo, ecc.). Potrebbe essere qualcosa di un po 'meno grave, ma comunque abbastanza serio (cioè dove sono coinvolti molti soldi). Infine, la tua app potrebbe essere qualcosa che le persone usano per la ricreazione (ad esempio i social media). I tipi di controlli che utilizzi e con quanta severità li imponi devono essere informati dal tipo di problema da risolvere.

Detto questo, mai supporre che tutti siano carini . Hai solo bisogno di leggere i commenti di YouTube per scoprire che è falso. Basta bilanciare i rischi e la ricompensa per la soluzione. Tuttavia, ci sono alcune cose da tenere a mente:

  • Il server dovrebbe sempre convalidare ciò che riceve. Ci sono troppe storie dell'orrore di persone cattive che hanno "acquistato" un prodotto costoso per $ 1 o meno solo perché il server si è fidato che il prezzo in dollari ricevuto dal browser fosse corretto. Non farlo.
  • Il browser può ripulire i dati o aiutare l'utente a fornire buoni dati. Ti aiuta solo in un secondo momento, ma l'importanza di questo passaggio dipende da ciò che stai facendo con i dati e da quanto è critico per il motivo dell'app esistente.
  • La tua applicazione dovrebbe essere in grado di tenere traccia di chi sta facendo cosa. In questo modo, se trovi una persona cattiva, hai un mezzo per costruire il tuo caso per terminare il loro account (o premere accuse formali se le loro azioni sono illegali). La granularità di tale tracciamento dipende dalle politiche e dalle preoccupazioni del tuo cliente.

Oltre a ciò, devi discutere i controlli con il tuo cliente. C'è sempre un compromesso. Più rigoroso fai l'applicazione, meno persone vorranno usarla. Ovviamente azioni difficili come terminare una sessione o impedire l'accesso alla tua applicazione devono essere giustificabili in qualche modo.

Questa è tutta la politica.

    
risposta data 17.04.2018 - 21:54
fonte
1

We are all good people and wish no harm upon others. I am the creator of this e-commerce website so I have delivered the HTML for the form which will always return a number, this means that I should not need to sanitize the number at all I could infact drop timming the value aswell - something I have a bad habbit of doing by default.

Tuttavia non siamo tutti brave persone. Un sacco di persone tenteranno di infrangere il tuo sistema e influenzare i tuoi clienti.

Dovresti sempre assumere che l'input dal mondo esterno sia pericoloso. Non importa se lo hai codificato sulla pagina o meno.

Direi, sul backend, di trasmettere il valore a un int e di convalidare l'int. Fatto.

    
risposta data 17.04.2018 - 21:37
fonte
0

Penso che sia entrambi. Se ti ho capito correttamente, "sanitizzazione" significa - al frontend, e "validation" è sul back-end, vero?

Se è così, potrebbe esserci un grande, singolo validatore "messaggio dal client" come menzionato nel terzo paragrafo. Ma come farlo .. dipende dagli strumenti che usi. Ma, imo, è meglio controllare (validare) una volta al back-end e implementare controlli più dettagliati / individuali (disinfettanti) nel front-end (UI).

    
risposta data 17.04.2018 - 21:26
fonte

Leggi altre domande sui tag