Hi Oscar,
>>> the solution is to always use User object in action and call his methods on
>>> him,
>
> What's User object? is some class provided by Struts 2?
It's the object representing the actual user that sends a request to
your application,
and there is no such class provided by struts2 - it will be your own User class.
To make it simple let's assume that if some user is logged in to your
application
there is an object of User class in session representing this someone
and his account.
Then if he wants to remove some contact, he needs to have right to do it,
simplest solution is by possesion - if he has some particular contact,
he can remove it,
this can be realised as a list of Contact objects in User class - a
field contactList in User or other special method in User.
So calling user.contactList.remove(contact) where contact is fetched
from DB by id for example,
will remove only a contact that belongs to this particular user from his list
and any attempt of request parameters forgery wont succeed
because it's simply impossible to remove someone elses contact.
It's like in real life, if You don't have access to my wallet (it's in
my pocket),
You can't use cash from it.
It's not the mistake that only beginners does,
everybody does it.
And the way to minimize it, can be code reviews or pair programming.
Best greetings,
Paweł Wielgus.
> 2010/6/3 Stephane Cosmeur <cosm...@gmail.com>:
>> Ok thank you, i understood.
>>
>> I understood as well all my conception is totally unsecured. I began this
>> project without ever developped any struts 2 or web aplication before.
>>
>> I guess it's the kind of mistake a beginner does :/
>>
>> If i want to make it right, i assume i have to review all the code and every
>> services.
>>
>> 2010/6/3 Paweł Wielgus <poulw...@gmail.com>
>>
>>> Hi all,
>>> just like the Dale already told You there is no way to prevent it by a
>>> tool or a plugin,
>>> because the problem lies elsewhere, any user always can gues wright
>>> parameters to perform an attack,
>>> the solution is to always use User object in action and call his methods on
>>> him,
>>> for example:
>>>
>>> user.contactList.remove(contact)
>>>
>>> that way any user will be able to only remove his contact, contrary it
>>> would be:
>>>
>>> globalContractList.removeById(contractId)
>>>
>>> which is very unsafe and unsecure.
>>>
>>> But this is only a programing practise and not a tool or a plugin that
>>> can be used ad-hoc.
>>> Also if You will use such a practise You will find that You don't need
>>> to care about hiding parameters,
>>> because it is not important at all.
>>>
>>> Best greetings,
>>> Paweł Wielgus.
>>>
>>>
>>> 2010/6/3 Stephane Cosmeur <cosm...@gmail.com>:
>>> > Thank you for your answers. they are useful but not quite appropriate
>>> with
>>> > my problem.
>>> > I dont want my application be that secure. So i dont think i need SSL or
>>> > HTTPS event if it could be good.
>>> >
>>> > I am going to give a concrete example :
>>> > A user can have any contacts, he can delete it. His contacts are listed
>>> in a
>>> > html table and each row has a delete link which call an action.
>>> > Then i construct my url like this :
>>> > <s:url id="deleteALaCarteEntry" action="DeleteALaCarteEntry">
>>> > <s:param name="id" value="id"/>
>>> > </s:url>
>>> > <td><s:a href="%{deleteALaCarteEntry}">Delete</s:a></td>
>>> >
>>> > In that case, how can i hide my id parameters ?
>>> >
>>> > If it's not posible i guess my only solution is to check in the server
>>> side
>>> > if the contact is present in the list of the user.
>>> >
>>> > In that case i would like to find a generic solution to apply the test,
>>> not
>>> > only for contact, but for company, supplier, orders, ..., as well.
>>> >
>>> > Regards
>>> >
>>> > 2010/6/3 Vishnu Vyasan Nelliparmbil <vis...@mun.gov.bh>
>>> >
>>> >> Hi,
>>> >>
>>> >> The advantage of the post parameter is that it can't be viewed by the
>>> user
>>> >> in the url. But a attacker can still edit the header and attack the
>>> >> application without much trouble.
>>> >>
>>> >> To improve security you can validate the parameter properly where you
>>> >> receive the parameter. For example number only or does not contains
>>> invalid
>>> >> characters in string for eg, <,>,_ ,/, etc like that.
>>> >>
>>> >> Another good thing will be to implement SSL.
>>> >>
>>> >> Now you can also go to OWASP and download the different security
>>> scanners
>>> >> and scan for the security loop holes.
>>> >>
>>> >> Best Regards
>>> >> Vishnu NV
>>> >>
>>> >> -----Original Message-----
>>> >> From: Rahul Mohan [mailto:rahul.mo...@tcs.com]
>>> >> Sent: Thursday, June 03, 2010 8:44 AM
>>> >> To: Struts Users Mailing List
>>> >> Subject: Re: Encrypting parameters
>>> >>
>>> >> Hi,
>>> >>
>>> >> I don't think its a good idea to expose the URLs to the users in a
>>> secure
>>> >> application. Avoid GET requests and stick to POST. Also, sticking to
>>> >> request forwarding instead of redirects will keep the URL fixed on the
>>> >> browser's address bar. You might have some issues with back button
>>> because
>>> >> of this, but in most business applications this is OK since going back
>>> one
>>> >> step in some process is anyways not allowed. Combined with HTTPS this
>>> will
>>> >> give you good enough protection against eavesdropping. But, to protect
>>> >> data access, you would still need to enforce some access control on the
>>> >> data based on the user credentials.
>>> >>
>>> >> cheers,
>>> >> Rahul Mohan
>>> >>
>>> >>
>>> >>
>>> >> From:
>>> >> Stephane Cosmeur <cosm...@gmail.com>
>>> >> To:
>>> >> Struts Users Mailing List <user@struts.apache.org>
>>> >> Date:
>>> >> 03-06-2010 08:53
>>> >> Subject:
>>> >> Encrypting parameters
>>> >>
>>> >>
>>> >>
>>> >> Hello,
>>> >>
>>> >> I would like to improve the security of my web application. My problem
>>> is
>>> >> I
>>> >> would like to encrypt the visible parameters in the URL to prevent user
>>> to
>>> >> change it to access data he should not see.
>>> >> At start i thought the simple attribute encode of s:url will work for
>>> what
>>> >> i
>>> >> need, but it's not the case. Then i don't believe a such useful feature
>>> is
>>> >> implemented in struts 2.
>>> >>
>>> >> So what is the best solution to perform it ?
>>> >>
>>> >> I was thinking to an interceptor which unencrypt each request for each
>>> >> action and a java function which encry the url in each jsp, but i'm not
>>> >> sure
>>> >> it's the good way to do it.
>>> >>
>>> >> Any help would be appreciated !
>>> >>
>>> >> Regards
>>> >>
>>> >> --
>>> >> Stéphane Cosmeur
>>> >>
>>> >>
>>> >> =====-----=====-----=====
>>> >> Notice: The information contained in this e-mail
>>> >> message and/or attachments to it may contain
>>> >> confidential or privileged information. If you are
>>> >> not the intended recipient, any dissemination, use,
>>> >> review, distribution, printing or copying of the
>>> >> information contained in this e-mail message
>>> >> and/or attachments to it are strictly prohibited. If
>>> >> you have received this communication in error,
>>> >> please notify us by reply e-mail or telephone and
>>> >> immediately and permanently delete the message
>>> >> and any attachments. Thank you
>>> >>
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>>> >> For additional commands, e-mail: user-h...@struts.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Stéphane Cosmeur
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>>> For additional commands, e-mail: user-h...@struts.apache.org
>>>
>>>
>>
>>
>> --
>> Stéphane Cosmeur
>>
>
>
>
> --
> Oscar Calderón
> SCJP 6
> http://www.javahowto.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
