Is CSRF possible with PUT or DELETE methods? Or does the use of PUT or DELETE prevent CSRF?



Is CSRF possible with PUT or DELETE methods?

If CORS is properly setup on a server to only allow a certain origins to access the server,

Is this enough to prevent CSRF attacks?

Does a proper CORS setup prevent CSRF attack?

I have **csrf protection** in spring framework. So in each request I send csrf token in header from ajax call, which is perfectly working.    

    &lt;meta name=&quot;_csrf&quot; content=&quot;${_csrf.token}&quot;/&gt;
    &lt;meta name=&quot;_csrf_header&quot; content=&quot;${_csrf.headerName}&quot;/&gt;
    
    var token = $(&quot;meta[name=&#39;_csrf&#39;]&quot;).attr(&quot;content&quot;);
    var header = $(&quot;meta[name=&#39;_csrf_header&#39;]&quot;).attr(&quot;content&quot;);

**In ajax** 

    beforeSend: function(xhr) {
                    xhr.setRequestHeader(header, token),
                    xhr.setRequestHeader(&quot;username&quot;, &quot;xxxx1&quot;),
                    xhr.setRequestHeader(&quot;password&quot;, &quot;password&quot;)
                }

I haven&#39;t any idea to **generate csrf token and include in header section of Postman Rest Client** ? Would you please help me to send csrf token from Postman Rest Client? 
![enter image description here][1]


  [1]: http://i.stack.imgur.com/f4VMD.png

How do I send spring csrf token from Postman rest client?

I have a web application built on JSF with MySQL as DB. I have already implemented the code to prevent CSRF in my application.

Now since my underlying framework is JSF, I guess I don&#39;t have to handle XSS attack as it is already handled by `UIComponent`. I am not using any JavaScript in any of the view pages. Even if I use do I really need to implement code to prevent XSS attacks?

For DB we are using prepared statements and stored procedures in all DB interactions.

Is there anything else needs to be handled for preventing these 3 common attacks?
I have already been through the [OWASP][1] site and their [cheat sheets][2].

Do I need to take care of any other potential attack vectors?
            


  [1]: http://www.owasp.org/
  [2]: https://www.owasp.org/index.php/Java_Server_Faces

CSRF, XSS and SQL Injection attack prevention in JSF

I&#39;m using curl to test one of my Django forms. The calls I&#39;ve tried (with errors from each, and over multiple lines for readability):

(1):

    curl
    -d &quot;{\&quot;email\&quot;:\&quot;test@test.com\&quot;}&quot;
    --header &quot;X-CSRFToken: [triple checked value from the source code of a page I already loaded from my Django app]&quot;
    --cookie &quot;csrftoken=[same csrf value as above]&quot;
    http://127.0.0.1:8083/registrations/register/

(with http header and `csrftoken` in cookie) results in a 400 error with no data returned.

(2):

    curl
    -d &quot;{a:1}&quot;
    --header &quot;X-CSRFToken:[as above]&quot;
    --cookie &quot;csrftoken=[as above];sessionid=[from header inspection in Chrome]&quot;
    http://127.0.0.1:8083/registrations/register/

(as in (1) but no spaces in header property declaration, and with `sessionid` in cookie too) results in the same 400 error with no data returned.

(3):

    curl
    -d &quot;{a:1}&quot;
    --header &quot;X-CSRFToken:[as above]&quot;
    http://127.0.0.1:8083/registrations/register/

(only http header with `X-CSRFToken`, no cookie) results in error code 403, with message: CSRF cookie not set.

How can I test my form with curl? What factors am I not considering besides cookie values and http headers?

How to use curl with Django, csrf tokens and POST requests

Can the TokenMismatchException be catched using try catch block? Instead of displaying the debug page that shows the &quot;TokenMismatchException in VerifyCsrfToken.php line 46...&quot;, I want it to display the actual page and just display an error message.

I have no problems with the CSRF, I just want it to still display the page instead of the debug page.

To replicate (using firefox):
Steps:

 1. Open page (http://example.com/login)
 2. Clear Cookies (Domain, Path, Session). I am using web developer toolbar plugin here.
 3. Submit form.

Actual Results: &quot;Whoops, looks like something went wrong&quot; page displays.
Expected Results: Still display the login page then pass an error of &quot;Token mismatch&quot; or something.

Notice that when I cleared the cookies, I didn&#39;t refresh the page in order for the token to generate a new key and force it to error out.

UPDATE (ADDED FORM):

            &lt;form class=&quot;form-horizontal&quot; action=&quot;&lt;?php echo route($formActionStoreUrl); ?&gt;&quot; method=&quot;post&quot;&gt;
            &lt;input type=&quot;hidden&quot; name=&quot;_token&quot; value=&quot;&lt;?php echo csrf_token(); ?&gt;&quot; /&gt;
            &lt;div class=&quot;form-group&quot;&gt;
                &lt;label for=&quot;txtCode&quot; class=&quot;col-sm-1 control-label&quot;&gt;Code&lt;/label&gt;
                &lt;div class=&quot;col-sm-11&quot;&gt;
                    &lt;input type=&quot;text&quot; name=&quot;txtCode&quot; id=&quot;txtCode&quot; class=&quot;form-control&quot; placeholder=&quot;Code&quot; /&gt;
                &lt;/div&gt;
            &lt;/div&gt;
            &lt;div class=&quot;form-group&quot;&gt;
                &lt;label for=&quot;txtDesc&quot; class=&quot;col-sm-1 control-label&quot;&gt;Description&lt;/label&gt;
                &lt;div class=&quot;col-sm-11&quot;&gt;
                    &lt;input type=&quot;text&quot; name=&quot;txtDesc&quot; id=&quot;txtDesc&quot; class=&quot;form-control&quot; placeholder=&quot;Description&quot; /&gt;
                &lt;/div&gt;
            &lt;/div&gt;
            &lt;div class=&quot;form-group&quot;&gt;
                &lt;label for=&quot;cbxInactive&quot; class=&quot;col-sm-1 control-label&quot;&gt;Inactive&lt;/label&gt;
                &lt;div class=&quot;col-sm-11&quot;&gt;
                    &lt;div class=&quot;checkbox&quot;&gt;
                        &lt;label&gt;
                            &lt;input type=&quot;checkbox&quot; name=&quot;cbxInactive&quot; id=&quot;cbxInactive&quot; value=&quot;inactive&quot; /&gt;&amp;nbsp;
                            &lt;span class=&quot;check&quot;&gt;&lt;/span&gt;
                        &lt;/label&gt;
                    &lt;/div&gt;
                &lt;/div&gt;
            &lt;/div&gt;
            &lt;div class=&quot;form-group&quot;&gt;
                &lt;div class=&quot;col-sm-12&quot;&gt;
                    &lt;button type=&quot;submit&quot; class=&quot;btn btn-primary pull-right&quot;&gt;&lt;i class=&quot;fa fa-save fa-lg&quot;&gt;&lt;/i&gt; Save&lt;/button&gt;
                &lt;/div&gt;
            &lt;/div&gt;
        &lt;/form&gt;

Nothing really fancy here. Just an ordinary form. Like what I&#39;ve said, the form is WORKING perfectly fine. It is just when I stated the above steps, it errors out due to the TOKEN being expired.  My question is that, should the form behave that way? I mean, when ever I clear cookies and session I need to reload the page too? Is that how CSRF works here?

Laravel catch TokenMismatchException

I have an website where people can place a vote like this:

    http://mysite.com/vote/25

This will place a vote on item 25. I want to only make this available for registered users, and only if they want to do this. Now I know when someone is busy on the website, and someone gives them a link like this:

    http://mysite.com/vote/30

then the vote will be places for him on the item without him wanting to do this.

I have read the [explanation on the OWASP website][1], but i don&#39;t really understand it

Is this an example of CSRF, and how can I prevent this. The best thing i can think off is adding something to the link like a hash. But this will be quite irritating to put something on the end of all the links. Is there no other way of doing this.

Another thing can someone maybe give me some other example of this, because the website seems fairly fugue to me.


  [1]: http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

CSRF (Cross-site request forgery) attack example and prevention in PHP

i&#39;m building a mobile app talking to my symfony2 app via webservices
I can&#39;t find a way to disable csrf protection on a specific controller/action

i want to post registration data to this action and use sf2 form validation. I do not call the form in my mobile app

Can&#39;t change container parameters in action, throw an exception because it is a frozen parameter...

I do not want to disable form protection for whole my application

any clue ?

thanks !


**update: with symfony 2.1.x**

    /**
     * {@inheritdoc}
     */
    public function setDefaultOptions(OptionsResolverInterface $resolver)
    {
        $resolver-&gt;setDefaults(array(
            &#39;csrf_protection&#39;   =&gt; false,
        ));
    }





Disable symfony 2 csrf token protection on ajax submit

I&#39;m using backbone.js and it works great. but the forms I&#39;m creating as a javascript template lacks the rails csrf protection token. How do I add it to templates I&#39;m creating in javascript?

Rails - How to add CSRF Protection to forms created in javascript?

I am sending data from view to controller with AJAXand I got this error:
&gt;WARNING: Can&#39;t verify CSRF token authenticity

I think I have to send this token with data.

Does anyone know how can I do this ?


**Edit: My solution**

I did this by putting the following code inside the AJAX post:

    headers: {
      &#39;X-Transaction&#39;: &#39;POST Example&#39;,
      &#39;X-CSRF-Token&#39;: $(&#39;meta[name=&quot;csrf-token&quot;]&#39;).attr(&#39;content&#39;)
    },



WARNING: Can&#39;t verify CSRF token authenticity rails

I know cookie-based authentication. SSL and HttpOnly flags can be applied to protect cookie-based authentication from MITM and XSS. However, more special measures will be needed to apply in order to protect it from CSRF. They are just a bit complicated. ([reference][1])

Recently, I discover that JSON Web Token (JWT) is quite hot as a solution for authentication. I know the stuff about encoding, decoding, and verifying JWT. However, I don&#39;t understand why some websites/tutorials tell that there is no need for CSRF protection if JWT is used. I have read quite a lot and have tried to summarize the problems below. I just want someone to provide a bigger picture of JWT and clarify the concepts I misunderstood about JWT.

1. If the JWT is stored in a cookie, I think it is the same as cookie-based authentication except that the server does not need to have sessions to verify the cookie/token. There is still a risk of CSRF if no special measure is implemented. Isn&#39;t JWT stored in a cookie?

2. If the JWT is stored in localStorage/sessionStorage, then there is no cookie involved so don&#39;t need to protect against CSRF. The question is how to send the JWT to the server. I found [here][2] that it is suggested to use jQuery to send the JWT by HTTP header of ajax requests. So, only the ajax requests can do the authentication?

3. Also, I found one more [blog][3] that points to use &quot;Authorization header&quot; and &quot;Bearer&quot; to send the JWT. I don&#39;t understand the method the blog talks about. Could someone please explain more about &quot;Authorization header&quot; and &quot;Bearer&quot;? Does this make the JWT transmitted by HTTP header of ALL requests? If yes, what about CSRF?


  [1]: http://sitr.us/2011/08/26/cookies-are-bad-for-you.html
  [2]: http://www.sitepoint.com/using-json-web-tokens-node-js/
  [3]: https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Where to store JWT in browser? How to protect against CSRF?

I have implemented in my app the mitigation to [CSRF attacks][1] following the informations that I have read on some blog post around the internet. In particular these post have been the driver of my implementation

 - [Best Practices for ASP.NET MVC][2] from the ASP.NET and Web Tools Developer Content Team
 - [Anatomy of a Cross-site Request Forgery Attack][3] from Phil Haack blog
 - [AntiForgeryToken in the ASP.NET MVC Framework - Html.AntiForgeryToken and ValidateAntiForgeryToken Attribute][4] from David Hayden blog

Basically those articles and recommendations says that to prevent the CSRF attack anybody should implement the following code:

1) Add the `[ValidateAntiForgeryToken]` on every action that accept the POST Http verb

    [HttpPost]
    [ValidateAntiForgeryToken]
    public ActionResult SomeAction( SomeModel model ) {
    }

2) Add the `&lt;%= Html.AntiForgeryToken() %&gt;` helper inside forms that submits data to the server

    &lt;div style=&quot;text-align:right; padding: 8px;&quot;&gt;
        &lt;%= Html.AntiForgeryToken() %&gt;
        &lt;input type=&quot;submit&quot; id=&quot;btnSave&quot; value=&quot;Save&quot; /&gt;
    &lt;/div&gt;

Anyway in some parts of my app I am doing Ajax POSTs with jQuery to the server without having any form at all. This happens for example where I am letting the user to click on an image to do a specific action. 

Suppose I have a table with a list of activities. I have an image on a column of the table that says &quot;Mark activity as completed&quot; and when the user click on that activity I am doing the Ajax POST as in the following sample:

    $(&quot;a.markAsDone&quot;).click(function (event) {
        event.preventDefault();
        $.ajax({
            type: &quot;post&quot;,
            dataType: &quot;html&quot;,
            url: $(this).attr(&quot;rel&quot;),
            data: {},
            success: function (response) {
                // ....
            }
        });
    });

How can I use the `&lt;%= Html.AntiForgeryToken() %&gt;` in these cases? Should I include the helper call inside the data parameter of the Ajax call?

Sorry for the long post and thanks very much for helping out

**EDIT**:

As per [jayrdub][5] answer I have used in the following way

    $(&quot;a.markAsDone&quot;).click(function (event) {
        event.preventDefault();
        $.ajax({
            type: &quot;post&quot;,
            dataType: &quot;html&quot;,
            url: $(this).attr(&quot;rel&quot;),
            data: {
                AddAntiForgeryToken({}),
                id: parseInt($(this).attr(&quot;title&quot;))
            },
            success: function (response) {
                // ....
            }
        });
    });


  [1]: https://en.wikipedia.org/wiki/Cross-site_request_forgery
  [2]: https://web.archive.org/web/20160301164154/http://blogs.msdn.com:80/b/aspnetue/archive/2010/09/17/second_2d00_post.aspx
  [3]: https://haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx/
  [4]: http://davidhayden.com/blog/dave/archive/2009/04/29/AntiForgeryTokenInMVCFramework.aspx
  [5]: https://stackoverflow.com/questions/4074199/jquery-ajax-calls-and-the-html-antiforgerytoken/4074289#4074289

jQuery Ajax calls and the Html.AntiForgeryToken()

I could use some help complying with Django&#39;s CSRF protection mechanism via my AJAX post. I&#39;ve followed the directions here:

http://docs.djangoproject.com/en/dev/ref/contrib/csrf/

I&#39;ve copied the AJAX sample code they have on that page exactly:

http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax

I put an alert printing the contents of `getCookie(&#39;csrftoken&#39;)` before the `xhr.setRequestHeader` call and it is indeed populated with some data. I&#39;m not sure how to verify that the token is correct, but I&#39;m encouraged that it&#39;s finding and sending something.

But Django is still rejecting my AJAX post.

Here&#39;s my JavaScript:

    $.post(&quot;/memorize/&quot;, data, function (result) {
        if (result != &quot;failure&quot;) {
            get_random_card();
        }
        else {
            alert(&quot;Failed to save card data.&quot;);
        }
    });

Here&#39;s the error I&#39;m seeing from Django:

&gt; [23/Feb/2011 22:08:29] &quot;POST /memorize/ HTTP/1.1&quot; 403 2332

I&#39;m sure I&#39;m missing something, and maybe it&#39;s simple, but I don&#39;t know what it is.  I&#39;ve searched around SO and saw some information about turning off the CSRF check for my view via the `csrf_exempt` decorator, but I find that unappealing.  I&#39;ve tried that out and it works, but I&#39;d rather get my POST to work the way Django was designed to expect it, if possible.

Just in case it&#39;s helpful, here&#39;s the gist of what my view is doing:

    def myview(request):

        profile = request.user.profile

        if request.method == &#39;POST&#39;:
            &quot;&quot;&quot;
            Process the post...
            &quot;&quot;&quot;
            return HttpResponseRedirect(&#39;/memorize/&#39;)
        else: # request.method == &#39;GET&#39;

            ajax = request.GET.has_key(&#39;ajax&#39;)

            &quot;&quot;&quot;
            Some irrelevent code...
            &quot;&quot;&quot;

            if ajax:
                response = HttpResponse()
                profile.get_stack_json(response)
                return response
            else:
                &quot;&quot;&quot;
                Get data to send along with the content of the page.
                &quot;&quot;&quot;

            return render_to_response(&#39;memorize/memorize.html&#39;,
                    &quot;&quot;&quot; My data &quot;&quot;&quot;
                    context_instance=RequestContext(request))


Thanks for your replies!

Django CSRF check failing with an Ajax POST request

From what I&#39;ve learned so far, the purpose of tokens is to prevent an attacker from forging a form submission.

For example, if a website had a form that input added items to your shopping cart, and an attacker could spam your shopping cart with items you don&#39;t want.

This makes sense because there could be multiple valid inputs for the shopping cart form, all the attacker would have to do is know an item that the website is selling. 

I understand how tokens work and add security in this case, because they ensure the user has actually filled in and pressed the &quot;Submit&quot; button of the form for each item added to the cart.

However, do tokens add any security to a user login form, which requires a username and password?

Since the username and password are very unique the attacker would have to know both in order for the login forgery to work (even if you didn&#39;t have tokens setup), and if an attacker already knew that, he could just sign onto the website himself. Not to mention, a CSRF attack that makes the user log himself in wouldn&#39;t have any practical purpose anyway.

Is my understanding of CSRF attacks and tokens correct? And are they useless for user login forms as I suspect?

Do login forms need tokens against CSRF attacks?

I am having trouble with the AntiForgeryToken with ajax. I&#39;m using ASP.NET MVC 3. I tried the solution in https://stackoverflow.com/questions/4074199/jquery-ajax-calls-and-the-html-antiforgerytoken. Using that solution, the token is now being passed:

    var data = { ... } // with token, key is &#39;__RequestVerificationToken&#39;

    $.ajax({
            type: &quot;POST&quot;,
            data: data,
            datatype: &quot;json&quot;,
            traditional: true,
            contentType: &quot;application/json; charset=utf-8&quot;,
            url: myURL,
            success: function (response) {
                ...
            },
            error: function (response) {
                ...
            }
        });

When I remove the `[ValidateAntiForgeryToken]` attribute just to see if the data (with the token) is being passed as parameters to the controller, I can see that they are being passed. But for some reason, the `A required anti-forgery token was not supplied or was invalid.` message still pops up when I put the attribute back.

Any ideas?

**EDIT**

The antiforgerytoken is being generated inside a form, but I&#39;m not using a submit action to submit it. Instead, I&#39;m just getting the token&#39;s value using jquery and then trying to ajax post that.

Here is the form that contains the token, and is located at the top master page:

    &lt;form id=&quot;__AjaxAntiForgeryForm&quot; action=&quot;#&quot; method=&quot;post&quot;&gt;
        @Html.AntiForgeryToken()
    &lt;/form&gt;

include antiforgerytoken in ajax post ASP.NET MVC

I&#39;ve seen articles and posts all over (including SO) on this topic, and the prevailing commentary is that same-origin policy prevents a form POST across domains.  The only place I&#39;ve seen someone suggest that same-origin policy does not apply to form posts, [is here][1].

I&#39;d like to have an answer from a more &quot;official&quot; or formal source.  For example, does anyone know the RFC that addresses how same-origin does or does not affect a form POST?

**clarification**: I am not asking if a GET or POST can be constructed and sent to any domain.  I am asking:

1. if Chrome, IE, or Firefox will allow content from domain &#39;Y&#39; to send a POST to domain &#39;X&#39;
1. if the server receiving the POST will actually see any form values at all.  I say this because the majority of online discussion records testers saying the server received the post, but the form values were all empty / stripped out.
1. What official document (i.e. RFC) explains what the expected behavior is (regardless of what the browsers have currently implemented).

Incidentally, if same-origin does not affect form POSTs - then it makes it somewhat more obvious of why anti-forgery tokens are necessary.  I say &quot;somewhat&quot; because it seems too easy to believe that an attacker could simply issue an HTTP GET to retrieve a form containing the anti-forgery token, and then make an illicit POST which contains that same token.  Comments?

  [1]: http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Cross Domain Form POSTing

I am writing an application (Django, it so happens) and I just want an idea of what actually a &quot;CSRF token&quot; is and how it protects the data.

Is the post data not safe if you do not use CSRF tokens?

What is a CSRF token? What is its importance and how does it work?

I know that there are answers regarding Django Rest Framework, but I couldn&#39;t find a solution to my problem.

I have an application which has authentication and some functionality.
I added a new app to it, which uses Django Rest Framework. I want to use the library only in this app. Also I want to make POST request, and I always receive this response:

    {
        &quot;detail&quot;: &quot;CSRF Failed: CSRF token missing or incorrect.&quot;
    }

I have the following code:

    # urls.py
    from django.conf.urls import patterns, url
    
    
    urlpatterns = patterns(
        &#39;api.views&#39;,
        url(r&#39;^object/$&#39;, views.Object.as_view()),
    )
    
    # views.py
    from rest_framework.views import APIView
    from rest_framework.response import Response
    from django.views.decorators.csrf import csrf_exempt
    
    
    class Object(APIView):
    
        @csrf_exempt
        def post(self, request, format=None):
            return Response({&#39;received data&#39;: request.data})

I want add the API without affecting the current application.
So my questions is how can I disable CSRF only for this app ?

Django Rest Framework remove csrf

Is it necessary to use CSRF Protection when the application relies on stateless authentication (using something like HMAC)?

Example:

 - We&#39;ve got a single page app (otherwise we have to append the token on each link: `&lt;a href=&quot;...?token=xyz&quot;&gt;...&lt;/a&gt;`.

 - The user authenticates himself using `POST /auth`. On successful authentication the server will return some token.

 - The token will be stored via JavaScript in some variable inside the single page app.

 - This token will be used to access restricted URLs like `/admin`.

 - The token will always be transmitted inside HTTP Headers.

 - There&#39;s NO Http Session, and NO Cookies.

As far as I understand, there should(?!) be no possibility to use cross site attacks, because the browser won&#39;t store the token, and hence it cannot automatically send it to the server (that&#39;s what would happen when using Cookies/Session).

Am I missing something?

CSRF Token necessary when using Stateless(= Sessionless) Authentication?

This question is about protecting against Cross Site Request Forgery attacks only.

It is specifically about: Is protection via the Origin header (CORS) as good as the protection via a CSRF token?

Example:

- Alice is logged in (using a cookie) with her browser to &quot;https://example.com&quot;. I assume, that she uses a modern browser.
- Alice visits &quot;https://evil.com&quot;, and evil.com&#39;s client side code performs some kind of request to &quot;https://example.com&quot; (classic CSRF scenario).

So:

- If we don&#39;t check the Origin header (server-side), and no CSRF token, we have a CSRF security hole.
- If we check a CSRF token, we&#39;re safe (but it&#39;s a bit tedious).
- If we do check the Origin header, the request from evil.com&#39;s client side code should be blocked just as well as it would when using a CSRF token - except, if it is possible somehow for evil.com&#39;s code to set the Origin header.

I know, that this should not be possible with XHR (see e.g. https://stackoverflow.com/questions/13242049/security-for-cross-origin-resource-sharing), at least not, if we trust the W3C spec to be implemented correctly in all modern browsers (can we?)

But what about other kinds of requests - e.g. form submit? Loading a script/img/... tag? Or any other way a page can use to (legally) create a request? Or maybe some known JS hack?

Note: I am not talking about

- native applications, 
- manipulated browsers, 
- cross site scripting bugs in example.com&#39;s page, 
- ...

CSRF protection with CORS Origin header vs. CSRF token

If the `protect_from_forgery` option is mentioned in application_controller, then I can log in and perform any GET requests, but on very first POST request Rails resets the session, which logs me out.

I turned the `protect_from_forgery` option off temporarily, but would like to use it with Angular.js. Is there some way to do that?

Rails CSRF Protection + Angular.js: protect_from_forgery makes me to log out on POST

I installed Laravel 5.7

Added a form to the file `\resources\views\welcome.blade.php`

    &lt;form method=&quot;POST&quot; action=&quot;/foo&quot; &gt;
        @csrf
        &lt;input type=&quot;text&quot; name=&quot;name&quot;/&gt;&lt;br/&gt;
        &lt;input type=&quot;submit&quot; value=&quot;Add&quot;/&gt;
    &lt;/form&gt;

Added to file `\routes\web.php`

    Route::post(&#39;/foo&#39;, function () {
        echo 1;
        return;
    });

After sending a POST request:

&gt; 419 Sorry, your session has expired. Please refresh and try again.

In version `5.6` there was no such a problem.


Post request in Laravel - Error - 419 Sorry, your session/ 419 your page has expired

My register page is showing the form properly with CsrfToken (`{{ csrf_field() }}`) present in the form).

**Form HTML**

    &lt;form class=&quot;form-horizontal registration-form&quot; novalidate method=&quot;POST&quot; action=&quot;{{ route(&#39;register&#39;) }}&quot;&gt;
            {{ csrf_field() }}
            ....
    &lt;/form&gt;

I am using inbuilt authentication for the users. Have not changed anything except the routes and redirects.

When I submit the form (just after reloading also), it gives that **The page has expired due to inactivity. Please refresh and try again.** error.

My be I am missing a very small thing. But not sure what it is. Any help?

**Update**

Found the issue. The session driver was set to array. Changed it to file and the error is gone now.
But what is wrong if I use array?

&quot;The page has expired due to inactivity&quot; - Laravel 5.5

I am trying to add some security to the forms on my website. One of the forms uses AJAX and the other is a straightforward &quot;contact us&quot; form. I&#39;m trying to add a CSRF token. The problem I&#39;m having is that the token is only showing up in the HTML &quot;value&quot; some of the time. The rest of the time, the value is empty. Here is the code I am using on the AJAX form:

PHP:

    if (!isset($_SESSION)) {
		session_start();
	$_SESSION[&#39;formStarted&#39;] = true;
	}
	if (!isset($_SESSION[&#39;token&#39;]))
    {$token = md5(uniqid(rand(), TRUE));
	$_SESSION[&#39;token&#39;] = $token;
	
    }

HTML

     &lt;form&gt;
    //...
    &lt;input type=&quot;hidden&quot; name=&quot;token&quot; value=&quot;&lt;?php echo $token; ?&gt;&quot; /&gt;
    //...
    &lt;/form&gt;

Any suggestions?

How to properly add cross-site request forgery (CSRF) token using PHP

I have a rails app that serves some APIs to an iPhone application.
I want to be able to simply post on a resource without minding on get the correct CSRF token.
I tried some methods that I see here in stackoverflow but it seems they no longer work on rails 3. 

Thank you for helping me.

Turn off CSRF token in rails 3

After configuring Spring Security 3.2, `_csrf.token` is not bound to a request or a session object.

This is the spring security config:

	&lt;http pattern=&quot;/login.jsp&quot; security=&quot;none&quot;/&gt;

    &lt;http&gt;
    	&lt;intercept-url pattern=&quot;/**&quot; access=&quot;ROLE_USER&quot;/&gt;
        &lt;form-login login-page=&quot;/login.jsp&quot;
        			authentication-failure-url=&quot;/login.jsp?error=1&quot;
        			default-target-url=&quot;/index.jsp&quot;/&gt;
        &lt;logout/&gt;
        &lt;csrf /&gt;
    &lt;/http&gt;

    &lt;authentication-manager&gt;
    	&lt;authentication-provider&gt;
			&lt;user-service&gt;
		    	&lt;user name=&quot;test&quot; password=&quot;test&quot; authorities=&quot;ROLE_USER/&gt;
		  	&lt;/user-service&gt;
    	&lt;/authentication-provider&gt;
    &lt;/authentication-manager&gt;


The login.jsp file

    &lt;form name=&quot;f&quot; action=&quot;${contextPath}/j_spring_security_check&quot; method=&quot;post&quot; &gt;
        &lt;input type=&quot;hidden&quot; name=&quot;${_csrf.parameterName}&quot; value=&quot;${_csrf.token}&quot; /&gt;
        &lt;button id=&quot;ingresarButton&quot;
                name=&quot;submit&quot;
                type=&quot;submit&quot;
                class=&quot;right&quot;
                style=&quot;margin-right: 10px;&quot;&gt;Ingresar&lt;/button&gt;
        &lt;span&gt;
            &lt;label for=&quot;usuario&quot;&gt;Usuario :&lt;/label&gt;
            &lt;input type=&quot;text&quot; name=&quot;j_username&quot; id=&quot;u&quot; class=&quot;&quot; value=&#39;&#39;/&gt;
        &lt;/span&gt;
        &lt;span&gt;
            &lt;label for=&quot;clave&quot;&gt;Contrase&amp;ntilde;a :&lt;/label&gt;

            &lt;input type=&quot;password&quot;
                   name=&quot;j_password&quot;
                   id=&quot;p&quot;
                   class=&quot;&quot;
                   onfocus=&quot;vc_psfocus = 1;&quot;
                   value=&quot;&quot;&gt;
        &lt;/span&gt;
    &lt;/form&gt;

And it renders the next html:

    &lt;input type=&quot;hidden&quot; name=&quot;&quot; value=&quot;&quot; /&gt;

The result is 403 HTTP status:

    Invalid CSRF Token &#39;null&#39; was found on the request parameter &#39;_csrf&#39; or header &#39;X-CSRF-TOKEN&#39;.


**UPDATE**
After some debug, the request object gets out fine form DelegatingFilterProxy, but in the line 469 of CoyoteAdapter it executes request.recycle(); that erases all the attributes...

I test in Tomcat 6.0.36, 7.0.50 with JDK 1.7.

I have not understood this behavior, rather than, it would be possible if someone point me in the direction of some application sample war with Spring Security 3.2 that works with CSRF.

Invalid CSRF Token &#39;null&#39; was found on the request parameter &#39;_csrf&#39; or header &#39;X-CSRF-TOKEN&#39;

I am building a web service that exclusively uses JSON for its request and response content (i.e., no form encoded payloads).

**Is a web service vulnerable to CSRF attack if the following are true?**

1. Any `POST` request without a top-level JSON object, e.g., `{&quot;foo&quot;:&quot;bar&quot;}`, will be rejected with a 400. For example, a `POST` request with the content `42` would be thus rejected.
    
2. Any `POST` request with a content-type other than `application/json` will be rejected with a 400. For example, a `POST` request with content-type `application/x-www-form-urlencoded` would be thus rejected.
    
3. All GET requests will be &lt;a href=&quot;http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html&quot;&gt;Safe&lt;/a&gt;, and thus not modify any server-side data.

4. Clients are authenticated via a session cookie, which the web service gives them after they provide a correct username/password pair via a POST with JSON data, e.g. `{&quot;username&quot;:&quot;user@example.com&quot;, &quot;password&quot;:&quot;my password&quot;}`.

Ancillary question: Are `PUT` and `DELETE` requests ever vulnerable to CSRF? I ask because it seems that most (all?) browsers disallow these methods in HTML forms.

EDIT: Added item #4.

EDIT: Lots of good comments and answers so far, but no one has offered a specific CSRF attack to which this web service is vulnerable.

Are JSON web services vulnerable to CSRF attacks?

How can I retrieve the CSRF token to pass with a JSON request?

I know that for security reasons [Rails is checking the CSRF token](http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails) on all the request types (including JSON/XML).

I could put in my controller `skip_before_filter :verify_authenticity_token`, but I would lose the CRSF protection (not advisable :-) ).

This similar (still not accepted) [answer](https://stackoverflow.com/questions/9044141/rails-devise-creating-new-users-via-json-request) suggests to

&gt; Retrieve the token with `&lt;%= form_authenticity_token %&gt;`

The question is how? Do I need to do a first call to any of my pages to retrieve the token and then do my real authentication with Devise? Or it is an information one-off that I can get from my server and then use consistently (until I manually change it on the server itself)?

rails - &quot;WARNING: Can&#39;t verify CSRF token authenticity&quot; for json devise requests

Cross Site Request Forgery (CSRF) is typically prevent with one of the following methods:

- Check referer - RESTful but unreliable
- insert token into form and store the token in the server session - not really RESTful
- cryptic one time URIs - not RESTful for the same reason as tokens
- send password manually for this request (not the cached password used with HTTP auth) - RESTful but not convenient


My idea is to use a user secret, a cryptic but static form id and JavaScript to generate tokens. 

    &lt;form method=&quot;POST&quot; action=&quot;/someresource&quot; id=&quot;7099879082361234103&quot;&gt;
    	&lt;input type=&quot;hidden&quot; name=&quot;token&quot; value=&quot;generateToken(...)&quot;&gt;
    	...
    &lt;/form&gt;

 1. `GET /usersecret/john_doe` fetched by the JavaScript from the authenticated user.
 2. Response: `OK 89070135420357234586534346` This secret is conceptionally static, but can be changed every day/hour ... to improve security. This is the only confidential thing.
 3. Read the cryptic (but static for all users!) form id with JavaScript, process it together with the user secret: `generateToken(7099879082361234103, 89070135420357234586534346)`
 4. Send the form along with the generated token to the server.
 5. Since the server knows the user secret and the form id, it is possible to run the same generateToken function as the client did before sending and compare both results. Only when both values are equal the action will be authorized.

Is something wrong with this approach, despite the fact that it doesn&#39;t work without JavaScript?

**Addendum:**

 - [Stateless CSRF Protection][1]


  [1]: http://appsandsecurity.blogspot.de/2012/01/stateless-csrf-protection.html

How to prevent CSRF in a RESTful application?

I&#39;m trying to understand the whole issue with CSRF and appropriate ways to prevent it. (Resources I&#39;ve read, understand, and agree with: [OWASP CSRF Prevention CHeat Sheet](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_$CSRF$_Prevention_Cheat_Sheet), https://stackoverflow.com/questions/9632262/questions-about-csrf.)

As I understand it, the vulnerability around CSRF is introduced by the assumption that (from the webserver&#39;s point of view) a valid session cookie in an incoming HTTP request reflects the wishes of an authenticated user. But all cookies for the origin domain are magically attached to the request by the browser, so really all the server can infer from the presence of a valid session cookie in a request is that the request comes from a browser which has an authenticated session; it cannot further assume anything about the *code* running in that browser, or whether it really reflects user wishes. The way to prevent this is to include additional authentication information (the &quot;CSRF token&quot;) in the request, carried by some means other than the browser&#39;s automatic cookie handling. Loosely speaking, then, the session cookie authenticates the user/browser and the CSRF token authenticates the code running in the browser.

So in a nutshell, if you&#39;re using a session cookie to authenticate users of your web application, you should also add a CSRF token to each response, and require a matching CSRF token in each (mutating) request. The CSRF token then makes a roundtrip from server to browser back to server, proving to the server that the page making the request is approved by (generated by, even) that server.

On to my question, which is about the specific transport method used for that CSRF token on that roundtrip.

It seems common (e.g. in [AngularJS](http://docs.angularjs.org/api/ng.$http), [Django](https://docs.djangoproject.com/en/dev/ref/contrib/csrf/), [Rails](http://guides.rubyonrails.org/security.html#csrf-countermeasures)) to send the CSRF token from server to client as a cookie (i.e. in a Set-Cookie header), and then have Javascript in the client scrape it out of the cookie and attach it as a separate XSRF-TOKEN header to send back to the server.

(An alternate method is the one recommended by e.g. [Express](http://dailyjs.com/2012/09/13/express-3-csrf-tutorial/), where the CSRF token generated by the server is included in the response body via server-side template expansion, attached directly to the code/markup that will supply it back to the server, e.g. as a hidden form input. That example is a more web 1.0-ish way of doing things, but would generalize fine to a more JS-heavy client.)

Why is it so common to use Set-Cookie as the downstream transport for the CSRF token / why is this a good idea? I imagine the authors of all these frameworks considered their options carefully and didn&#39;t get this wrong. But at first glance, using cookies to work around what&#39;s essentially a design limitation on cookies seems daft. In fact, if you used cookies as the roundtrip transport (Set-Cookie: header downstream for the server to tell the browser the CSRF token, and Cookie: header upstream for the browser to return it to the server) you would reintroduce the vulnerability you are trying to fix.

I realize that the frameworks above don&#39;t use cookies for the whole roundtrip for the CSRF token; they use Set-Cookie downstream, then something else (e.g. a X-CSRF-Token header) upstream, and this does close off the vulnerability. But even using Set-Cookie as the downstream transport is potentially misleading and dangerous; the browser will now attach the CSRF token to every request including genuine malicious XSRF requests; at best that makes the request bigger than it needs to be and at worst some well-meaning but misguided piece of server code might actually try to use it, which would be really bad. And further, since the actual intended recipient of the CSRF token is client-side Javascript, that means this cookie can&#39;t be protected with http-only. So sending the CSRF token downstream in a Set-Cookie header seems pretty suboptimal to me.

Why is it common to put CSRF prevention tokens in cookies?

Using React on the frontend with a RESTful API as backend and authorisation by a JSON Web Token (JWT), how do we handle sessions? For example after login, I get a JWT token from REST. If I save it to localStorage I am vulnerable to XSS, if I save it to cookies, same problems except I set cookies to HttpOnly, but React can&#39;t read HttpOnly Cookies (I need to read cookie to take JWT from it, and use this JWT with REST requests), also I didn&#39;t mention the Cross Site Request Forgery (CSRF) problem. If you&#39;re using REST as backend, you can&#39;t use CSRF Tokens.

As a result, React with REST seems like a bad solution and I need to rethink my architecture. Is it possible to offer your users a secure React application that handles all business logic on the REST API side without fear of losing their data?

**Update:**

As far as I understood, it is possible to do this:

1. React makes an AJAX call to the REST API
2. React gets a JWT token from the REST API
3. React writes HttpOnly cookie
4. Because React can&#39;t read HttpOnly cookies, we use it as-is in all our REST calls where we need authentication
6. The REST API calls to check the XMLHttpRequest header, which is some kind of CSRF protection
7. The REST API side checks for cookie, reads JWT from it and does stuff

I lack theoretical knowledge here. The logic looks pretty secure, but I still need an answer to my questions and approve of this &quot;workflow&quot;.

React frontend and REST API, CSRF

I&#39;m implementing a website in Angular.js, which is hitting an ASP.NET WebAPI backend.

Angular.js has some in-built features to help with anti-csrf protection. On each http request, it will look for a cookie called &quot;XSRF-TOKEN&quot; and submit it as a header called &quot;X-XSRF-TOKEN&quot; .

This relies on the webserver being able to set the XSRF-TOKEN cookie after authenticating the user, and then checking the X-XSRF-TOKEN header for incoming requests.

The [Angular documentation][1] states:

&gt; To take advantage of this, your server needs to set a token in a JavaScript readable session cookie called XSRF-TOKEN on first HTTP GET request. On subsequent non-GET requests the server can verify that the cookie matches X-XSRF-TOKEN HTTP header, and therefore be sure that only JavaScript running on your domain could have read the token. The token must be unique for each user and must be verifiable by the server (to prevent the JavaScript making up its own tokens). We recommend that the token is a digest of your site&#39;s authentication cookie with salt for added security.

I couldn&#39;t find any good examples of this for ASP.NET WebAPI, so I&#39;ve rolled my own with help from various sources. My question is - can anyone see anything wrong with the code?

First I defined a simple helper class:

    public class CsrfTokenHelper
	{
		const string ConstantSalt = &quot;&lt;ARandomString&gt;&quot;;

		public string GenerateCsrfTokenFromAuthToken(string authToken)
		{
			return GenerateCookieFriendlyHash(authToken);
		}

		public bool DoesCsrfTokenMatchAuthToken(string csrfToken, string authToken) 
		{
			return csrfToken == GenerateCookieFriendlyHash(authToken);
		}

		private static string GenerateCookieFriendlyHash(string authToken)
		{
			using (var sha = SHA256.Create())
			{
				var computedHash = sha.ComputeHash(Encoding.Unicode.GetBytes(authToken + ConstantSalt));
				var cookieFriendlyHash = HttpServerUtility.UrlTokenEncode(computedHash);
				return cookieFriendlyHash;
			}
		}
	}

Then I have the following method in my authorisation controller, and I call it after I call   FormsAuthentication.SetAuthCookie():

		// http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacks
		// http://docs.angularjs.org/api/ng.$http
		private void SetCsrfCookie()
		{
			var authCookie = HttpContext.Current.Response.Cookies.Get(&quot;.ASPXAUTH&quot;);
			Debug.Assert(authCookie != null, &quot;authCookie != null&quot;);
			var csrfToken = new CsrfTokenHelper().GenerateCsrfTokenFromAuthToken(authCookie.Value);
			var csrfCookie = new HttpCookie(&quot;XSRF-TOKEN&quot;, csrfToken) {HttpOnly = false};
			HttpContext.Current.Response.Cookies.Add(csrfCookie);
		}

Then I have a custom attribute which I can add to controllers to make them check the csrf header:

    public class CheckCsrfHeaderAttribute : AuthorizeAttribute
	{
		//	http://stackoverflow.com/questions/11725988/problems-implementing-validatingantiforgerytoken-attribute-for-web-api-with-mvc
		protected override bool IsAuthorized(HttpActionContext context)
		{
			// get auth token from cookie
			var authCookie = HttpContext.Current.Request.Cookies[&quot;.ASPXAUTH&quot;];
			if (authCookie == null) return false;
			var authToken = authCookie.Value;

			// get csrf token from header
			var csrfToken = context.Request.Headers.GetValues(&quot;X-XSRF-TOKEN&quot;).FirstOrDefault();
			if (String.IsNullOrEmpty(csrfToken)) return false;

			// Verify that csrf token was generated from auth token
			// Since the csrf token should have gone out as a cookie, only our site should have been able to get it (via javascript) and return it in a header. 
			// This proves that our site made the request.
			return new CsrfTokenHelper().DoesCsrfTokenMatchAuthToken(csrfToken, authToken);
		}
	}

Lastly, I clear the Csrf token when the user logs out:

    HttpContext.Current.Response.Cookies.Remove(&quot;XSRF-TOKEN&quot;);

Can anyone spot any obvious (or not-so-obvious) problems with that approach?

  [1]: http://docs.angularjs.org/api/ng.$http

Angular against Asp.Net WebApi, implement CSRF on the server

I&#39;m a PHP developer learning Ruby on Rails by reading [Michael Hartl&#39;s tutorial][1]. Here is a quote from the book, referring to `csrf_meta_tag`:

&gt; ...the Rails method `csrf_meta_tag` [prevents] cross-site request
&gt; forgery (CSRF), a type of malicious web attack. Don’t worry about the
&gt; details (I don’t); just know that Rails is working hard to keep your
&gt; application secure.

The thing is, I&#39;m genuinely curious. How does inserting `csrf-param` and `csrf-token` meta tags prevent CSRF? I tried Googling, but couldn&#39;t find anything.


  [1]: http://ruby.railstutorial.org/ruby-on-rails-tutorial-book

Rails: How Does csrf_meta_tag Work?

Do you know any Java cookie implementation which allows to set a custom flag for cookie, like `SameSite=strict`? It seems that [`javax.servlet.http.Cookie`][1] has a strictly limited set of flags which can be added.


  [1]: https://docs.oracle.com/javaee/7/api/javax/servlet/http/Cookie.html

SameSite cookie in Java application

I read that when using JWT, there is no need to protect against CSRF attacks, for instance: &quot;[since you are not relying on cookies, you don&#39;t need to protect against cross site requests][1]&quot;.

However, something I do not understand: if I store the token in `localStorage` (as I was advised [on a tutorial of the same website][2]), what prevents an attacker to forge a malicious request by reading my `localStorage` instead of my cookies?

Since it was generated on the server side, I don&#39;t get how I could use a token for a client request without it being stored somewhere on the client.

  [1]: https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
  [2]: https://auth0.com/blog/2015/04/09/adding-authentication-to-your-react-flux-app/

CSRF protection with JSON Web Tokens

How do you pass a csrftoken with the python module Requests?  This is what I have but it&#39;s not working, and I&#39;m not sure which parameter to pass it into (data, headers, auth...)

    import requests
    from bs4 import BeautifulSoup
    
    URL = &#39;https://portal.bitcasa.com/login&#39;

    client = requests.session(config={&#39;verbose&#39;: sys.stderr})

    # Retrieve the CSRF token first
    soup = BeautifulSoup(client.get(&#39;https://portal.bitcasa.com/login&#39;).content)
    csrftoken = soup.find(&#39;input&#39;, dict(name=&#39;csrfmiddlewaretoken&#39;))[&#39;value&#39;]

    login_data = dict(username=EMAIL, password=PASSWORD, csrfmiddlewaretoken=csrftoken)
    r = client.post(URL, data=login_data, headers={&quot;Referer&quot;: &quot;foo&quot;})

Same error message every time.

    &lt;h1&gt;Forbidden &lt;span&gt;(403)&lt;/span&gt;&lt;/h1&gt;
    &lt;p&gt;CSRF verification failed. Request aborted.&lt;/p&gt;

Passing csrftoken with python Requests

The django csrf middleware can&#39;t be disabled.  I&#39;ve commented it out from my Middleware of my project but my logins are failing due to missing CSRF issues.  I&#39;m working from the Django trunk.  How can CSRF cause issues if it is not enabled in middleware?

I have to disable it because there are lots of POST requests on my site that CSRF just breaks.  Any feedback on how I can completely disable CSRF in a django trunk project?

The &quot;new&#39; CSRF framework from Django&#39;s trunk is also breaking an external site that is coming in and doing a POST on a URL I&#39;m giving them (this is part of a restful API.)  I can&#39;t disable the CSRF framework as I said earlier, how can I fix this?

All Csrf Solutions on Gang of Coders

Total of 37 Csrf Solutions