Sono troppo ingegnerizzato se considero un errore intenzionale dell'utente?

È eccessivamente ingegneristico se aggiungo protezione contro illeciti intenzionali di un utente (per dirla leggermente), se il danno che l'utente può subire non è correlato al mio codice?

Per chiarire, sto esponendo un semplice servizio JSON RESTful come questo:

GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item

Il servizio stesso non è pensato per essere utilizzato tramite un browser, ma solo da applicazioni di terze parti, controllate dall'utente (come app telefoniche, app desktop, ecc.). Inoltre, il servizio stesso dovrebbe essere apolide (ovvero senza sessione).

L'autenticazione viene eseguita con l'autenticazione di base su SSL.

Sto parlando di un possibile comportamento "dannoso" come questo:

L'utente inserisce l'URL GET in un browser (nessun motivo ma ...). Il browser richiede l'autent di base, lo elabora e memorizza l'autent per la sessione di navigazione corrente. Senza chiudere il browser, l'utente visita un sito Web dannoso, che ha un javascript CSRF / XSRF dannoso che effettua un POST al nostro servizio.

Lo scenario di cui sopra è altamente improbabile e so che dal punto di vista commerciale non dovrei preoccuparmi troppo. Ma per migliorare la situazione, pensi che se anche il nome utente / la password sono richiesti nei dati POST JSON, ti aiuteranno?

O dovrei eliminare completamente l'autent di base, sbarazzarmi del GET e utilizzare solo POST / PUT con le informazioni di autorizzazione in essi? Poiché le informazioni recuperate tramite GET possono anche essere sensibili.

Dall'altro lato, l'utilizzo di intestazioni personalizzate è considerato pura implementazione REST? Posso eliminare l'autent di base e utilizzare intestazioni personalizzate. In questo modo, è possibile evitare almeno l'attacco CSRF da un browser e le applicazioni che utilizzano il servizio imposteranno nome utente / password in heather personalizzato. Male per questo approccio è che ora il servizio non può essere utilizzato da un browser.

Over-engineering? Affatto. Le misure anti-XSRF sono una parte necessaria di qualsiasi applicazione o servizio Web sicuro. Potrebbe essere "altamente improbabile" che qualcuno scelga di attaccarti, ma ciò non rende il tuo software meno insicuro.

I sistemi sono stati comunemente attaccati usando XSRF e, sebbene i risultati siano meno immediatamente-ovviamente negativi dell'iniezione SQL o XSS, sono abbastanza cattivi da compromettere tutte le funzionalità interagibili dall'utente.

Ciò significa che non è possibile avere un'interfaccia RESTful "pura" in cui gli unici parametri sono le proprietà della chiamata stessa. Devi includere qualcosa nella richiesta che un utente malintenzionato non può indovinare. Che potrebbe essere la coppia nome utente-password, ma questo è lontano dalla scelta possibile solo. Potresti avere un nome utente insieme a un token generato da un hash salato della password. Potresti avere token emessi dal servizio stesso al momento dell'autenticazione (che potrebbero essere ricordati nella sessione o verificati crittograficamente).

dovrei sbarazzarmi del GET

No, le richieste GET vengono utilizzate per le richieste di lettura che non hanno alcuna operazione di scrittura attiva (sono "idempotenti"). Sono solo le operazioni di scrittura che richiedono la protezione XSRF.

Non fidarti mai di nulla. Ogni richiesta è un attacco. Ogni utente è un hacker. Se sviluppi con questa mentalità, la tua applicazione sarà molto più sicura, stabile e con meno probabilità di essere dirottata da un utente malintenzionato. Tutto ciò che serve è una persona intelligente per trovare un modo per aggirare la tua sicurezza e metterti in seria difficoltà con i tuoi dati (una delle tue risorse più preziose ).

Se hai identificato una falla nella sicurezza della tua applicazione, fai tutto ciò che pensi di dover fare per colmare il divario. La tua API, in particolare, dovrebbe essere il software più poco affidabile esistente. Richiederei le credenziali e andrei con Posta richieste.

Se il codice viene stabilito e mantenuto, i casi limite dovrebbero essere esaminati e trattati caso per caso.

FISSAGGIO DOVUTO ALCUNI ERRORI DA PARTE MIA:

GET dovrebbe essere comunque utilizzato come parte di un servizio RESTful adeguato, l'autenticazione deve essere comunque presente. Quello che stavo cercando di ipotizzare era che per motivi di sicurezza GET è molto simile a POST ma la posta fa il suo lavoro senza mettere le informazioni in una barra degli indirizzi, che tende ad essere la grande differenza di sicurezza (e perché non mi piace GET), ma come pubblicato da @Lee,

GET requests are used to retrieve resources, and PUT/POST are used to add/update 
resources so it would be completely against expectations for a RESTful API to use
PUT/POST to get data. 

Poiché questo verrà utilizzato da applicazioni di terze parti, è necessario seguire le buone pratiche per un servizio RESTful in modo che l'implementatore finale non venga confuso da questa parte.

Dovresti considerare tutte le eventualità plausibili, incluso l'utente che è attivamente malizioso e (con successo) decodifica qualsiasi barriera di "sicurezza per oscurità".

Allo stesso tempo, dovresti valutare l'impatto di un hack di successo e la probabilità che si verifichi un tentativo. Per esempio:

• Un servizio interno protetto da un solido firewall ha meno probabilità di essere soggetto ad attacchi rispetto a un servizio su Internet pubblico.

• L'impatto di qualcuno che sta eliminando un forum di discussione dei clienti è inferiore all'impatto che hanno rubato le carte di credito dei clienti.

Il mio punto è che la "sicurezza totale" è "infinitamente costosa" ... e praticamente irrealizzabile. Idealmente, dovresti prendere le tue decisioni su dove tracciare la linea sulla base di un'analisi costi-benefici approfondita.