Bug 50172 - Digest allows access bypassing secuity
Summary: Digest allows access bypassing secuity
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_auth_digest (show other bugs)
Version: 2.2.17
Hardware: Other Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2010-10-28 09:30 UTC by Emrys Jones
Modified: 2018-11-07 21:09 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Emrys Jones 2010-10-28 09:30:07 UTC
I am not a very experienced Apache person, so please forgive me if I have this wrong.  If this is just user error, feel free to delete (although the solution would be appreciated.)

Essentially there seems to be a way of bypassing Digest authentication.  N.B. these webpages are under development and sit in a sub-tree htdocs/website .

1. In my httpd.conf I have set "AllowOverride All" in all directories just to be sure.  It made no difference.  The mod_auth_digest module is built-in using the flag to 'configure'.
2. In the htdocs/protected directory I have a .htaccess file

AuthType Digest
AuthName "Please login"
AuthUserFile /srv/www/passwd
Require user users

ErrorDocument 401 "/website/preloginrequired.html"
ErrorDocument 404 "/website/preloginrequired.html"

Note that I use AuthUserFile because it works, whereas AuthDigestFile throws an 'Invalid command' line in error_log, plus authentication doesn't work.

3. I have a page htdocs/website/loginclientarea.html that essentially puts a message on the screen that says "Please login", it also has
<body onLoad="window.location='protected/clientarea.html'">

As soon as the page has pasted, it tries to branch to the protected page, causing the browser login box to appear.  So I get a login page, and when they have completed it successfully, they get into the protected page.  Works on every browser I can find, bar one.

On version 6.0.2800.1106.xpsl.020828-1920 of IE6 no browser login box is presented and you arrive straight into the protected page without giving a  password.  Just to make sure there is no issue of cached passwords etc. I have changed the password on 'protected' twice and it still happens although this browser has never logged into the protected page with the new password.

I suggest this is not a browser issue; the Apache server should not be handing out the page without authentication under any circumstances.  But it does.
Comment 1 Dan Poirier 2010-10-28 10:32:29 UTC
Can you get a network trace of IE6 accessing the protected page without a userid/password?  Also please provide the configuration files.
Comment 2 William A. Rowe Jr. 2018-11-07 21:09:53 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.