Vantaggi / Svantaggi che non consentono richieste di accesso non Ajax

0

Sul progetto a cui sto lavorando, ho notato che all'accesso è presente un back-end di controllo che controlla se la richiesta è una richiesta di ajax (controlla 'X-Requested-With: XMLHttpRequest') o no. Se la richiesta è una richiesta Ajax, viene eseguito il login, altrimenti la richiesta se negata.

Nessuno sa perché questo controllo è necessario qui e le persone che hanno aggiunto questo controllo non sono disponibili. Ciò solleva alcune domande nella mia testa, perché a un servizio REST non dovrebbe essere consentito l'accesso utilizzando una richiesta "non ajax"? è più sicuro (non vedo come)?

L'unico vantaggio su back-end che posso vedere per questo è se vogliamo server diversi contenuti (html per richieste 'non ajax', json per ajax).

Ci sono altri vantaggi / svantaggi nell'usare questo controllo?

    
posta haraki 02.04.2018 - 18:30
fonte

1 risposta

2

Per servire contenuti diversi, dovrebbe essere utilizzata la negoziazione del contenuto corretta. Il tipo di contenuto di base su alcune intestazioni personalizzate anziché l'intestazione di richiesta Accept rende le cose più complesse di quanto debbano essere. Tuttavia, hai ragione che questo potrebbe essere uno dei motivi, implementato da una persona che non aveva familiarità con HTTP.

Un'altra possibilità sarebbe quella di rendere il sistema più sicuro. Sebbene questo sia un modo sbagliato per proteggere il sistema (poiché la restrizione può essere facilmente aggirata dal client aggiungendo l'intestazione richiesta), impedisce ai robot semplicistici di testare le combinazioni utente / password, " come dichiarato da amon .

Una terza possibilità sarebbe quella di assicurarsi che le richieste di accesso vengano sempre effettuate tramite AJAX (per alcuni motivi criptici). In questo modo, se il codice lato client viene modificato in modo da eseguire POST ordinario per l'accesso, sarà presto possibile capire che qualcosa è andato storto, dal momento che l'accesso non funzionerà più.

Nessuno di questi motivi è abbastanza strong da giustificare l'uso dell'intestazione personalizzata:

  • La negoziazione del contenuto dovrebbe essere eseguita utilizzando il meccanismo HTTP standard. Non è necessario reinventare la ruota solo per rendere la manutenzione più difficile di quanto non sia necessario.

  • La sicurezza dovrebbe essere gestita correttamente, usando procedure di sicurezza standard. L'argomento è troppo grande per essere descritto in una risposta, quindi vedi Security.SE e i libri sull'argomento, se interessati.

  • Se esiste un motivo valido per effettuare solo accessi AJAX, il codice dovrebbe essere modificato per rendere questo motivo molto esplicito. Se non ci sono motivi, dovrebbe consentire sia le azioni di accesso AJAX che quelle non AJAX per rendere possibile l'utilizzo del sito Web da parte di utenti che hanno disabilitato JavaScript. A seconda dell'applicazione, questo potrebbe non avere molto senso (se l'applicazione rimanente si basa completamente su JavaScript, non vi è alcun motivo per consentire tali utenti in ogni caso).

risposta data 02.04.2018 - 20:07
fonte

Leggi altre domande sui tag