Hello Guys, Would appreciate some comments on my last post...
Thanks in advance.. Farhan. mfs wrote: > > Yet another question on the usage CryptedUrlWebRequestCodingStrategy. So > lets say we have implemented the CryptedUrlWebRequestCodingStrategy, now > even in that case wouldn't the following statement be true. > > "All pages which are mounted through any of the > bookmarkable-url-encoding-strategies for NICE urls would STILL be > vulnerable to CSRF attacks? " > > Though the statement wouldn't be true for forms/links or any wicket > event/action on that page (correct me if i am wrong here). To prevent > that we should ensure that : > > - No such critical actions are performed in the constructor of the > page. In other words all such actions (ideally) should be invoked via some > events on the page itself. > > Thanks in advance, > > Farhan. > > > > igor.vaynberg wrote: >> >> the javadoc is out of date please open a jira issue to have the javadoc >> updated. >> >> -igor >> >> On Sat, Sep 12, 2009 at 2:50 PM, mfs <[email protected]> wrote: >>> >>> Hi Guys, >>> >>> Sorry for not picking up the right thread for this question but I am not >>> able to submit a post. Anyways.. >>> >>> My question is regarding the javadocs for >>> CryptedUrlWebRequestCodingStrategy >>> which in the end says "Because the algorithm is reversible, URLs which >>> were >>> bookmarkable before will remain bookmarkable.". I wonder if that is true >>> for >>> post 1.3.5 releases where the encryption involves the user-session id ? >>> >>> Thanks in advance >>> Farhan. >>> >>> >>> >>> >>> Vytautas Civilis wrote: >>>> >>>> Hi Erik, >>>> >>>> that's not a concern for me really - I'm providing static application >>>> specific key (not uber secure I know), this let's me have a >>>> bookmarkable >>>> page even with encrypted key (as enc key does not change). >>>> >>>> The issue (more like a feature request :]), is that hybrid >>>> encodes/decodes params in different way than >>>> CryptedUrlWebRequestCodingStrategy (which uses the more common style of >>>> QueryStringUrlCodingStrategy). >>>> I imagine, that's the only problem, so perhaps anyone has implemented >>>> that already, e.g. with some params encoding/decoding strategy, which >>>> could be supplied to hybrid strat (or to crypt strat ;]). >>>> >>>> cvl >>>> >>>> Erik van Oosten wrote: >>>>> Hi Vytautas, >>>>> >>>>> You can not encrypt bookmarkable URLs as encryption is done per >>>>> session. >>>>> So if you're URLs need to be secure you are limited to regular Link's. >>>>> >>>>> Regards, >>>>> Erik. >>>>> >>>>> >>>>> >>>>> Vytautas Čivilis wrote: >>>>>> for the same purpose, one would encrypt QueryStringUrlCodingStrategy. >>>>>> >>>>>> e.g., if you have /path1/path2/param1/value1 >>>>>> and param1/value1 might expose some business logic or security >>>>>> related >>>>>> concerns. >>>>>> in the same manner as /path1/path2/param1=value1 would >>>>>> >>>>>> cvl >>>>>> >>>>>> Johan Compagner wrote: >>>>>> >>>>>>> why would you encrypt the hybrid? >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/HybridUrlCodingStrategy-and-CryptedUrlWebRequestCodingStrategy-tp23960469p25418524.html >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > -- View this message in context: http://www.nabble.com/HybridUrlCodingStrategy-and-CryptedUrlWebRequestCodingStrategy-tp23960469p25448169.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
