Autenticazione / autenticazione iOS con un servizio Web REST

2

siamo attualmente nella fase di progettazione di un nuovo "Gateway-Server" che vogliamo sviluppare. Il nostro server ha un servizio REST. Il mio compito è trovare opzioni valide per proteggere l'accesso al servizio REST di cui sopra (auth / auth)

Questo server verrà utilizzato in un ambiente aziendale, il che significa che abbiamo un LDAP / Active Directory a nostra disposizione. Le informazioni che fornirò tramite questa API sono di alto valore e dovrebbero essere adeguatamente protette sul dispositivo e sul server. L'app e il back-end saranno utilizzati dai dipendenti, non ci sono utenti pubblici.

Useremo un Application Server (Glassfish) come componente base per il nostro back-end. Voglio usare i meccanismi di sicurezza incorporati perché voglio evitare di inventare le mie soluzioni che probabilmente saranno inferiori.

Qual è la best practice per proteggere il back-end dall'accesso non autorizzato / non autenticato?

O più specificamente:

  • Come posso proteggere l'accesso al back-end?
  • È un'opzione per trasmettere il nome utente e la password ad ogni richiesta effettuata dal dispositivo mobile al back-end?
  • È buona norma convalidare il nome utente / password trasmessi contro l'LDAP?

Bello sapere:

  • Il server gateway è dietro un proxy inverso.
  • Gli utenti devono autenticarsi con nome utente / password quando vogliono replicare (connettersi al back-end)
  • la comunicazione tra dispositivo e backend sarà protetta con TLS

Grazie

    
posta theXs 28.02.2013 - 15:38
fonte

1 risposta

2

Ci sono difetti comuni nei sistemi di autenticazione che dovrebbero essere evitati:

  • In un ambiente aziendale è importante terminare autenticazione immediatamente. Se un dipendente viene licenziato, potrebbe cercare vendetta, e anche una stretta finestra di accesso cloud è sufficiente a causare grave perdita monetaria.
  • Bruteforce. Deve esserci un sistema in atto per le richieste di autenticazione a limite di velocità provenienti da un ip specifico. Bloccare le richieste fino a quando un IP può risolvere un capthca è un buon approccio che viene utilizzato da Google e altri.
  • Perdita di informazioni su un canale non sicuro. Questo è mitigato da TLS (o HTTPS). TLS ha i suoi problemi ed è sempre configurato male per impostazione predefinita. Assicurati di utilizzare suite di crittografia sicure (TLS V1 o versioni successive) e di disabilitare le richieste di rinegoziazione. Qualsiasi scanner di vulnerabilità degno di questo nome mostrerà queste violazioni, e sono una scoperta comune in natura.
  • Bypass di iniezione e autenticazione. Assicurati di aver compreso Iniezione LDAP .

Forzare ogni richiesta di contenere un nome utente / password risolve il primo problema di risoluzione immediata. Se ogni richiesta deve essere inviata ad Active Directory, esiste una sola volta per revocare l'accesso. LDAP è un database non relazionale molto veloce e le richieste di filtro sono molto veloci (molto più veloci di SQL).

    
risposta data 28.02.2013 - 19:17
fonte