CODEWITHSUNDEEP
asp.net-mvchttphttpsantiforgerytoken
Luis Abreu
Luis Abreu

Reputation: 4570

ASPNET MVC 5: Anti-forgery cookie not present

I've got an app that uses antiforgerytoken to secure all forms. the app is hosted on a web site that has the http binding set to the 8080 abd the https set to the 443 (default https port). Until now, I made sure that all the requests were made through https (The MVC app was using the required https filter, web config had the cookies entry requiressl set to true and owin had the auth cookies also set to https).

Recently, we had to change things because now we've got a firewall which handles the https requests for us. it will always serve the response through https to the final client, but I had change my app so that it could be called through http.

I've removed the required https filter, the required ssl for the cookies from the config and changed the owin auth cookies settings, and thought everything would be ok. Unfortunately, that didn't happen and I've started getting the anti forgery token cookie missing exception during validation. Now, the thing is that everything works out if I use https, but it will break if i change to http (which is in port 8080).

I've ended up changing the anti forgery configuration settings from within the global asax, but I'm not able to find a good explanation for the previous problem. in other words, why does the https access work without any problems but the http access ends up throwing an exception saying it can't find the anti forgery cookie...

any ideas?

Thanks, Luís

Upvotes: 0

Views: 2147

Answers (1)

Chris Pratt
Chris Pratt

Reputation: 239470

More likely than not, you're using secure cookies (cookies sent with the Secure tag). These will only ever survive on HTTPS connections. As soon as SSL is dropped, so are any secure cookies. You could turn it off, but that actually opens up an attack vector on your users, allowing their cookies to be exposed in plain text through protocol-switching.

The best thing you could do is keep it secure all the way. Just because SSL is being provided by the firewall, doesn't mean you can't implement SSL on your site as well. The only difference is that you would need a self-signed cert, since obviously the external domain will not apply. Other than that there should be no problem proxying to a secure site internally, rather than an unsecure one.

Upvotes: 4

Related Questions