41–50 of 76 posts
I can kind of get behind the malformed header. But I have very hard time thinking up any suite of actions that would lead to a code resulting in leaked obfuscated query with a hard coded password. All while password somehow using a LIKE statement matching a sql injection.
Is there any precedent for this?
Edit: rewrote my sentence because it was barely readable.
Earlier quoted context omitted.
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.
Respectfully, you are incorrect. Delegating session and cookie management to the framework or (in php's case) the language is so much simpler that I have seen manual implementations of this behavior only 2-3 times in my career. And the idea that logging in incorrectly would somehow return a malformed, but correct, session-setting header is again, pathological. Most of the time, these types of profound errors come fro…
That looks like what modern bigcorp webapps do, with random looking css class names that change every release.
Earlier quoted context omitted.
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.
Respectfully, you are incorrect. Delegating session and cookie management to the framework or (in php's case) the language is so much simpler that I have seen manual implementations of this behavior only 2-3 times in my career. And the idea that logging in incorrectly would somehow return a malformed, but correct, session-setting header is again, pathological. Most of the time, these types of profound errors come fro…
I'll trust them on that claim. But is my $100 getting me an industry-certified analysis?
I could hire a licensed MD Engineer Pharmacist Cosmetologist Veterinarian to walk my dog for me, but I don't expect them to perform heart surgery for $100
Is this pen testing or a puzzle? I can kind of get behind the malformed header. But I have very hard time thinking up any suite of actions that would lead to a code resulting in leaked obfuscated query with a hard coded password. All while password somehow using a LIKE statement matching a sql injection. Is there any precedent for this? Edit: rewrote my sentence because it was barely readable.
As a result, those systems are typically harder to maintain or secure by just anybody, even by some experts who are not from the NIH mindset (here's where the author's approach isn't really fair, IMO). Proprietary systems are are less likely to present the typical bell curve security issues that an automated scanner would pick up.
What they are more vulnerable to is puzzle logic--the "what's going on here, hmm let's have a tinker" approach. Which is exactly what the author presented and it also matches his broader approach of "let's have a tinker...with freelancers".
It's a subjective security vs. objective security approach. Both sides are important. But both sides should know about how the other side works.
This is a common problem when hiring supposed experts. Unless the one doing the hiring is reasonably skilled in the area being hired for, it is very difficult to judge the skill and quality of the candidate.
So how would someone know they have connected to a honeypot? Presumably detecting this sort of thing is deliberately difficult, otherwise there isn't much point of the honeypot?
How in the world could that happen?
Edit: I guess it could happen if a developer decided to debug SQL via http response which seems pretty insane
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.