Hi Werner, I tried out the settings you suggested and reinstalled the
application. Now I have processNonCompliantMessages set to false. The
ping2.py script (see my previous mail) which previously worked does not
work anymore. Which is the correct behavior since I have older namespace
for wsu. However, the ping1.py script was *still* able to invoke the
service and PWCallBack class never got called. The behavior for that
script remained the same as it was before. So, toggling the value of
processNonCompliantMessages still did not provide the scurity needed
from non compliant messages.
Thanks
Mir
Dittmann Werner wrote:
Mir,
sorry, I didn't read your e-mail carefully. WSS4J can be
configured to support this behaviour using parameters
in WSSConfig.java. Currently the parameter
"processNonCompliantMessages" is set to true, meaning that
WSS4J processes non-compliant messages (messages that
do use a match of the various OASIS WSS namespaces). This
was done to support a simple migration from the various draft
specifications to the agreed standard.
If you set this parameter to false (and recompile the whole
stuff - unfortunatly we didn't yet implement a way do do
it during runtime) then WSS4J is restrictive in the sense you
mentioned.
Regards,
Werner
-----Urspr�ngliche Nachricht-----
Von: Mir Shafiqul Islam [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 20. April 2005 17:53
An: Dittmann Werner
Cc: [email protected]
Betreff: Re: AW: Possible security bug in handling digest password
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-wssec
urity-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
