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 > > > > > > > > > > > > >
