Is this something that will be changed in the CVS-kept codebase? I think that WSS4J needs to make available code that is secure out of the box (without requiring code changes or config changes).
On 4/21/05, Dittmann Werner <[EMAIL PROTECTED]> 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 > > > > > > > > > > > > > > > > > > > > >
