[wcf] Best practice per la protezione di un'API / servizio web REST



Answers

Non ci sono standard per REST diversi da HTTP. Ci sono servizi REST stabiliti là fuori. Ti suggerisco di dare un'occhiata a loro e avere un'idea di come funzionano.

Ad esempio, abbiamo preso in prestito molte idee dal servizio S3 REST di Amazon durante lo sviluppo del nostro. Ma abbiamo scelto di non utilizzare il modello di sicurezza più avanzato basato sulle firme delle richieste. L'approccio più semplice è l'autenticazione HTTP Basic su SSL. Devi decidere cosa funziona meglio nella tua situazione.

Inoltre, consiglio vivamente il libro RESTful Web Services di O'reilly. Spiega i concetti fondamentali e fornisce alcune buone pratiche. In genere puoi prendere il modello che forniscono e associarlo alla tua applicazione.

Question

Quando si progetta un'API o un servizio REST esistono delle best practice consolidate per la gestione della sicurezza (autenticazione, autorizzazione, gestione dell'identità)?

Quando si crea un'API SOAP si ha WS-Security come guida e molta letteratura sull'argomento. Ho trovato meno informazioni sulla protezione degli endpoint REST.

Mentre capisco che REST intenzionalmente non ha specifiche analoghe a WS- * spero che siano emerse migliori pratiche o modelli raccomandati.

Qualsiasi discussione o link a documenti pertinenti sarebbe molto apprezzato. Se è importante, utilizzeremo WCF con i messaggi serializzati POX / JSON per le nostre API / servizi REST creati utilizzando la v3.5 di .NET Framework.




REST in sé non offre standard di sicurezza, ma cose come OAuth e SAML stanno rapidamente diventando gli standard in questo spazio. Tuttavia, l'autenticazione e l'autorizzazione sono solo una piccola parte di ciò che devi considerare. Molte delle vulnerabilità note relative alle applicazioni Web si applicano molto alle API di REST. È necessario considerare la convalida dell'input, il cracking della sessione, i messaggi di errore inappropriati, le vulnerabilità interne dei dipendenti e così via. È un grande argomento.




OWASP (Open Web Application Security Project) ha alcuni trucchi che trattano tutti gli aspetti dello sviluppo di applicazioni Web. Questo progetto è una fonte di informazioni molto preziosa e affidabile. Per quanto riguarda i servizi REST è possibile controllare questo: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet




Ho usato OAuth un paio di volte e ho usato anche altri metodi (BASIC / DIGEST). Suggerisco di cuore OAuth. Il seguente link è il miglior tutorial che ho visto su OAuth:

http://hueniverse.com/oauth/guide/




Sono un po 'sorpreso SSL con certificati client non è stato ancora menzionato. Certo, questo approccio è davvero utile solo se puoi contare sulla comunità di utenti identificati dai certificati. Ma alcuni governi / aziende li rilasciano ai loro utenti. L'utente non deve preoccuparsi di creare un'altra combinazione di nome utente / password e l'identità viene stabilita su ogni singola connessione in modo che la comunicazione con il server possa essere interamente stateless, senza richiedere sessioni utente. (Per non implicare che nessuna / tutte le altre soluzioni menzionate richiedono sessioni)




Il fatto che il mondo SOAP sia abbastanza ben coperto dagli standard di sicurezza non significa che sia sicuro per impostazione predefinita. In primo luogo, gli standard sono molto complessi. La complessità non è un ottimo amico di sicurezza e le vulnerabilità di implementazione come gli attacchi di wrapping di firma XML sono endemiche qui.

Per quanto riguarda l'ambiente .NET non mi sarà di grande aiuto, ma "Costruire servizi Web con Java" (un mattone con ~ 10 autori) mi ha aiutato molto a capire l'architettura di sicurezza WS- * e, soprattutto, le sue stranezze.




È passato un po 'di tempo ma la domanda è ancora pertinente, anche se la risposta potrebbe essere cambiata un po'.

Un gateway API sarebbe una soluzione flessibile e altamente configurabile. Ho provato e utilizzato KONG un bel po 'e mi è piaciuto molto quello che ho visto. KONG fornisce un'API REST di amministrazione propria che puoi utilizzare per gestire gli utenti.

Express-gateway.io è più recente ed è anche un gateway API.




