This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12272 - Improve section on DNS spoofing attacks to address user attacks
Summary: Improve section on DNS spoofing attacks to address user attacks
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Web Storage (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-09 17:40 UTC by Mark Watson
Modified: 2011-06-01 18:21 UTC (History)
5 users (show)

See Also:


Attachments

Description Mark Watson 2011-03-09 17:40:41 UTC
Section 7.1 on DNS spoofing attacks states: "Pages using TLS can be sure that only pages using TLS that have certificates identifying them as being from the same domain can access their storage areas."

We could add "This protects against DNS spoofing attacks which do not involve the user. However, if the user is involved in the attack this protection can be circumvented by the user installing root certificates for fake certification authorities and then creating site certificates to be used in conjunction with DNS spoofing. Therefore a web page author cannot be sure that the information stored in web storage has not been viewed or modified by or on behalf of the user."

i.e. page authors should be aware that even with TLS information inside web storage can be viewed and modified by or on behalf of the user.
Comment 1 Aryeh Gregor 2011-03-09 20:41:34 UTC
How is this different from the user just manually editing the storage areas on disk, or a malicious program installed on their computer doing that?  The client is always untrusted.  The only guarantees we can even try to provide are against network attacks, e.g., an attacker who gets the user to visit a malicious webpage.  That should be safe as long as the client isn't compromised.
Comment 2 Mark Watson 2011-03-09 20:54:47 UTC
(In reply to comment #1)
> How is this different from the user just manually editing the storage areas on
> disk, or a malicious program installed on their computer doing that?  The
> client is always untrusted.  The only guarantees we can even try to provide are
> against network attacks, e.g., an attacker who gets the user to visit a
> malicious webpage.  That should be safe as long as the client isn't
> compromised.

You're right, but the existing text suggested to me that using TLS provided some assurance *for the web page* that the information was safe from attack. In fact it provides this assurance only in respect of certain kinds of attack. Perhaps that is implicit and doesn't need to be called out ?
Comment 3 Aryeh Gregor 2011-03-11 02:15:50 UTC
Yes, maybe it would be worth explicitly calling out (if it hasn't been already) that anyone with access to the user's computer has full access to website storage.  Some people seem to get confused about that and think that some type of magical encryption should be used that only lets the site itself access it, somehow.
Comment 4 Ian 'Hixie' Hickson 2011-06-01 17:42:19 UTC
I've tweaked the text.
Comment 5 contributor 2011-06-01 17:43:43 UTC
Checked in as WHATWG revision r6169.
Check-in comment: Don't overpromise in security sections...
http://html5.org/tools/web-apps-tracker?from=6168&to=6169