Sicurezza del portale di informazioni verticali con un browser Web personalizzato

3

Sto creando un SaaS che verrà consegnato attraverso un portale di informazioni verticali (VIP).

Nella mia ricerca ho scoperto che sviluppando un browser web snello personalizzato e installandolo sulla piattaforma client, posso limitare l'accesso al portale sul Web, consentendo solo a questo browser personalizzato di accedervi.

Comprendo che esiste una minaccia di duplicazione del browser client. ma ritengo sia un'opzione migliore invece che qualsiasi browser possa accedere al portale per ricevere i servizi a pagamento e molto più facile da contrassegnare per la pirateria.

Tuttavia, per quanto riguarda la sicurezza di un browser personalizzato, non sono stato in grado di trovare alcuna informazione utile. Vorrei approfondire su questo punto, ma a meno che non mi manchi qualcosa (che probabilmente è il caso), non ho nulla da fare.

Puoi indicarmi la direzione giusta per effettuare una valutazione approfondita delle minacce su un build del browser personalizzato per un SaaS consegnato da VIP?

Modifica

Guardando le possibilità di una connessione personalizzata da server a client, non sto cercando di reinventare la ruota, ma guardando opzioni innovative per apportare miglioramenti alla ruota.

Non presumo che nessun sistema sia totalmente sicuro e credo fermamente che la pratica della IT Security sia un costante work in progress che deve essere migliorato (quindi, lo scopo di questa domanda).

    
posta Chad 21.05.2012 - 03:09
fonte

2 risposte

3

A me sembra che tu voglia accedere alla tua applicazione SaaS basata sul Web solo da browser / client / host che hanno alcune proprietà di integrità del sistema che di solito mancano in un tipico host di client Web - ad es. assenza di malware, resistenza al malware. Se è così, allora dovresti prendere in considerazione lo sviluppo di un client che è un'appliance dedicata al browser dedicata: a) consegnato agli utenti come immagine liveCD da avviare su PC HW tipico da RO; b) costruito usando SE Linux e bootstrap per limitare il software applicativo eseguibile a un browser web; c) filtro di pacchetti locale configurato per consentire la comunicazione solo con l'host (i) del lato server dell'applicazione; d) browser configurato per fidarsi solo del certificato del server lato server dell'applicazione; e) molte altre caratteristiche di supporto, ma questo è il succo.

Un esempio funzionante di appliance browser dedicata e rinforzata è disponibile all'indirizzo:      link Inoltre, è probabile che si desideri creare nell'immagine client una coppia di chiavi e un certificato PK che il server richiede come pre-richiesta per il servizio. Come si fa notare, è certamente possibile estrarre e utilizzare la coppia di chiavi e chiavi da un diverso host client; ma è una buona misura per prevenire l'uso casuale o accidentale di host "normali" del client in modo che il server interagisca con questi client rischiosi. Se la tua applicazione utilizza un'autenticazione utente avanzata, ridimensiona ulteriormente il rischio limitando il pool di persone che trarrebbero vantaggio da qualcosa di così strano come le chiavi di cracking di un dispositivo browser dedicato e perfettamente utilizzabile, al fine di installare il loro PC esistente come client, senza dover avviare dal supporto RO come pre-richiesta per l'utilizzo dell'applicazione.

Spero che questo aiuti! John Sebes link

    
risposta data 21.05.2012 - 22:28
fonte
1

Questa è (in) sicurezza sebbene oscura , non vedo come questo migliori la sicurezza di qualsiasi sistema. Probabilmente il motivo per cui non riesci a trovare alcuna informazione su questo argomento è perché non è una buona idea. Sospetto che avresti implementato anche il tuo protocollo HTTP, e poi proibirai ai clienti di annusare il cavo con wireshark / Tcpdump. Oah e dovrai proibire al cliente di aprire i propri social e accedere a telnet ...

Ma a parte questo, posso ancora trovare e sfruttare xss / csrf / sql injection / qualsiasi cosa usi solo un browser Web ... Ciò che impedisce all'utente malintenzionato di inserire istruzioni SQL in un modulo html o nella barra degli indirizzi. Quindi, reimplementando il wheal, stai già dando all'attaccante uno strumento perfetto per compromettere il tuo sistema.

Qual è il punto?

    
risposta data 21.05.2012 - 04:38
fonte

Leggi altre domande sui tag