Opened 2 years ago

Closed 2 years ago

#21756 closed defect (invalid)

HTTP Authentication data is still sent to third parties with ESR 52 based Tor Browser

Reported by: gk Owned by: arthuredelstein
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff52-esr, tbb-7.0-must, tbb-7.0-frequent, TorBrowserTeam201708
Cc: ezio, arthuredelstein, tbb-team Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor4

Description

Testing a build based on ESR 52 and our patches in #20680 it turns our that HTTP Authentication data seems to leak to third parties as can be seen on the http://ip-check.info test.

Child Tickets

Change History (18)

comment:1 Changed 2 years ago by cypherpunks

Keywords: ff52-esr added; ff52esr removed

Seems related to #21755.

comment:2 Changed 2 years ago by arthuredelstein

In the #20680 branch, I dropped our #13900 patch because ESR52 is supposed to isolate HTTP Auth by first party. There is an automated test in ESR52 from https://bugzilla.mozilla.org/1301523. So I think the http://ip-check.info site is detecting that the HTTP Auth credentials are being saved to the third party, but it isn't testing if these credentials are shared by with first party.

I wrote a manual test and was able to confirm that first-party isolation (double keying) is working. Here's the test:

First visit https://arthuredelstein.net/auth-test.html. It contains an iframe located at torpat.ch/auth. Username is "username" and password is "password". Once credentials are entered at the prompt, you can reload and the credentials will be remembered such that no prompt is shown for a second time.

Next visit https://torpat.ch/auth-test.html. It also has an iframe at the same location. If double-keying is working correctly, the browser should prompt again for username and password even though the third-party domain is the same (torpat.ch).

Test source: https://github.com/arthuredelstein/auth-test

comment:3 Changed 2 years ago by arthuredelstein

Keywords: TorBrowserTeam201703R added; TorBrowserTeam201703 removed
Status: newneeds_review

comment:4 Changed 2 years ago by gk

Keywords: TorBrowserTeam201704R added; TorBrowserTeam201703R removed

Moving review tickets to April.

comment:5 Changed 2 years ago by gk

Keywords: tbb-7.0-must-alpha added; tbb-7.0-must removed

Getting this on our radar for alpha release in less than two weeks.

comment:6 in reply to:  2 ; Changed 2 years ago by gk

Keywords: TorBrowserTeam201704 added; TorBrowserTeam201704R removed
Status: needs_reviewassigned

Replying to arthuredelstein:

In the #20680 branch, I dropped our #13900 patch because ESR52 is supposed to isolate HTTP Auth by first party. There is an automated test in ESR52 from https://bugzilla.mozilla.org/1301523. So I think the http://ip-check.info site is detecting that the HTTP Auth credentials are being saved to the third party, but it isn't testing if these credentials are shared by with first party.

I am not so sure about that. They are saved in Tor Browser 6.5.1 as well but still the test passes with it. We are stripping the third party headers when we are doing a request. Now, the most likely explanation is that the test is showing a red outcome just in case it gets any third party headers back. Then this would be indeed no issue for us. What it actually does is implementing:

http://blog.jeremiahgrossman.com/2007/04/tracking-users-without-cookies.html

using things like http://Session:483452791@ipcheck.info/auth.css.php in a stylesheet link from ip-check.info to work without JS as well.

Do you think you could come up with a test for that scenario, too, to be extra sure that nothing is sneaking in?

comment:7 in reply to:  6 ; Changed 2 years ago by arthuredelstein

Replying to gk:

Replying to arthuredelstein:

In the #20680 branch, I dropped our #13900 patch because ESR52 is supposed to isolate HTTP Auth by first party. There is an automated test in ESR52 from https://bugzilla.mozilla.org/1301523. So I think the http://ip-check.info site is detecting that the HTTP Auth credentials are being saved to the third party, but it isn't testing if these credentials are shared by with first party.

I am not so sure about that. They are saved in Tor Browser 6.5.1 as well but still the test passes with it. We are stripping the third party headers when we are doing a request.

You're right, I misspoke here. I should have said, the ip-check site is detecting if third-party credentials are sent back at all, but it isn't testing if these credentials are sent back under a different first party.

Now, the most likely explanation is that the test is showing a red outcome just in case it gets any third party headers back. Then this would be indeed no issue for us. What it actually does is implementing:

http://blog.jeremiahgrossman.com/2007/04/tracking-users-without-cookies.html

using things like http://Session:483452791@ipcheck.info/auth.css.php in a stylesheet link from ip-check.info to work without JS as well.

Do you think you could come up with a test for that scenario, too, to be extra sure that nothing is sneaking in?

So my test from comment:2 is already testing if any third-party headers are received back under a new first party. Are you interested in testing the silent authentication scenario (with and without JS), or is there some other characteristic of that demo you would like to test?

comment:8 in reply to:  7 Changed 2 years ago by gk

Replying to arthuredelstein:

Replying to gk:

Do you think you could come up with a test for that scenario, too, to be extra sure that nothing is sneaking in?

So my test from comment:2 is already testing if any third-party headers are received back under a new first party. Are you interested in testing the silent authentication scenario (with and without JS), or is there some other characteristic of that demo you would like to test?

If you think there is no loophole where this kind of feature abuse can subvert our defenses then feel free to close this ticket without adding a particular test for the ip-check scenario.

comment:9 Changed 2 years ago by gk

Keywords: TorBrowserTeam201705 added; TorBrowserTeam201704 removed

Moving our tickets to May 2017.

comment:10 Changed 2 years ago by gk

Cc: ezio arthuredelstein added
Status: assignedneeds_information

#22187 is a duplicate. Arthur: where are we with this ticket? IIRC you still wanted to work on something before closing it?

comment:11 Changed 2 years ago by arthuredelstein

I think further loopholes are unlikely, but I think I should look for them nonetheless, just in case.

So I think, in the interest of getting as many patches as possible into the alpha, I should postpone working on this again until after the alpha deadline.

comment:12 Changed 2 years ago by gk

Keywords: tbb-7.0-must added; tbb-7.0-must-alpha removed

We are beyond the alpha testing. Moving tickets for tbb-7.0-must.

comment:13 Changed 2 years ago by gk

Cc: tbb-team added
Owner: changed from tbb-team to arthuredelstein
Status: needs_informationassigned

comment:14 Changed 2 years ago by gk

Keywords: TorBrowserTeam201706 added; TorBrowserTeam201705 removed

Moving our tickets to June.

comment:15 Changed 2 years ago by gk

Keywords: TorBrowserTeam201707 added; TorBrowserTeam201706 removed

Moving Tickets to July 2017.

comment:16 Changed 2 years ago by gk

Keywords: tbb-7.0-frequent added

Tracking frequent 7.0 reports

comment:17 Changed 2 years ago by gk

Keywords: TorBrowserTeam201708 added; TorBrowserTeam201707 removed

Moving our Tickets to August.

comment:18 Changed 2 years ago by gk

Resolution: invalid
Status: assignedclosed

I talked to the JonDos people (who build the ip-check.info-test) and we think we are in agreement that this was a test error. So, closing this ticket.

Note: See TracTickets for help on using tickets.