La terminología que usa un navegador en particular para describir los complementos es un poco inútil. Algunos navegadores llaman a algunas cosas complementos, algunos navegadores llaman a algunas extensiones de cosas. Alguien en algún momento se le ocurrió la idea de nombrar "cookies" de almacenamiento temporal después de todo y qué tan útil es ese nombre.
Por lo tanto, un mecanismo de extensión (como en cualquier extensión de la funcionalidad del navegador) funciona en dos niveles:
1) El navegador implementa algún sub idioma como las interfaces de usuario representadas con XML (XUL en Firefox es esto, específicamente xulrunner le permite describir una interfaz de usuario en xml). Además, muchas de las extensiones de Firefox se pueden implementar en javascript (busque spidermonkey y similares, este es un componente de firefox que ejecuta javascript; en firefox, hay funciones adicionales que permiten que javascript haga cosas, como transformar el DOM del La página que se está navegando actualmente, o lo que sea. En este nivel, el navegador puede controlar lo que hace la extensión de forma bastante trivial, pero cualquier cosa que la extensión quiera hacer que Firefox no admita o no permita, no se puede hacer. >
OS <-- Firefox <-- Nice extension interpreter <- extension javascript.
2) A veces, necesitas hacer algo para lo que Firefox no esté diseñado para hacer, o no se puede hacer de manera eficiente en un formato de javascript u otro interpretado, como ejecutar flash o decodificar weird-codec.oddfile, por ejemplo. Situaciones como esta Firefox tienden a manejarse con "manejadores" que funcionan un poco como este:
OS <--- Firefox <--- webpage containing something
|
Plugin API---Relevant part of webpage, like <embed>
| |
OS <----- Plugin! like ns_flash.so or such like
Aquí, las extensiones se compilan para que coincidan con la arquitectura de extensión de Firefox para este tipo de cosas. Firefox expone un cierto conjunto de funciones para permitir que la extensión lo controle de ciertas maneras, pero la extensión también puede pedirle al sistema operativo que haga las cosas directamente. Si se comporta bien, básicamente toma la entrada relevante (es decir, aquí hay un archivo .swf ) y hace lo que tiene que hacer ("firefox, en este cuadro, dibuja este video"). Sin embargo, técnicamente podría hacer cualquier cosa que su usuario pueda hacer, porque Firefox no lo detiene.
En cuanto a por qué se debe compilar Firesheep, esto se debe a que depende de libpcap (o similar), que trata de extraer paquetes de información del "cable", es decir, de un dispositivo que los está recibiendo. Una interfaz inalámbrica es particularmente susceptible a esto porque muchos adaptadores inalámbricos son omnidireccionales, por lo que cualquier interfaz en la vecindad recoge estos paquetes. Por lo general, su kernel (sistema operativo) eliminará los paquetes que no estén dirigidos a él; sin embargo, configurar la interfaz en modo promiscuo es la forma en que le pide que no lo haga. libpcap hace esto por ti y te permite capturar esos paquetes. Para hacer esto, necesita acceso directo (probablemente administrativo / raíz) al sistema operativo.
Firesheep funciona completamente analizando esos paquetes, encontrando los http que no están encriptados, raspándolos para obtener datos de inicio de sesión y luego informándolos.
Ahora, volviendo al riesgo de seguridad de estos complementos, es bastante obvio, un complemento que funciona como código nativo (en Firefox, un complemento, en lugar de una extensión) puede hacer lo que sea que el usuario pueda hacer (olvídese de Firefox) así que como Hendrik lo expresa correctamente, si ignora la gran advertencia, eso es un problema. Una extensión debería poder hacer un daño limitado.
Mientras estamos aquí, el modelo de Google Chrome vuelve a ser diferente. Cada aplicación en una computadora está compuesta por procesos y subprocesos: en muchos procesos, los subprocesos son básicamente procesos ligeros y comparten memoria a través del proceso y así es como se logra la concurrencia, sin embargo, un solo subproceso colapsa todo el proceso y cualquier subproceso puede técnicamente alterar la memoria de otro hilo sin restricción.
Por lo tanto, google chrome funciona creando procesos para cada dominio único que visita de forma única, actuando como si tuviera un proceso por pestaña (para muchos casos de uso) y cada extensión de ejecución que utiliza. En realidad, también puede personalizar esto para ejecutar un proceso por pestaña o solo un proceso por dominio. independientemente de las visitas que realices. Así que mientras que en Firefox obtienes:
Firefox thread/1
thread/2
thread/3
En google chrome obtienes
Chrome master process
Chrome child process for security.stackexchange.com
Chrome child process for meta.stackoverflow.com
Chrome child process for flash
Ahora, cada proceso hijo está fuertemente restringido. La forma estándar de crear un proceso le otorga de manera predeterminada los permisos que tenga el padre (herencia) pero Google Chrome establece los permisos de forma explícita. Los procesos secundarios solo pueden comunicarse con el proceso principal cuando quieren hacer algo y cualquier llamada a la API que realice al sistema operativo está severamente restringida por los tokens de control de acceso de Windows. Entonces, la idea aquí es que un complemento, en teoría, debe ser capaz de hacer solo lo que necesita.
Esa es en gran medida la teoría de la idea de google chrome. En la práctica, los documentos de diseño implican que debe pasar --sandbox-plugins , es decir, no estoy seguro de qué. la extensión de los complementos de sandboxing es automática y si todos funcionan correctamente todavía.
