5:39 p.m.
[
https://issues.jboss.org/browse/AS7-5915?page=com.atlassian.jira.plugin.s...
]
Adam Halbardier commented on AS7-5915:
--------------------------------------
After some additional digging, I think the issue exists in
org.apache.catalina.authenticator.DigestAuthenticator. Specifically, in
DigestInfo.validate()
long count;
try {
count = Long.parseLong(nc, 16);
} catch (NumberFormatException nfe) {
return false;
}
NonceInfo info;
synchronized (cnonces) {
info = cnonces.get(cnonce);
}
if (info == null) {
info = new NonceInfo();
} else {
if (count <= info.getCount()) {
return false;
}
}
Notice how the nc is associated with the cnonce. This code requires that if a cnonce has
previously been seen, then the nc must be greater than the last nc that had that cnonce.
The correct interpretation of the RFC would be to associate nc with nonce. If the nonce
value on the request has already been seen, then the nc on the request must be greater
than the previous nc associated with that nonce value. From RFC 2716: "The nc-value
is the hexadecimal count of the number of requests (including the current request) that
the client has sent with the nonce value in this request."
While the fix seems trivial (change the Map to use the nonce instead of cnonce as the
key), I don't have JBoss downloaded and built, so I'll leave that to whoever picks
up this issue.
Thanks! Cheers...
HTTP Digest Fails when cnonce is Repeated
-----------------------------------------
Key: AS7-5915
URL: https://issues.jboss.org/browse/AS7-5915
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.1.1.Final
Environment: Windows 7
Reporter: Adam Halbardier
Assignee: Remy Maucherat
HTTP digest authentication requests seem to fail when the cnonce from the browser is
repeated across multiple requests. (Firefox often does this.) For example:
1) Request resource protected by HTTP digest authentication
2) Receive response with header: WWW-Authenticate=Digest realm="helios",
qop="auth", nonce="1352490667388:dbdb24005a909963fabb3fd5e18711a9",
opaque="Yy4sDZbcknyS26MFy7VH2tfm"
3) Send auth request with header: authorization=Digest username="helios",
realm="helios",
nonce="1352490667388:dbdb24005a909963fabb3fd5e18711a9",
uri="/rest-services/rs/architecture/ui/waveforms",
response="b4900878b8ffdf49e8216d706420871e",
opaque="Yy4sDZbcknyS26MFy7VH2tfm", qop=auth, nc=00000001,
cnonce="082c875dcb2ca740"
4) Receive an HTTP 200
5) Close Firefox
6) Open Firefox and send request to same resource
7) Receive response with header: WWW-Authenticate=Digest realm="helios",
qop="auth", nonce="1352490696962:b2318fc8d36fda0a46e9b8b4de62c597",
opaque="Yy4sDZbcknyS26MFy7VH2tfm"
8) Send request with header: authorization=Digest username="helios",
realm="helios",
nonce="1352490696962:b2318fc8d36fda0a46e9b8b4de62c597",
uri="/rest-services/rs/architecture/ui/waveforms",
response="03c3ee574d29c7ce911b645b9a4e7f0c",
opaque="Yy4sDZbcknyS26MFy7VH2tfm", qop=auth, nc=00000001,
cnonce="082c875dcb2ca740"
9) Receive an HTTP 401 with header: WWW-Authenticate=Digest realm="helios",
qop="auth", nonce="1352490703289:9ce53cff6e7ba74f12b8d440bd4ec04c",
opaque="Yy4sDZbcknyS26MFy7VH2tfm"
10) Send request with header: authorization=Digest username="helios",
realm="helios",
nonce="1352490703289:9ce53cff6e7ba74f12b8d440bd4ec04c",
uri="/rest-services/rs/architecture/ui/waveforms",
response="43acf50b9a019c9c26464e5cd43b0942",
opaque="Yy4sDZbcknyS26MFy7VH2tfm", qop=auth, nc=00000001,
cnonce="1522e61005789929"
11) Receives HTTP 200
Notice that the cnonce in the first and second auth requests are the same. In the third
the cnonce changes and the auth request is accepted. This pattern is repeatable over and
over again (sometimes the cnonce does not change for many attempts, all of which fail, but
as soon as the browser changes it, the request succeeds). In all cases, the response is
computed correctly. This behavior does not appear consistent with RFC 2617 (it's
acceptable to repeat the nc and cnonce values across different 401 challenges). Further
investigation found that when the 401 is returned in the second case, the
storeDigestCallback is never executed, suggesting the failure happens before the response
digest is ever evaluated.
This is the security domain configuration in standalone.xml
<security-domain name="helios"
cache-type="default">
<authentication>
<login-module code="UsersRoles"
flag="required">
<module-option name="usersProperties"
value="${jboss.server.config.dir}/helios-users.properties"/>
<module-option name="rolesProperties"
value="${jboss.server.config.dir}/helios-roles.properties"/>
<module-option name="hashAlgorithm"
value="MD5"/>
<module-option name="hashEncoding"
value="RFC2617"/>
<module-option name="hashUserPassword"
value="false"/>
<module-option name="hashStorePassword"
value="true"/>
<module-option name="passwordIsA1Hash"
value="true"/>
<module-option name="storeDigestCallback"
value="org.jboss.security.auth.callback.RFC2617Digest"/>
</login-module>
</authentication>
</security-domain>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira