La terminologia utilizzata da un browser particolare per descrivere gli addon è leggermente inutile. Alcuni browser chiamano alcuni componenti aggiuntivi, alcuni browser chiamano alcune estensioni di cose. Qualcuno a un certo punto ha avuto l'idea di nominare "cookies" temporanei di archiviazione e quanto è utile come nome.
Quindi un meccanismo di estensione (come in qualsiasi estensione della funzionalità del browser) funziona su due livelli:
1) Il browser implementa alcune lingue secondarie come interfacce utente renderizzate in XML (XUL in firefox è questo, in particolare xulrunner consente di descrivere un'interfaccia utente in xml). Inoltre, molte delle estensioni di firefox possono essere implementate in javascript (cercare spidermonkey e simili, questo è un componente di firefox che esegue javascript - in firefox, ci sono funzioni aggiuntive che permettono a quel javascript di fare cose, come trasformare il DOM del a questo livello il browser può controllare ciò che l'estensione fa abbastanza banalmente, ma tutto ciò che l'estensione vuole fare che Firefox non supporta o non permetterà, non può essere fatto. Ecco una foto:
OS <-- Firefox <-- Nice extension interpreter <- extension javascript.
2) A volte, devi fare qualcosa che firefox non è costruito per fare, o non può essere fatto in modo efficiente in un formato interpretato da javascript o altro, come ad esempio eseguire flash o decodificare weird-codec.oddfile. Situazioni come questa firefox tendono a gestire i "gestori" che operano un po 'in questo modo:
OS <--- Firefox <--- webpage containing something
|
Plugin API---Relevant part of webpage, like <embed>
| |
OS <----- Plugin! like ns_flash.so or such like
Qui, le estensioni sono compilate per corrispondere all'architettura di estensione di firefox per questo genere di cose. Firefox espone un certo insieme di funzioni per consentire all'estensione di controllarlo in determinati modi, ma l'estensione può anche chiedere al sistema operativo di fare le cose direttamente. Se è ben fatto, prende sostanzialmente l'input rilevante (ad esempio, ecco un file .swf ) e fa tutto ciò che deve fare ("firefox, in questa casella, disegnare questo video"). Tuttavia, potrebbe tecnicamente fare qualsiasi cosa l'utente possa fare, perché Firefox non lo sta fermando.
Riguardo al motivo per cui Firesheep deve essere compilato, questo dipende dal fatto che esso dipende da libpcap (o simili), che riguarda l'estrazione di pacchetti di informazioni dal "filo", cioè da un dispositivo che li sta ricevendo. Un'interfaccia wireless è particolarmente suscettibile a questo perché molti adattatori wireless sono omnidirezionali, quindi qualsiasi interfaccia in prossimità preleva questi pacchetti. Di solito, il kernel (sistema operativo) rilascia pacchetti non ad esso indirizzati, tuttavia, impostando l'interfaccia su modalità promiscua è come si chiede di non farlo. libpcap fa questo per te e ti permette di afferrare quei pacchetti. Per fare questo, ha bisogno di un accesso diretto (probabilmente amministrativo / root) al sistema operativo.
Firesheep funziona interamente analizzando tali pacchetti, trovando quelli http che non sono crittografati, raschiandoli per i dati di accesso e segnalandoli.
Ora, torniamo al rischio per la sicurezza di questi plugin - è abbastanza ovvio, un plugin che funziona come codice nativo (in firefox, un plugin, piuttosto che un'estensione) può fare tutto ciò che l'utente può fare (dimentica Firefox)) così come dice giustamente Hendrik, se si ignora l'avvertenza del grosso grasso, questo è un problema. Un'estensione dovrebbe essere in grado di fare danni limitati.
Mentre siamo qui, il modello di Google Chrome è di nuovo diverso. Ogni applicazione su un computer è composta da processi e thread - in molti thread di ose sono fondamentalmente processi leggeri e condividono memoria attraverso il processo ed è così che si ottiene la concorrenza, tuttavia, un singolo thread in crash interrompe l'intero processo e qualsiasi thread può tecnicamente altera la memoria di un altro thread senza restrizioni.
Quindi google chrome funziona creando processi per ogni dominio univoco che visiti in modo univoco, comportandoti come se avessi un processo per scheda (per molti casi d'uso) e ogni estensione in esecuzione che usi. In realtà, puoi anche personalizzare questo per eseguire un processo per scheda o solo un processo per dominio indipendentemente dalle visite che fai. Quindi mentre in Firefox ottieni:
Firefox thread/1
thread/2
thread/3
In google chrome ottieni
Chrome master process
Chrome child process for security.stackexchange.com
Chrome child process for meta.stackoverflow.com
Chrome child process for flash
Ora, ogni processo figlio è strongmente limitato. Il modo standard per creare un processo fornisce per impostazione predefinita le autorizzazioni che il genitore ha (ereditarietà) ma google chrome imposta le autorizzazioni in modo esplicito. I processi figlio possono comunicare solo con il processo principale quando vogliono fare qualcosa e le eventuali chiamate API che fanno al sistema operativo sono severamente limitate dai token di controllo accessi di Windows. Quindi l'idea qui è che un plugin dovrebbe, in teoria, essere solo in grado di fare ciò che è necessario.
Questa è la teoria dell'idea di google chrome. In pratica i documenti di progettazione implicano che devi passare --sandbox-plugins , ovvero non sono attualmente sicuro di cosa i plug-in di estensione sandboxing sono automatici e funzionano correttamente.
