In che modo Google Chrome gestisce l'autenticazione sui siti?

Con un cookie!

Chrome, come qualsiasi altro browser, sta memorizzando un cookie nel tuo file system. Questi cookie sono ciò che ti consente di riconnetterti automaticamente ad alcuni siti. Dal momento che si trova nel tuo file system, anche se riavvii, saranno ancora lì. Più processi o meno è irrilevante qui.

Quindi potresti chiederti, se i cookie sono nel mio file system, vuol dire che qualsiasi pagina può accedervi?

No . Solo la pagina per cui è stato creato il cookie può accedervi. Quello che applica questa politica è il tuo browser. Se il tuo browser sta facendo correttamente il suo lavoro, allora sei ok dato che invierà solo il cookie al sito giusto (server).

Puoi anche accedere ai cookie direttamente guardando il file system, ma per questo è necessario avere accesso al sistema operativo. Le pagine web non hanno accesso a questo, quindi il browser sta facendo quel lavoro per loro e dà loro solo i cookie che dovrebbero essere in grado di leggere.

Divertimento

Devi proteggere i tuoi cookie. Rubare i tuoi cookie è quasi come rubare la tua password / nome utente. Se qualcuno o qualcosa del genere, come un virus, ruba i cookie che risiedono sul tuo computer, può impersonare te su quel sito Web se hai effettuato l'accesso.

Puoi controllare, modificare e aggiungere cookie con strumenti come firebug. Quindi, se vuoi montare un attacco falso puoi:

• accedi su un sito web utilizzando chrome
• leggi il cookie in chrome usando lo strumento per sviluppatori
• apri firefox con firebug e aggiungi il cookie di autenticazione che hai trovato in chrome

Sarai quindi connesso a quel sito Web in Firefox e in Chrome. Questa è una versione semplicistica del dirottamento della sessione di hacking. Potresti trasferire il cookie su un altro computer, se lo desideri.

Da questa pagina: link

There's only one browser process, which manages the tabs, windows, and "chrome" of the browser. This process also handles all interactions with the disk, network, user input, and display, but it makes no attempt to parse or render any content from the web.

E dalla sezione sulle schede del renderer:

Each renderer process is run in a sandbox, which means it has almost no direct access to your disk, network, or display. All interactions with web apps, including user input events and screen painting, must go through the browser process. This lets the browser process monitor the renderers for suspicious activity, killing them if it suspects an exploit has occurred.

Suppongo che la parte "interazioni con il disco, la rete, l'input dell'utente" includa cookie di sessione e simili.

Per prima cosa, in particolare su Google Chrome, troverai questo articolo molto utile. CullenJ ha menzionato prima che Chrome utilizza processi non thread, ma non è vero. Usa entrambi. Secondo l'articolo collegato sopra, Chrome utilizza una discussione per gestire le operazioni del database SQlite e fornisce l'esempio delle operazioni sui cookie, così possiamo presumere che Chrome memorizzi i cookie in un database SQLite da qualche parte.

Ora diamo un'occhiata alla seguente citazione:

We discourage locking and threadsafe objects. Instead, objects live on only one thread, we pass messages between threads for communication, and we use callback interfaces (implemented by message passing) for most cross-thread requests.

Quindi, sappiamo che Google utilizza il passaggio dei messaggi e possiamo trovare ulteriori informazioni su di esso leggendo su IPC .

Quali stati:

Chromium has a multi-process architecture which means that we have a lot of processes communicating with each other. Our main inter-process communication primitive is the named pipe. On Linux & OS X, we use a socketpair(). A named pipe is allocated for each renderer process for communication with the browser process. The pipes are used in asynchronous mode to ensure that neither end is blocked waiting for the other.

Within the browser, communication with the renderers is done in a separate I/O thread. Messages to and from the views then have to be proxied over to the main thread using a ChannelProxy. The advantage of this scheme is that resource requests (for web pages, etc.), which are the most common and performance critical messages, can be handled entirely on the I/O thread and not block the user interface. These are done through the use of a ChannelProxy::MessageFilter which is inserted into the channel by the RenderProcessHost. This filter runs in the I/O thread, intercepts resource request messages, and forwards them directly to the resource dispatcher host. See Multi-process Resource Loading for more information on resource loading.

Each renderer also has a thread that manages communication (in this case, the main thread), with the rendering and most processing happening on another thread (see the diagram in multi-process architecture). Most messages are sent from the browser to the WebKit thread through the main renderer thread and vice-versa. This extra thread is to support synchronous renderer-to-browser messages (see "Synchronous messages" below).

Se ti stavi chiedendo quale sia una named pipe Wikipedia dà questa definizione:

A named pipe is system-persistent and exists beyond the life of the process and can be deleted once it is no longer being used. Processes generally attach to the named pipes (usually appearing as a file) to perform inter-process communication.

Ora vorrei ottenere un'ultima citazione dalla documentazione relativa all'architettura multi processo . Si legge come segue:

We also have strategies to assign new tabs to existing processes if the total number of processes is too large, or if the user already has a process open navigated to that domain.

Ho letto anche in uno dei loro documenti che considerano i sottodomini come lo stesso dominio del dominio principale per la compatibilità JavaScript. Ad esempio: sub1.example.com, sub2.example.com e example.com sono considerati come lo stesso dominio di Chrome.

Quindi questo potrebbe non essere il modo in cui croma lo fa esattamente (ma puoi leggerlo ulteriormente seguendo la loro documentazione) ma, in base a ciò che ho letto fino ad ora, posso implementare un browser facendo quanto segue:

1. Sfogliare su facebook.com e il browser avvia un nuovo renderer e crea una named pipe
2. Accedo e il renderer invia un messaggio al thread del database per memorizzare il cookie
3. Apro altri siti non collegati e il browser crea più renderer e pipe
4. Per qualche motivo ho voglia di aprire un'altra scheda per il browser facebook.com e i messaggi del browser il renderer che ha già aperto facebook.com per eseguire il rendering di un'altra scheda.
5. La nuova scheda ha tutte le informazioni disponibili per la prima scheda Facebook.com perché condividono un processo (avrei il processo di memorizzare la propria copia di un cookie o qualcosa per la lettura in modo da non dover disturbare il thread del database , ma potrebbe non essere quello che fa Chrome).
6. Se decido di disconnettermi, il thread del database vede che il cookie è cambiato e lo scrive nel database. Se rimango connesso non tocchi il database.

Ora, devo aggiungere che la durata predefinita dei cookie è quando il browser si chiude e scade. Quindi, per supportare l'apertura e la chiusura del browser, il sito web deve dirlo per ignorare questa durata (che molti siti fanno).

Ok, quindi se un browser sostituisce la durata dei cookie, allora viene memorizzato nel database (sì, nel file system) e verrà letto di nuovo quando tornerai su questo sito. È insicuro conservarlo lì? No, non se il tuo computer non è compromesso e il sistema operativo sta facendo il suo lavoro correttamente.

Come nota a margine, i sistemi operativi hanno trovato il modo di rilevare e bloccare gli attacchi.

Per quanto riguarda l'accesso a un altro browser, fanno tutti cose simili per l'archiviazione dei cookie e se ti infastidisce tanto se usi la modalità di navigazione in incognito di Chrome o vedi questo documentazione che afferma:

If you want Google Chrome to automatically delete cookies when you close all your browser windows, select the "Keep local data only until I quit my browser" checkbox in the Content Settings dialog. You can also make exceptions so that specific sites’ cookies are deleted whenever you close your browser.