Servizi Web sicuri: REST su HTTPS vs SOAP + WS-Security. Che è migliore? [chiuso]

Non sono affatto un esperto di sicurezza, ma preferisco creare servizi Web in stile REST.

Nel creare un nuovo servizio che deve avere i dati che trasmette sicuri. Siamo entrati in un dibattito su quale approccio sia più sicuro: REST con HTTPS o SOAP WS con WS-Security.

Ho l'impressione che potremmo usare HTTPS per tutte le chiamate al servizio web e questo approccio sarebbe sicuro. Per come la vedo io, "se HTTPS è abbastanza buono per siti Web bancari e finanziari, è abbastanza buono per me". Ancora una volta, non sono esperto in questo spazio, ma penso che queste persone abbiano riflettuto molto sul problema e si sentano a proprio agio con HTTPS.

Un collega non è d'accordo e dice che SOAP e WS-Security sono l'unica strada da percorrere.

Il web sembra essere su tutti i fronti.

Forse la comunità qui potrebbe pesare sui pro e contro di ciascuno? Grazie!

HTTPS protegge la trasmissione del messaggio sulla rete e fornisce al client alcune garanzie sull'identità del server. Questo è ciò che è importante per la tua banca o broker di borsa online. Il loro interesse nell'autenticare il client non è nell'identità del computer, ma nella tua identità. Quindi i numeri delle carte, i nomi utente, le password ecc. Vengono utilizzati per autenticarti. Di solito vengono quindi prese alcune precauzioni per garantire che le presentazioni non siano state manomesse, ma nel complesso tutto ciò che accade nella sessione è considerato come avviato da te.

WS-Security offre riservatezza e protezione dell'integrità dalla creazione del messaggio al suo consumo. Quindi, invece di garantire che il contenuto delle comunicazioni possa essere letto solo dal server giusto, garantisce che possa essere letto solo dal giusto processo sul server. Invece di presumere che tutte le comunicazioni nella sessione avviata in modo sicuro provengano da utenti autenticati, ognuno deve essere firmato.

C'è una spiegazione divertente che coinvolge motociclisti nudi qui:

https://docs.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked

Quindi WS-Security offre più protezione di HTTPS e SOAP offre un'API più ricca di REST. La mia opinione è che, a meno che tu non abbia davvero bisogno delle funzionalità o della protezione aggiuntive, dovresti saltare il sovraccarico di SOAP e WS-Security. So che è un po 'un cop-out, ma le decisioni su quanta protezione sia effettivamente giustificata (non solo su cosa sarebbe bello costruire) devono essere prese da coloro che conoscono il problema intimamente.

La sicurezza REST dipende dal trasporto, mentre la sicurezza SOAP no.

REST eredita le misure di sicurezza dal trasporto sottostante mentre SOAP definisce le proprie tramite WS-Security.

Quando parliamo di REST, su HTTP - tutte le misure di sicurezza applicate HTTP vengono ereditate e questo è noto come sicurezza a livello di trasporto.

Sicurezza a livello di trasporto, protegge il tuo messaggio solo mentre si trova sul filo - non appena lascia il filo, il messaggio non è più protetto.

Ma, con WS-Security, la sua sicurezza a livello di messaggio - anche se il messaggio lascia il canale di trasporto, sarà comunque protetto. Inoltre, con la sicurezza a livello di messaggio è possibile crittografare parzialmente il messaggio [non l'intero messaggio, ma solo le parti desiderate] - ma con la sicurezza a livello di trasporto non è possibile farlo.

WS-Security ha misure per autenticazione, integrità, riservatezza e non ripudio, mentre SSL non supporta il non ripudio [con OAuth a 2 zampe].

In termini di prestazioni SSL è molto più veloce di WS-Security.

Grazie...

Tecnicamente, il modo in cui lo hai scritto non è corretto, poiché la comunicazione del metodo SOAP non è sicura e il metodo REST non ha detto nulla sull'autenticazione di utenti legittimi.

HTTPS impedisce agli aggressori di intercettare la comunicazione tra due sistemi. Verifica inoltre che il sistema host (server) sia effettivamente il sistema host a cui l'utente intende accedere.

WS-Security impedisce alle applicazioni non autorizzate (utenti) di accedere al sistema.

Se un sistema RESTful ha un modo per autenticare gli utenti e un'applicazione SOAP con WS-Security utilizza HTTPS, allora entrambi sono davvero sicuri. È solo un modo diverso di presentare e accedere ai dati.

Vedi l' articolo wiki :

In situazioni point-to-point, la riservatezza e l'integrità dei dati possono anche essere applicate ai servizi Web mediante l'utilizzo di Transport Layer Security (TLS), ad esempio inviando messaggi tramite https.

WS-Security risolve tuttavia il problema più ampio del mantenimento dell'integrità e della riservatezza dei messaggi fino a quando non viene inviato un messaggio dal nodo di origine, fornendo la cosiddetta sicurezza end-to-end.

Questo è:

• HTTPS è un meccanismo di sicurezza a livello di trasporto (punto a punto)
• WS-Security è un meccanismo di sicurezza a livello di applicazione (end-to-end).

Come dici tu, REST è abbastanza buono per le banche, quindi dovrebbe essere abbastanza buono per te.

Esistono due aspetti principali della sicurezza: 1) crittografia e 2) identità.

