Fråga:
Hur ser webbläsare till att deras inställningssida är säker
ThankYouSRT
2017-11-17 17:11:14 UTC
view on stackexchange narkive permalink

Titta på bilden nedan.

settings page

Denna sida laddas inte över https, så hur ser moderna webbläsare till att sidan är säker?

Vad försöker du skydda dem mot?
@Alpha3031 - att använda TLS skulle göra det mindre säkert.Detta skulle innebära att man öppnade en uttagsanslutning som potentiellt skulle kunna vara Man in the Middle.Eftersom Chrome-binären måste innehålla certifikatet för att signera förfrågningarna kan alla som har åtkomst till den binära och anslutningen läsa / ändra data.
Som en sidoanteckning, om du tittar i säkerhetsavsnittet på utvecklingskonsolen på inställningssidan kommer den att rapportera att ["Denna sida är inte säker."] (Https://i.stack.imgur.com/fwflO.png)
Chrome har extra inställningar om du loggar in med ett Google-konto.Därför, när du är inloggad. Dina personliga inställningar skyddas via deras fjärrlagring.
@MichealJohnson: Eftersom det är mycket lättare att skriva ett användargränssnitt i HTML + CSS + JS än C ++.
@MichealJohnson, och här var jag, öppnade detta och tänkte att det skulle ha varit exakt poängen.
@SiyuanRen Det är inte så svårt att skapa ett gränssnitt på ett språk som C eller C ++.Det finns verktygslådor för att göra det ännu enklare.Utvecklare gör det hela tiden.Jag tvivlar på att latskap är den enda anledningen.
@MichealJohnson: här har vi utvecklarna av en av världens bästa cross-platform, cross technology UI toolkit: HTML + CSS + JS, och du föreslår att de är lata om de inte använder ett annat verktygslåda för att utveckla sitt eget användargränssnitt?Skulle Java-utvecklare också vara lata för att utveckla Eclipse i Java?
@LieRyan Nej, du saknar poängen.Det är inte * mycket * arbete att utveckla ett användargränssnitt med en standardverktygssats, det skulle förmodligen ta en genomsnittlig utvecklare ungefär en vecka eller två att implementera Firefox-inställningssidan i GTK (till exempel eller vad som helst GUI-verktygslåda de använder).Det är något som varje applikationsutvecklare måste göra - de utvecklar en del som återger sitt specifika innehåll, sedan utvecklar de en annan del som sätter ett standardgränssnitt runt innehållet.
@Michael Johnson: HTML5 * är * en standardverktygssats.En webbläsare är inte bara en innehållsapplikation, det är en applikationsplattform.I själva verket är det förmodligen * den * mest framgångsrika verktygsgränssnittet för gränssnittsgränssnitt, och det är förmodligen den enda som faktiskt har en skriftlig, leverantörsneutral standardspecifikation, något som andra plattformsverktygssatser bara någonsin kunde drömma om.Varför skulle de använda det som, ur deras perspektiv, * en sämre UI-verktygslåda *.
@MichaelJohnson: Firefox använder XUL-verktygslåda, som är en intern plattformsverktygssats.Även om Firefox integreras med GTK så att den kan anpassa sig till GTK-teman för bättre integration med systemets utseende och känsla (vilket är en sak som Chrome saknar), använder den inte riktigt GTK.
Sju svar:
Hector
2017-11-17 17:16:01 UTC
view on stackexchange narkive permalink

Vad finns det att säkra från? Den laddas direkt i webbläsaren. Det finns ingen anslutning utanför maskinens lokala användarkontext, vilket betyder att det inte finns något att avlyssna / manipulera med.

För att ändra det du ser måste du antingen ändra webbläsarens körbarhet, minnesutrymme eller ändra underliggande data som används för att lagra inställningarna. För att kunna läsa värdena måste du kunna läsa antingen webbläsarens minnesutrymme eller underliggande filer. Alla dessa är slutspel. Om en skadlig skådespelare kan göra det har de full kontroll och det finns inget sätt att skydda från det.

Om en skadlig skådespelare kunde ha sådan kontroll kan de faktiskt också skapa anslutningar via http och visa det som "https" på skärmen, vilket gör användaren ingen klokare.
@vsz - eller bara lappa ut certifikatkontrollerna och MitM HTTPS-anslutningar.
Vad händer om webbläsaren innehåller skadlig kod?
@Worse_Username - Sedan kontrollerar de allt - inklusive möjligheten att visa "Du tittar på en säker Google Chrome-sida" -banner.Om någon kontrollerar webbläsaren har de full kontroll över absolut allt som görs i den.
@Hector vad händer om de bara kontrollerar en del av webbläsaren?
@Worse_Username - Visst processegregering kan skydda andra aspekter av webbläsaren från att en enda process utnyttjas.Men beroende på behörigheter kan det troligtvis fortfarande läsas direkt i andra processer under samma användarkonto.Och även om det inte finns något som hindrar det från att läsa / skriva direkt till den underliggande lagringen där inställningarna finns.Om de har kodkörning på din dator som antingen ditt användarkonto eller en administratör bör du anta att de kan kontrollera allt du kan.
@Worse_Username Jag kan inte föreställa mig ett scenario där någon bara har delvis kontroll över en applikation.Om de kan kontrollera en del av det kan de också få kontroll över de andra delarna.
@CareyGregory - de finns.Särskilt där applikationen är uppdelad i separata processer som körs på separata maskiner - till exempel att få kontroll över databasservern men inte applikationen på högsta nivå.Men det är sällsynt, särskilt i en webbläsares sammanhang.
@Hector Okej, visst, om det är ett distribuerat system med appar som körs på andra maskiner är det annorlunda, men någon som har fått kontroll över en app kan förmodligen styra alla appar på samma behörighetsnivå och användarutrymme på den maskinen.
@CareyGregory - se min kommentar ovan där jag sa exakt det.Eftersom du uppgav att du inte kunde se något scenario kände jag att det kan vara bra att föreslå något annat.Värt att notera att du kan uppnå liknande genom att dela upp bearbetningen mellan sandlådeprocesser på samma maskin.
Man kan föreställa sig en webbläsare kodad på ett radikalt paranoid sätt, där den inte bara delas upp i olika processer utan också aggressivt tappar privilegier i var och en av dem (till exempel med en blandning av BDS-fängelser och `pledge (2)` på OpenBSD, ellernamnområden och andra moderna isoleringstekniker på Linux).De mest utsatta delarna av webbläsaren (de som agerar baserat på otillförlitliga data från internet) kan kastreras helt till den punkt att om de komprometteras kan de göra nästan ingenting som användaren.Hypotetiskt intressant, men jag tror att det inte förändrar svaret.
Om jag registrerar en protokollhanterare som heter "chrome" öppnar programmet "chrome: // settings".Chrome själv använder dock inte protokollhanteraren från Windows-registret för att öppna den sidan, så detta fungerar inte inifrån Chrome
Detta svarar inte direkt på frågan.Jag kan tänka vad du ville säga, men du skrev inte ner det.Så än en gång: Varför säger Chrome att inställningssidan är säker?
@ChristianStrempfer - medan du är tekniskt korrekt att jag inte svarade på det har du ställt en annan fråga till OP.Jag ser mitt svar som indirekt att svara på frågan så kommer inte att redigera det.Svaret är att de inte behöver göra någonting - de vet att det är säkert eftersom de kontrollerar alla aspekter av det.
David Richerby
2017-11-17 18:17:32 UTC
view on stackexchange narkive permalink

Den här sidan laddas inte över https

Den laddas inte över någonting . Webbläsaren visar den bara i en webbläsarram eftersom den ramen redan har möjlighet att visa webbformulär så att samma kod används för att visa detta formulär, även om den inte kommer från webben.

Jag är säker på att den laddas över något, som OS IO: b
"även om det inte kommer från webben" Kommer inte en del av användarinställningarna i Chrome från din profil så att de synkroniseras med alla dina andra enheter?Jag antar att de lagras och laddas från webben.
@Mast Data som fyller sidan kan ha laddats ner från webben (eller någon annan internettjänst) någon gång.Men det är inte vad frågan ställer om.Medan webbläsaren körs har den säkert sina egna inställningar i minnet.
@MichaelPittino, det laddas inte över något mer än din skrivbordsbakgrund är.
@PaulDraper Vilken ska också laddas över OS IO, eller hur?: P
@MichaelPittino nej, det borde inte "laddas över OS IO" (vad du menar exakt med detta).Det skulle innebära t.ex.att en viss html-sida genereras någon annanstans och sedan hämtas som en vanlig sida av något protokoll på samma sätt som att ta emot data från en nätverksanslutning - t.ex. sidor hämtade från file: // -protokoll eller localhost IP.Det * kan * vara som file: // lagrade statiska sidor, men det är inte nödvändigtvis så.Inställningssidan DOM kan enkelt genereras från inställningsdata i Chrome-processen, utan att siddata eller någonting skickas genom OS-systemanrop.
Kallmanation
2017-11-17 20:31:07 UTC
view on stackexchange narkive permalink

Som andra svar har sagt är sidan säker eftersom den laddas från webbläsaren, inte överförs eller är tillgänglig av någon annan.

Men varför bryr sig Chrome om att markera sådana en uppenbarligen säker sida som säker? För att mildra eventuella nätfiskeförsök. Det skulle vara trivialt att skapa en falsk inställningssida och servera den till dig för att lura dig att vidta åtgärder. ( Det verkar osannolikt för mig att någon faktiskt skulle falla för att ha öppnat en falsk inställningssida, men användarnas lättförståelse förvånar mig alltid. )

Denna flagga är bara ett försök till. för att försöka göra användarna mer medvetna om att undvika dumma misstag, eftersom de är överlägset den svagaste länken i säkerhetskedjan.

Inställningssidan är just det, en HTML-sida med en URL.För mig verkar det som en helt rimlig attack att ha en sida som säger "Google loggade av misstag alla från Chrome. Gå till Chrome: inställningar (bekvämt länkade på sidan) för att logga in igen", men länk Chrome: Settings.gå till en sida som är värd på webbplatsen och ha en phishing-sida där.Google kommer förmodligen att ge upp en phishing-varning, men en minoritet skulle fortfarande klicka igenom.
@Nzall exakt detta.Människor är dumma som stenar och verkar falla för de mest illa tänkta beten.Därför måste vi försöka hjälpa dem hur som helst ...
"Men * varför * bryr sig Chrome om att markera en så uppenbar säker sida som säker? För att mildra eventuella nätfiskeförsök."- ja, det kommer främst att hjälpa till att identifiera den säkra sidan som säker.Det gör inte mycket för att identifiera den osäkra sidan som osäker.
Arminius
2017-11-17 22:05:00 UTC
view on stackexchange narkive permalink

Inställningssidor laddas från den lokala maskinen, de hämtas inte över ett nätverk och kan därför inte utsättas för en MITM-attack. Vissa av dessa sidor kan begära faktiska webbresurser, men dessa tas vanligtvis emot via HTTPS.

Dessutom har webbläsarleverantörer upprättat vissa pseudoprotokoll för att skilja de ofta privilegierade inställningarna / system-URL: erna från webbresurser. Exempel på dessa är om: eller krom: . Som ett ytterligare skyddsmått kan de flesta av dessa webbadresser inte öppnas från en okontrollerad domän.

Det vill säga en vanlig webbplats kan inte ens öppna (eller länka till) webbläsarens inställningssida:

Mozilla Firefox

(Mozilla Firefox)

Google Chrome

(Google Chrome)

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

Titta på protokollet. Det är krom: // inte https.

Internet har dussintals protokoll och var och en har sin egen säkerhetsmodell (eller brist på dem). sftp är säkert, ftp är inte, irc är inte, etc.

file: // får endast åtkomst till lokala filer på din hårddisk. Det kommunicerar inte över Internet alls , så det är säkert.

chrome: // är liknande. Det förblir inom Chrome och skickas inte någonstans, så igen, säkert av natur.

För referens på bakgrunden av `chrome: //`: https://superuser.com/a/517161
Joe
2017-11-17 22:03:05 UTC
view on stackexchange narkive permalink

Det är precis som att öppna ett lokalt lagrat textdokument.

Det finns ingen kommunikation med en annan server när du öppnar textfilen och det enda sättet att ändra innehållet i filen är om en angripare har direkt åtkomst till systemet.

Det är ett säkert sätt att observera innehållet i en fil.

När det gäller inställningssidan laddas den inte från en webbserver, det är bara visas i Chrome som om det vore en webbplats.

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

Sidorna laddas lokalt, vilket innebär att du kan ladda vilken krom som helst: // sida utan internetanslutning.

Av den anledningen finns det inget att fånga upp eftersom ingen information någonsin överförs till internet (förutom naturligtvis för saker som att ladda ner uppdateringar, i vilket fall den använder https för att ladda ner).



Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...