I wonder if this was made by AI or a shit programmer
-
This post did not contain any content.wrote on last edited by [email protected]
Not a big fan of the wording here. Plenty of skilled programmers make dumb mistakes. There should always be systems in place to ensure these dumb mistakes don't make it to production. Especially when related to sensitive information. Where was the threat model and the system in place to enforce it? The idea that these problems are caused by "shit programmers" misses the real issue: there was either no system or an insufficient system to test features and define security requirements.
-
Fantastic for building BaaS apps
Bullshit as a Service?
-
Giraffe In Giraffe Out
Gorilla In Giraffe Out
That would be the real trick.
-
Bullshit as a Service?
Bananas as a Service
-
This post did not contain any content.
What was the BASE_URL here? I’m guessing that’s like a profile page or something?
So then you still first have to get a URL to each profile? Or is this like a feed URL?
-
What was the BASE_URL here? I’m guessing that’s like a profile page or something?
So then you still first have to get a URL to each profile? Or is this like a feed URL?
It's a public firebase bucket
-
It's a public firebase bucket
Oh Jesus
-
I work in security and I kinda doubt this. There are plenty of issues just like what is outlined here that would be much easier to exploit than social engineering. Social engineering costs a lot more than
GET /secrets.json.There is good reason to be concerned about both, but 95% sounds way off and makes it sound like companies should allocate significantly more time to defend against social engineering, when they should first try to ensure social engineering is the easiest way to exploit their system. I can tell you from about a decade of experience that it typically isn't.
https://www.infosecinstitute.com/resources/security-awareness/human-error-responsible-data-breaches/
You're right. It's 74%.
https://www.cybersecuritydive.com/news/clorox-380-million-suit-cognizant-cyberattack/753837/
It's way easier to convince someone that you are just a lost user who needs access than it is to try to probe an organization's IT security from the outside.
This is only going to get worse with the ability to replicate other's voices and images. People already consistently fall for text message and email social engineering. Now someone just needs to build a model off a CSO doing interviews for a few hours and then call their phone explaining there has been a breach. Sure, 80% of good tech professionals won't fall for it, but the other 20% that just got hired out of their league and are fearing for their jobs will immediately do what they are told, especially if the breach is elaborate enough to convince them it's an internal security thing.
-
Not a big fan of the wording here. Plenty of skilled programmers make dumb mistakes. There should always be systems in place to ensure these dumb mistakes don't make it to production. Especially when related to sensitive information. Where was the threat model and the system in place to enforce it? The idea that these problems are caused by "shit programmers" misses the real issue: there was either no system or an insufficient system to test features and define security requirements.
I found a bad programmer!
-
Believe it or not a lot of hacking is more like this than you think.
Shodan lists 100'000s of publicly accessible security cameras.
-
I remember when a senior developer where i worked was tired of connecting to the servers to check its configuration, so they added a public facing rest endpoint that just dumped the entire active config, including credentials and secrets
That was a smaller slip-up than exposing a database like that (he just forgot that the config contained secrets) but still funny that it happened
That's not a "senior developer." That's a developer that has just been around for too long.
Secrets shouldn't be in configurations, and developers shouldn't be mucking around in production, nor with production data.
-
This post did not contain any content.
This reminds me of how I showed a friend and her company how to get databases from BLS and it's basically all just text files with urls. "What API did you call? How did you scrape the data?"
Nah man, it's just... there. As government data should be. They called it a hack.
-
Not a big fan of the wording here. Plenty of skilled programmers make dumb mistakes. There should always be systems in place to ensure these dumb mistakes don't make it to production. Especially when related to sensitive information. Where was the threat model and the system in place to enforce it? The idea that these problems are caused by "shit programmers" misses the real issue: there was either no system or an insufficient system to test features and define security requirements.
I can tell you exactly what happened. "Hey Claude, I need to configure and setup a DB with Firebase to store images from our application." and then promptly hit shift+tab and then went to go browse Reddit.
nothing was tested. nothing was verified. They let the AI do its thing they checked in on it after an hour or so. once it was done it was add all, commit -m "done", push origin master. AI doesn't implement security stuff. there was zero security here.
-
Not below average dev necessarily, but when posting code examples on the internet people often try to get a point across. Like how do I solve X? Here is code that solves X perfectly, the rest of the code is total crap, ignore that and focus on the X part. Because it's just an example, it doesn't really matter. But when it's used to train an LLM it's all just code. It doesn't know which parts are important and which aren't.
And this becomes worse when small little bits of code are included in things like tutorials. That means it's copy pasted all over the place, on forums, social media, stackoverflow etc. So it's weighted way more heavily. And the part where the tutorial said: "Warning, this code is really bad and insecure, it's just an example to show this one thing" gets lost in the shuffle.
Same thing when an often used pattern when using a framework gets replaced by new code where the framework does a little bit more so the same pattern isn't needed anymore. The LLM will just continue with the old pattern, even though there's often a good reason it got replaced (for example security issues). And if the new and old version aren't compatible with each other, you are in for a world of hurt trying to use an LLM.
And now with AI slop flooding all of these places where they used to get their data, it just becomes worse and worse.
These are just some of the issues why using an LLM for coding is probably a really bad idea.
Didn't expect this much. I don't think about tuto example being weighted heavier. This make sense.
-
I found a bad programmer!
I found someone who hasn't yet made their big dumb mistake. Give it time.
-
I found someone who hasn't yet made their big dumb mistake. Give it time.
I've dodged the bullet for 20 years, now. I guess i had better get cracking
-
Not below average dev necessarily, but when posting code examples on the internet people often try to get a point across. Like how do I solve X? Here is code that solves X perfectly, the rest of the code is total crap, ignore that and focus on the X part. Because it's just an example, it doesn't really matter. But when it's used to train an LLM it's all just code. It doesn't know which parts are important and which aren't.
And this becomes worse when small little bits of code are included in things like tutorials. That means it's copy pasted all over the place, on forums, social media, stackoverflow etc. So it's weighted way more heavily. And the part where the tutorial said: "Warning, this code is really bad and insecure, it's just an example to show this one thing" gets lost in the shuffle.
Same thing when an often used pattern when using a framework gets replaced by new code where the framework does a little bit more so the same pattern isn't needed anymore. The LLM will just continue with the old pattern, even though there's often a good reason it got replaced (for example security issues). And if the new and old version aren't compatible with each other, you are in for a world of hurt trying to use an LLM.
And now with AI slop flooding all of these places where they used to get their data, it just becomes worse and worse.
These are just some of the issues why using an LLM for coding is probably a really bad idea.
Yeah, once you get the LLM's response you still have to go to the documentation to check whether it's telling the truth and the APIs it recommends are current. You're no better off than if you did an internet search and tried to figure out who's giving good advice, or just fumbled your own way through the docs in the first place.
-
Yeah, once you get the LLM's response you still have to go to the documentation to check whether it's telling the truth and the APIs it recommends are current. You're no better off than if you did an internet search and tried to figure out who's giving good advice, or just fumbled your own way through the docs in the first place.
whether it's telling the truth
"whether the output is correct or a mishmash"
"Truth" implies understanding that these don't have, and because of the underlying method the models use to generate plausible-looking responses based on training data, there is no "truth" or "lying" because they don't actually "know" any of it.
I know this comes off probably as super pedantic, and it definitely is at least a little pedantic, but the anthropomorphism shown towards these things is half the reason they're trusted.
That and how much ChatGPT flatters people.
-
Believe it or not a lot of hacking is more like this than you think.
I think that’s less about “hacking” and more about modern day devs being overworked by their hot-shit team lead and clueless PMs and creating “temporary” solutions that become permanent in the long run.
This bucket was probably something they set up early in the dev cycle so they could iterate components without needing to implement an auth system first and then got rushed into releasing before it could be fixed. That’s almost always how this stuff happens; whether it’s a core element or a rushed DR test.
-
Social engineering is probably 95% of modern attack vectors. And that's not even unexpected, some highly regarded computer scientists and security researchers concluded this more than a decade ago.
This has been the case for 40+ years. Humans are almost always the weakest link.
