Egor Homakov

Aside from Filedescriptor's work, here are some of my favourite blogs in the web application security space (not an exhaustive list):

- https://blog.orange.tw/

- https://ngailong.wordpress.com/

- https://whitton.io/

- https://sakurity.com/blog

- https://homakov.blogspot.com/

- https://buer.haus/

- https://philippeharewood.com/

- https://portswigger.net/research

- https://gerbenjavado.com/

- https://medium.com/@intideceukelaire

- https://samcurry.net/

- https://stephensclafani.com/

- https://www.josipfranjkovic.com/

- https://www.arneswinnen.net/

- https://blog.assetnote.io/

- https://medium.com/@alex.birsan

- https://cablej.io/

- https://jonbottarini.com/

- https://www.corben.io/

There is also this massive list of write-ups that might be of interest to you: https://github.com/ngalongc/bug-bounty-reference.

Shameless plug: I write about web application security at https://edoverflow.com/.

AFAIK most of that info is in HN and twitter discussions between webappsec people. Here's a link[0] to a CSP leak that was briefly discussed on the webappsec mailing list. I also know Homakov wrote one[1].

That's one of the reasons I like this talk so much. It really cemented these type of issue with real attacks, instead of a loosely described bunch of PoC. I remember reading somewhere on an RFC (perhaps CSP) that reporting can cause unwanted information leakage, but I didn't find it in the security considerations with a quick control+f just now.

[0] - https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0030.html

[1] - http://homakov.blogspot.com/2014/01/using-content-security-policy-for-evil.html

> * This is how to use CORS without Preflights: http://homakov.blogspot.com/2014/01/how-to-use-cors-without-...*

Am I misreading, or is the thing you link to a proposal for what user-agents should do, rather than a technique that works now? Ah, I see you are the author of what you linked to, so maybe I am misreading?

(Also, are there secruity concerns with first making the request, and only finding out after you made it if you were allowed to make it? Seems like for POST requests (or GET requests on badly implemented apps), the request alone can be dangerous, even if the browser refuses to share the response with the script after seeing the response headers)

It's because Facebook, Google, and some others run generous bug bounties / white-hat programs. Without committing a crime, people can make a lot for disclosing it directly and confidentially. Vulnerabilities can pay 5-15k and there have been 30-40k payouts. Occasionally, you'll see a blog post explaining the process from detection to payment, like: http://homakov.blogspot.com/2013/02/hacking-facebook-with-oauth2-and-chrome.html

FB paid out 1.3m in 2014. http://www.zdnet.com/article/facebook-bug-bounty-program-paid-out-1-3-million-in-2014/

Logged-out csrf is an issue if you are serving as an oauth provider. There might be other use cases that I haven't thought about. I would ere on the side of precaution and implement logged-out csrf.

If you create a session for the logged-out user, you must be careful about not recycling the same session once logged in or you expose yourself to session fixation.

http://stephensclafani.com/2011/04/06/oauth-2-0-csrf-vulnerability/ and http://homakov.blogspot.com/2014/01/two-severe-wontfix-vulnerabilities-in.html explain the issue pretty well.

Facebook's OAuth2 implementation is so broken. Homakov found a X-XSS-Protection-related issue: http://homakov.blogspot.no/2013/02/hacking-facebook-with-oauth2-and-chrome.html.

After reading Homakov's and Nir's discussions I started looking for some bugs myself. And guess what? ~10 hours later I found another access_token-stealing exploit that has the same implications as Nir's exploit (although mine doesn't work in all browsers). Reported it 2 days ago.

Wouldn't surprise me if there's more bugs/exploits to be discovered :(