Am Donnerstag, 3. Juli 2014 15:30:09 UTC+2 schrieb Bert JW Regeer:
Hello Bert,
If your GET requests are not idempotent (i.e. They will always return the
exact same response, and don’t modify any state) there is no cross site
request forgery that can happen.
I think you mean if the GET
On Tue, Jul 8, 2014 at 2:27 AM, Torsten Irländer tors...@irlaender.de
wrote:
I think the general conclusion that GET request are not vulnerable is only
true under certain circumstances. And I as a implementer do not want to
think about every GET request if it might get a threat in some
Am Dienstag, 8. Juli 2014 15:23:47 UTC+2 schrieb Chris Rossi:
On Tue, Jul 8, 2014 at 2:27 AM, Torsten Irländer tor...@irlaender.de
javascript: wrote:
I think the general conclusion that GET request are not vulnerable is
only true under certain circumstances. And I as a implementer do
If you have expensive calculations, you can just lock them down onto a POST
page under HTTPS with a CSRF token. That will eliminate most issues.
You can also segment expensive routes to run in their own application
instance , and throttle users (based on session, ip, etc ) so that general
Am Freitag, 4. Juli 2014 11:05:49 UTC+2 schrieb cornelius:
Am 04.07.2014 10:21, schrieb Torsten Irländer:
As I did not wanted to keep track on synchronizer tokens on the server
side, the original web application read the session cookie from the browser
and added the this token as
Am Donnerstag, 3. Juli 2014 10:48:24 UTC+2 schrieb cornelius:
Am 03.07.2014 08:43, schrieb Torsten Irländer:
Am Donnerstag, 3. Juli 2014 00:32:15 UTC+2 schrieb cornelius:
Am 02.07.2014 23:01, schrieb Torsten Irländer:
Am Mittwoch, 2. Juli 2014 17:00:02 UTC+2 schrieb Bert JW
Am 04.07.2014 10:21, schrieb Torsten Irländer:
As I did not wanted to keep track on synchronizer tokens on the
server side, the original web application read the session cookie
from the browser and added the this token as parameter for the
further requests. Thus the server
Am Donnerstag, 3. Juli 2014 00:32:15 UTC+2 schrieb cornelius:
Am 02.07.2014 23:01, schrieb Torsten Irländer:
Am Mittwoch, 2. Juli 2014 17:00:02 UTC+2 schrieb Bert JW Regeer:
On Jul 2, 2014, at 7:29, Torsten Irländer tor...@irlaender.de wrote:
I guess that most people only talk
On Jul 3, 2014, at 00:43 , Torsten Irländer tors...@irlaender.de wrote:
Am Donnerstag, 3. Juli 2014 00:32:15 UTC+2 schrieb cornelius:
Am 02.07.2014 23:01, schrieb Torsten Irländer:
Am Mittwoch, 2. Juli 2014 17:00:02 UTC+2 schrieb Bert JW Regeer:
On Jul 2, 2014, at 7:29, Torsten
Am Donnerstag, 3. Juli 2014 01:15:41 UTC+2 schrieb Randall Leeds:
On Wed, Jul 2, 2014 at 2:01 PM, Torsten Irländer tor...@irlaender.de
javascript: wrote:
Am Mittwoch, 2. Juli 2014 17:00:02 UTC+2 schrieb Bert JW Regeer:
On Jul 2, 2014, at 7:29, Torsten Irländer tor...@irlaender.de
On Jul 3, 2014, at 00:57 , Torsten Irländer tors...@irlaender.de wrote:
Hmm... I was thinking of a simple HTML mail with some JS code which gets
executed in Alice browser when opening the Mail. Is this problematic to start
because the webmailer hopefully escapes and strips such malicious
Am Donnerstag, 3. Juli 2014 09:03:32 UTC+2 schrieb Bert JW Regeer:
On Jul 3, 2014, at 00:57 , Torsten Irländer tor...@irlaender.de
javascript: wrote:
Hmm... I was thinking of a simple HTML mail with some JS code which gets
executed in Alice browser when opening the Mail. Is this
Am 03.07.2014 08:43, schrieb Torsten Irländer:
Am Donnerstag, 3. Juli 2014 00:32:15 UTC+2 schrieb cornelius:
Am 02.07.2014 23:01, schrieb Torsten Irländer:
Am Mittwoch, 2. Juli 2014 17:00:02 UTC+2 schrieb Bert JW Regeer:
On Jul 2, 2014, at 7:29, Torsten Irländer
On Jul 3, 2014, at 02:48 , Cornelius Kölbel cornelius.koel...@netknights.it
wrote:
Am 03.07.2014 08:43, schrieb Torsten Irländer:
Am Donnerstag, 3. Juli 2014 00:32:15 UTC+2 schrieb cornelius:
Am 02.07.2014 23:01, schrieb Torsten Irländer:
Am Mittwoch, 2. Juli 2014 17:00:02 UTC+2
Hi,
I need to protect some of my GET requests in the application against CSRF
attacks.
AFAIKS many (if not all) resources writing about CSRF protection say that
this is usually only need to be done for POST requests which will change
data or the state of the application. However I feel the
On Jul 2, 2014, at 7:29, Torsten Irländer tors...@irlaender.de wrote:
Hi,
I need to protect some of my GET requests in the application against CSRF
attacks.
AFAIKS many (if not all) resources writing about CSRF protection say that
this is usually only need to be done for POST requests
Am Mittwoch, 2. Juli 2014 17:00:02 UTC+2 schrieb Bert JW Regeer:
On Jul 2, 2014, at 7:29, Torsten Irländer tor...@irlaender.de
javascript: wrote:
I need to protect some of my GET requests in the application against
CSRF attacks.
AFAIKS many (if not all) resources writing about CSRF
Am 02.07.2014 23:01, schrieb Torsten Irländer:
Am Mittwoch, 2. Juli 2014 17:00:02 UTC+2 schrieb Bert JW Regeer:
On Jul 2, 2014, at 7:29, Torsten Irländer tor...@irlaender.de
javascript: wrote:
I need to protect some of my GET requests in the application
against CSRF
On Wed, Jul 2, 2014 at 2:01 PM, Torsten Irländer tors...@irlaender.de
wrote:
Am Mittwoch, 2. Juli 2014 17:00:02 UTC+2 schrieb Bert JW Regeer:
On Jul 2, 2014, at 7:29, Torsten Irländer tor...@irlaender.de wrote:
I need to protect some of my GET requests in the application against
CSRF
On Jul 2, 2014, at 15:01 , Torsten Irländer tors...@irlaender.de wrote:
Am Mittwoch, 2. Juli 2014 17:00:02 UTC+2 schrieb Bert JW Regeer:
On Jul 2, 2014, at 7:29, Torsten Irländer tor...@irlaender.de wrote:
I need to protect some of my GET requests in the application against CSRF
20 matches
Mail list logo
