Discovering a security vulnerability in a major grocery delivery platform
zerforschung.org
zerforschung.org
this means most likely a junior developer built this service, and on top graphQL is used which is built relational first / security is one step away.
it sucks that companies grow fast in the tech scene, try to make their wealth using technology without really understanding it.
also why on earth do you need to expose your suppliers (sendgrid) api keys to the frontend
it's not about ignoring security as if it's extra work, it's about not being qualified enough to do a reasonable job.
security is hard, but this is going out of your way to expose your system.
People learn how to do certain programming tasks in one way, and instead of trying to fully understand "what" and "why" they're doing it, they just keep doing it. This approach works fine in a computer class, or in internships, but it breaks down when comes to writing secure apps.
It is similar with SQL injection: using prepared queries is not really difficult. I'd even claim that it's easier and simpler to write compared to string concatenation. But "knowing" about them takes time, curiosity and preparation. But making queries via string concatenation is how people used to learn.
Another thing is over-engineering (the wrong kind): it is more difficult to write tens of classes rather than doing what the task requires, but some people still do it because that's how they learned to program.
There are no shortcuts, unfortunately. So far we've solved this partially by using slogans: "Just use BCrypt" was a popular one a few years ago. But honestly I don't think this is enough.
We need more mentorship (for the beginners) and more peer reviews (for the experienced).
It's the other way round: you need to make sure not to expose sensitive parts of your configuration to the client. That's an extra step you can forget about (or fail to consider in the first place).
If the security incident is actually really terrible, simply fold the publicly-facing company and pivot with all the IP in the IP company. Maybe white-label it, or maybe just wait a little and start the exact same type of company under a new brand. Only the papers get a slap on the wrist.
Nobody really cares. Security isn't a topic ever.
Founders pay you VC money to fly across the country to talk for days about UI wireframes, but nobody ever cares about where or how you store data.
I think this is the reason most software just flat out sucks. It's easy to use if you ignore the part where it doesn't work half the time.
Most companies don't consider themselves "tech" and there is a lot of space for people who refuse to learn "technical mumbo jumbo" like just basic use of web browser or getting at least some knowledge of how browser is working.
I would push back a little bit that this is the sole reason (and thus not quite as solvable a problem as one might think). A couple other reasons that help explain why a lot of software sucks:
1) Unlike other engineering disciplines, there is not strict adherence to codified standards. It's easy for me to argue that my solution is adequate, even when if yours may be objectively better. An electrician or civil engineer has much less leeway for creativity because they are constrained by codes, standards, and industry-accepted best practices where adherence/compliance is culturally ingrained. Software, by comparison, is very much the Wild West.
2) It's very easy to change. Because software is relatively easy to change, it means configurations are often less stable. Especially at scale (and combined with the lack of standards), this can cause problems.
3) It's relatively cheap to implement (superficially at least) and there's a low barrier for entry (superficially at least). Software doesn't have the culture of other engineering disciplines regarding accreditation. I'm not a huge fan of credentialism personally, but it can provide a stop-gap in terms of skills, especially when those doing the hiring don't know how to properly assess those skills.
Never. There are too many people using too many technologies with too many deadlines and constant turnover. It will always be possible to find a service with simple vulnerabilities.
Security assessment should have been part of due diligence.
Now I know investors don't care much about this, but they should, lest they want to see their investments on the news in not so flattering colors.
The ROI on just jamming the gas pedal actually means that “horrific accidents” don’t affect profit all that much.
I mean, hiring desperate people and students to make deliveries in a couple if cities at a loss seems not to be the greatest feat. Services like Uber at least have some tech in-house which is mildly innovative. But this is just pathetic.
We think that only the best of us are making money but If you can consistently make even a small return on the investment money, you basically have a job as long as you want it. They don’t care if it’s crap, they just care if you give them more money than they started with.
- full name, date of birth and email have been leaked by multiple websites;
- phone number was leaked by Facebook (added it for 2FA many years ago);
- address information can be found in the public database of the Chamber of Commerce.
That doesn't make negligence okay, but at least Gorillas and Flink both gave me a €15 discount on my groceries in return.
EDIT: re the downvotes - I guess it's ok to ask crypto people all the time about real world cases but then not to accept any questions about real world cases elsewhere...
It's been more than a year, they have a pretty strong case to get rid of it but... Brazilian bureaucracy is slow and convoluted, it's been more than a year and neither can get any credit and get non-stop calls from banks and collection agencies.
Someone could have sent out 200k emails to steal money from 200k people.
I also store all leaked data just for fun. Guess what someone can do when they are out for you?
Writing an API which doesn't leak is very easy. I think it's reasonable to keep security.
I get calls from “Visa and Mastercard customer service” because they don’t know which one I have and are playing the numbers game. “Hi Mr. ceejayoz, I’m calling from Chase about account x2093” with Chase’s 1-800 spoofed on caller ID will catch a lot more people.
For you or for bunch of people on HN or that are somewhat tech literate it might be a mere annoyance.
There is far more people who have email/phone number but they don't understand much more. They get scammed every week or two as I read on local news. Scammers get free information that can be used to target a person and they use it.
Just type into google "man scammed out of life savings"
https://abc7chicago.com/remote-access-bank-account-scam-phon...
At least for email, I have a spam filter that catches most of the crap.
Neither my email nor phone number are very secret of course. I actually give out business cards, have some address information on my website (because you have to in Germany). Same for my phone number and email address.
Someone who owns a hardware wallet is probably a much better than the average person as a prospect to target for an altcoin or NFT purchase, for example.
I use Android's Call Screening and no scammer has ever made it to me.
Personally, I just let unknown numbers go to voicemail.
https://zerforschung.org/posts/zapptales/
What could go wrong? Everything.
Unreal.
Companies can build insecure systems (that are profitable) much faster and much cheaper than they can build systems that are profitable and secure.
It has been my experience that security is seen as a necessary evil. It's not seen as a benefit or feature that customers want. Security employees/consultants are often seen as road-blocks or obstructionists. I think this is largely why technical security has been replaced by compliance. Just check the box mentality. When they get hacked they can say, "but we were compliant and we'll do better next time".
IMPO, that basic conflict explains why systems are repeatedly compromised and why companies nor customers really care about good technical security.
Ideally there should be measures in place to mitigate these worst case scenarios but those are legitimately hard, expensive, and require commitment at all levels of the company.
This wasn't that. The worst vulnerability was caused by a very basic mistake that was more at the level of fundamental competence than security expertise. If you're going to use GraphQL you need someone who knows about GraphQL. It's been out a while now, they aren't that hard to find.
They have also recently analyzed Djokovic's test certificate: https://zerforschung.org/posts/djokovic-pcr-test-en/
Stuff like that is super interesting. I love this investigative journalism. Another one I find captivating is: https://www.bellingcat.com/
https://declassifieduk.org/cia-sidekick-gives-2-6m-to-uk-med...
Bellingcat was crucial in identifying the Tiergarten killer and the corresponding researcher was invited to court as a witness[1].
[1] https://www.theguardian.com/world/2021/dec/15/germany-convic...
I also think that there must be a line between getting hacked because some 5th level transitional dependency had a memory overflow bug which made it possible for the attacker to push some sensitive data in the response headers vs "auth? what auth?".
Very hard to exactly define it though, where it should lie, other than the extreme examples.
https://www.theverge.com/2021/11/14/22781341/fbi-email-syste...
<input type="hidden" name="userId" value ="{{session.userId}}">
I'm sure you can guess what it's used for and what it's not compared against.
> Gorillas has experienced extreme growth in recent weeks and also raised another absurd 290 million US dollars in venture capital
it does not seem absurd considering the current market valuations of online retailers.
How did they check the scopes? Did they use these API keys to make requests? Would that be legal?
EDIT: If Germany has the same conventions as The Netherlands, DD-MM-YYYY is probably even more common
First because it’s consistent with the longer written out date format used in German: „19. Januar 2022“ (19th of January 2022) – note the dot after the 19.
Second because it’s also consistent with how it’s spoken. The dot denotes ordinal numbers in German and that’s also how the date is spoken: „Neunzehnter Erster Zweitausend Zweiundzwanzig“ or “nineteenth first two thousand twenty and two”.
Dashes and slashes are highly likely to be confusing to people if used in that context, though advisable if you are using any other date format because then at least people will be weirded out and likely pay closer attention if there’s anything going on with that date.
It is true that DIN 5008 (which defines rules for word processing and does have some weight in professional circles) recommends YYYY-MM-DD, however this way of writing the date never took hold in Germany (just because it’s part of a norm doesn’t make it commonly used or accepted) and DIN 5008 does actually allow for DD.MM.YYYY.
<meta property="article:published_time" content="2021-05-10T22:00:00+02:00">