Domanda:
In che modo i browser si assicurano che la loro pagina delle impostazioni sia sicura
ThankYouSRT
2017-11-17 17:11:14 UTC
view on stackexchange narkive permalink

Dai un'occhiata all'immagine sottostante.

settings page

Questa pagina non viene caricata su https, quindi come fanno i browser moderni ad assicurarsi che questo la pagina è sicura?

Contro cosa stai cercando di proteggerli?
@Alpha3031: l'utilizzo di TLS lo renderebbe meno sicuro.Ciò comporterebbe l'apertura di una connessione socket che potrebbe essere potenzialmente Man in the Middle'd.Dal momento che il binario chrome dovrebbe contenere il certificato per firmare le richieste, chiunque abbia accesso a quel binario e la connessione potrebbe leggere / modificare i dati.
Come nota a margine, se si guarda nella sezione sulla sicurezza della console di sviluppo nella pagina delle impostazioni, verrà segnalato che ["Questa pagina non è sicura."] (Https://i.stack.imgur.com/fwflO.png)
Chrome ha impostazioni extra se accedi utilizzando un account Google.Pertanto, una volta effettuato l'accesso. Le impostazioni personalizzate sono protette tramite la memoria utente remota.
@MichealJohnson: Perché scrivere un'interfaccia utente in HTML + CSS + JS è molto più semplice di C ++.
@MichealJohnson, ed eccomi qui, aprendo questo e pensando che sarebbe stato esattamente il punto.
@SiyuanRen Non è così difficile creare un'interfaccia in un linguaggio come C o C ++.Ci sono toolkit per renderlo ancora più semplice.Gli sviluppatori lo fanno sempre.Dubito che la pigrizia sia l'unica ragione.
@MichealJohnson: qui abbiamo gli sviluppatori di uno dei migliori toolkit dell'interfaccia utente cross-platform e cross-technology al mondo: HTML + CSS + JS, e stai suggerendo che sono pigri se non usano un altro toolkit per sviluppare la propria interfaccia utente?Gli sviluppatori Java sarebbero anche pigri per lo sviluppo di Eclipse in Java?
@LieRyan No, stai perdendo il punto.Non è un * molto * lavoro sviluppare un'interfaccia utente utilizzando un toolkit standard, probabilmente uno sviluppatore medio impiegherebbe circa una settimana o due per reimplementare la pagina delle impostazioni di Firefox in GTK (ad esempio, o qualsiasi toolkit GUI che stia utilizzando).È qualcosa che ogni sviluppatore di applicazioni deve fare: sviluppa una parte che rende il loro contenuto particolare, quindi sviluppa un'altra parte che mette un'interfaccia utente standard attorno al contenuto.
@Michael Johnson: HTML5 * è * un toolkit standard.Un browser non è solo un'applicazione di contenuto, è una piattaforma applicativa.In effetti, è probabilmente * il * toolkit dell'interfaccia utente multipiattaforma di maggior successo, ed è probabilmente l'unico che ha effettivamente una specifica standard scritta e indipendente dal fornitore, qualcosa che altri toolkit multipiattaforma potrebbero solo sognare.Perché dovrebbero utilizzare quello che sarebbe, dal loro punto di vista, * un toolkit di interfaccia utente inferiore *.
@MichaelJohnson: Firefox utilizza il toolkit XUL, che è un toolkit multipiattaforma interno.Mentre Firefox si integra con GTK in modo che possa adattarsi ai temi GTK per una migliore integrazione con l'aspetto del sistema (che è una cosa che manca a Chrome), in realtà non usa GTK.
Sette risposte:
Hector
2017-11-17 17:16:01 UTC
view on stackexchange narkive permalink

Da cosa puoi proteggerlo? Viene caricato direttamente nel browser. Non c'è connessione al di fuori del contesto utente locale della macchina, il che significa che non c'è nulla da intercettare / manomettere.

Per modificare ciò che vedi dovresti modificare l'eseguibile del browser, lo spazio di memoria o modificare i dati sottostanti utilizzati per memorizzare le impostazioni. Per leggere i valori dovresti essere in grado di leggere lo spazio di memoria del browser o i file sottostanti. Tutti questi sono end-game. Se un attore malintenzionato può farlo, ha il pieno controllo e non c'è modo di proteggerlo.

Infatti, se un malintenzionato potesse avere tale controllo, potrebbe anche effettuare connessioni tramite http e visualizzarlo come "https" sullo schermo, rendendo l'utente non più saggio.
@vsz - o semplicemente patchare i controlli dei certificati e le connessioni HTTPS MitM.
Cosa succede se il browser contiene codice dannoso?
@Worse_Username - Quindi controllano tutto, inclusa la possibilità di mostrare il banner "Stai visualizzando una pagina sicura di Google Chrome".Se qualcuno controlla il browser, ha il pieno controllo di tutto ciò che viene fatto al suo interno.
@Hector e se controllassero solo una parte del browser?
@Worse_Username - La separazione sicura dei processi può proteggere altri aspetti del browser da un singolo processo che viene sfruttato.Ma a seconda delle autorizzazioni, è probabile che possa ancora leggere direttamente in altri processi con lo stesso account utente.E anche in caso contrario non c'è nulla che impedisca di leggere / scrivere direttamente nella memoria sottostante in cui risiedono le impostazioni.Se eseguono codice sulla tua macchina come account utente o amministratore, dovresti presumere che possano controllare tutto ciò che puoi.
@Worse_Username Non riesco a immaginare uno scenario in cui qualcuno ha solo il controllo parziale di un'applicazione.Se possono controllarne una parte, possono anche ottenere il controllo delle altre parti.
@CareyGregory: esistono.Soprattutto quando l'applicazione è suddivisa in processi separati che vengono eseguiti su macchine separate, ad esempio acquisendo il controllo del server database ma non dell'applicazione di livello superiore.Ma è raro soprattutto nel contesto di un browser.
@Hector Va bene, certo, se si tratta di un sistema distribuito con app in esecuzione su altre macchine è diverso, ma qualcuno che ha ottenuto il controllo di un'app può probabilmente controllare tutte le app con lo stesso livello di privilegi e spazio utente su quella macchina.
@CareyGregory - vedi il mio commento sopra dove ho detto esattamente questo.Dal momento che hai affermato di non poter vedere nessuno scenario, ho ritenuto che potesse essere utile suggerire diversamente.Vale la pena notare che è possibile ottenere risultati simili suddividendo l'elaborazione tra i processi in modalità sandbox sulla stessa macchina.
Si potrebbe immaginare un browser codificato in modo radicalmente paranoico, in cui non solo si divide in processi diversi, ma abbandona anche in modo aggressivo i privilegi in ciascuno di essi (ad esempio, utilizzando un mix di prigioni BDS e "pledge (2)" su OpenBSD, ospazi dei nomi e altre moderne tecnologie di isolamento su Linux).Le parti più vulnerabili del browser (quelle che agiscono sulla base di dati non attendibili di Internet) possono essere completamente neutralizzate al punto che, se compromesse, non potrebbero fare quasi nulla come utente.Ipoteticamente interessante, anche se penso che non cambi la risposta.
Se registro un gestore di protocollo chiamato "chrome", andando su `chrome: // settings` si apre l'applicazione.Tuttavia, Chrome stesso non utilizza il gestore del protocollo dal registro di Windows per aprire quella pagina, quindi non funzionerà dall'interno di Chrome
Questo non risponde direttamente alla domanda.Posso pensare quello che volevi dire, ma non l'hai scritto.Quindi ancora una volta: perché Chrome dice che la pagina delle impostazioni è sicura?
@ChristianStrempfer - anche se tecnicamente hai ragione sul fatto che non ho risposto, hai posto una domanda diversa a OP.Considero la mia risposta come una risposta indiretta alla domanda, quindi non la modificherò.La risposta è che non devono fare nulla: sanno che è sicuro perché ne controllano ogni aspetto.
David Richerby
2017-11-17 18:17:32 UTC
view on stackexchange narkive permalink

Questa pagina non viene caricata su https

Non viene caricata su nulla . Il browser lo visualizza solo all'interno di un frame del browser perché quel frame ha già la capacità di visualizzare i moduli web, quindi lo stesso codice viene utilizzato per visualizzare questo modulo, anche se non proviene dal web.

Bene, sono sicuro che sia caricato su qualcosa, come OS IO: b
"anche se non proviene dal Web" Le impostazioni utente di Chrome non provengono dal tuo profilo in modo che siano sincronizzate con tutti gli altri tuoi dispositivi?Suppongo che siano archiviati e caricati dal web.
@Mast I dati che popolano la pagina potrebbero essere stati scaricati dal web (o da qualche altro servizio Internet) ad un certo punto.Ma non è questo ciò su cui si pone la domanda.Mentre il browser è in esecuzione, ha sicuramente le proprie impostazioni presenti in memoria.
@MichaelPittino, non viene caricato su qualcosa più di quanto lo sia lo sfondo del desktop.
@PaulDraper Quale dovrebbe essere caricato anche su OS IO, giusto?: P
@MichaelPittino no, non dovrebbe essere "caricato su OS IO" (qualunque cosa tu intenda esattamente con questo).Ciò implicherebbe ad es.che una particolare pagina html viene generata da qualche altra parte e quindi recuperata come una pagina normale da un protocollo in modo simile alla ricezione di dati da una connessione di rete, ad esempio come pagine recuperate da file: // protocollo o IP localhost.* Potrebbe * essere come file: // pagine statiche memorizzate, ma non è necessariamente così.Il DOM della pagina delle impostazioni può essere semplicemente generato dai dati delle impostazioni all'interno del processo Chrome, senza che i dati della pagina o altro vengano passati attraverso le chiamate di sistema del sistema operativo.
Kallmanation
2017-11-17 20:31:07 UTC
view on stackexchange narkive permalink

Come hanno già detto altre risposte, la pagina è sicura perché viene caricata dal browser, non trasmessa o accessibile da nessun altro.

Ma perché Chrome si preoccupa di contrassegnare tali una pagina ovviamente sicura quanto sicura? Per mitigare eventuali tentativi di phishing. Sarebbe banale creare una falsa pagina delle "impostazioni" e mostrartela per indurti a intraprendere azioni. ( Mi sembra improbabile che qualcuno si innamori effettivamente di aprire una falsa pagina delle impostazioni, ma la creduloneria degli utenti mi stupisce sempre. )

Questa bandiera è solo un altro tentativo nel tentativo di rendere gli utenti più consapevoli per evitare errori stupidi, dal momento che sono di gran lunga l'anello più debole della catena della sicurezza.

La pagina delle impostazioni è proprio questo, una pagina HTML con un URL.A me sembra un attacco perfettamente plausibile avere una pagina che dice "Google ha disconnesso accidentalmente tutti da Chrome. Vai a chrome: settings (comodamente collegato nella pagina) per accedere di nuovo", ma avere il link chrome: settingsandare a una pagina ospitata sul sito e avere una pagina di phishing lì.Google probabilmente lancerà un avviso di phishing, ma una minoranza continuerà a fare clic.
@Nzall esattamente questo.Le persone sono mute come rocce e sembrano innamorarsi delle esche più mal concepite.Ecco perché dobbiamo cercare di aiutarli come possiamo ...
"Ma * perché * Chrome si preoccupa di contrassegnare una pagina così evidentemente sicura come sicura? Per mitigare eventuali tentativi di phishing."- beh, questo aiuterà principalmente a identificare la pagina protetta come sicura.Non fa molto per identificare la pagina insicura come insicura.
Arminius
2017-11-17 22:05:00 UTC
view on stackexchange narkive permalink

Le pagine delle impostazioni vengono caricate dalla macchina locale, non vengono recuperate su una rete e quindi non possono essere soggette ad un attacco MITM. Alcune di queste pagine possono richiedere risorse web effettive, ma queste vengono solitamente ricevute tramite HTTPS.

Inoltre, i fornitori di browser hanno stabilito alcuni pseudo-protocolli per distinguere le impostazioni / URL di sistema spesso privilegiati dalle risorse web. Esempi di questi sono about: o chrome: . Come ulteriore misura di protezione, la maggior parte di questi URL non può essere aperta da un dominio non privilegiato.

Cioè, un normale sito web non può nemmeno aprire (o collegarsi alla) pagina delle impostazioni del browser:

Mozilla Firefox

(Mozilla Firefox)

Google Chrome

(Google Chrome)

Harper - Reinstate Monica
2017-11-18 22:54:12 UTC
view on stackexchange narkive permalink

Guarda il protocollo. È chrome: // non https.

Internet ha dozzine di protocolli e ognuno ha il proprio modello di sicurezza (o la sua mancanza). sftp è sicuro, ftp non lo è, irc non lo è, ecc.

file: // accede solo ai file locali sul disco rigido. Non comunica su Internet affatto , quindi è sicuro.

chrome: // è simile. Rimane all'interno di Chrome e non viene trasmesso da nessuna parte, quindi di nuovo sicuro per natura.

Per riferimento sullo sfondo di `chrome: //`: https://superuser.com/a/517161
Joe
2017-11-17 22:03:05 UTC
view on stackexchange narkive permalink

È proprio come aprire un documento di testo memorizzato localmente.

Non c'è comunicazione con un altro server durante l'apertura del file di testo e l'unico modo per modificare il contenuto del file è se un attaccante ha accesso diretto al sistema.

È un modo sicuro per osservare il contenuto di un file.

Nel caso della pagina delle impostazioni, non viene caricato da un server web, è solo visualizzato in Chrome come se fosse un sito web.

Nate D
2017-11-18 09:06:05 UTC
view on stackexchange narkive permalink

Le pagine vengono caricate localmente, il che significa che puoi caricare qualsiasi pagina chrome: // senza connessione a Internet.

Per questo motivo, non c'è nulla da intercettare poiché nessuna informazione viene mai trasmessa a Internet (tranne ovviamente per cose come il download di aggiornamenti, nel qual caso utilizzerà https per il download).



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...