Common CSRF vulnerability in OAuth2 implementations
1–4 of 4 posts
Re: Common CSRF vulnerability in OAuth2 implementations
#2It takes 3-4 extra lines of code to implement CSRF protection for oauth2 login in python. The same kind of idiots who set themselves up for stupid sql injection attacks omit CSRF protection. How is this interesting?
Re: Common CSRF vulnerability in OAuth2 implementations
#3It takes 3-4 extra lines of code to implement CSRF protection for oauth2 login in python. The same kind of idiots who set themselves up for stupid sql injection attacks omit CSRF protection. How is this interesting?
It's interesting precisely because that mistake is "common" (though I'll admit some frustration that the actual vulnerabilities aren't disclosed, so we don't know how common). It says so right in the headline.
Maybe you already knew this. Maybe you are too smart to make such a mistake (though in my experience, people quick to dismiss "simple" security practices are the most likely to forget them and make this kind of mistake). Some people aren't. And others, like me (also way-too-smart-to-ever-do something-like-this of course) don't actually know much about OAuth and read the link interested in learning more about its security landscape.
Re: Common CSRF vulnerability in OAuth2 implementations
#4It takes 3-4 extra lines of code to implement CSRF protection for oauth2 login in python. The same kind of idiots who set themselves up for stupid sql injection attacks omit CSRF protection. How is this interesting?
Vulnerabilities become interesting at two (perhaps more) different points in their lifecycle. One is when the idea of the vulnerability is first revealed (or first thought of). A second point is when the vulnerability begins to be seen "in the wild". The first is interesting for theoretical reasons, the second for practical reasons. This story relates to the vulnerability appearing "in the wild".