Om du antar att du inte använder ett huvudlösenord, så att lösenordsdatabasen lagras i klartext: Det beror på vilken typ av skadlig kod du hänvisar till. Om det finns en 0-dagars exploatering (eller om du använder en icke-patchad webbläsare), som "bryter ur", inbäddad i något av de saker du nämner, vilket effektivt orsakar godtycklig kodkörning på din värd, kommer den skadliga programvaran att kunna återställa hela databas (men det kommer att vara minst av dina bekymmer).

I det vanliga fallet med enkel javascriptkörning (med xss till exempel) kan skriptet fånga lösenordet som är associerat med formerna för det specifik sida. Återigen, om det finns en ouppdaterad brist i webbläsaren som skriptet utnyttjar, som att bryta samma ursprungspolicy-skydd i webbläsaren, kan det kanske återställa alla lösenord från databasen.

Slutligen, om angriparen inte kan "lura webbläsaren" (som att attackera en sårbarhet), kan han också i slutändan försöka "lura användaren" - tänk socialteknik - genom att använda något subtilt sätt att göra det så att du skicka databasen själv utan att märka den.

Jag tycker fortfarande att det är värt att notera vad den andra frågan inte gör: den huvudsakliga sårbarheten är att många webbläsare lagrar lösenord som vanlig text eller svagt dolda. Om så är fallet kan någon som har tillfällig åtkomst till din dator bara ta hela vägen. Så det är viktigt att ställa in ett huvudlösenord eller motsvarande.

Observera att vissa webbläsare inte ens implementerar kryptering av lösenord.

Förutom det, om webbläsaren eller den slags relaterade visningsprogramvara som du listar, har felaktiga fel, kan en angripare naturligtvis få tillgång till lösenord tillsammans med bredare möjligheter att äventyra hela systemet. Håll dessa system lappade och var försiktig när du surfar!

Lösenord som sparats i en fil utan skydd (av ett icke-lagrat huvudlösenord) är en dålig idé eftersom en sårbarhet i någon mjukvara (vare sig det är en webbläsare eller inte) kan göra det möjligt för angriparen att ladda upp filen. Exempel (inte de enda!): CVE-2006-1729, CVE-2011-0167. Filer i webbläsarprofilen är särskilt utsatta (jag kan inte hitta en referens just nu men kom ihåg att se buggar som bara exponerade profilkatalogen).

Medan ett webbläsarfel trots allt kan ge angriparen åtkomst till minneslagring i minnet, filöverföringsfel kan vara mer subtila ( CVE-2007-3511: oavsiktlig filuppladdning genom att flytta inmatningsfokus) och svårare att fixa utan att bryta användbar funktionalitet (logikfel , till skillnad från godtyckliga kodkörningsfel som vanligtvis är enkla när felet har hittats).

För att klargöra och kanske bestrida vad John säger - Jag är inte säker på att du behöver bryta samma ursprungspolicy för att dra nytta av en xss vuln på en webbplats för att få sparade referenser. En del JavaScript för att analysera formuläret och skicka dem till en tredje part behöver inte bryta samma ursprung.