31–40 of 76 posts
This comes down to the fact that penetration testing has a high false-negative rate. There's no way for a customer to really evaluate what a mostly empty report means, if there actually are no bugs, or the penetration tester missed them/did a poor job.
The problem that strikes me here (as a professional pentester) is that these vulnerabilities are so pathological. There is no realistic series of errors that would lead you to really design an app with hardcoded sqli looking credentials or somehow return a cookie with a malformed header, let alone one that somehow automatically authenticated the user. I am extremely onboard with the idea that pentesting as a whole ha…
They might have hardcoded admin-level passwords for debugging, then forgotten about it.
They might have mis-typed HTTP headers like 'set-cookie', after having written manually a lot of auth & session management that should really be done using well-vetted libraries instead.
Because for most people its not about security, its about liability and having a proven attempt at trying to "security" implies in their minds that they are not liable.
Sadly security is a mindset and a process like healthy eating but we socially model it as a eating a single apple which translates to hiring one person for less than $100 and taking what they say as authority.
People are paying pentesters because their payer’s policy asks them to. Of course there will be a huge market for someone with an alleged certification to run automated tools, the value is in the box checking and report generation, not the bespoke broken website fixing.
Obviously this is a bit of a reaching statement, some organizations understand the legal, career, and regulatory risk and proactively do it. In every org I've sat down with the head to explain those risks, I can see how it can be made priority and budget.
The problem that strikes me here (as a professional pentester) is that these vulnerabilities are so pathological. There is no realistic series of errors that would lead you to really design an app with hardcoded sqli looking credentials or somehow return a cookie with a malformed header, let alone one that somehow automatically authenticated the user. I am extremely onboard with the idea that pentesting as a whole ha…
I suspect these would be realistic vulnerabilities introduced by freelance or inexperienced devs hired by a startup, for example. They might have hardcoded admin-level passwords for debugging, then forgotten about it. They might have mis-typed HTTP headers like 'set-cookie', after having written manually a lot of auth & session management that should really be done using well-vetted libraries instead.
Back at my startup days, I once worked with a poor guy who was dynamically generating individual IDs for each element on a page and their corresponding CSS for each page. He was unaware that CSS also had _classes_, which perfectly encapsulated the behavior he was trying to create. His work was complex, and full of errors, but it had a certain logic to it- it was the path of least resistance that he saw available to him.
These don't look like that. They just look like weird errors designed to avoid showing up on, or triggering false positives on, DAST tools. I thinking testing people's skills without those tools is a good goal, i just think the methodology here is wrong.
The problem that strikes me here (as a professional pentester) is that these vulnerabilities are so pathological. There is no realistic series of errors that would lead you to really design an app with hardcoded sqli looking credentials or somehow return a cookie with a malformed header, let alone one that somehow automatically authenticated the user. I am extremely onboard with the idea that pentesting as a whole ha…
I realize that in this scenario it is literally designed-in, but I understand the point the author is trying to prove. If a "scanner jokey" gets results that tells him or her there is SQL injection, a competent tester will try to verify what their tool is telling them. If the tester is doing that in this case, they'll find other injection strings not working and (hopefully) start looking under the hood to see what is going on and discover this pathological hard-coded pw and be able to tell the client that. Maybe it's the work of a malicious dev?
I agree that a pentester with a lot of experience will have skills that are honed to find common bug patterns, but it's nice to be able to find these seemingly bizarre issues and have an explanation for the client. It shows you really understood the app and what it's doing.
Earlier quoted context omitted.
Obviously this is a bit of a reaching statement, some organizations understand the legal, career, and regulatory risk and proactively do it. In every org I've sat down with the head to explain those risks, I can see how it can be made priority and budget.
will it survive budget review though?
Edit: Followup - here is a primer method. The exact method differs if you are talking with leaders, or middle management, or space occupiers. (Leaders as in intelligent, aggressive forward thinkers). You have to make it personal, and show them how the thing that they care most about (eg: career, personal security, promotion, or liability exposure) is at risk; which now-a-days is a true statement.
Clickbait title. I refuse to click.