La trasmissione in SSL / HTTPS fornisce la crittografia via cavo. Ma dovrai anche assicurarti che entrambi i server possano confermare di sapere con chi stanno parlando. Questo può avvenire tramite certificati client SSL, segreti condivisi, ecc.

Sono sicuro che si potrebbe affermare che SOAP è "più sicuro" ma probabilmente non in alcun modo significativo. L'analogia dei motociclisti nudi è carina ma se accurata significherebbe che l'intera Internet è insicura.

Non ho ancora il rappresentante necessario per aggiungere un commento o avrei semplicemente aggiunto questo alla risposta di Bell. Penso che Bell abbia fatto un ottimo lavoro nel riassumere i pro e i contro di alto livello dei due approcci. Solo alcuni altri fattori che potresti voler considerare:

1) Le richieste tra i tuoi clienti e il tuo servizio devono passare attraverso intermediari che richiedono l'accesso al payload? In tal caso, WS-Security potrebbe adattarsi meglio.

2) In realtà è possibile utilizzare SSL per fornire al server la certezza dell'identità dei client usando una funzione chiamata autenticazione reciproca. Tuttavia, questo non è molto utile al di fuori di alcuni scenari molto specializzati a causa della complessità della sua configurazione. Quindi Bell ha ragione sul fatto che WS-Sec si adatta molto meglio qui.

3) SSL in generale può essere un po 'un orso per l'installazione e la manutenzione (anche nella configurazione più semplice) a causa in gran parte dei problemi di gestione dei certificati. Avere qualcuno che sa come farlo per la tua piattaforma sarà un grande vantaggio.

4) Se potrebbe essere necessario eseguire una qualche forma di mappatura delle credenziali o federazione delle identità, WS-Sec potrebbe valere il sovraccarico. Non che non puoi farlo con REST, hai solo meno struttura per aiutarti.

5) Portare tutte le truffe di WS-Security nei posti giusti sul lato client delle cose può essere più una seccatura di quanto pensi che dovrebbe.

Alla fine, però, dipende davvero da molte cose che probabilmente non sapremo. Per la maggior parte delle situazioni direi che uno dei due approcci sarà "abbastanza sicuro" e quindi non dovrebbe essere il principale fattore decisivo.

Brace yourself, here there's another coming :-)

Oggi ho dovuto spiegare alla mia ragazza la differenza tra il potere espressivo di WS-Security rispetto a HTTPS. È un informatico, quindi anche se non conosce tutto il jumbo XML di mumbo capisce (forse meglio di me) cosa significa crittografia o firma. Tuttavia, volevo un'immagine forte, che potesse farle capire davvero a cosa servono le cose, piuttosto che come sono state implementate (che è arrivato un po 'più tardi, non è sfuggita :-)).

