Aggiornamento del metodo di richiesta e filtraggio del tipo di contenuto per la protezione da CSRF
Cross-site request forgery (CSRF) è un attacco da applicazione web che invia una richiesta falsa per conto di una vittima inconsapevole. Se un utente è attualmente autenticato in un sito e può essere indotto a inviare un comando dannoso, l'autore dell'attacco può fare una richiesta di modifica di stato utilizzando le credenziali della vittima.
Per ulteriori informazioni, vedere i link riportati di seguito.
Una difesa comune contro gli attacchi CSRF consiste nell'utilizzare token sincronizzati. Tuttavia, ThingWorx utilizza un approccio alternativo e instrada tutte le richieste tramite un filtro restrittivo del tipo di contenuto. Questo approccio è ugualmente sicuro ma è più appropriato per un'implementazione senza stato.
Aggiornare il metodo di richiesta
Per default, il metodo di richiesta non può essere modificato mediante i parametri di richiesta. Se l'applicazione è stata sviluppata utilizzando queste procedure, è possibile procedere come descritto di seguito.
• Rimuovere eventuale codice che modifichi un metodo GET in un metodo POST tramite i parametri di richiesta. Questo è l'approccio consigliato come best practice.
• Impostare il valore Consenti cambio metodo di richiesta nella configurazione del sottosistema Piattaforma su true.
 |
Questa non è la best practice consigliata e si deve essere consapevoli che, se si segue questa procedura, si espone l'implementazione/l'applicazione alla possibilità di attacchi CSRF.
L'opzione Consenti cambio metodo di richiesta è obsoleta e verrà rimossa dalle future release di ThingWorx.
|
Filtraggio del tipo di contenuto
ContentTypeFilter è stato implementato per verificare che il tipo di contenuto nell'intestazione della richiesta sia applicazione/json, applicazione/xml o testo/xml per tutti i metodi POST, PUT e DELETE. Se la richiesta è multipart/form-data, verifica la presenza di un'intestazione X-XSRF-TOKEN con il valore TWX-XSRF-TOKEN-VALUE. Le richieste per questi dati di modulo/multiparte sono per il caricamento di file.
• Se si eseguono caricamenti di file, il browser deve implementare l'oggetto FormData.
 |
FormData non è disponibile nei browser meno recenti (Internet Explorer 9 e versioni precedenti), pertanto in questi browser il caricamento di file non funziona (incluse le importazioni di estensioni ed entità) quando è incluso ContentTypeFilter.
|
|
|
L'opzione Filter Content-Type può essere disattivata nel sottosistema Piattaforma tuttavia si deve essere consapevoli che, se si esegue questa operazione, si espone l'implementazione/l'applicazione alla possibilità di attacchi CSRF.
L'opzione Filter Content-Type è obsoleta e verrà rimossa dalle future release di ThingWorx. Dopo la rimozione, un amministratore non è più in grado di disattivare il tipo di contenuto del filtro.
|
Best practice per la protezione da CSRF
Utilizzare le linee guida riportate di seguito per gestire la protezione da CSRF.
• Quando si sviluppano nuove applicazioni, tutti i mashup creati in Composer sono protetti. Se si utilizza un'interfaccia utente personalizzata che accede a ThingWorx tramite l'API REST, assicurarsi che non si includano richieste che richiedono un cambio di metodo.
• Quando si sviluppano nuove estensioni Java, verificare che tutti i nuovi servizi siano esposti tramite il framework di annotazione dei servizi di ThingWorx. Questo framework è responsabile dell'identificazione, della mappatura e dell'instradamento di tutte le richieste in entrata in un'implementazione di un servizio. Tutti i servizi creati ed esposti mediante le annotazioni dei servizi di ThingWorx saranno protette da CSRF.
• Nel caso raro in cui un nuovo servizio debba ignorare il framework di annotazione di ThingWorx, verificare che il servizio reagisca solo ai metodi GET, POST, PUT o DELETE.
Link correlati