Autenticazione HTTP: identifica il client

1

Abbiamo un sito web, in cui ogni utente deve accedere per accedere ad un'area privata. All'interno dell'area privata, ci sono alcune informazioni sull'utente, un profilo, comprese alcune informazioni sensibili (indirizzo di casa, coordinate bancarie, ecc.)

Naturalmente, seguiamo le best practice qui (hashing strong, SSL con gli algoritmi corretti, verifica password deboli, ecc ...).

Offriamo inoltre una base API su OAuth per terze parti. In questo modo l'utente sa a cosa può accedere un'applicazione registrata, l'applicazione non deve memorizzare le credenziali dell'utente, possiamo limitare ciò che l'applicazione ottiene ... tutti i soliti vantaggi. Ad esempio, l'API può leggere le informazioni del profilo, ma le informazioni sensibili vengono cancellate o omesse.

Il problema è: abbiamo un'applicazione di terze parti che ha deciso che l'utilizzo dell'API non era valido; al contrario, richiede le credenziali, le archivia (in testo in chiaro ...), quindi autentica utilizzando un POST. E legge le informazioni dell'utente che eseguono il raschia schermo. In realtà quindi utilizza solo le informazioni "pubbliche", ma potrebbe accedere anche a quelle informazioni sensibili che vorremmo non divulgare.

Non sono particolarmente preoccupato che l'app perderà le informazioni dell'utente (penso che siano state fatte in questo modo perché sono sciatte / pigre, non dannose), ma comunque questo è un comportamento meno desiderabile. E mi ha fatto pensare: c'è un modo per gestire questa situazione alla radice?

Voglio affrontare il problema nel modo più efficace e sto cominciando a chiedermi: c'è un modo per consentire all'utente di accedere SOLO attraverso la tua pagina? Per evitare che qualcun altro si autentichi usando solo un POST? Per quanto ne sappia, puoi renderlo difficile da fare (usare id una tantum nella pagina / intestazioni, usando l'hashing lato client (Javascript), ecc.) Ma non c'è modo di essere sicuro al 100% del post proviene da "la tua pagina". Ma non sono un esperto di sicurezza, quindi potrei mancare qualcosa. E in ogni caso, qual è il modo migliore per mitigare il problema, rendendolo poco pratico (ma con poco o nessun onere per l'utente - nessun captcha - che comunque non risolverà il problema)?

EDIT: per essere chiari: non sto parlando di soluzioni per "prevenire" screen-scraping. Abbiamo già delle attenuazioni per renderlo difficile (e altri per renderlo ancora più difficile in futuro) che farà desistere questa particolare app. Sto parlando della procedura di accesso: cosa puoi fare per assicurarti che il nome utente e la password provengano dal tuo modulo? Uno dei "punti vendita" di OAuth è che date le vostre credenziali a qualcuno (google, twitter) di cui vi fidate; in effetti, si viene reindirizzati a un modulo nel dominio "trusted". Oltre a guardare l'url, la provenienza delle credenziali viene forzata in qualche modo? Se sì, come?

    
posta Lorenzo Dematté 17.06.2014 - 11:02
fonte

3 risposte

1

Se stanno raschiando lo schermo, rompono il loro screen-raschietto cambiando la tua pagina web. Denominare il campo "password" "nome utente" e il campo "nome utente" "password". Introdurre un campo modulo nascosto in modo casuale con contenuti casuali che devono essere postati durante il login. Introdurre modifiche alla struttura della pagina che non modificano l'aspetto. Sii creativo.

Lo screen-scraping si basa su "punti di riferimento" nella pagina per trovare il contenuto importante. Se quei punti di riferimento cambiano costantemente, la persona che scrive lo screen-raschietto dovrà aggiornarla costantemente per mantenerla funzionante e, si spera, otterrà il messaggio che non dovrebbero fare le cose in questo modo.

    
risposta data 17.06.2014 - 11:17
fonte
1

L'utilizzo di un CAPTCHA è solitamente un buon modo per scoraggiare l'automazione. Questo può scoraggiare logins legittimi, e la terza parte può sempre passare il captcha all'utente.

Potresti potenzialmente inserire nella lista nera gli indirizzi IP utilizzati da terzi. Possono aggirare questo cambiando gli indirizzi IP, ma il fastidio di farlo potrebbe essere abbastanza dissuasivo.

Mi viene in mente che ciò che fanno i terzi potrebbe essere illegale in alcune giurisdizioni. Se i tuoi termini e condizioni negano l'accesso a terze parti che non utilizzano l'API OAuth, ritengo che questo sia abbastanza chiaro. (si prega comunque di avere una consulenza legale adeguata)

Anche se non è illegale, puoi avvisare i tuoi utenti legittimi delle applicazioni di terzi che memorizzano i loro dati in modo improprio.

    
risposta data 17.06.2014 - 13:05
fonte
0

Questo è quello che ho ottenuto finora (è un mix delle altre (2) risposte che ho ottenuto fino ad ora, e l'investigazione personale: Per scoraggiamento "generale" dello screen-scraping:

  • Puoi randomizzare l'id / classe del contenuto che viene "raschiato". (ma il raschietto potrebbe analizzare l'HTML in modo più preciso)
  • Per una maggiore malvagità, puoi persino aggiungere altri contenuti, con ID / classe simile, che contiene contenuti simili ma errati ed è nascosto da css (ma il raschietto potrebbe analizzare anche il CSS)
  • Esclusione utente-agente (ma il raschietto può fingere)
  • Potresti vietare l'IP (s) (ma potresti voler consentire app legittime - e accesso web - dallo stesso client)

Ora, puoi evitare tutte le seccature (almeno nel mio caso, dove tutto è dietro un login) "fissando" il login, o meglio, identifica il cliente come autorizzato. Il problema è che nel caso di un'applicazione web, il "client" espone tutto in bella vista: html, css, JS.

Quindi, non hai un posto per "segreti", sul client: tutto ciò che vede il browser, anche il raschietto vede.

In ogni caso, l'obiettivo di questa domanda era di rendere il login attraverso la pagina Web il più difficile da replicare possibile. Finora, questo è quello che ho pensato:

  1. Puoi chiedere CAPTCHA all'accesso (ma questo fa male all'usabilità e può essere passato all'utente)
  2. È possibile eseguire l'autenticazione a due fattori (stesso inconveniente)
  3. Puoi usare qualcosa come un token CSRF (ma dal momento che non sei ancora in una sessione, il cliente può solo "raschiare" il token e inviarlo tramite il login POST)
  4. Puoi usare l'hashing sul lato client, cancellare il token 'CSRF-like' e chiederlo nella risposta (ma questo può essere "sconfitto", leggendo il codice JavaScript e implementando lo stesso hashing o eseguendo direttamente il JS)

Puoi renderlo sempre più difficile, ma siccome il raschietto può imitare un client web legittimo sotto ogni aspetto (e presentare all'utente ciò che anche lui / lei vuole). Se implementi almeno 3 o 4, il "login automatico" (semplicemente inserendo il nome utente e la password) non funziona più, e potrebbe invece essere un strong incentivo nell'utilizzo di OAuth.

Quindi no, per quanto a mia conoscenza è impossibile garantire che l'accesso verrà dal "tuo modulo", perché alla fine è solo un POST, e non c'è modo di affermare l'identità del "tuo modulo" . (Related: OpenID spoofing / phishing )

    
risposta data 20.06.2014 - 13:03
fonte

Leggi altre domande sui tag