Hacker News new | past | comments | ask | show | jobs | submit | EdOverflow's comments login

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. :)



You may want to edit your comment so the links are not inside a code block (and thus clickable). Thanks.


Updated accordingly. :)


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


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


How so?


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.


Is this related to the issues recently discovered with the TLS-01-SNI validation method for TLS certs?

Looking over how GitLab handles setting up custom domains[1], it's pretty clear they were affected by that. I thought it was pretty much decided that's more a problem with the Baseline Requirements than with individual service providers like GitLab though. Mozilla even went so far as to forbid CAs from using two of the Baseline Requirement validation methods as a result of that vulnerability[2]. Assuming the CAs comply this shouldn't be an issue anymore, right?

Or were you referring to something else?

[1]: https://docs.gitlab.com//ce/user/project/pages/introduction....

[2]: https://groups.google.com/d/msg/mozilla.dev.security.policy/...


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


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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: