Ajax Request Security

[Douglas Ferguson <do...@douglasferguson.us>]

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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Ajax Request Security

[Jeremy Thomerson <je...@wickettraining.com>]

I received the following question in my personal email regarding this
thread.  I decided to respond here.

First, let me add this:
Remember that there is NO additional security given to you by POST as
it relates to GET.  Both are insecure if you pass the action (ie
delete), the key (ie entity ID) in the request and you perform the
request without authentication.


> Hey Jeremy, I saw your post on users-wicket.apache.org
> regarding Ajax security. One of your comments was regarding
> ajax state-changing calls and how they should be POSTs
> (which I absolutely agree with). I've noticed though that some
> of the Wicket Ajax classes use GETs for such operations.
> Do you think it's worth raising a bug or change request
> regarding this? Regards, Brendan

No - I don't think this is a bug.  I think that it was actually a
misunderstanding of what I said.  The point of my response was that
you need to validate the request no matter what kind it is - link
clicked - form submit - bookmarkable page requested - ajax request.
For security, you should not expose edit / delete actions via
bookmarkable pages (like you unfortunately must do in most PHP sites,
etc, where you pass the ID to a delete page...)  Instead, with Wicket,
the model is held in the session and referred to by the link - which
has NO data that could be fiddled with to modify the results.

Now, what I was saying when I said "typically your normal Ajax
behavior should not be deleting / editing unless it is a form post" is
that typically you are not going to have an AjaxUpdatingBehavior or an
ajax link that edits / deletes data (disclaimer: yes, there are
reasons to have an ajax delete link).  What I meant was not HTTP POST
- I just meant form submission - which in ajax actually happens via
GET.

--
Jeremy Thomerson
http://www.wickettraining.com




On Fri, May 8, 2009 at 12:14 AM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> 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
> <do...@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:jeremy@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
>> <do...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Ajax Request Security

[Jeremy Thomerson <je...@wickettraining.com>]

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
<do...@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:jeremy@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
> <do...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Ajax Request Security

[Douglas Ferguson <do...@douglasferguson.us>]

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:jeremy@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
<do...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Ajax Request Security

[Jeremy Thomerson <je...@wickettraining.com>]

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
<do...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org