Quindi va così. Supponi di essere nudo e di guidare la tua moto verso una determinata destinazione. Nel caso (A) attraversi un tunnel trasparente: la tua unica speranza di non essere arrestato per un comportamento osceno è che nessuno sta guardando. Questa non è esattamente la strategia più sicura che puoi escogitare ... (nota la caduta di sudore dalla fronte del ragazzo :-)). Ciò equivale a un POST in chiaro, e quando dico "equivalente" intendo. Nel caso (B), ti trovi in ​​una situazione migliore. Il tunnel è opaco, quindi fintanto che viaggi in esso il tuo registro pubblico è al sicuro. Tuttavia, questa non è ancora la situazione migliore. Devi ancora uscire di casa e raggiungere l'ingresso del tunnel, e una volta fuori dal tunnel probabilmente dovrai scendere e camminare da qualche parte ... e questo vale per HTTPS. Vero, il tuo messaggio è sicuro mentre attraversa il più grande abisso: ma una volta consegnato dall'altra parte non sai davvero quante fasi dovrà passare prima di raggiungere il punto reale in cui i dati verranno elaborati. E ovviamente tutte quelle fasi potrebbero usare qualcosa di diverso rispetto a HTTP: un MSMQ classico che buffer richieste che non possono essere servite subito, per esempio. Cosa succede se qualcuno nasconde i tuoi dati mentre si trovano in quel limbo di preelaborazione? Hm. (leggi questo "hm" come quello pronunciato da Morfeo alla fine della frase "pensi che sia l'aria che stai respirando?"). La soluzione completa (c) in questa metafora è dolorosamente banale: mettiti dei vestiti dannati su te stesso, e specialmente sul casco mentre sei in moto !!! Quindi puoi tranquillamente andare in giro senza dover fare affidamento sull'opacità degli ambienti. Si spera che la metafora sia chiara: i vestiti vengono con te indipendentemente dalla media o dall'infrastruttura circostante, come fa la sicurezza a livello di messaggistica. Inoltre, puoi decidere di coprire una parte ma rivelarne un'altra (e puoi farlo su base personale: la sicurezza aeroportuale può togliere la giacca e le scarpe, mentre il tuo medico può avere un livello di accesso più elevato), ma ricorda che le camicie a maniche corte sono cattiva pratica anche se sei orgoglioso del tuo bicipite :-) (meglio una polo o una maglietta).

Sono felice di dire che ha capito! Devo dire che la metafora dei vestiti è molto potente: sono stato tentato di usarlo per introdurre il concetto di politica (i club della discoteca non ti lasceranno con le scarpe sportive; non puoi andare a prelevare denaro in una banca in mutande) , mentre questo è un aspetto perfettamente accettabile mentre ti bilanci su una tavola da surf; e così via) ma ho pensato che per un pomeriggio fosse abbastanza ;-)

Architettura - WS, Wild Ideas

Per gentile concessione: http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked. aspx

Lavoro in questo spazio ogni giorno, quindi voglio riassumere i buoni commenti su questo nel tentativo di chiuderlo:

SSL (HTTP / s) è solo un livello che garantisce:

1. Il server al quale è collegato presenta un certificato che dimostra la sua identità (sebbene ciò possa essere falsificato tramite avvelenamento da DNS).
2. Il livello di comunicazione è crittografato (non intercettare).

WS-Security e relativi standard / implementazioni utilizzano PKI che:

1. Dimostrare l'identità del client.
2. Dimostrare che il messaggio non è stato modificato in transito (MITM).
3. Consente al server di autenticare / autorizzare il client.

L'ultimo punto è importante per le richieste di servizio quando l'identità del cliente (chiamante) è fondamentale per sapere se devono essere autorizzati a ricevere tali dati dal servizio. SSL standard è l'autenticazione unidirezionale (server) e non fa nulla per identificare il client.

La risposta in realtà dipende dai tuoi requisiti specifici.

Ad esempio, è necessario proteggere i propri messaggi Web o non è richiesta la riservatezza e tutto ciò che serve è autenticare le parti finali e garantire l'integrità del messaggio? Se questo è il caso - e spesso accade con i servizi Web - HTTPS è probabilmente il martello sbagliato.

Tuttavia, per esperienza, non trascurare la complessità del sistema che stai costruendo. Non solo HTTPS è più facile da distribuire correttamente, ma è più facile eseguire il debug di un'applicazione che si basa sulla sicurezza del livello di trasporto (su HTTP semplice).

In bocca al lupo.

REST su HTTPS Dovrebbe essere un metodo sicuro fintanto che il provider API implementa l'autorizzazione a fine server. In un caso di applicazione Web, ciò che facciamo è accedere a un'applicazione Web tramite HTTPS e alcune autenticazioni / autorizzazioni, tradizionalmente le applicazioni Web non presentavano problemi di sicurezza, quindi API Restful contrasterebbe senza problemi problemi di sicurezza!

Se la tua chiamata RESTFul invia messaggi XML avanti e indietro incorporati nel corpo HTML della richiesta HTTP, dovresti essere in grado di avere tutti i vantaggi di WS-Security come la crittografia XML, i certificati, ecc. Nei tuoi messaggi XML mentre usi qualsiasi funzionalità di sicurezza sono disponibili da http come la crittografia SSL / TLS.