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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)?
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
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
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]
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
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
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
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
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
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
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
[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
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
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
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
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
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
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
32 matches
Mail list logo
