Sakurity is a security consultancy whose blog covers web vulnerabilities, OAuth, and bug bounty findings, such as the Starbucks hack.
Commenters praise the author's skill and low consulting rate, and discuss his Starbucks findings and companies reacting badly to vulnerability reports.
The prevalence of XSS suggest that the web ecosystem has failed to produce the sort of tools you suggest. If such tools actually existed and were good, people would use them and web app exploits would be a curiosity rather than an expectation.
However, no such tool exists. I think there's a deeper issue here: the sheer number of ways you can generate XSS alone, even ignoring the other exploit types, is far beyond what any tool is capable of stopping. Look at one of the XSS holes found by Homakov that I linked to from my article:
http://sakurity.com/blog/2015/06/25/puzzle2.html
The XSS occurs on this line of JavaScript, not HTML:
$.get(location.pathname+'?something')
That's a simple line of JQuery that does an XmlHttpRequest to the same page that was loaded with an additional parameter. By itself, it is not an XSS. But if the backend is/was running Ruby on Rails (presumably some old version by now) then it could turn into an XSS due to a combination of features that all look superficially harmless.
Show me the tool that would have avoided that type of exploit, without already knowing about it and having some incredibly specific hardcoded static analysis rule.
When I argue that the web is unsafe by design, it's because cases like that aren't rare, they're common. To paraphrase Veekun, scratch the surface of web security and you'll find yourself in a bottomless downward spiral, uncovering more and more horrifying trivia.
He never 'got a lawsuit.' Instead, he got some comments from the contact to whom he reported it that criticized his approach. It's not even clear just who this person was. It seems he had trouble locating a contact to report security issues to, so this may as well have just been a low level support rep who was in over his head and saying things he shouldn't have.
"The hardest part - responsible disclosure. Support guy honestly answered there’s absolutely no way to get in touch with technical department and he’s sorry I feel this way. Emailing InformationSecurityServices@starbucks.com on March 23 was futile (and it only was answered on Apr 29). After trying really hard to find anyone who cares, I managed to get this bug fixed in like 10 days.
The unpleasant part is a guy from Starbucks calling me with nothing like “thanks” but mentioning “fraud” and “malicious actions” instead. Sweet!"
http://sakurity.com/blog/2015/05/21/starbucks.html
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/.
>1. how this works
So if you are a developer, your best bet is "How it works?" here: https://github.com/sakurity/securelogin
If you don't speak Ruby, hit me up I will dedicate all my time to help you.. and even get free audit as early adopter. FYI we conducted security audit for Auth0 (https://sakurity.com/)
Actually by using auth0 you rely not on one central authority, but on two: auth0 and google/microsoft oauth. If _either_ of them is compromised, your users accounts are too. If that worries you, try SL:
With SecureLogin you only rely on the local app user installs. First login friction? Not great, but is getting better, I'm giving it daily to normal users and it improves.
> If this is just a communication of risks, then those are not being communicated
Correct, that message is not very informative. I think it will be removed.
I hope not as Service Workers is an awful technology.
It is completely hostile to users. If I close a web page I expect everything related to that web page to stop. Immediately. I don't expect there to be lingering background threads consuming battery life, network data and disk storage. And in Chrome you can only discover service workers by enabling a Debug mode and memorising a specific URL. Exactly how does a non-developer figure out what is going on ?
If Apple had any sense they would ban service workers and instead propose use case specific, tightly focused and managed APIs that focus on security and battery life first.
Also just a hint at a future where Botnets are running in your browser:
https://sakurity.com/blog/2016/12/10/serviceworker_botnet.html
I have never used a gift card at starbucks before, but that bill [0] doesn't make any sense to me.
He says he has two cards: One has $15, one has $5.
Card 3203 is billed $14.68 and card 6075 is billed $2.02.
The remaining balance on card 3203 is $0, card 6075 has $5.70 remaining.
If card 3203 had $15 and card 6075 had $5 before he used them, the remaining balance should have been $0.32 and $2.98, respectively...
That's really me guessing, but it could be the $5 was just an example to explain the concept and in fact he used smaller values (e.g. $0.05) to be able to trigger the bug more often without generating too much cash... but he should have explained the bill somehow.
[0] http://sakurity.com/img/sbcheck.jpg