Hi Werner, you are absolutely right in your assessment of mixing the
name spaces and not sticking to one single one. However, an attacker
would not mind doing it and mix and match name spaces to access the
service without being authorized. And that is my point, if the xml sent
does not adhere to a specification or mix and match and wss4j can not
properly detect the required element (in this case the digest password)
wss4j should throw up its hands in the air and not let anyone in. Right
now it just silently lets the invoker pass through and invoke the actual
service (ping1.py).
Thanks
Mir
Dittmann Werner wrote:
Hir,
loking at your examples I found that you mix some "standard"
levels of the WS specification (yes, there were some draft
standards, the first implementation of WSS4J implemented a
draft, later we changed to the agreed standard - this is why
we intoduced the "backward" compatibility mode, the various
string are defined in WSConstants, by default we use the
OASIS_1_= setup).
The ping2.py is the example that uses the right URI for the
password type, however the napespace definition for wsu
is not correct. It should read as:
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
if you use the agreed OASIS 1.0 specification (if you refer
to the original OASIS docs pls also look at the errata when
looking up the correct namespace defintions).
Because of the wrong wsu namespace WSS4J cannot find an element
that is required for PasswordDigest (wsu:Created).
Regards,
Werner
-----Urspr�ngliche Nachricht-----
Von: Mir Shafiqul Islam [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 19. April 2005 21:46
An: [email protected]
Betreff: Possible security bug in handling digest password
I am new to wss4j and ws-security in general. So I maybe missing
something obvious.
I have axis 1.2 RC3 along with latest wss4j code from cvs. I have a
simple service setup with my own password call back handler and
everything works as expected from java environment. However, while
testing interoperability with some simple python scripts I ran into a
behavior that I can at best call a security hole.
Here is the scenario. If the password Type is specified as
"wsse:PasswordDigest" (compliant to older specification) the
WSDoAllReceiver class never detects the password as legitimate digest
password. The type is compared against fixed constant value
specified in
WSConstants.PASSWORD_DIGEST
(http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-usern
ame-token-profile-1.0#PasswordDigest).
Since the password type supplied is non compliant (or unknown) to the
Type specification should not wss4j throw some sort of exception? The
user is allowed to invoke the web service method as if he was fully
authenticated. This can be easily reproduced with the attached python
scripts. Just create a simple echo/ping service with axis and wss4j
ping1.py : Does not authenticate using password call back class and lets
user invoke method
ping2.py : Does the right thing and invokes appropriate password call
back class
server.config.xml : My service deployer file
ping1.output.txt: Packet captured via ethereal. Never authenticated the
user but invoked the ws method successfully
ping2.output.txt: Packet captured via ethereal. Failed to authenticate
the user so displayed proper error message
Thanks!
Mir