Per Web Application Security, dovresti dare un'occhiata a OWASP ( https://www.owasp.org/index.php/Main_Page ) che fornisce i cheatsheet per vari attacchi di sicurezza. Puoi incorporare il maggior numero possibile di misure per proteggere la tua Applicazione. Per quanto riguarda la sicurezza dell'API (autorizzazione, autenticazione, gestione dell'identità), esistono diversi modi, come già menzionato (base, digest e OAuth). Esistono fori di loop in OAuth1.0, quindi è possibile utilizzare OAuth1.0a (OAuth2.0 non è ampiamente adottato a causa di problemi con le specifiche)




C'è una grande lista di controllo trovata su Github :

Autenticazione

  • Non reinventare la ruota in Autenticazione, generazione di token, memorizzazione della password. Usa gli standard.

  • Usa le funzioni Max Retry e jail in Login.

  • Usa la crittografia su tutti i dati sensibili.

JWT (Token Web JSON)

  • Usa una chiave complicata a caso (JWT Secret) per fare in modo che la forza bruta imponga il token molto duramente.

  • Non estrarre l'algoritmo dal payload. Forza l'algoritmo nel backend (HS256 o RS256).

  • Effettuare la scadenza del token ( TTL , RTTL ) il più breve possibile.

  • Non memorizzare dati sensibili nel payload JWT , può essere decodificato facilmente.

OAuth

  • Convalidare sempre redirect_uri lato server per consentire solo gli URL autorizzati.

  • Cerca sempre di scambiare codice e non token (non consentire response_type=token ).

  • Utilizza il parametro di stato con un hash casuale per impedire CSRF sul processo di autenticazione OAuth .

  • Definire l'ambito predefinito e convalidare i parametri di ambito per ciascuna applicazione.

Accesso

  • Limitare le richieste (Throttling) per evitare attacchi DDoS / brute-force.

  • Usa HTTPS sul lato server per evitare MITM (Man In The Middle Attack)

  • Utilizza l'intestazione HSTS con SSL per evitare attacchi SSL Strip.

Ingresso

  • Utilizzare il metodo HTTP appropriato in base all'operazione: GET (leggi), POST (crea), PUT/PATCH (sostituisci / aggiorna) e DELETE (per eliminare un record) e risponde con 405 Method Not Allowed se il metodo richiesto non è 'appropriato per la risorsa richiesta.

  • Convalidare il tipo di contenuto su richiesta Accept intestazione (Negoziazione del contenuto) per consentire solo il formato supportato (ad es. application/xml , application/json , ecc.) E rispondere con la risposta 406 Not Acceptable se non corrisponde.

  • Convalidare il content-type di content-type dei dati inviati come si accetta (ad esempio application/x-www-form-urlencoded , multipart/form-data , application/json , ecc.).

  • Convalidare l'input dell'utente per evitare le vulnerabilità comuni (es. XSS, SQL-Injection, Remote Code Execution, ecc.).

  • Non utilizzare dati sensibili (credenziali, password, token di sicurezza o chiavi API) nell'URL, ma utilizzare l'intestazione di Authorization standard.

  • Utilizzare un servizio gateway API per abilitare la memorizzazione nella cache, i criteri di Rate Limit (ad es. Quota, arresto limite, limite di velocità simultanea) e distribuire le risorse API in modo dinamico.

in lavorazione

  • Controllare se tutti gli endpoint sono protetti dietro l'autenticazione per evitare processi di autenticazione danneggiati.

  • L'ID risorsa personale dell'utente deve essere evitato. Usa / me / ordini invece di / utente / 654321 / ordini.

  • Non aumentare automaticamente gli ID. Utilizzare invece UUID.

  • Se stai analizzando i file XML, assicurati che l'analisi delle entità non sia abilitata per evitare XXE (attacco di entità esterna XML).

  • Se stai analizzando i file XML, assicurati che l'espansione dell'entità non sia abilitata per evitare la bomba Billion Laughs / XML tramite un attacco esponenziale di espansione dell'entità.

  • Utilizzare un CDN per i caricamenti di file.

  • Se hai a che fare con una quantità enorme di dati, usa Workers e Code per elaborare il più possibile in background e restituire la risposta velocemente per evitare il blocco HTTP.

  • Non dimenticare di disattivare la modalità DEBUG .

Produzione

  • Invia X-Content-Type-Options: nosniff header.

  • Invia X-Frame-Options: deny intestazione.

  • Invia Content-Security-Policy: default-src 'none' intestazione.

  • Rimuovi le intestazioni delle impronte digitali: X-Powered-By , Server , X-AspNet-Version ecc.

  • Forza il content-type per la risposta, se restituisci l' application/json il tipo di contenuto della tua risposta è application/json .

  • Non restituire dati sensibili come credenziali, password, token di sicurezza.

  • Restituire il codice di stato corretto in base all'operazione completata. (ad es. 200 OK , 400 Bad Request 401 Unauthorized , 401 Unauthorized , 405 Method Not Allowed , ecc.).




Related