#disabled: + #callback:
Locked
 
|
Hi -
If in a Seaside form (3.2.1 but not sure it matters) you have an input with a callback (& e.g #onChange: handler) and set its state to 'disabled' a nefarious actor can remove the 'disabled' state from the form element in the browser and then trigger the seaside callback on the form submit. How do people usually handle this? Right now in critical places I have two sets of form-input-drawing code e.g. disable ifTrue:[ html textInput disabled: true; value: self name ] ifFalse:[ html textInput onChange: html jQuery ajax serializeThis; on: #name of: self]. But in other places I am neglectful. It seems to me that if I moved the #disabled: send down to be the last thing sent to the input then I could modify the #disabled: method to wipe out the callback and any javascript handlers attached to the input, preventing the unlikely attack I mention above. Does that make sense? Thanks for any thoughts you care to share Paul _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
either https and or a cookie or include a hash of what is serialised or what you expect a an gruement. in each case you detect a change. I have used cookies with encrypted info along with hashes along with random data so with each ajax call I verify. setting it up takes work. so you do not have to litter code with complicated crypto. It has passed some pretty stringent security requirements. be sure you trust the crypto libraries and you should be fine. The only actor you can not defeat is someone that has the money and access to a d-wave (Quantum computing) Kind Regards, Sean Glazier On Mon, Feb 27, 2017 at 11:35 AM, PAUL DEBRUICKER <[hidden email]> wrote: Hi - _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: #disabled: + #callback:
|
|
In reply to this post by Paul DeBruicker
Hi Paul,
> On 27 Feb 2017, at 17:35, PAUL DEBRUICKER <[hidden email]> wrote: > > Hi - > > > If in a Seaside form (3.2.1 but not sure it matters) you have an input with a callback (& e.g #onChange: handler) and set its state to 'disabled' a nefarious actor can remove the 'disabled' state from the form element in the browser and then trigger the seaside callback on the form submit. Well, I had a problem very close to that, that actually cost me real money ! In a shopping cart I used <A> tags that rendered as buttons (Bootstrap), disabling them when the user was not supposed to continue (as in not order for free from a far away country ;-). The continue button looked disabled, but it wasn't. So I ended up doing renderContinueOn: html | anchor | html space. (anchor := html anchor) class: 'btn btn-primary'; disabled: self canContinue not. "since <A> cannot really be disabled, do not add a callback !" self canContinue ifTrue: [ anchor callback: [ ... ] ]. anchor with: [ .. ] It was of course my own fault, but it would be nice if calling disabled: false on a Seaside component had the effect of disabling callbacks as well. Sven > How do people usually handle this? > > > > Right now in critical places I have two sets of form-input-drawing code e.g. > > disable > ifTrue:[ html textInput > disabled: true; > value: self name ] > ifFalse:[ html textInput > onChange: html jQuery ajax serializeThis; > on: #name of: self]. > > But in other places I am neglectful. > > > It seems to me that if I moved the #disabled: send down to be the last thing sent to the input then I could modify the #disabled: method to wipe out the callback and any javascript handlers attached to the input, preventing the unlikely attack I mention above. > > > Does that make sense? > > > Thanks for any thoughts you care to share > > > Paul > > > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
That works as well and is easier to do. the app I did we had to be much more anal about everything Kind Regards, Sean Glazier On Mon, Feb 27, 2017 at 2:15 PM, Sven Van Caekenberghe <[hidden email]> wrote: Hi Paul, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
NEVER rely on client-side for security or related checks. ALWAYS add server-side checks too. If you want seaside to disable the callbacks on a disabled button, it will need still need to make a server call, which can also be intercepted/hacked. It would be a false sense of security. Of course, it might be handy but do not rely on it. Cheers, Johan
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |