#907 assigned defect

Stop caps from leaking to phishing-filter servers — at Version 18

Reported by: davidsarah Owned by: davidsarah
Priority: minor Milestone: eventually
Component: code-frontend-web Version: 1.5.0
Keywords: capleak integrity confidentiality forward-compatibility newurls docs websec Cc:
Launchpad Bug:

Description (last modified by zooko)

Some phishing filters send URLs to a filter on some other machine. That's a bad idea and probably not very effective at preventing phishing, but they do it anyway. However, they strip query parts before sending it to the filter (according to Tyler Close and the web calculus documentation).

The webapi accepts URLs of the form http://host:port/uri?uri=..., but it redirects to an URL of the form http://host:port/uri/.... We should prefer to put the cap in the query, and we should probably also allow the shorter form http://host:port/?....

Change History (19)

comment:1 Changed at 2010-01-16T17:52:48Z by davidsarah

  • Summary changed from Stop caps from leaking to phishing filters to Stop caps from leaking to phishing-filter servers

comment:2 Changed at 2010-01-16T17:53:48Z by davidsarah

  • Keywords newurls added

comment:3 Changed at 2010-01-17T14:51:30Z by davidsarah

  • Keywords capleak added; security removed

comment:4 in reply to: ↑ description Changed at 2010-01-18T02:40:00Z by davidsarah

  • Keywords docs added

Replying to davidsarah:

[Phishing filters] strip query parts before sending it to the filter (according to Tyler Close and the web calculus documentation).

http://waterken.sourceforge.net/web-key/#browser_how

The webapi accepts URLs of the form http://host:port/uri?uri=..., but it redirects to an URL of the form http://host:port/uri/.... We should prefer to put the cap in the query, and we should probably also allow the shorter form http://host:port/?....

Actually that would cause a regression in #52, because the query part isn't taken into account when resolving relative URLs. I don't know how to avoid that problem. Perhaps the answer is simply to document that users should turn phishing filters off.

Changed at 2010-02-02T02:01:01Z by davidsarah

Document leakage of cap URLs via phishing filters in known_issues.txt

comment:5 Changed at 2010-02-02T02:01:20Z by davidsarah

  • Keywords review-needed added

comment:6 Changed at 2010-02-02T04:29:22Z by zooko

Applied in 8a43361aaa7f1201. Thank you!

comment:7 Changed at 2010-02-02T04:29:33Z by zooko

  • Keywords review-needed removed

comment:8 Changed at 2010-02-02T06:34:32Z by davidsarah

  • Priority changed from major to minor

Since this is now documented as a known issue (with instructions on how to disable IE's phishing filter), I'm downgrading it to minor.

Last edited at 2011-04-25T23:41:27Z by davidsarah (previous) (diff)

comment:9 Changed at 2010-02-23T03:12:47Z by zooko

  • Milestone changed from undecided to 2.0.0

comment:10 Changed at 2010-03-13T02:49:25Z by davidsarah

  • Priority changed from minor to major

Bumping back up to major, because it appears that Firefox 3 does have a phishing filter that is enabled by default. The Firefox prefs UI does a poor job of labelling this as what it is: it's enabled by the "Block reported attack sites" and "Block reported web forgeries" options in the Tools | Options... | Security tab. The filter server provider is Google's Safe browsing API.

comment:11 Changed at 2010-03-13T05:01:39Z by davidsarah

  • Priority changed from major to minor

It appears from the specification that the "safe browsing API" protocol is not vulnerable in a way that would affect Tahoe. 32 bits of information about any particular URL is potentially leaked, but that would not be enough to either guess a cap or apply a cryptanalytic attack.

comment:12 follow-up: Changed at 2010-04-01T19:26:42Z by zooko

Here's a news story about an accusation that Google Chrome sends back a lot of information about the URL to a remote server:

http://arstechnica.com/microsoft/news/2010/03/microsoft-google-chrome-doesn-your-privacy-microsoft-google-chrome-doesnt-respect-your-privacy.ars

comment:13 in reply to: ↑ 12 Changed at 2010-04-04T00:44:35Z by davidsarah

Replying to zooko:

Here's a news story about an accusation that Google Chrome sends back a lot of information about the URL to a remote server:

http://arstechnica.com/microsoft/news/2010/03/microsoft-google-chrome-doesn-your-privacy-microsoft-google-chrome-doesnt-respect-your-privacy.ars

I cannot reproduce the alleged behaviour of the address bar search at all using Chrome 5.0.366.2 dev. Perhaps it has been fixed since Chrome 3.

comment:14 Changed at 2010-04-12T20:18:54Z by davidsarah

  • Milestone changed from 2.0.0 to 1.8.0
  • Owner set to davidsarah
  • Status changed from new to assigned

comment:15 Changed at 2010-06-21T03:18:27Z by davidsarah

The documentation about this in docs/known_issues.txt (now docs/known_issues.rst) was updated in 15b65ae54b199345.

Last edited at 2011-04-25T23:40:36Z by davidsarah (previous) (diff)

comment:16 Changed at 2010-08-09T22:18:46Z by zooko

  • Milestone changed from 1.8.0 to 1.9.0

comment:17 Changed at 2011-05-28T19:38:28Z by davidsarah

  • Milestone changed from 1.9.0 to eventually

comment:18 Changed at 2013-09-14T17:39:02Z by zooko

  • Description modified (diff)
  • Keywords websec added
Note: See TracTickets for help on using tickets.