5 ms·

So they found a hard-coded API token and no further user authentication to limit the requests. This is obviously a common rookie mistake (didn't Facebook, Snapc

by zaroth 10y ago

So they found a hard-coded API token and no further user authentication to limit the requests. This is obviously a common rookie mistake (didn't Facebook, Snapchat, Instagram all fall for this at some point?) and security software particularly should not have such a basic vulnerability, but I do think TFA veers past security writeup into editorial when they start critiquing the cost/pricing and calling for customers to drop the software, particularly since the vendor was responsive to the report. It seems like maybe the vendor's communication trailed off toward the end leaving OP with bad feelings which show up in the write-up. Generally I like to see security research and vulnerabilities reported as a way to document the process used and experience gained, but not to skewer the company except with respect to their responsiveness of a patch. Of course, everyone here is free to skewer the app as much as they like, I just don't like reading it in the actual write-up.

caf 10y ago
Sure, but.. this isn't Instagram, is it? Somehow I feel that if you're purporting to build a safety-critical service, the bar ought to be set a bit higher for you than if you're sharing pictures of people's lunch. It's a common rookie mistake, but perhaps the takeaway is that this kind of area isn't something that rookies should be tackling.
- deleted 10y ago
  [deleted]
- patcheudor 10y ago
  >Sure, but.. this isn't Instagram, is it? Somehow I feel that if you're purporting to build a safety-critical service, the bar ought to be set a bit higher for you than if you're sharing pictures of people's lunch. To your point and going back to what zaroth was getting at I'm wondering why I didn't see the typical references to a bug bounty, permission or payout that are typical in write-ups of this nature. This really does concern me. Poking around server-side with an account you clearly weren't meant to interact with could have serious repercussions up to and including service outages. You'd be amazed at the sorts of mistakes I've seen in code that could lead to unintentionally taking down a service. A number of years ago I discovered a flaw with a major identity management provider. If the POST request parameters were placed out of expected order it crashed the application into a zombied state where it could no longer accept requests, causing a denial of service situation until it was restarted. Worse, the event wasn't logged. You don't typically log POSTs in the HTTPD and they didn't have application layer logging at that level either so without monitoring HTTPS traffic there was no way to troubleshoot why the application was hanging. I've seen lots of vulnerabilities like this including in life critical systems. Because of the unexpected as well as US law, I always check to see if there's a bug bounty first or I reach out to the vendor and get written permission. I really am paranoid about what's in criminal code as well as accidentally causing an outage. There are certainly a number of ethics and possibly legal issue which appear to be at play here beyond just embarrassing the company. Hopefully we'll here more about the bug bounty program.

by zaroth 10y ago

caf 10y ago

Sure, but.. this isn't Instagram, is it? Somehow I feel that if you're purporting to build a safety-critical service, the bar ought to be set a bit higher for you than if you're sharing pictures of people's lunch. It's a common rookie mistake, but perhaps the takeaway is that this kind of area isn't something that rookies should be tackling.

deleted 10y ago
[deleted]
patcheudor 10y ago
>Sure, but.. this isn't Instagram, is it? Somehow I feel that if you're purporting to build a safety-critical service, the bar ought to be set a bit higher for you than if you're sharing pictures of people's lunch. To your point and going back to what zaroth was getting at I'm wondering why I didn't see the typical references to a bug bounty, permission or payout that are typical in write-ups of this nature. This really does concern me. Poking around server-side with an account you clearly weren't meant to interact with could have serious repercussions up to and including service outages. You'd be amazed at the sorts of mistakes I've seen in code that could lead to unintentionally taking down a service. A number of years ago I discovered a flaw with a major identity management provider. If the POST request parameters were placed out of expected order it crashed the application into a zombied state where it could no longer accept requests, causing a denial of service situation until it was restarted. Worse, the event wasn't logged. You don't typically log POSTs in the HTTPD and they didn't have application layer logging at that level either so without monitoring HTTPS traffic there was no way to troubleshoot why the application was hanging. I've seen lots of vulnerabilities like this including in life critical systems. Because of the unexpected as well as US law, I always check to see if there's a bug bounty first or I reach out to the vendor and get written permission. I really am paranoid about what's in criminal code as well as accidentally causing an outage. There are certainly a number of ethics and possibly legal issue which appear to be at play here beyond just embarrassing the company. Hopefully we'll here more about the bug bounty program.