Re: Security Features offered by Wicket
While that is true.. It's also true that wicket devs favor stuff proven with a quickstart, because it becomes easier to make a fix for something you can see in code.. So as I've written once before a quickstart should be the way to go or just use one of the existing applications, phone book or blog tutorial etc. And make a hack at that... regards Nino Ned Collyer wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack? -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
I can claim anything in thought experiments. That is easy. Making it true is something different. Martijn On 3/4/08, Ned Collyer [EMAIL PROTECTED] wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack? -- View this message in context: http://www.nabble.com/Security-Features-offered-by-Wicket-tp15738864p15824235.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] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
Wicket does nothing to protect from CSRF attacks, and it is trivially vulnerable. Sure it's a lot more difficult with the standard ?wicket:interface type URLs than it would be with more predictable URLs, but you can still quite easily guess the URLs, and futhermore, to improve your chances of success you can simply include many images in the attacking page with different values for the URLs, i.e., img src=http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1; and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in one page. Furthermore, most people actually LIKE predictable urls and go to great length to mount pages and make them bookmarkable. There's even a StatelessForm component, which is entirely vulnerable to CSRF. Thus, I'd say that even without a quickstart, it's obvious that Wicket does not offer any CSRF protection out of the box, and that if you want this kind of protection, you will have to do it yourself (which is probably not really difficult; though I think many people are not aware of these kind of attack vectors and don't even think about it, which is why it would be nice if Wicket *could* do it out of the box). I believe that answers the original question, that CSRF protection is *NOT* a security feature offered by Wicket. Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: While that is true.. It's also true that wicket devs favor stuff proven with a quickstart, because it becomes easier to make a fix for something you can see in code.. So as I've written once before a quickstart should be the way to go or just use one of the existing applications, phone book or blog tutorial etc. And make a hack at that... regards Nino Ned Collyer wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack? smime.p7s Description: S/MIME Cryptographic Signature
Re: Security Features offered by Wicket
My point is, if the code path exists, doing some elaborate session hijacking sniffer something something predict blah... can be a pain in the arse and not really a valuable investment. A better thing would be to ask the devs if it is plausible (regardless of how hard it might be in the real world). If the answer to plausibility is yes, then there needs to be a solution. Not a yeah its plausible try to hack it approach. If the OP cannot hack the system, but an attacker uses the exact methods he's described here, then that would be pretty embarrassing for all parties. Martijn Dashorst wrote: I can claim anything in thought experiments. That is easy. Making it true is something different. Martijn -- View this message in context: http://www.nabble.com/Security-Features-offered-by-Wicket-tp15738864p15824726.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]
Re: Security Features offered by Wicket
Yes!! This is what I want to say in my example! The request is made by the victim's browser and the attacker don't require to hijack the session!! Thank you Sebastiaan for explain better than me! Arthur. 2008/3/4, Sebastiaan van Erk [EMAIL PROTECTED]: The point of CSRF attack is that you *DONT* have to hijack the session. By including for example an image on the attacking website with a src reference to the vulnerable website, the browser load the page of vulnerable website, and if you currently have a session, the browser will be tricked into using your current session. That means, if you're logged in, the attacking website can trick your browser into (unknowingly and against your will) requesting any url on the vulnerable website in the context of your current session. No session hijacking required. Regards, Sebastiaan Ned Collyer wrote: My point is, if the code path exists, doing some elaborate session hijacking sniffer something something predict blah... can be a pain in the arse and not really a valuable investment. A better thing would be to ask the devs if it is plausible (regardless of how hard it might be in the real world). If the answer to plausibility is yes, then there needs to be a solution. Not a yeah its plausible try to hack it approach. If the OP cannot hack the system, but an attacker uses the exact methods he's described here, then that would be pretty embarrassing for all parties. Martijn Dashorst wrote: I can claim anything in thought experiments. That is easy. Making it true is something different. Martijn
Re: Security Features offered by Wicket
I believe that answers the original question, that CSRF protection is *NOT* a security feature offered by Wicket. I think the same, I said it and they tell me that URLs wasn't predictables when the page identifiers are a correlative numbers, so vulnerable to CSRF attacks. I want to emphasize that I think that these tasks (avoid CSRF attacks, to offer confidentiality, avoid tampering data in forms) would must be resolved by default by frameworks like Wicket to offer a security framework. Arthur. 2008/3/4, Sebastiaan van Erk [EMAIL PROTECTED]: Wicket does nothing to protect from CSRF attacks, and it is trivially vulnerable. Sure it's a lot more difficult with the standard ?wicket:interface type URLs than it would be with more predictable URLs, but you can still quite easily guess the URLs, and futhermore, to improve your chances of success you can simply include many images in the attacking page with different values for the URLs, i.e., img src= http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1 and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in one page. Furthermore, most people actually LIKE predictable urls and go to great length to mount pages and make them bookmarkable. There's even a StatelessForm component, which is entirely vulnerable to CSRF. Thus, I'd say that even without a quickstart, it's obvious that Wicket does not offer any CSRF protection out of the box, and that if you want this kind of protection, you will have to do it yourself (which is probably not really difficult; though I think many people are not aware of these kind of attack vectors and don't even think about it, which is why it would be nice if Wicket *could* do it out of the box). I believe that answers the original question, that CSRF protection is *NOT* a security feature offered by Wicket. Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: While that is true.. It's also true that wicket devs favor stuff proven with a quickstart, because it becomes easier to make a fix for something you can see in code.. So as I've written once before a quickstart should be the way to go or just use one of the existing applications, phone book or blog tutorial etc. And make a hack at that... regards Nino Ned Collyer wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack?
Re: Security Features offered by Wicket
As with all thing's you can make them more or less secure. As stated before, depending on a level of paranoia nothing are secure! Mounting a page and making it stateless, and further more making it take parameters is one of less safer ones. If the application is a web one, well use CSRF attacks, use random attacks, Bruteforce the site, go to their operator and get inside the database. Eventually you will get in, if you cover your tracks. If the application is a desktop version, deploy a keylogger and a mouse recorder, grab their password file. If they cycle passwords, bruteforce that too. Might not work with the first 100 users, but in time and theory you will get in. Nothing is secure. Having an quickstart as a usecase could help developers decide if its worth the effort. Whats a reasonable level for security... I guess the best one is telling the users to use the browser exclusivly for the bank site and be sure to logout before leaving it. -Nino Sebastiaan van Erk wrote: Wicket does nothing to protect from CSRF attacks, and it is trivially vulnerable. Sure it's a lot more difficult with the standard ?wicket:interface type URLs than it would be with more predictable URLs, but you can still quite easily guess the URLs, and futhermore, to improve your chances of success you can simply include many images in the attacking page with different values for the URLs, i.e., img src=http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1; and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in one page. This is not new, it's been discussed a few messages ago... You still need to hijack the users session. Furthermore, most people actually LIKE predictable urls and go to great length to mount pages and make them bookmarkable. There's even a StatelessForm component, which is entirely vulnerable to CSRF. Thus, I'd say that even without a quickstart, it's obvious that Wicket does not offer any CSRF protection out of the box, and that if you want this kind of protection, you will have to do it yourself (which is probably not really difficult; though I think many people are not aware of these kind of attack vectors and don't even think about it, which is why it would be nice if Wicket *could* do it out of the box). I believe that answers the original question, that CSRF protection is *NOT* a security feature offered by Wicket. I believe that true in the sense that you can always make your pages vulnerable if you want to (also if its unknowingly). Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: While that is true.. It's also true that wicket devs favor stuff proven with a quickstart, because it becomes easier to make a fix for something you can see in code.. So as I've written once before a quickstart should be the way to go or just use one of the existing applications, phone book or blog tutorial etc. And make a hack at that... regards Nino Ned Collyer wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack? -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
That said... Would a valid solution involving appending a pair of session keys to the url workout? http://thesiteiwannahack.com/?wicket:keyA=somethingreallylongwicket:keyB=somethinkreallylongwicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1 The wicket:key would be added after the user logged in.. Whats to say of that approach.. Would it be okay? Then the hacker should also guess those two keys, and that would be as secure as possible? regards Nino Nino Saturnino Martinez Vazquez Wael wrote: As with all thing's you can make them more or less secure. As stated before, depending on a level of paranoia nothing are secure! Mounting a page and making it stateless, and further more making it take parameters is one of less safer ones. If the application is a web one, well use CSRF attacks, use random attacks, Bruteforce the site, go to their operator and get inside the database. Eventually you will get in, if you cover your tracks. If the application is a desktop version, deploy a keylogger and a mouse recorder, grab their password file. If they cycle passwords, bruteforce that too. Might not work with the first 100 users, but in time and theory you will get in. Nothing is secure. Having an quickstart as a usecase could help developers decide if its worth the effort. Whats a reasonable level for security... I guess the best one is telling the users to use the browser exclusivly for the bank site and be sure to logout before leaving it. -Nino Sebastiaan van Erk wrote: Wicket does nothing to protect from CSRF attacks, and it is trivially vulnerable. Sure it's a lot more difficult with the standard ?wicket:interface type URLs than it would be with more predictable URLs, but you can still quite easily guess the URLs, and futhermore, to improve your chances of success you can simply include many images in the attacking page with different values for the URLs, i.e., img src=http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1; and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in one page. This is not new, it's been discussed a few messages ago... You still need to hijack the users session. Furthermore, most people actually LIKE predictable urls and go to great length to mount pages and make them bookmarkable. There's even a StatelessForm component, which is entirely vulnerable to CSRF. Thus, I'd say that even without a quickstart, it's obvious that Wicket does not offer any CSRF protection out of the box, and that if you want this kind of protection, you will have to do it yourself (which is probably not really difficult; though I think many people are not aware of these kind of attack vectors and don't even think about it, which is why it would be nice if Wicket *could* do it out of the box). I believe that answers the original question, that CSRF protection is *NOT* a security feature offered by Wicket. I believe that true in the sense that you can always make your pages vulnerable if you want to (also if its unknowingly). Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: While that is true.. It's also true that wicket devs favor stuff proven with a quickstart, because it becomes easier to make a fix for something you can see in code.. So as I've written once before a quickstart should be the way to go or just use one of the existing applications, phone book or blog tutorial etc. And make a hack at that... regards Nino Ned Collyer wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack? -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
Having an quickstart as a usecase could help developers decide if its worth the effort. Since the moment that wicket does not add any random parameter to urls, the applications are vulnerable to CSRF attacks, so I think that quickstart application could be a good example but I think that we can view easily that URLs are predictable and therefore a framework vulnerable (by default) to this attack type. Nothing is secure I agree with this confirmation but if we develop a secure frameworks BY DEFAULT, we will prevent a lot of attacks BY DEFAULT! Security features must be functionalities offered by frameworks by default and they do not have to be an option of the final users. Arthur. 2008/3/4, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED]: As with all thing's you can make them more or less secure. As stated before, depending on a level of paranoia nothing are secure! Mounting a page and making it stateless, and further more making it take parameters is one of less safer ones. If the application is a web one, well use CSRF attacks, use random attacks, Bruteforce the site, go to their operator and get inside the database. Eventually you will get in, if you cover your tracks. If the application is a desktop version, deploy a keylogger and a mouse recorder, grab their password file. If they cycle passwords, bruteforce that too. Might not work with the first 100 users, but in time and theory you will get in. Nothing is secure. Having an quickstart as a usecase could help developers decide if its worth the effort. Whats a reasonable level for security... I guess the best one is telling the users to use the browser exclusivly for the bank site and be sure to logout before leaving it. -Nino Sebastiaan van Erk wrote: Wicket does nothing to protect from CSRF attacks, and it is trivially vulnerable. Sure it's a lot more difficult with the standard ?wicket:interface type URLs than it would be with more predictable URLs, but you can still quite easily guess the URLs, and futhermore, to improve your chances of success you can simply include many images in the attacking page with different values for the URLs, i.e., img src= http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1 and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in one page. This is not new, it's been discussed a few messages ago... You still need to hijack the users session. Furthermore, most people actually LIKE predictable urls and go to great length to mount pages and make them bookmarkable. There's even a StatelessForm component, which is entirely vulnerable to CSRF. Thus, I'd say that even without a quickstart, it's obvious that Wicket does not offer any CSRF protection out of the box, and that if you want this kind of protection, you will have to do it yourself (which is probably not really difficult; though I think many people are not aware of these kind of attack vectors and don't even think about it, which is why it would be nice if Wicket *could* do it out of the box). I believe that answers the original question, that CSRF protection is *NOT* a security feature offered by Wicket. I believe that true in the sense that you can always make your pages vulnerable if you want to (also if its unknowingly). Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: While that is true.. It's also true that wicket devs favor stuff proven with a quickstart, because it becomes easier to make a fix for something you can see in code.. So as I've written once before a quickstart should be the way to go or just use one of the existing applications, phone book or blog tutorial etc. And make a hack at that... regards Nino Ned Collyer wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack? -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
Hi, Nino Saturnino Martinez Vazquez Wael wrote: As with all thing's you can make them more or less secure. As stated before, depending on a level of paranoia nothing are secure! But that's got nothing to do with the question: does Wicket offer security feature X? Nor does it help answer the follow up question: should Wicket off security feature X? If the application is a web one, well use CSRF attacks, use random attacks, Bruteforce the site, go to their operator and get inside the database. Eventually you will get in, if you cover your tracks. I disagree. You don't necessary eventually get in. Brute force is infeasible (in well designed systems). Going to their operator leaves tracks and has high risk and high costs. Doing a CSRF attack is easy, anonymous, and can be done remotely. Nothing is secure. Oh darn, well I guess I'll just remove my password protection from my computer, it's not secure anyway!!! Having an quickstart as a usecase could help developers decide if its worth the effort. Whats a reasonable level for security... I guess the best one is telling the users to use the browser exclusivly for the bank site and be sure to logout before leaving it. I don't see how a quickstart will help... Maybe it will help show *what* a CSRF attack is for those who don't know. :-) I think the original poster makes a good point. I think a CSRF attack is relatively high risk, and relatively low cost to fix. All it takes (I think, don't pin me on this, I have to research it a bit more) is something like a secure token to be kept in the state of the form which must be sent back on submit by the user, which is then matched. The wicket user does not have to know about this at all, it is transparent. As added benefit it blocks double form posts. In the case that it is desired that posts can be made without first having to request the page with the form, one should be able to turn CSRF protection off. Considering its 1) ease of implementation, 2) low intrusiveness, 3) added value, I definately think it's worth considering protecting Wicket from CSRF by default. Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
Re: Security Features offered by Wicket
Wicket has support for protection just enable it: CryptedUrlWebRequestCodingStrategy and you can use that in combination with: UrlCompressingWebRequestProcessor The problem with this is i guess that the normal form get then also still works but i am not sure On Tue, Mar 4, 2008 at 11:42 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Wicket does nothing to protect from CSRF attacks, and it is trivially vulnerable. Sure it's a lot more difficult with the standard ?wicket:interface type URLs than it would be with more predictable URLs, but you can still quite easily guess the URLs, and futhermore, to improve your chances of success you can simply include many images in the attacking page with different values for the URLs, i.e., img src= http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1 and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in one page. Furthermore, most people actually LIKE predictable urls and go to great length to mount pages and make them bookmarkable. There's even a StatelessForm component, which is entirely vulnerable to CSRF. Thus, I'd say that even without a quickstart, it's obvious that Wicket does not offer any CSRF protection out of the box, and that if you want this kind of protection, you will have to do it yourself (which is probably not really difficult; though I think many people are not aware of these kind of attack vectors and don't even think about it, which is why it would be nice if Wicket *could* do it out of the box). I believe that answers the original question, that CSRF protection is *NOT* a security feature offered by Wicket. Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: While that is true.. It's also true that wicket devs favor stuff proven with a quickstart, because it becomes easier to make a fix for something you can see in code.. So as I've written once before a quickstart should be the way to go or just use one of the existing applications, phone book or blog tutorial etc. And make a hack at that... regards Nino Ned Collyer wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack?
Re: Security Features offered by Wicket
Hmm, Im a little slow this week.. Theres even an article about it: http://javathoughts.capesugarbird.com/2007/08/protecting-wicket-application-against.html Johan Compagner wrote: Wicket has support for protection just enable it: CryptedUrlWebRequestCodingStrategy and you can use that in combination with: UrlCompressingWebRequestProcessor The problem with this is i guess that the normal form get then also still works but i am not sure On Tue, Mar 4, 2008 at 11:42 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Wicket does nothing to protect from CSRF attacks, and it is trivially vulnerable. Sure it's a lot more difficult with the standard ?wicket:interface type URLs than it would be with more predictable URLs, but you can still quite easily guess the URLs, and futhermore, to improve your chances of success you can simply include many images in the attacking page with different values for the URLs, i.e., img src= http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1 and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in one page. Furthermore, most people actually LIKE predictable urls and go to great length to mount pages and make them bookmarkable. There's even a StatelessForm component, which is entirely vulnerable to CSRF. Thus, I'd say that even without a quickstart, it's obvious that Wicket does not offer any CSRF protection out of the box, and that if you want this kind of protection, you will have to do it yourself (which is probably not really difficult; though I think many people are not aware of these kind of attack vectors and don't even think about it, which is why it would be nice if Wicket *could* do it out of the box). I believe that answers the original question, that CSRF protection is *NOT* a security feature offered by Wicket. Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: While that is true.. It's also true that wicket devs favor stuff proven with a quickstart, because it becomes easier to make a fix for something you can see in code.. So as I've written once before a quickstart should be the way to go or just use one of the existing applications, phone book or blog tutorial etc. And make a hack at that... regards Nino Ned Collyer wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack? -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
Checkout the other part of this thread, I think this has become a dead end... http://javathoughts.capesugarbird.com/2007/08/protecting-wicket-application-against.html Sebastiaan van Erk wrote: Hi, Nino Saturnino Martinez Vazquez Wael wrote: As with all thing's you can make them more or less secure. As stated before, depending on a level of paranoia nothing are secure! But that's got nothing to do with the question: does Wicket offer security feature X? Nor does it help answer the follow up question: should Wicket off security feature X? If the application is a web one, well use CSRF attacks, use random attacks, Bruteforce the site, go to their operator and get inside the database. Eventually you will get in, if you cover your tracks. I disagree. You don't necessary eventually get in. Brute force is infeasible (in well designed systems). Going to their operator leaves tracks and has high risk and high costs. Doing a CSRF attack is easy, anonymous, and can be done remotely. Nothing is secure. Oh darn, well I guess I'll just remove my password protection from my computer, it's not secure anyway!!! Having an quickstart as a usecase could help developers decide if its worth the effort. Whats a reasonable level for security... I guess the best one is telling the users to use the browser exclusivly for the bank site and be sure to logout before leaving it. I don't see how a quickstart will help... Maybe it will help show *what* a CSRF attack is for those who don't know. :-) I think the original poster makes a good point. I think a CSRF attack is relatively high risk, and relatively low cost to fix. All it takes (I think, don't pin me on this, I have to research it a bit more) is something like a secure token to be kept in the state of the form which must be sent back on submit by the user, which is then matched. The wicket user does not have to know about this at all, it is transparent. As added benefit it blocks double form posts. In the case that it is desired that posts can be made without first having to request the page with the form, one should be able to turn CSRF protection off. Considering its 1) ease of implementation, 2) low intrusiveness, 3) added value, I definately think it's worth considering protecting Wicket from CSRF by default. Regards, Sebastiaan -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
good article Nino! Our paranoia is not going to be really a paranoia... ;-) As Sebastian comment CSRF attack is relatively high risk, and relatively low cost to fix. Arthur. 2008/3/4, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED]: Hmm, Im a little slow this week.. Theres even an article about it: http://javathoughts.capesugarbird.com/2007/08/protecting-wicket-application-against.html Johan Compagner wrote: Wicket has support for protection just enable it: CryptedUrlWebRequestCodingStrategy and you can use that in combination with: UrlCompressingWebRequestProcessor The problem with this is i guess that the normal form get then also still works but i am not sure On Tue, Mar 4, 2008 at 11:42 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Wicket does nothing to protect from CSRF attacks, and it is trivially vulnerable. Sure it's a lot more difficult with the standard ?wicket:interface type URLs than it would be with more predictable URLs, but you can still quite easily guess the URLs, and futhermore, to improve your chances of success you can simply include many images in the attacking page with different values for the URLs, i.e., img src= http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1 and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in one page. Furthermore, most people actually LIKE predictable urls and go to great length to mount pages and make them bookmarkable. There's even a StatelessForm component, which is entirely vulnerable to CSRF. Thus, I'd say that even without a quickstart, it's obvious that Wicket does not offer any CSRF protection out of the box, and that if you want this kind of protection, you will have to do it yourself (which is probably not really difficult; though I think many people are not aware of these kind of attack vectors and don't even think about it, which is why it would be nice if Wicket *could* do it out of the box). I believe that answers the original question, that CSRF protection is *NOT* a security feature offered by Wicket. Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: While that is true.. It's also true that wicket devs favor stuff proven with a quickstart, because it becomes easier to make a fix for something you can see in code.. So as I've written once before a quickstart should be the way to go or just use one of the existing applications, phone book or blog tutorial etc. And make a hack at that... regards Nino Ned Collyer wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack? -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
How does the crypted web url request coding strategy work with bookmarkable pages and nice urls? Do they play nice together? The form with the token looks good, the question I have is, why is something like it not the default (since almost everybody's site will be vulnerable without it)? Currently protection from CSRF requires people 1) to know about CSRF and either 2a) to code their own form solution (which might be broken) or to rip it from the web (which might also be broken ;-)), or 2b) to enable the CryptedUrlWebRequestCodingStrategy. In any case, knowledge of such attacks is required and an action needs to be taken, if you want to be protected. That's something maybe the framework could do for you? Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: Hmm, Im a little slow this week.. Theres even an article about it: http://javathoughts.capesugarbird.com/2007/08/protecting-wicket-application-against.html Johan Compagner wrote: Wicket has support for protection just enable it: CryptedUrlWebRequestCodingStrategy and you can use that in combination with: UrlCompressingWebRequestProcessor The problem with this is i guess that the normal form get then also still works but i am not sure On Tue, Mar 4, 2008 at 11:42 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Wicket does nothing to protect from CSRF attacks, and it is trivially vulnerable. Sure it's a lot more difficult with the standard ?wicket:interface type URLs than it would be with more predictable URLs, but you can still quite easily guess the URLs, and futhermore, to improve your chances of success you can simply include many images in the attacking page with different values for the URLs, i.e., img src= http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1 and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in one page. Furthermore, most people actually LIKE predictable urls and go to great length to mount pages and make them bookmarkable. There's even a StatelessForm component, which is entirely vulnerable to CSRF. Thus, I'd say that even without a quickstart, it's obvious that Wicket does not offer any CSRF protection out of the box, and that if you want this kind of protection, you will have to do it yourself (which is probably not really difficult; though I think many people are not aware of these kind of attack vectors and don't even think about it, which is why it would be nice if Wicket *could* do it out of the box). I believe that answers the original question, that CSRF protection is *NOT* a security feature offered by Wicket. Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: While that is true.. It's also true that wicket devs favor stuff proven with a quickstart, because it becomes easier to make a fix for something you can see in code.. So as I've written once before a quickstart should be the way to go or just use one of the existing applications, phone book or blog tutorial etc. And make a hack at that... regards Nino Ned Collyer wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack? smime.p7s Description: S/MIME Cryptographic Signature
Re: Security Features offered by Wicket
Arthur Ahiceh wrote: good article Nino! Our paranoia is not going to be really a paranoia... ;-) :) As Sebastian comment CSRF attack is relatively high risk, and relatively low cost to fix. Yes that's true.. Arthur. 2008/3/4, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED]: Hmm, Im a little slow this week.. Theres even an article about it: http://javathoughts.capesugarbird.com/2007/08/protecting-wicket-application-against.html Johan Compagner wrote: Wicket has support for protection just enable it: CryptedUrlWebRequestCodingStrategy and you can use that in combination with: UrlCompressingWebRequestProcessor The problem with this is i guess that the normal form get then also still works but i am not sure On Tue, Mar 4, 2008 at 11:42 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Wicket does nothing to protect from CSRF attacks, and it is trivially vulnerable. Sure it's a lot more difficult with the standard ?wicket:interface type URLs than it would be with more predictable URLs, but you can still quite easily guess the URLs, and futhermore, to improve your chances of success you can simply include many images in the attacking page with different values for the URLs, i.e., img src= http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1 and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in one page. Furthermore, most people actually LIKE predictable urls and go to great length to mount pages and make them bookmarkable. There's even a StatelessForm component, which is entirely vulnerable to CSRF. Thus, I'd say that even without a quickstart, it's obvious that Wicket does not offer any CSRF protection out of the box, and that if you want this kind of protection, you will have to do it yourself (which is probably not really difficult; though I think many people are not aware of these kind of attack vectors and don't even think about it, which is why it would be nice if Wicket *could* do it out of the box). I believe that answers the original question, that CSRF protection is *NOT* a security feature offered by Wicket. Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: While that is true.. It's also true that wicket devs favor stuff proven with a quickstart, because it becomes easier to make a fix for something you can see in code.. So as I've written once before a quickstart should be the way to go or just use one of the existing applications, phone book or blog tutorial etc. And make a hack at that... regards Nino Ned Collyer wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack? -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
Sebastiaan van Erk wrote: How does the crypted web url request coding strategy work with bookmarkable pages and nice urls? Do they play nice together? Im also thinking of Ajax, how does fit it... The form with the token looks good, the question I have is, why is something like it not the default (since almost everybody's site will be vulnerable without it)? I was thinking that too, or at least bring in the option, having a safeForm or something like it packaged with wicket.. Currently protection from CSRF requires people 1) to know about CSRF and either 2a) to code their own form solution (which might be broken) or to rip it from the web (which might also be broken ;-)), or 2b) to enable the CryptedUrlWebRequestCodingStrategy. In any case, knowledge of such attacks is required and an action needs to be taken, if you want to be protected. That's something maybe the framework could do for you? Hmm, if theres not performance/memory issues i'd say go for it aswell. Making stuff secure as default is always nice... Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: Hmm, Im a little slow this week.. Theres even an article about it: http://javathoughts.capesugarbird.com/2007/08/protecting-wicket-application-against.html Johan Compagner wrote: Wicket has support for protection just enable it: CryptedUrlWebRequestCodingStrategy and you can use that in combination with: UrlCompressingWebRequestProcessor The problem with this is i guess that the normal form get then also still works but i am not sure On Tue, Mar 4, 2008 at 11:42 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Wicket does nothing to protect from CSRF attacks, and it is trivially vulnerable. Sure it's a lot more difficult with the standard ?wicket:interface type URLs than it would be with more predictable URLs, but you can still quite easily guess the URLs, and futhermore, to improve your chances of success you can simply include many images in the attacking page with different values for the URLs, i.e., img src= http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1 and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in one page. Furthermore, most people actually LIKE predictable urls and go to great length to mount pages and make them bookmarkable. There's even a StatelessForm component, which is entirely vulnerable to CSRF. Thus, I'd say that even without a quickstart, it's obvious that Wicket does not offer any CSRF protection out of the box, and that if you want this kind of protection, you will have to do it yourself (which is probably not really difficult; though I think many people are not aware of these kind of attack vectors and don't even think about it, which is why it would be nice if Wicket *could* do it out of the box). I believe that answers the original question, that CSRF protection is *NOT* a security feature offered by Wicket. Regards, Sebastiaan Nino Saturnino Martinez Vazquez Wael wrote: While that is true.. It's also true that wicket devs favor stuff proven with a quickstart, because it becomes easier to make a fix for something you can see in code.. So as I've written once before a quickstart should be the way to go or just use one of the existing applications, phone book or blog tutorial etc. And make a hack at that... regards Nino Ned Collyer wrote: Nick, I think you would be quite surprised at the level of auditing something has to pass to be used in a financial system, especially a bank. (unless u have some dodgy bank) If something is theoretically possible, then thats as good as proven. Gotta remember that hackers are a lot smarter in many instances than the people who wrote the software to keep them out. Nick Heudecker wrote: Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack? -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
Just a thought from a security newbie... does/can wicket require POST for form submissions? Would that prevent the issue of embedding the evil param values in the src of an image? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
Forget it... it wouldn't help much. http://en.wikipedia.org/wiki/Csrf: Using POST instead of GET does not offer protection, as JavaScript can be used to forge POST requests with ease. On Mar 4, 2008, at 9:29 AM, Alex Jacoby wrote: Just a thought from a security newbie... does/can wicket require POST for form submissions? Would that prevent the issue of embedding the evil param values in the src of an image? - 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]
Re: Security Features offered by Wicket
On Tue, Mar 4, 2008 at 4:42 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: The form with the token looks good, the question I have is, why is something like it not the default (since almost everybody's site will be vulnerable without it)? because we are a generic framework and i believe the thinking so far has been that this kind of security is not a requirement but an exception. clearly if you are building a banking app then security is the default and unsecure is the exception. eg we can enable csrf protection out of the box, but then you are completely screwed if you want to have your website indexed - crawlers dont like different urls pointing to same content and they dont support sessions. if our users tell us they want the security to be the default we would make the switch... -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
btw, if you really want to be extremely secure and don't mind some number crunching overhead, you might try using cryptographically secure urls. it's as easy as installing a new url coding strategy in wicket. Arthur Ahiceh wrote: Hi guys, I have a very critical application in a banking environment and I wanted to resolve the following questions over Security. This points are questioned after read some documentation from mailing lists (webappsec, struts, wicket, etc.) and projects like HDIV[2]. 1. ESCAPING CHARACTERS: I have read in wicket's mailing list that all wicket components escape values. I have done some tests in wicket-examples application distributed in wicket-1.3.1 release and I have modified, in FormInput.properties file, value of key string with this value scriptalert(xss);/script and I see that this script is executed when I load the page with this message key. So, i don't know if all components escape or not values! 2. INTEGRITY: Actualy in my bank application we have hidden fileds in our forms to store critical values and I want to know if wicket by default guarantees data integrity or not. I want to guarantee integrity like HDIV does in Struts and Spring MVC apps... is it possible in wicket? I have read in wicket's documentation that it is possible to encrypt urls ensuring integrity ( http://cwiki.apache.org/WICKET/url-coding-strategies.html) but is it possible to apply this strategy to forms? Or data tampering attacks are possible in wicket forms with hidden fields? So, can Wicket ensure data integrity? 3. CONFIDENTIALITY: After read HDIV's reference document I have see that in our application data base identifiers are presented in html pages as combo values ids and now we want to hide these values. I thought about implementing a common renderer for all my wicket components to be responsible for returning a value relative to the original values, but I do not like it because it is probably that my programmers don't use it in all cases and it is a risk that I don't want to run. Is there any wicket functionality to return confidential data, by default, for form's values? I do not want to rely on developers... 4. RANDOM TOKENS: I want to avoid CSRF attacks and I have read ( http://www.owasp.org/index.php/Top_10_2007-A5) that a possible solution is to add random tokens to all requests. Is it possible to add a random parameter to requests automatically in wicket? I need your help to answer this questions, pls! thanks! [1] http://www.nabble.com/Shout-more-about-security-advantages-of-Wicket--to14800934.html#a14816425 [2] http://www.hdiv.org/docs/hdiv-reference.pdf -- View this message in context: http://www.nabble.com/Security-Features-offered-by-Wicket-tp15738864p15834345.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]
Re: Security Features offered by Wicket
yeah, urls keyed to user's session... -igor On Tue, Mar 4, 2008 at 10:48 AM, Jonathan Locke [EMAIL PROTECTED] wrote: btw, if you really want to be extremely secure and don't mind some number crunching overhead, you might try using cryptographically secure urls. it's as easy as installing a new url coding strategy in wicket. Arthur Ahiceh wrote: Hi guys, I have a very critical application in a banking environment and I wanted to resolve the following questions over Security. This points are questioned after read some documentation from mailing lists (webappsec, struts, wicket, etc.) and projects like HDIV[2]. 1. ESCAPING CHARACTERS: I have read in wicket's mailing list that all wicket components escape values. I have done some tests in wicket-examples application distributed in wicket-1.3.1 release and I have modified, in FormInput.properties file, value of key string with this value scriptalert(xss);/script and I see that this script is executed when I load the page with this message key. So, i don't know if all components escape or not values! 2. INTEGRITY: Actualy in my bank application we have hidden fileds in our forms to store critical values and I want to know if wicket by default guarantees data integrity or not. I want to guarantee integrity like HDIV does in Struts and Spring MVC apps... is it possible in wicket? I have read in wicket's documentation that it is possible to encrypt urls ensuring integrity ( http://cwiki.apache.org/WICKET/url-coding-strategies.html) but is it possible to apply this strategy to forms? Or data tampering attacks are possible in wicket forms with hidden fields? So, can Wicket ensure data integrity? 3. CONFIDENTIALITY: After read HDIV's reference document I have see that in our application data base identifiers are presented in html pages as combo values ids and now we want to hide these values. I thought about implementing a common renderer for all my wicket components to be responsible for returning a value relative to the original values, but I do not like it because it is probably that my programmers don't use it in all cases and it is a risk that I don't want to run. Is there any wicket functionality to return confidential data, by default, for form's values? I do not want to rely on developers... 4. RANDOM TOKENS: I want to avoid CSRF attacks and I have read ( http://www.owasp.org/index.php/Top_10_2007-A5) that a possible solution is to add random tokens to all requests. Is it possible to add a random parameter to requests automatically in wicket? I need your help to answer this questions, pls! thanks! [1] http://www.nabble.com/Shout-more-about-security-advantages-of-Wicket--to14800934.html#a14816425 [2] http://www.hdiv.org/docs/hdiv-reference.pdf -- View this message in context: http://www.nabble.com/Security-Features-offered-by-Wicket-tp15738864p15834345.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]
Re: Security Features offered by Wicket
Hi igor,
your response demonstrate that Wicket's behaviour is very simple to extend
and it is that I like from wicket. I think that to prevent CSRF attacks is
neccessary to add your random parameter to all requests...it was that I
would like to comment here! To prevent CSRF with a random parameter is
necessary to extend wicket's behaviour and it isn't an automatically task
delegated in Wicket framework.
There are people that thinks that CSRF attacks are not possible in Wicket
applications but I think that wicket's urls are easily created by an
attacker with a valid values stored in a victim's session and therefore
attacks are possible by src attribute of images. See:
http://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics
Using captchas this problem is resolved but as I said here what I wanted was
that Wicket prevented by default CSRF attacks.
I want to clarify that I like Wicket and what I'm doing is asking and
helping to secure Wicket...I think that this solutions are not paranoia and
they are necessary in production environments...
Arthur.
2008/2/29, Igor Vaynberg [EMAIL PROTECTED]:
here are some ideas to much over...
class SecureForm extends Form {
private String token;
protected void onbeforerender() { token=UUID.randomUUID.toString(); }
protected void oncomponenttagbody() {
getresponse().write(input type='hidden' name='token'
value='+token+'/);
super.oncomponenttagbody();
}
public boolean process() {
if (!token.equals(getrequest().getparameter(token)) {
throw new IllegalStateException(token mismatch);
}
return super.process();
}
}
so now you have token validation between http space and session space
if you want to take it to the next level
class SecureTextField extends TextField {
private String secureName;
public String getInputName() {
if (secureName==null) {
secureName=a+UUID.randomUUID().toString().replace(-,);
}
return secureName;
}
}
and now you have a textfield whose input name is unpredictable
there are all kinds of things you can easily do in wicket, just
depends on your level of paranoia.
-igor
On Fri, Feb 29, 2008 at 7:33 AM, Arthur Ahiceh [EMAIL PROTECTED]
wrote:
Hi again,
The example that I put here is a typical example when you read articles
about CSRF attacks. It demonstrates that the attack request is made
by a
valid user with his credentials (cookies).
This second authentication usually also contains an encrypted
version of
the amount that should be transfered.
yes! this is random token solution that I have commented. You can add a
random parameter to all requests or to encrypt the values of all the
noneditable parameters (links, lists, radios, etc.).
Therefore, if we did not adopt automatic solutions it is probable that
most
of the applications they are vulnerable to this type of attacks. Is it
not
better than frameworks like Wicket solves certain vulnerabilities to
us?
CryptedUrlWebRequestCodingStrategy... (William Hoover)
This strategy as I know is only applied to urls and not to data forms!
But I
would like that this point was confirmed by a wicket's developers
group.
public wiki document... (Martin Makundi)
First, I would like to know Wickets' features better and they confirmed
me
if my questions are correct or no...
CONFIDENTIALITY
It is not possible out of the box afaik but you could either try to
subclass Form or write a filter to intercept and replace form values
when wicket sends the response and reverse it when the user submits
the form.
right, I know that I could do it as HDIV does but I like to know if
this
feature is provided by Wicket framework, I think that it would be very
interesting...what do you think about an automatic solution?
Excuse me, I'm french and my english is poorer than I would like.
Thanks again four your time! I consider that it is a subject that to
all
interests to us.
Arthur.
2008/2/29, Maurice Marrink [EMAIL PROTECTED]:
While pages ids have been correlatives, hacker could always
construct a
valid url to generate a CSRF attack. Let's see a typical
example...
Consider a bank web site that allows its users to make account
transfers.
Once a user has logged in and received an authentication cookie,
he
needs
only to request the URL
http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::inputForm4_hf_0transferTo=123amount=1000in
order to transfer $1000 to account number 123. If an attacker can
trick
an already-authenticated user into visiting a malicious page that
contains
an image link like img src=
http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::inputForm4_hf_0transferTo=456amount=1000/
,
the user's
Re: Security Features offered by Wicket
Arthur,
Only what you can *prove* matters, not what you think. Have you created an
example application with a CSRF attack?
On Mon, Mar 3, 2008 at 10:42 AM, Arthur Ahiceh [EMAIL PROTECTED]
wrote:
Hi igor,
your response demonstrate that Wicket's behaviour is very simple to extend
and it is that I like from wicket. I think that to prevent CSRF attacks is
neccessary to add your random parameter to all requests...it was that I
would like to comment here! To prevent CSRF with a random parameter is
necessary to extend wicket's behaviour and it isn't an automatically task
delegated in Wicket framework.
There are people that thinks that CSRF attacks are not possible in Wicket
applications but I think that wicket's urls are easily created by an
attacker with a valid values stored in a victim's session and therefore
attacks are possible by src attribute of images. See:
http://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics
Using captchas this problem is resolved but as I said here what I wanted
was
that Wicket prevented by default CSRF attacks.
I want to clarify that I like Wicket and what I'm doing is asking and
helping to secure Wicket...I think that this solutions are not paranoia
and
they are necessary in production environments...
Arthur.
2008/2/29, Igor Vaynberg [EMAIL PROTECTED]:
here are some ideas to much over...
class SecureForm extends Form {
private String token;
protected void onbeforerender() { token=UUID.randomUUID.toString(); }
protected void oncomponenttagbody() {
getresponse().write(input type='hidden' name='token'
value='+token+'/);
super.oncomponenttagbody();
}
public boolean process() {
if (!token.equals(getrequest().getparameter(token)) {
throw new IllegalStateException(token mismatch);
}
return super.process();
}
}
so now you have token validation between http space and session space
if you want to take it to the next level
class SecureTextField extends TextField {
private String secureName;
public String getInputName() {
if (secureName==null) {
secureName=a+UUID.randomUUID().toString().replace(-,);
}
return secureName;
}
}
and now you have a textfield whose input name is unpredictable
there are all kinds of things you can easily do in wicket, just
depends on your level of paranoia.
-igor
On Fri, Feb 29, 2008 at 7:33 AM, Arthur Ahiceh [EMAIL PROTECTED]
wrote:
Hi again,
The example that I put here is a typical example when you read
articles
about CSRF attacks. It demonstrates that the attack request is made
by a
valid user with his credentials (cookies).
This second authentication usually also contains an encrypted
version of
the amount that should be transfered.
yes! this is random token solution that I have commented. You can add
a
random parameter to all requests or to encrypt the values of all the
noneditable parameters (links, lists, radios, etc.).
Therefore, if we did not adopt automatic solutions it is probable
that
most
of the applications they are vulnerable to this type of attacks. Is
it
not
better than frameworks like Wicket solves certain vulnerabilities to
us?
CryptedUrlWebRequestCodingStrategy... (William Hoover)
This strategy as I know is only applied to urls and not to data
forms!
But I
would like that this point was confirmed by a wicket's developers
group.
public wiki document... (Martin Makundi)
First, I would like to know Wickets' features better and they
confirmed
me
if my questions are correct or no...
CONFIDENTIALITY
It is not possible out of the box afaik but you could either try to
subclass Form or write a filter to intercept and replace form
values
when wicket sends the response and reverse it when the user
submits
the form.
right, I know that I could do it as HDIV does but I like to know if
this
feature is provided by Wicket framework, I think that it would be
very
interesting...what do you think about an automatic solution?
Excuse me, I'm french and my english is poorer than I would like.
Thanks again four your time! I consider that it is a subject that to
all
interests to us.
Arthur.
2008/2/29, Maurice Marrink [EMAIL PROTECTED]:
While pages ids have been correlatives, hacker could always
construct a
valid url to generate a CSRF attack. Let's see a typical
example...
Consider a bank web site that allows its users to make account
transfers.
Once a user has logged in and received an authentication cookie,
he
needs
only to request the URL
http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::inputForm4_hf_0transferTo=123amount=1000in
order
Re: Security Features offered by Wicket
Hi Igor, 4. CSRF attacks first you would have to hijack the session... then in order for you to hit ?wicket:interface=:0:goGerman::ILinkListener:: a few things have to be true: a) attacker has to hijack the session b) page id (the 0 part of the url) has to match with the link path in the user's session. this depends on the order user has visited the pages c) user had to actually have visited the page previously even if thats not enough it is trivial to write your own coding strategy that appends the random token and stores its mirror in session While pages ids have been correlatives, hacker could always construct a valid url to generate a CSRF attack. Let's see a typical example... Consider a bank web site that allows its users to make account transfers. Once a user has logged in and received an authentication cookie, he needs only to request the URL http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::inputForm4_hf_0transferTo=123amount=1000in order to transfer $1000 to account number 123. If an attacker can trick an already-authenticated user into visiting a malicious page that contains an image link like img src= http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::inputForm4_hf_0transferTo=456amount=1000/, the user's (victim) browser will automatically request that URL, thus making an account transfer without the user's knowledge or consent. Once the victim makes a valid transfer, the transfer's values are in session, so if the attacker generates many images like commented with different values in interface parameter, he would obtain the objective. So, I think that it is necessary to insert a random value to all requests or generate confidential values for all parameters of a request. What do you think? 3. CONFIDENTIALITY: I have seen in forms that radio's options an checkbox's values have no confidential values. Could I put automatically all form values confidentiality in Wicket? I don't want that the attacker sees the original values... Is it possible to apply encrypt strategy to forms? thanks! Arthur.
RE: Security Features offered by Wicket
What about using the CryptedUrlWebRequestCodingStrategy? In your WebApplication:
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor() {
protected IRequestCodingStrategy
newRequestCodingStrategy() {
// encrypt URL with a hash format
return new
CryptedUrlWebRequestCodingStrategy(new WebRequestCodingStrategy());
}
};
}
-Original Message-
From: Arthur Ahiceh [mailto:[EMAIL PROTECTED]
Sent: Friday, February 29, 2008 9:04 AM
To: users@wicket.apache.org
Subject: Re: Security Features offered by Wicket
Hi Igor,
4. CSRF attacks
first you would have to hijack the session...
then in order for you to hit
?wicket:interface=:0:goGerman::ILinkListener::
a few things have to be true:
a) attacker has to hijack the session
b) page id (the 0 part of the url) has to match with the link path
in
the user's session. this depends on the order user has visited the
pages
c) user had to actually have visited the page previously
even if thats not enough it is trivial to write your own coding
strategy that appends the random token and stores its mirror in
session
While pages ids have been correlatives, hacker could always construct a
valid url to generate a CSRF attack. Let's see a typical example...
Consider a bank web site that allows its users to make account transfers.
Once a user has logged in and received an authentication cookie, he needs
only to request the URL
http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::inputForm4_hf_0transferTo=123amount=1000in
order to transfer $1000 to account number 123. If an attacker can
trick
an already-authenticated user into visiting a malicious page that contains
an image link like img src=
http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::inputForm4_hf_0transferTo=456amount=1000/,
the user's (victim) browser will automatically request that URL, thus making
an account transfer without the user's knowledge or consent.
Once the victim makes a valid transfer, the transfer's values are in
session, so if the attacker generates many images like commented with
different values in interface parameter, he would obtain the objective.
So, I think that it is necessary to insert a random value to all requests or
generate confidential values for all parameters of a request. What do you
think?
3. CONFIDENTIALITY: I have seen in forms that radio's options an checkbox's
values have no confidential values. Could I put automatically all form
values confidentiality in Wicket? I don't want that the attacker sees the
original values...
Is it possible to apply encrypt strategy to forms?
thanks!
Arthur.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
Hi Arthur! It would be nice if you wrote a public wiki document about Wicket Security Audit from the point of view of security-sensitive institutions. After you have gathered all the necessary information, of course. This would speed up the adoption of Wicket in similar projects as there would be research done on the subject. ** Martin 2008/2/29, Arthur Ahiceh [EMAIL PROTECTED]: Hi Igor, 4. CSRF attacks first you would have to hijack the session... then in order for you to hit ?wicket:interface=:0:goGerman::ILinkListener:: a few things have to be true: a) attacker has to hijack the session b) page id (the 0 part of the url) has to match with the link path in the user's session. this depends on the order user has visited the pages c) user had to actually have visited the page previously even if thats not enough it is trivial to write your own coding strategy that appends the random token and stores its mirror in session While pages ids have been correlatives, hacker could always construct a valid url to generate a CSRF attack. Let's see a typical example... Consider a bank web site that allows its users to make account transfers. Once a user has logged in and received an authentication cookie, he needs only to request the URL http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::inputForm4_hf_0transferTo=123amount=1000in order to transfer $1000 to account number 123. If an attacker can trick an already-authenticated user into visiting a malicious page that contains an image link like img src= http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::inputForm4_hf_0transferTo=456amount=1000/, the user's (victim) browser will automatically request that URL, thus making an account transfer without the user's knowledge or consent. Once the victim makes a valid transfer, the transfer's values are in session, so if the attacker generates many images like commented with different values in interface parameter, he would obtain the objective. So, I think that it is necessary to insert a random value to all requests or generate confidential values for all parameters of a request. What do you think? 3. CONFIDENTIALITY: I have seen in forms that radio's options an checkbox's values have no confidential values. Could I put automatically all form values confidentiality in Wicket? I don't want that the attacker sees the original values... Is it possible to apply encrypt strategy to forms? thanks! Arthur. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
Hi again, The example that I put here is a typical example when you read articles about CSRF attacks. It demonstrates that the attack request is made by a valid user with his credentials (cookies). This second authentication usually also contains an encrypted version of the amount that should be transfered. yes! this is random token solution that I have commented. You can add a random parameter to all requests or to encrypt the values of all the noneditable parameters (links, lists, radios, etc.). Therefore, if we did not adopt automatic solutions it is probable that most of the applications they are vulnerable to this type of attacks. Is it not better than frameworks like Wicket solves certain vulnerabilities to us? CryptedUrlWebRequestCodingStrategy... (William Hoover) This strategy as I know is only applied to urls and not to data forms! But I would like that this point was confirmed by a wicket's developers group. public wiki document... (Martin Makundi) First, I would like to know Wickets' features better and they confirmed me if my questions are correct or no... CONFIDENTIALITY It is not possible out of the box afaik but you could either try to subclass Form or write a filter to intercept and replace form values when wicket sends the response and reverse it when the user submits the form. right, I know that I could do it as HDIV does but I like to know if this feature is provided by Wicket framework, I think that it would be very interesting...what do you think about an automatic solution? Excuse me, I'm french and my english is poorer than I would like. Thanks again four your time! I consider that it is a subject that to all interests to us. Arthur. 2008/2/29, Maurice Marrink [EMAIL PROTECTED]: While pages ids have been correlatives, hacker could always construct a valid url to generate a CSRF attack. Let's see a typical example... Consider a bank web site that allows its users to make account transfers. Once a user has logged in and received an authentication cookie, he needs only to request the URL http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::inputForm4_hf_0transferTo=123amount=1000in order to transfer $1000 to account number 123. If an attacker can trick an already-authenticated user into visiting a malicious page that contains an image link like img src= http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::inputForm4_hf_0transferTo=456amount=1000/ , the user's (victim) browser will automatically request that URL, thus making an account transfer without the user's knowledge or consent. Once the victim makes a valid transfer, the transfer's values are in session, so if the attacker generates many images like commented with different values in interface parameter, he would obtain the objective. So, I think that it is necessary to insert a random value to all requests or generate confidential values for all parameters of a request. What do you think? In this case i think the problem would be the app allowing the transfer without requiring additional authentication and not the framework. Fortunately my online bank does require this and thus no amount of links will ever get past the response of authenticate yourself again. This second authentication usually also contains an encrypted version of the amount that should be transfered. 3. CONFIDENTIALITY: I have seen in forms that radio's options an checkbox's values have no confidential values. Could I put automatically all form values confidentiality in Wicket? I don't want that the attacker sees the original values... Is it possible to apply encrypt strategy to forms? It is not possible out of the box afaik but you could either try to subclass Form or write a filter to intercept and replace form values when wicket sends the response and reverse it when the user submits the form. Maurice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
Hi Arthur, While I can't address all of your concerns, I can address a couple. 1. ESCAPING CHARACTERS: I have read in wicket's mailing list that all wicket components escape values. I have done some tests in wicket-examples application distributed in wicket-1.3.1 release and I have modified, in FormInput.properties file, value of key string with this value scriptalert(xss);/script and I see that this script is executed when I load the page with this message key. So, i don't know if all components escape or not values! I'm not familiar with that example, but from my experience, Wicket components escape HTML unless specifically told otherwise. 2. INTEGRITY: Actualy in my bank application we have hidden fileds in our forms to store critical values and I want to know if wicket by default guarantees data integrity or not. I want to guarantee integrity like HDIV does in Struts and Spring MVC apps... is it possible in wicket? Hidden fields are not required with Wicket applications since the data that was formerly stored in hidden fields in other frameworks is maintained in Wicket's model classes. I had a hard time understanding this at first as well, but the essential element is you don't need hidden fields in Wicket applications. I have read in wicket's documentation that it is possible to encrypt urls ensuring integrity ( http://cwiki.apache.org/WICKET/url-coding-strategies.html) but is it possible to apply this strategy to forms? Or data tampering attacks are possible in wicket forms with hidden fields? So, can Wicket ensure data integrity? 3. CONFIDENTIALITY: After read HDIV's reference document I have see that in our application data base identifiers are presented in html pages as combo values ids and now we want to hide these values. I thought about implementing a common renderer for all my wicket components to be responsible for returning a value relative to the original values, but I do not like it because it is probably that my programmers don't use it in all cases and it is a risk that I don't want to run. Is there any wicket functionality to return confidential data, by default, for form's values? I do not want to rely on developers... This goes alone with my earlier response. Unless you explicitly present them to the user, there is no need to expose internal identifiers. 4. RANDOM TOKENS: I want to avoid CSRF attacks and I have read ( http://www.owasp.org/index.php/Top_10_2007-A5) that a possible solution is to add random tokens to all requests. Is it possible to add a random parameter to requests automatically in wicket? Perhaps someone else can chime in here, but I don't think this is a problem with Wicket applications. I need your help to answer this questions, pls! thanks! [1] http://www.nabble.com/Shout-more-about-security-advantages-of-Wicket--to14800934.html#a14816425 [2] http://www.hdiv.org/docs/hdiv-reference.pdf -- Nick Heudecker Professional Wicket Training Consulting http://www.systemmobile.com Eventful - Intelligent Event Management http://www.eventfulhq.com
Re: Security Features offered by Wicket
On Thu, Feb 28, 2008 at 7:53 AM, Nick Heudecker [EMAIL PROTECTED] wrote: Hi Arthur, While I can't address all of your concerns, I can address a couple. 1. ESCAPING CHARACTERS: I have read in wicket's mailing list that all wicket components escape values. I have done some tests in wicket-examples application distributed in wicket-1.3.1 release and I have modified, in FormInput.properties file, value of key string with this value scriptalert(xss);/script and I see that this script is executed when I load the page with this message key. So, i don't know if all components escape or not values! I'm not familiar with that example, but from my experience, Wicket components escape HTML unless specifically told otherwise. I dont think we escape certain values that come from .properties files. These files are maintained by programmers and are never written to by users, so whats the point of escaping them? 2. INTEGRITY: Actualy in my bank application we have hidden fileds in our forms to store critical values and I want to know if wicket by default guarantees data integrity or not. I want to guarantee integrity like HDIV does in Struts and Spring MVC apps... is it possible in wicket? Hidden fields are not required with Wicket applications since the data that was formerly stored in hidden fields in other frameworks is maintained in Wicket's model classes. I had a hard time understanding this at first as well, but the essential element is you don't need hidden fields in Wicket applications. right. to put it simpler - what used to be in hidden fields is now stored in session I have read in wicket's documentation that it is possible to encrypt urls ensuring integrity ( http://cwiki.apache.org/WICKET/url-coding-strategies.html) but is it possible to apply this strategy to forms? Or data tampering attacks are possible in wicket forms with hidden fields? So, can Wicket ensure data integrity? Since hidden values are stored in session instead - yes. Users cannot temper with things you do not explicitly expose. 4. RANDOM TOKENS: I want to avoid CSRF attacks and I have read ( http://www.owasp.org/index.php/Top_10_2007-A5) that a possible solution is to add random tokens to all requests. Is it possible to add a random parameter to requests automatically in wicket? Wicket urls are already session-relative and somewhat random (depend on the path you take through the application), so I am not sure if anything more needs to be done... -igor Perhaps someone else can chime in here, but I don't think this is a problem with Wicket applications. I need your help to answer this questions, pls! thanks! [1] http://www.nabble.com/Shout-more-about-security-advantages-of-Wicket--to14800934.html#a14816425 [2] http://www.hdiv.org/docs/hdiv-reference.pdf -- Nick Heudecker Professional Wicket Training Consulting http://www.systemmobile.com Eventful - Intelligent Event Management http://www.eventfulhq.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Features offered by Wicket
First, thank you for your quick reply! 1. ESCAPING CHARACTERS: I have read in wicket's mailing list that all wicket components escape values. I have done some tests in wicket-examples application distributed in wicket-1.3.1 release and I have modified, in FormInput.properties file, value of key string with this value scriptalert(xss);/script and I see that this script is executed when I load the page with this message key. So, i don't know if all components escape or not values! I'm not familiar with that example, but from my experience, Wicket components escape HTML unless specifically told otherwise. I dont think we escape certain values that come from .properties files. These files are maintained by programmers and are never written to by users, so whats the point of escaping them? right. I was thinking that wicket:message component could be abble to read data from Wicket's models. I confused with Struts' tag bean:message. I have seen that components like FeedbackPanel escapes messages so XSS attacks like commented here (http://shh.thathost.com/secadv/spring-form-xss/) are resolved in Wicket! 2. INTEGRITY: Actualy in my bank application we have hidden fileds in our forms to store critical values and I want to know if wicket by default guarantees data integrity or not. I want to guarantee integrity like HDIV does in Struts and Spring MVC apps... is it possible in wicket? Hidden fields are not required with Wicket applications since the data that was formerly stored in hidden fields in other frameworks is maintained in Wicket's model classes. I had a hard time understanding this at first as well, but the essential element is you don't need hidden fields in Wicket applications. right. to put it simpler - what used to be in hidden fields is now stored in session I have read in wicket's documentation that it is possible to encrypt urls ensuring integrity ( http://cwiki.apache.org/WICKET/url-coding-strategies.html) but is it possible to apply this strategy to forms? Or data tampering attacks are possible in wicket forms with hidden fields? So, can Wicket ensure data integrity? Since hidden values are stored in session instead - yes. Users cannot temper with things you do not explicitly expose. right. Wicket's models will have these hiddens' information so is not possible to tamper these data values. ok! 4. RANDOM TOKENS: I want to avoid CSRF attacks and I have read ( http://www.owasp.org/index.php/Top_10_2007-A5) that a possible solution is to add random tokens to all requests. Is it possible to add a random parameter to requests automatically in wicket? Wicket urls are already session-relative and somewhat random (depend on the path you take through the application), so I am not sure if anything more needs to be done... To prevent CSRF attacks you must to add some random values to all requests because session-relative values could be hit it, you have to think that wicket urls allways have the same format (?wicket:interface=:0:goGerman::ILinkListener::) and it is simple to construct requests for CSRF attacks. Arthur.
Re: Security Features offered by Wicket
On Thu, Feb 28, 2008 at 9:43 AM, Arthur Ahiceh [EMAIL PROTECTED] wrote: Wicket urls are already session-relative and somewhat random (depend on the path you take through the application), so I am not sure if anything more needs to be done... To prevent CSRF attacks you must to add some random values to all requests because session-relative values could be hit it, you have to think that wicket urls allways have the same format (?wicket:interface=:0:goGerman::ILinkListener::) and it is simple to construct requests for CSRF attacks. first you would have to hijack the session... then in order for you to hit ?wicket:interface=:0:goGerman::ILinkListener:: a few things have to be true: a) attacker has to hijack the session b) page id (the 0 part of the url) has to match with the link path in the user's session. this depends on the order user has visited the pages c) user had to actually have visited the page previously even if thats not enough it is trivial to write your own coding strategy that appends the random token and stores its mirror in session -igor Arthur. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
