Comments for WebstersProdigy http://webstersprodigy.net Colored Hat. New post roughly every other Friday Sun, 19 May 2013 18:09:05 +0000 hourly 1 http://wordpress.com/ Comment on .NET MVC AntiforgeryToken CSRF Testing by webstersprodigy http://webstersprodigy.net/2013/02/14/mvc-antiforgery/comment-page-1/#comment-2029 Sun, 19 May 2013 18:09:05 +0000 http://webstersprodigy.net/?p=2113#comment-2029 There are a lot of PHP frameworks and a lot of them seem to try to mitigate CSRF in a different way. The principles are the same though. For it to be effective for multi-users, the nonce should be tied to the auth. A good generic design can be as simple as (sha512(sessionCookie) == postNonce)

]]> Comment on .NET MVC AntiforgeryToken CSRF Testing by mall http://webstersprodigy.net/2013/02/14/mvc-antiforgery/comment-page-1/#comment-2024 Sun, 19 May 2013 12:26:36 +0000 http://webstersprodigy.net/?p=2113#comment-2024 can you show how this CSRF nonce should be tied to the user’s session in PHP? ….ASP.NET it’s quite strange to me……..Thanks.

]]> Comment on Common .NET ViewstateUserKey CSRF Issue by webstersprodigy http://webstersprodigy.net/2013/03/21/common-net-viewstateuserkey-csrf-issue/comment-page-1/#comment-1952 Thu, 16 May 2013 20:35:17 +0000 http://webstersprodigy.net/?p=2133#comment-1952 It should be ok if you set viewstateuserkey to sessionID in forms auth because in that case ASP.NET_SessionId is used for auth. It’s important to understand writing a cookie is a lot easier than reading a cookie. So if the victim uses forms auth, then yes, an attacker could still write over the sessionID cookie, but at that point the victim is no longer logged in and CSRF isn’t as relevant.

]]> Comment on Common .NET ViewstateUserKey CSRF Issue by Pawel http://webstersprodigy.net/2013/03/21/common-net-viewstateuserkey-csrf-issue/comment-page-1/#comment-1948 Thu, 16 May 2013 18:14:37 +0000 http://webstersprodigy.net/?p=2133#comment-1948 What should be done in a scenario with forms authentication? If attacker hijacks formsauth cookie, wouldn’t it be the same case like hijacking the ASP.NET_SessionId?

]]> Comment on Common .NET ViewstateUserKey CSRF Issue by Murali http://webstersprodigy.net/2013/03/21/common-net-viewstateuserkey-csrf-issue/comment-page-1/#comment-1925 Wed, 15 May 2013 16:37:31 +0000 http://webstersprodigy.net/?p=2133#comment-1925 Hmm, I see. So the key needs to be tightly coupled with the auth.

]]> Comment on Common .NET ViewstateUserKey CSRF Issue by webstersprodigy http://webstersprodigy.net/2013/03/21/common-net-viewstateuserkey-csrf-issue/comment-page-1/#comment-1921 Wed, 15 May 2013 14:53:38 +0000 http://webstersprodigy.net/?p=2133#comment-1921 It shouldn’t matter. Assuming the key is constant between users and “session” is not used for auth, then $attacker could just replace $victim’s values as his own and the application has no way to distinguish.

]]> Comment on Common .NET ViewstateUserKey CSRF Issue by Murali http://webstersprodigy.net/2013/03/21/common-net-viewstateuserkey-csrf-issue/comment-page-1/#comment-1918 Wed, 15 May 2013 11:48:45 +0000 http://webstersprodigy.net/?p=2133#comment-1918 How about encrypting Session ID with a server secret key and using the encrypted value as the viewstateuserkey?

]]> Comment on Common OAuth issue you can use to take over accounts by Egor Homakov (@homakov) http://webstersprodigy.net/2013/05/09/common-oauth-issue-you-can-use-to-take-over-accounts/comment-page-1/#comment-1812 Sat, 11 May 2013 09:22:01 +0000 http://webstersprodigy.net/?p=2207#comment-1812 lsd lol. There are 2 kinds of bugs. 1st – CSRF for no state (http://homakov.blogspot.ru/2012/07/saferweb-most-common-oauth2.html) and 2nd Facebook login fixation. It cannot be fixed w/o fb efforts, so their answer is unbelievable

]]> Comment on Common OAuth issue you can use to take over accounts by Stephen Sclafani http://webstersprodigy.net/2013/05/09/common-oauth-issue-you-can-use-to-take-over-accounts/comment-page-1/#comment-1790 Fri, 10 May 2013 17:54:13 +0000 http://webstersprodigy.net/?p=2207#comment-1790 Back in 2009 I report a vulnerability to Facebook in their pre-OAuth Facebook Connect that was very smiler to the attack you describe: An attacker could force a user to login to a Facebook account and then finish the connection process with any website that had implemented Facebook Connect through a series of additional CSRF attacks. I advised Facebook to implement login CSRF protection and in response they added the “lsd” parameter to their logged out forms. However, the check for the parameter was never turned on. The explanation that was given to me at the time was that doing so would break desktop and other such apps. Four years later and the parameter is still being sent unchecked for.

]]> Comment on Common OAuth issue you can use to take over accounts by webstersprodigy http://webstersprodigy.net/2013/05/09/common-oauth-issue-you-can-use-to-take-over-accounts/comment-page-1/#comment-1785 Fri, 10 May 2013 14:07:15 +0000 http://webstersprodigy.net/?p=2207#comment-1785 I totally agree this is a Facebook bug, but it’s also a bug with people who don’t apply CSRF protection correctly. Without this you can do almost the same attack in several scenarios, like MiTM. But Facebook having CSRF on the login makes it worse.

I reported a repro (the above text almost) to Facebook last January. They basically said, yeah, it would be good to have csrf protection on login, but they’ve been aware of it for some time and it’s more an issue with the sites that use them for OAuth. Maybe I’ll update the post with some of this. Anyway, this is the second bug I’ve reported to FB. The first landed me on the wall but was before a bug bounty program, this one didn’t qualify :)

]]>