A critical security issue was discovered by Dom. in which a basic authentication session that was initialized in a request would persist on subsequent requests, even if they were not using basic authentication any more. See the original report below for the steps that could replicate this issue.
The critical security bug has been fixed in the meanwhile thanks to. But we still need test coverage to ensure that this issue does not resurface in the future.
A failing test has been posted in comment #60 which included the reverted patch fromto prove that the test correctly detects the security issue. The current test is green to prove that the problem is fixed in HEAD.
Test that if a user authenticates using basic authentication and then does a subsequent request _without_ basic authentication the user is no longer authenticated.
Review the patch.
User interface changes
Original report by Dom.
Say you have a drupal 8 website with an admin account and page not accessible by anonymous, for instance /admin/reports.
- Drupal 8 HEAD
- Standard profile install
- Everything to out-of-the-box, thus using Bartik theme and Seven per admin pages.
- Activate HTTP Basic Authentication core module (or use you own module with an Authentication Provider)
- Disconnect from your site
- Visit forbidden page for anonymous using your browser, such as /admin/reports => you should have a 403 forbidden using Bartik theme.
- Perform a GET request as anonymous. You can use any poster for this. For my test, I made it with Postman for Chrome, allowing various authentication method. => You willl get "/admin/reports" and get the expected 403 error using Bartik theme
- Perform a GET request with basic auth registering as admin. => You willl get "/admin/reports", but as a 403 error using Seven theme, this is not expected for two reasons :
- change of theme used
- you provided authentication so you should be logged and see the page
- Refresh the page "/admin/reports" on your browser : you are now logged in. => This is wrong :
- you should not be logged in the browser (although I'm not sure on this point).
- Do the GET to page "/admin/reports" again with your poster with the basic authentication : still 403. => but we saw using the browser that we are logged in !
- Do the GET to page "/admin/reports" again with your poster without authentication. => now you see the report page, although you did not provide authentication. This is wrong. The session from the browser should not affect what is done using the poster.
Beta phase evaluation
|Issue category||Task because we are adding missing test coverage.|
|Issue priority||Major since this is part of a critical meta issue, and is providing test coverage for a critical security vulnerability.|
|Unfrozen changes||Unfrozen because it only changes test coverage.|
|Prioritized changes||The main goal of this issue is enhancing security by providing test coverage for an access restriction bypass vulnerability.|
|Disruption||Not disruptive because it is adding test coverage for a problem that is already fixed in HEAD.|