[Seaside-dev] Seaside and CSRF attacks

[Ron Teitelbaum]

Hey Tim,

Did you see: http://www.seaside.st/about/security

Protection against CSRF

Seaside automatically generats a unique id that is tied to the session for
each action. This id acts like a token.

Read more about CSRF at OWASP
<http://www.owasp.org/index.php/Cross-Site_Request_Forgery>.

CSRF is basically being able to execute a task from a different program
impersonating a user that is already logged into a different site.

The attacker knows the user is logged into some program.  They know how to
get that program to do something bad.  They trick the users into executing
some code that does something bad on the other program that is running.
Click here to get free $50 gift card! href=https://imloggedin.com?my really
bad code goes here.  This works because my really bad code is going to be
sent to the location the user is logged into which means it will have
access to cookies and will think this is a valid request for a user that is
logged in.  Validating the cookies is not sufficient to ensure the request
came from your application.

You can prevent this from happening if you have something on the current
page in the browser that is unique, you then check that token to make sure
the request is coming from your program and not from some other program
running on your computer (my really bad code).  The server needs to
validate the data is coming from the browser (Header, URL, Field) matches
what was set by your application (for each page) before executing any
tasks.  The attacker doesn't have access to that token so trying to execute
some task should fail.

All the best,

Ron Teitelbaum

On Tue, Aug 21, 2018 at 5:30 PM, tim Rowledge <tim at rowledge.org> wrote:

>
>
> > On 21-08-2018, at 1:07 PM, Esteban A. Maringolo <emaringolo at gmail.com>
> wrote:
> >
> > Hi,
> >
> > On 21/08/2018 16:44, Max Leske wrote:
> >
> [snip useful stuff]
>
> > I'm working with Seaside in VW, let me know if you need any further help
> > with that. Seaside in VW isn't as updated as in other platforms.
>
> Thanks; what would be really useful to me (and I feel it would make a good
> explanatory page for the seaside.st site as well) would be pointers to
> the right basic class(es) and methods to provide a simple example of the
> sequence of events that we get.
>
> With much hand-waving I guess we might be able to say something like -
>
> A buttonwidgetclass has created html that shows a button on your page.
> clicking on the button sends a URL like this {pighrpghrgrud.eu/
> dsifjjrgirjr/wibble?soopasekritkey} to the server and it gets routed to
> thingummyclass by the dispatch code in whotzitclass>>blurgmethod.  The
> soopasekritkey included in the URL is checked against the key(s) for
> classA/classB/whatever which ensures that only requests made by pages
> generated by this server in this session during this phase of the moon
> (etc) are handled (what happens to other ones? Can we make things at the
> bad guys' end blow up? I wish).
>
> A diagram would probably help a lot to make a useful page.
>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> "!" The strange little noise you make when you can't scream...
>
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20180821/0416da6e/attachment-0001.html>