Thoughts on SameSite cookie and CSRF

During a security assessment I noticed that Firefox automatically set the SameSite value of a session cookie to Lax. According to the Mozilla specs, this is the case for ‘modern browsers’.

The SameSite attribute set to Lax seems to protect against CSRF (every cross-origin request that’s doesn’t use GET). Obviously, outdated browser would still be vulnerable.

Would you still bother developers with implementing CSRF protection, if session cookies are protected by default in modern browsers? It depends on your security/business philosophy, and the type of application, whether it’s worth the effort. I’m interested in your opinion on the matter. Obviously, in the best case one would implement classic CSRF protection everywhere, but it keeps getting harder to sell the implementation efforts as a business case to development teams.

Go to Source
Author: Beurtschipper

URL editing shows success message, but doesn’t carry out function

I’ve been looking into my college’s internal alumni network. In that we can send connections to users and when you send a connection request, you’re taken to a url which is: https://www.website.com/yourwall/sent-invite/username/?Sendcon=true
And a message

Your invitation to Name was sent.

is displayed where ‘Name’ is the name of the user associated with ‘username’
Even though we get a success message, the connection request is not sent. And if we supply an invalid ‘username’ parameter into the url we still get a success message but as:

Your invitation to {:user} was sent.

Could this be a vulnerability? How can it be exploited and mitigated?

Go to Source
Author: Ananda Sai A

How to “trust” data that is posted from one application to other

We have a use case where a bunch of data needs to be posted from our application to a partner site where the end user takes some actions and then returns back to our site. On the return, the partner site also posts some data back to us. We need to establish trust for both the redirects.. i.e. the partner site needs to confirm that the data is originated at our end and hasn’t been modified during the transmission nd the same applies for post back from partner site. Our main constraint is that it should be a low cost solution for our partners. Our application is a multi-tenanted app with various partners (dozens). The usecase is applicable for all of them.

One option we looked at is a two step process, where our site posts a unique transaction id to the partner site which then calls a webservice hosted by us to get the complete data. We can secure our webservice using 2-way SSL auth and same goes for the data from the partner site. But the problem with the extra cost involved in creating a webservice at each partner end. This would delay the onboarding of a new partner and increase the cost.

Are there other alternatives to this problem than the PKI based solution?

Go to Source
Author: RKodakandla