▲ 110 ▼ What are some common misconceptions about programming that you'd like to debunk? (programming.dev) submitted 2 years ago by mac@programming.dev to c/programming@programming.dev 179 comments fedilink hide all child comments
[–] abhibeckert@lemmy.world 3 points 2 years ago* (2 children) Programmers are not hackers. The reverse might be true but hacking is about finding problems (and exploiting them) while programming is about fixing problems. You have to find a problem before you can fix it. All good programmers are hackers. permalink fedilink source parent hideshow 4 child comments replies: [–] Sickday@kbin.run 6 points 2 years ago (1 child) You don't need to be a hacker to find those problems. You need to be a good detective. All good programmers are detectives. permalink fedilink source parent hideshow 2 child comments replies: [–] fkn@lemmy.world 1 point 2 years ago (1 child) I don't think either is actually true. I know many programmers who can fix a problem once the bug is identified but wouldn't be able to find it themselves nor would they be able to determine if a bug is exploitable without significant coaching. Exploit finding is a specific skill set that requires thinking about multiple levels of abstraction simultaneously (or intentionally methodically). I have found that most programmers simply don't do this. I think the definition of "good" comes into play here, because the vast majority of programmers need to dependably discover solutions to problems that other people find. Ingenuity and multilevel abstract thinking are not critically important and many of these engineers who reliably fix problems without hand holding are good engineers in my book. I suppose that it could be argued that finding the source of a bug from a bug report requires detective skills, but even this is mostly guided inspection with modern tooling. permalink fedilink source parent hideshow 2 child comments replies: [–] pkill@programming.dev 1 point 2 years ago* (last edited 2 years ago) Yeah take for instance ransomware. That is easy since a lot of your targets might distrust regular user input but be much less cautious about stuff that should presumably be only accessible internally but isn't actually even properly locked behind a VPN gate so a simple credential stuffing would do and from then onwards it is actually easier than a physical kidnapping since you don't need to worry about using physical force to ensure your victim submits, doesn't escape or recognize you. But then you need to actually be smart to make sure you don't de-anonymize yourself in the process, don't render your operation just some temporary disturbance by ensuring your victim doesn't just restore their backups if your goal is a denial of service until you get paid and not expecting ransom for not releasing breach data. Or take carding. Not technically super difficult, especially with the whole illusion of security that many non-technical users have (ie the infamous padlock when I can literally set up a phishing site with letsencrypt that'd log all the form data in minutes), but then good luck cashing out on that with all the KYC on virtually every crypto exchange out there and all that granted 3DS doesn't stop you. permalink fedilink source parent [–] BrianTheeBiscuiteer@lemmy.world 2 points 2 years ago (2 children) Programmers have the source code right in front of them, hackers usually don't. It's quite amazing what they can do taking shots in the dark. permalink fedilink source parent hideshow 4 child comments replies: [–] pkill@programming.dev 1 point 2 years ago (1 child) depends. Desktop code, sure, reverse engineering from assembly takes some time but some good dissasemblers might be able to produce some C skeleton to start from. Though you might get lucky just exploiting the supply chain of bloated open source with a hellton of vulnerabilities deps/infra like glibc, apache or sudo. But web code? Sure, minifiers exist but not every website uses them and even if their do, thanks to all the new stuff since ES5 you can for example spend way less time doing something like finding a Math.random() based, ergo cryptographically utterly broken PRNG. Or for example you can easily rule out whether the website uses header-to-cookie based CSRF protection by just checking the console on any authenticated write-like request. The rest could be automated with things like zaproxy or selenium/curl-impersonate/puppeteer scripts. permalink fedilink source parent hideshow 2 child comments replies: [–] BrianTheeBiscuiteer@lemmy.world 1 point 2 years ago "Hacking" also has plenty of specialties like programming. When I think of hacking my first thought is remote, non-http services. Webservers are fair game for hacking but they're also meant for public consumption so I'd guess monitoring is a bit more severe (not that companies don't skimp on intrusion detection). permalink fedilink source parent [+] pkill@programming.dev 1 point 2 years ago [deleted] permalink fedilink source parent
[–] Sickday@kbin.run 6 points 2 years ago (1 child) You don't need to be a hacker to find those problems. You need to be a good detective. All good programmers are detectives. permalink fedilink source parent hideshow 2 child comments replies: [–] fkn@lemmy.world 1 point 2 years ago (1 child) I don't think either is actually true. I know many programmers who can fix a problem once the bug is identified but wouldn't be able to find it themselves nor would they be able to determine if a bug is exploitable without significant coaching. Exploit finding is a specific skill set that requires thinking about multiple levels of abstraction simultaneously (or intentionally methodically). I have found that most programmers simply don't do this. I think the definition of "good" comes into play here, because the vast majority of programmers need to dependably discover solutions to problems that other people find. Ingenuity and multilevel abstract thinking are not critically important and many of these engineers who reliably fix problems without hand holding are good engineers in my book. I suppose that it could be argued that finding the source of a bug from a bug report requires detective skills, but even this is mostly guided inspection with modern tooling. permalink fedilink source parent hideshow 2 child comments replies: [–] pkill@programming.dev 1 point 2 years ago* (last edited 2 years ago) Yeah take for instance ransomware. That is easy since a lot of your targets might distrust regular user input but be much less cautious about stuff that should presumably be only accessible internally but isn't actually even properly locked behind a VPN gate so a simple credential stuffing would do and from then onwards it is actually easier than a physical kidnapping since you don't need to worry about using physical force to ensure your victim submits, doesn't escape or recognize you. But then you need to actually be smart to make sure you don't de-anonymize yourself in the process, don't render your operation just some temporary disturbance by ensuring your victim doesn't just restore their backups if your goal is a denial of service until you get paid and not expecting ransom for not releasing breach data. Or take carding. Not technically super difficult, especially with the whole illusion of security that many non-technical users have (ie the infamous padlock when I can literally set up a phishing site with letsencrypt that'd log all the form data in minutes), but then good luck cashing out on that with all the KYC on virtually every crypto exchange out there and all that granted 3DS doesn't stop you. permalink fedilink source parent
[–] fkn@lemmy.world 1 point 2 years ago (1 child) I don't think either is actually true. I know many programmers who can fix a problem once the bug is identified but wouldn't be able to find it themselves nor would they be able to determine if a bug is exploitable without significant coaching. Exploit finding is a specific skill set that requires thinking about multiple levels of abstraction simultaneously (or intentionally methodically). I have found that most programmers simply don't do this. I think the definition of "good" comes into play here, because the vast majority of programmers need to dependably discover solutions to problems that other people find. Ingenuity and multilevel abstract thinking are not critically important and many of these engineers who reliably fix problems without hand holding are good engineers in my book. I suppose that it could be argued that finding the source of a bug from a bug report requires detective skills, but even this is mostly guided inspection with modern tooling. permalink fedilink source parent hideshow 2 child comments replies: [–] pkill@programming.dev 1 point 2 years ago* (last edited 2 years ago) Yeah take for instance ransomware. That is easy since a lot of your targets might distrust regular user input but be much less cautious about stuff that should presumably be only accessible internally but isn't actually even properly locked behind a VPN gate so a simple credential stuffing would do and from then onwards it is actually easier than a physical kidnapping since you don't need to worry about using physical force to ensure your victim submits, doesn't escape or recognize you. But then you need to actually be smart to make sure you don't de-anonymize yourself in the process, don't render your operation just some temporary disturbance by ensuring your victim doesn't just restore their backups if your goal is a denial of service until you get paid and not expecting ransom for not releasing breach data. Or take carding. Not technically super difficult, especially with the whole illusion of security that many non-technical users have (ie the infamous padlock when I can literally set up a phishing site with letsencrypt that'd log all the form data in minutes), but then good luck cashing out on that with all the KYC on virtually every crypto exchange out there and all that granted 3DS doesn't stop you. permalink fedilink source parent
[–] pkill@programming.dev 1 point 2 years ago* (last edited 2 years ago) Yeah take for instance ransomware. That is easy since a lot of your targets might distrust regular user input but be much less cautious about stuff that should presumably be only accessible internally but isn't actually even properly locked behind a VPN gate so a simple credential stuffing would do and from then onwards it is actually easier than a physical kidnapping since you don't need to worry about using physical force to ensure your victim submits, doesn't escape or recognize you. But then you need to actually be smart to make sure you don't de-anonymize yourself in the process, don't render your operation just some temporary disturbance by ensuring your victim doesn't just restore their backups if your goal is a denial of service until you get paid and not expecting ransom for not releasing breach data. Or take carding. Not technically super difficult, especially with the whole illusion of security that many non-technical users have (ie the infamous padlock when I can literally set up a phishing site with letsencrypt that'd log all the form data in minutes), but then good luck cashing out on that with all the KYC on virtually every crypto exchange out there and all that granted 3DS doesn't stop you. permalink fedilink source parent
[–] BrianTheeBiscuiteer@lemmy.world 2 points 2 years ago (2 children) Programmers have the source code right in front of them, hackers usually don't. It's quite amazing what they can do taking shots in the dark. permalink fedilink source parent hideshow 4 child comments replies: [–] pkill@programming.dev 1 point 2 years ago (1 child) depends. Desktop code, sure, reverse engineering from assembly takes some time but some good dissasemblers might be able to produce some C skeleton to start from. Though you might get lucky just exploiting the supply chain of bloated open source with a hellton of vulnerabilities deps/infra like glibc, apache or sudo. But web code? Sure, minifiers exist but not every website uses them and even if their do, thanks to all the new stuff since ES5 you can for example spend way less time doing something like finding a Math.random() based, ergo cryptographically utterly broken PRNG. Or for example you can easily rule out whether the website uses header-to-cookie based CSRF protection by just checking the console on any authenticated write-like request. The rest could be automated with things like zaproxy or selenium/curl-impersonate/puppeteer scripts. permalink fedilink source parent hideshow 2 child comments replies: [–] BrianTheeBiscuiteer@lemmy.world 1 point 2 years ago "Hacking" also has plenty of specialties like programming. When I think of hacking my first thought is remote, non-http services. Webservers are fair game for hacking but they're also meant for public consumption so I'd guess monitoring is a bit more severe (not that companies don't skimp on intrusion detection). permalink fedilink source parent [+] pkill@programming.dev 1 point 2 years ago [deleted] permalink fedilink source parent
[–] pkill@programming.dev 1 point 2 years ago (1 child) depends. Desktop code, sure, reverse engineering from assembly takes some time but some good dissasemblers might be able to produce some C skeleton to start from. Though you might get lucky just exploiting the supply chain of bloated open source with a hellton of vulnerabilities deps/infra like glibc, apache or sudo. But web code? Sure, minifiers exist but not every website uses them and even if their do, thanks to all the new stuff since ES5 you can for example spend way less time doing something like finding a Math.random() based, ergo cryptographically utterly broken PRNG. Or for example you can easily rule out whether the website uses header-to-cookie based CSRF protection by just checking the console on any authenticated write-like request. The rest could be automated with things like zaproxy or selenium/curl-impersonate/puppeteer scripts. permalink fedilink source parent hideshow 2 child comments replies: [–] BrianTheeBiscuiteer@lemmy.world 1 point 2 years ago "Hacking" also has plenty of specialties like programming. When I think of hacking my first thought is remote, non-http services. Webservers are fair game for hacking but they're also meant for public consumption so I'd guess monitoring is a bit more severe (not that companies don't skimp on intrusion detection). permalink fedilink source parent
[–] BrianTheeBiscuiteer@lemmy.world 1 point 2 years ago "Hacking" also has plenty of specialties like programming. When I think of hacking my first thought is remote, non-http services. Webservers are fair game for hacking but they're also meant for public consumption so I'd guess monitoring is a bit more severe (not that companies don't skimp on intrusion detection). permalink fedilink source parent