Iniezione di informazioni in una pagina Web (Gmail). Solleva problemi di sicurezza?

3

Sto sviluppando un'estensione Google Chrome che crittografa / decrittografa le email per gli utenti Gmail. Pertanto, rilevo le e-mail crittografate quando l'utente apre una e-mail sull'utilizzo dei tag. Una volta che una e-mail criptata è stata rilevata, all'utente viene chiesta una password e il testo in chiaro è visualizzato in un pop-up.

Voglio usare la finestra di dialogo dell'interfaccia utente di Jquery per visualizzare il testo normale. Se conosci un po 'della finestra di dialogo dell'interfaccia utente di Jquery, sai che devi inserire un tag div nella pagina web (gmail qui) in cui inserisci le cose che vuoi visualizzare nel pop-up. E poi chiama il dialogo su questo div.

Quindi le mie domande sono:

1.) Solleva problemi di sicurezza per iniettare il testo normale nella pagina Web?

2.) La pagina Web (così Gmail) può rilevare tale iniezione?

3.) È vulnerabile a un attacco Man in the middle?

Idealmente, non vorrei che Gmail fosse in grado di rilevarlo e ottenere il testo normale, specialmente quando ora siamo a conoscenza del programma PRISM, ma se può essere rilevato solo da Gmail e da nessun altro è comunque buono per un inizio.

    
posta Kheil 02.07.2013 - 22:15
fonte

2 risposte

3

1.) Does it raise security problems to inject the plain text in the web page ?

Il testo semplice è solo testo ... non ci sono impatti sulla sicurezza a meno che non inizi ad iniettare codice che viene effettivamente eseguito lato server. Oltre ciò, quello che stai descrivendo è crittografia / decrittazione lato client. Di conseguenza, finirai con testo normale (= decrittografato) o con un blocco di caratteri "casuali" (= crittografato, supposizione codifica base64 dopo la crittografia e decodifica bas64 prima che la decodifica sia più sicura quando si pensa ai trasferimenti di posta elettronica)

2.) Does the web page (so Gmail) can detect such injection ?

Poiché Google cambia / aggiorna il suo codice su una base piuttosto frequente, è difficile dirlo. Al momento non lo farebbe ... tuttavia potrebbe cambiare ogni secondo (a seconda di quando Google effettuerà un prossimo aggiornamento minore online). Teoricamente, è possibile per Google implementare una semplice routine javascript che cerca le modifiche della pagina stessa o degli elementi figlio del documento (come la textarea). In pratica, non è attualmente in esecuzione ... ma come ho detto: quando Google modifica il suo codice, potresti trovarti nei guai e la tua estensione non sarà valida prima che sia realmente live.

3.)Is it vulnerable to a Man in the middle attack ?

Se con "it", intendi la crittografia / decodifica sul lato client ... no, come succede CLIENT-side prima di inviare dati ovunque.

Se con "it" intendi "traffico email" quando invii i dati dopo la crittografia, dovresti sapere che - generalmente - il traffico email "può" essere vulnerabile agli attacchi MITM. Tuttavia, poiché la posta di Google tende a rafforzare l'uso di SSL, personalmente ritengo che sia sicuro dagli attacchi MITM quando gli utenti mantengono effettivamente l'SSL abilitato in ogni momento.

Parlando di vulnerabilità, vorrei indicarti altre due cose che dovresti prendere in considerazione:

  1. A seconda della cripta che userete, il modo in cui implementerete le cose può e avrà un impatto importante sulle potenziali vulnerabilità (criptate) da considerare.

  2. Le macchine client di mittente e / o destinatario potrebbero essere compromesse, intercettando e trasferendo i dati decifrati usando malware come trojan.

  3. L'invio di blocchi di dati crittografati via email può e molto probabilmente ti metterà al centro di qualunque agenzia governativa possa essere interessata al contenuto di tali "messaggi codificati". È noto da anni, ma le notizie recenti relative a #prism ci hanno ricordato che "loro" stanno attivamente analizzando il traffico come e-mail quando qualcosa sembra sospetto. Immagino di non dover spiegare che l'uso della crittografia non sta dicendo "Non ho niente da nascondere" , ma piuttosto il contrario.

Ultimo ma non meno importante, ricorda che - quando si tratta di sviluppo di software in generale - ci sono restrizioni all'importazione di crittografia e ci sono ancora più restrizioni relative alla esportazione di crittografia e export of cryptography negli Stati Uniti ) relativo alle implementazioni crittografiche. A seconda della residenza, questi potrebbero avere un impatto sul prodotto che si intende creare. Attualmente, molti paesi, in particolare quelli che partecipano al Wassenaar Arrangement , hanno restrizioni simili. Quindi, assicurati di leggere i documenti forniti con gli algoritmi crittografici che intendi utilizzare o potresti affrontare altri tipi di problemi in seguito.

    
risposta data 03.07.2013 - 03:06
fonte
2
  1. Gmail esegue alcuni seri filtri sui contenuti delle e-mail visualizzate per evitare attacchi XSS. Quando inizi a inviare e-mail crittografate, dovresti occuparti di queste cose se inserisci dati forniti dall'utente nel contesto di Gmail. Questo compito è tutt'altro che banale, suggerisco di dare un'occhiata a soluzioni whitelist come HTML Purifier .
  2. Se stiamo parlando solo della parte di iniezione, Gmail avrebbe bisogno di un codice speciale lato client da generare per rilevare il codice iniettato. Tuttavia, Gmail sarà in teoria in grado di rilevare che stai inviando dati crittografati sul lato server (in base ai metadati generati per la tua soluzione o semplicemente misurando l'entropia) e utilizza queste informazioni per segnalare che l'iniezione di codice avrà probabilmente luogo. Forse puoi usare qualche tipo di steganografia ma tieni presente che i servizi di intelligence sono veramente intelligenti.
  3. In base al secondo punto Gmail (NSA, Big Brother, l'hacker che ha rilevato Gmail, ecc.) avrà modi per rilevare il fatto della crittografia e finché riporterà il testo in chiaro al proprio origin , avranno dei modi per leggerlo.
risposta data 02.07.2013 - 23:04
fonte

Leggi altre domande sui tag