EdOverflow

I am a security researcher referenced in the winning web-hacking technique on that list ("Dependency Confusion" by Alex Birsan [1]) and was ranked 7th in Portswigger's 2019 issue [2,3]. My motto has always been "Learn to make it; then break it." In other words, I invest a lot of time familiarising myself with technologies and specifications before examining how their implementation might lead to security flaws. This process usually requires reading a lot of technical documentation and source code, and becoming acquainted with how organisations implement said technologies.

Once I feel comfortable with my understanding of the subject material, I start to think about how certain aspects of the technology could lead to security flaws or interesting areas of research. At times this may require out-of-the-box thinking or can even be the result of pure luck.

The "bug bounty" aspect of this all tends to come into play once I want to find case studies for my research.

[1]: https://medium.com/@alex.birsan/dependency-confusion-4a5d60f...

[2]: https://portswigger.net/research/top-10-web-hacking-techniqu...

[3]: https://edoverflow.com/2019/ci-knew-there-would-be-bugs-here...

I am the author of an Internet Draft (security.txt) that is going through a similar process to Mark Nottingham's RFC above, so I might be able to help.

This is an "Informational" specification which means it went via the "Non-Standards Track". You can read more about this process here: https://www.ietf.org/standards/process/informational-vs-expe....

The Internet Draft (ID) was presented at the DISPATCH meeting session at IETF 103 which includes some discussion at the end of the presentation: https://youtu.be/OAKv4Sc0jhM?t=1183. The "Informational" vs "Standards" track topic is actually brought up briefly here: https://youtu.be/OAKv4Sc0jhM?t=1660.

There were some discussions surrounding the ID in the ART mailing lists: https://mailarchive.ietf.org/arch/msg/art/52wxNQ4KI-Z_9tFuFL....

You can also see comments by the IESG review board here: https://datatracker.ietf.org/doc/rfc8959/ballot/.

Hope that clears up any confusion. :)

Updated accordingly. :)

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/.

(Obligatory: I am not a lawyer)

This is what the "safe harbor" that the author was referring to is supposed to cover.

> Tesla considers that a pre-approved, good-faith security researcher who complies with this policy to access a computer on a research-registered vehicle has not accessed a computer without authorization or exceeded authorized access under the Computer Fraud and Abuse Act ("CFAA"). [1]

*.teslamotors.com, which is where the blind XSS payload fired, is in scope and therefore the safe harbor covers that asset too. For more on bug bounty safe harbors, I would highly recommend taking a look at Amit Elazari's work at https://amitelazari.com/%23legalbugbounty-hof and https://github.com/edoverflow/legal-bug-bounty.

[1]: https://bugcrowd.com/tesla

This is a wonderful thing to see and I hope that more vendors will follow suit. Amit Elazari [1] has been doing some amazing work in this field advocating for legal safe harbours for security researchers. She posts regular reviews of security policies encouraging vendors to help protect security researchers using #legalbugbounty on Twitter. [2] In fact, it appears that Amit was responsible for some of the changes to Dropbox' security policy: https://twitter.com/d0nutptr/status/973322158351921152. Well done, Dropbox and Amit!

[1]: https://twitter.com/AmitElazari

[2]: https://twitter.com/hashtag/legalbugbounty

This sounds like something along the lines of password reset poisoning as described in James Kettles' technical write-up "Practical HTTP Host header attacks". [1]

[1]: http://www.skeletonscribe.net/2013/05/practical-http-host-he....

My finding was heavily inspired by Frans' report, but it is not actually related.

Unfortunately, I cannot disclose any further details until GitLab give me permission to do so. All that I can say is that GitLab has certain features for custom domains that GitHub does not have. I plan on publishing a technical write-up once everything has been resolved.

Yes, GitHub pages are vulnerable to (sub)domain takeovers too [1], but GitLab has a couple of specific characteristics that make matters worse.

[1]: https://hackerone.com/reports/263902

I am the security researcher that reported this issue to GitLab. There is more to the issue than is described in GitLab's security advisory and it was definitely a design flaw on GitLab's part. Hopefully, more details will be published soon.