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:
-
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.
-
Le macchine client di mittente e / o destinatario potrebbero essere compromesse, intercettando e trasferendo i dati decifrati usando malware come trojan.
-
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.