<div dir="ltr">Hey Tim,<div><br></div>Did you see: <a href="http://www.seaside.st/about/security">http://www.seaside.st/about/security</a><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><h1 style="margin-bottom:15px;color:rgb(1,89,141);font-weight:normal;font-size:21px;font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;text-align:left;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Protection against CSRF</h1></div><div><p style="margin-bottom:15px;color:rgb(0,40,66);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:12px;text-align:left;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Seaside automatically generats a unique id that is tied to the session for each action. This id acts like a token.</p></div><div><p style="margin-bottom:15px;color:rgb(0,40,66);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:12px;text-align:left;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Read more about CSRF<span> </span><a title="http://www.owasp.org/index.php/Cross-Site_Request_Forgery" class="external" href="http://www.owasp.org/index.php/Cross-Site_Request_Forgery" style="color:rgb(0,138,255)">at OWASP</a>.</p></div></blockquote><div>CSRF is basically being able to execute a task from a different program impersonating a user that is already logged into a different site. </div><div><br></div><div>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=<a href="https://imloggedin.com?my">https://imloggedin.com?my</a> 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.</div><div><br></div><div>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.</div><div><br></div><div>All the best,</div><div><br></div><div>Ron Teitelbaum</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 21, 2018 at 5:30 PM, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> On 21-08-2018, at 1:07 PM, Esteban A. Maringolo <<a href="mailto:emaringolo@gmail.com">emaringolo@gmail.com</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> On 21/08/2018 16:44, Max Leske wrote:<br>
> <br>
</span>[snip useful stuff]<br>
<span class=""><br>
> I'm working with Seaside in VW, let me know if you need any further help<br>
> with that. Seaside in VW isn't as updated as in other platforms.<br>
<br>
</span>Thanks; what would be really useful to me (and I feel it would make a good explanatory page for the <a href="http://seaside.st" rel="noreferrer" target="_blank">seaside.st</a> 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.<br>
<br>
With much hand-waving I guess we might be able to say something like -<br>
<br>
A buttonwidgetclass has created html that shows a button on your page. clicking on the button sends a URL like this {<a href="http://pighrpghrgrud.eu/dsifjjrgirjr/wibble?soopasekritkey" rel="noreferrer" target="_blank">pighrpghrgrud.eu/<wbr>dsifjjrgirjr/wibble?<wbr>soopasekritkey</a>} 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). <br>
<br>
A diagram would probably help a lot to make a useful page.<br>
<span class=""><br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
</span>"!" The strange little noise you make when you can't scream...<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.<wbr>squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" rel="noreferrer" target="_blank">http://lists.squeakfoundation.<wbr>org/mailman/listinfo/seaside-<wbr>dev</a><br>
</div></div></blockquote></div><br></div></div>