wcf - tutorial - rest web service java




Best practice per la protezione di un'API/servizio web REST (12)

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.


È 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.


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 un'enorme quantità di dati, usa Workers e Queues 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.).


Come detto, Amazon S3 è un buon modello con cui lavorare. Le loro firme di richiesta hanno alcune caratteristiche (come l'incorporazione di un timestamp) che aiutano a prevenire la riproduzione di richieste accidentali e dannose.

La cosa bella di HTTP Basic è che praticamente tutte le librerie HTTP lo supportano. Ovviamente, in questo caso, è necessario richiedere SSL perché inviare password in chiaro su Internet è quasi universalmente una cosa negativa. È preferibile eseguire il Digest di base quando si utilizza SSL perché, anche se il chiamante sa già che sono richieste le credenziali, Digest richiede un ulteriore roundtrip per scambiare il valore nonce. Con Basic, i chiamanti inviano semplicemente le credenziali la prima volta.

Una volta stabilita l'identità del cliente, l'autorizzazione è in realtà solo un problema di implementazione. Tuttavia, è possibile delegare l'autorizzazione ad altri componenti con un modello di autorizzazione esistente. Ancora una volta la cosa bella di Basic qui è che il tuo server finisce con una copia in chiaro della password del client che puoi semplicemente passare ad un altro componente all'interno della tua infrastruttura, se necessario.



Ho cercato molto sulla sicurezza di ws e abbiamo finito con l'utilizzo di token tramite cookie dal client al server per autenticare le richieste. Ho utilizzato la sicurezza di primavera per l'autorizzazione delle richieste in servizio perché dovevo autenticare e autorizzare ogni richiesta in base a criteri di sicurezza specificati che erano già presenti nel DB.


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/


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.


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


Puoi anche dare un'occhiata a OAuth , un protocollo aperto emergente per l'autorizzazione basata su token che si rivolge in modo specifico alle http apis.

È molto simile all'approccio adottato da flickr e ricorda l' apis del latte "resto" (non necessariamente buoni esempi di apis riposati, ma buoni esempi dell'approccio basato sui token).


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.


Tutti in queste risposte hanno trascurato il vero controllo / autorizzazione degli accessi.

Se ad esempio le tue API / servizi web REST riguardano il POSTing / GETing delle cartelle cliniche, potresti voler definire la polizza di controllo degli accessi su chi può accedere ai dati e in quali circostanze. Per esempio:

  • i medici possono ottenere la cartella clinica di un paziente con cui hanno una relazione di assistenza
  • nessuno può inviare dati medici al di fuori delle ore di pratica (ad esempio da 9 a 5)
  • gli utenti finali possono ottenere le cartelle cliniche di loro proprietà o le cartelle cliniche dei pazienti per i quali sono tutori
  • gli infermieri possono AGGIORNARE la cartella clinica di un paziente che appartiene alla stessa unità dell'infermiere.

Al fine di definire e implementare tali autorizzazioni a grana fine, sarà necessario utilizzare un linguaggio di controllo degli accessi basato su attributi chiamato XACML, il linguaggio di markup del controllo di accesso eXtensible.

Gli altri standard qui sono i seguenti:

  • OAuth: id. federazione e delega di autorizzazione, ad esempio lasciando che un servizio agisca per mio conto su un altro servizio (Facebook può postare sul mio Twitter)
  • SAML: identity federation / web SSO. SAML parla molto di chi è l'utente.
  • Standard WS-Security / WS- *: si concentrano sulla comunicazione tra i servizi SOAP. Sono specifici del formato di messaggistica a livello di applicazione (SOAP) e trattano aspetti di messaggistica, ad es. Affidabilità, sicurezza, riservatezza, integrità, atomicità, eventi ... Nessuno copre il controllo degli accessi e tutti sono specifici per SOAP.

XACML è indipendente dalla tecnologia. Può essere applicato a applicazioni Java, .NET, Python, Ruby ... servizi Web, API REST e altro ancora.

Le seguenti sono risorse interessanti:


Uno dei migliori post che abbia mai visto per quanto riguarda la sicurezza in relazione a REST è finito a 1 RainDrop . Le API di MySpace usano OAuth anche per la sicurezza e hai pieno accesso ai loro canali personalizzati nel codice RestChess, con cui ho fatto molte esplorazioni. Questo è stato demoato su Mix e puoi trovare il post here .





rest-security