Convalida del tipo di contenuto nelle API REST

Question

Convalida del tipo di contenuto nelle API REST

#1 da (4 voti)

5

Sto provando a capirlo, perché è consigliabile convalidare il content-type , inviato da un client a un'API REST.

Gli stati di OWASP nella scheda Trucchi sulla sicurezza REST :

When POSTing or PUTting new data, the client will specify the Content-Type (e.g. application/xml or application/json) of the incoming data. The server should never assume the Content-Type; it should always check that the Content-Type header and the content are the same type. A lack of Content-Type header or an unexpected Content-Type header should result in the server rejecting the content with a 406 Not Acceptable response.

Non dichiarano mai realmente come possa essere sfruttata una convalida mancante. Ovviamente è meglio convalidare l'input, per il parser dei dati, ma l'intestazione può essere falsificata comunque da un utente malintenzionato, giusto?

Perché è suggerita la convalida content-type e in che modo è possibile sfruttare una convalida mancante?

api rest http header

posta SaAtomic 22.03.2017 - 14:19

fonte

1 risposta

Leggi altre domande sui tag api rest http header

Memorizza le chiavi di crittografia su un server utilizzando Node.js e MySQL Come si memorizza la chiave segreta di un utente su un server?

score 4 · Accepted Answer

In primo luogo, l'autore dell'attacco non può sempre spoofare il tipo di contenuto. Ad esempio, se la tua API REST supporta un'app Web che utilizza i cookie per contenere token di sessione, un utente malintenzionato può provare a utilizzare CORS (cross-origine XHR) o inviare automaticamente moduli HTML per attaccare gli utenti del servizio quando la vittima visita la pagina dell'attacker . Se si effettua una richiesta cross-site dal sito dell'utente malintenzionato (che non dispone dell'autorizzazione CORS per Access-Control-Allow-Header: Content-Type), l'utente malintenzionato non può impostare l'intestazione Content-Type. Tuttavia, se l'applicazione presume che il tipo di contenuto è qualcosa che CORS non consente per impostazione predefinita (come JSON) e non verifica l'intestazione, allora un utente malintenzionato può inviare una richiesta utilizzando uno dei tipi di contenuto non preflight / permesso-per-predefinito / consentito-in modo che venga accettato da un parser JSON (o qualsiasi altra cosa). Naturalmente, idealmente avresti anche protezioni anti-CSRF, ma a volte la gente pensa "Accetto solo JSON e non permetto ai siti di terze parti di inviarmi JSON, quindi sono al sicuro" quando in pratica permettono anche ad altri tipi di contenuto purché il corpo della richiesta sia anche JSON valido.

Altre volte è importante fare cose come lasciare che un utente carichi file (sempre qualcosa da fare con cautela); se si limitano i tipi di file consentiti, ma in realtà non si verifica che il tipo di file caricato sia ciò che si suppone, si potrebbero verificare diversi tipi di problemi (a seconda di cosa si fa con i file caricati). Se fai cose diverse con tipi di file diversi, potresti dover verificare che l'utente abbia specificato un file di uno dei tipi consentiti e che il file caricato sia valido per quel tipo.