If you have someone's session ID (within the lifetime of the session)
you can break into any application - java, php, etc. That's just how
it is. But if you have that level of information on them while the
session is still live, then you are either already pulling off a man
in the middle attack, sniffing their packets, or have compromised
their machine or the server.
It's not obfuscation - the links are relative to the path that you
took through the application. When your session expires, they can't
be used any more. But if you sent the link to someone else, in their
session, the link wouldn't even work unless they took a path so
similar to yours that their page map was the same (i.e. the fifth page
in the page map was the edit users page, and they could click the
sixth "editFoo" link on that page).
Just look at the URLs that are generated when you add(new Link("foo")
{ public void onClick() {}}; - Now copy those to another computer and
try them - no bueno. Now, dump your cookies and get a new session -
try the link - no bueno.
And then, you should have action-level security anyway - so it should
protect from unauthorized users completing actions that they should
not be. And typically your normal Ajax behavior should not be
deleting / editing unless it is a form post (which you need to verify
ajax or not) or a link (which again, needs to be subject to your
role-based security).
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, May 7, 2009 at 6:29 PM, Douglas Ferguson
<doug...@douglasferguson.us> wrote:
> How is this session relative security implemented?
>
> Is this really just security through obfuscation?
>
> I.E. If you know the session id could you make valid Ajax Requests?
>
> Douglas
>
> -----Original Message-----
> From: Jeremy Thomerson [mailto:jer...@wickettraining.com]
> Sent: Thursday, May 07, 2009 5:26 PM
> To: users@wicket.apache.org
> Subject: Re: Ajax Request Security
>
> Ajax requests, like non-bookmarkable links within Wicket, are
> inherently secure through the fact that they are session-relative.
> That is, unless you specifically try to make it less secure, it is
> secure by default in that I can not just twiddle with an ID field in
> the request URL to edit an entity with a different ID.
>
> However, many ajax requests may submit form data. And, of course, all
> such data DOES need to be checked - which should be accomplished
> automatically if you have added validation to your form fields.
> Again, the URL is session-relative, and can't be emailed to someone
> else for them to use or fiddled with to create an unexpected request.
> But the data itself that is submitted must always be verified.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
>
> On Thu, May 7, 2009 at 5:22 PM, Douglas Ferguson
> <doug...@douglasferguson.us> wrote:
>> It just dawned on me that most users will protect their url parameters to
>> make sure that end users can't fiddle with parameters and see inappropriate
>> data, however, is it conceivable to issue ajax requests to get an app to do
>> something it shouldn't?
>>
>> If so, any tips on how to build a request that would cause an ajax response?
>> Is important to protect all ajax calls?
>>
>> Dougals
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
