EdOverflow
Joined 9 years ago
Karma
314
Submissions
19
Member since
Oct 21
Recent submissions
Comment · 4 years ago
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...
Comment · 5 years ago
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. :)
Comment · 6 years ago
Updated accordingly. :)
Comment · 6 years ago
Aside from Filedescriptor's work, here are some of my favourite blogs in the web application security space (not an exhaustive list):
- https://ngailong.wordpress.com/
- https://homakov.blogspot.com/
- https://philippeharewood.com/
- https://portswigger.net/research
- https://medium.com/@intideceukelaire
- https://stephensclafani.com/
- https://www.josipfranjkovic.com/
- https://www.arneswinnen.net/
- https://medium.com/@alex.birsan
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/.
Comment · 7 years ago
(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.
Comment · 8 years ago
Comment · 8 years ago
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!
Comment · 8 years ago
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....
Comment · 8 years ago
My finding was heavily inspired by Frans' report, but it is not actually related.
- Website: https://edoverflow.com/
- Twitter: https://twitter.com/EdOverflow
- GitHub: https://github.com/EdOverflow