I would love to see the exploit. There are vulnerabilities discovered everyday that amount to very little in terms of use in real world implementations.
Yes, recently we got a security “finding” from a security researcher.
His vulnerability required first for someone to remove or comment out calls to sanitize data and then said we had a vulnerability due to lack of sanitation…
Throughout my career, most security findings are like this, useless or even a bit deceitful. Some are really important, but most are garbage.
That’s so idiotic. Either that guy was a total amateur who couldn’t put together that “no shit, if you comment out the lines that do thing, it won’t do thing” or he was completely malevolent and disingenuous and just trying to justify his position by coming up with some crap that the big bosses are probably too stupid to recognize the idiocy of.
Either way, not someone I would want to be doing business with…
He had the persosctive that once you hop between source code files that constitutes a security boundary. If you had intake.c and user data.c that got linked together, well data.c needed its own sanitation… Just in case…
I suspect he used a tool that checked files and noted the risky pattern and the tool didn’t understand the relationship and be was so invested that he tortured it a bit to have any finding. I think he was hired by a client and in my experience a security consultant always has a finding, no matter how clean in practice the system was.
Another finding by another security consultant was that an open source dependency hasn’t had any commits in a year. No vulnerabilities, but since no one had changed anything, he was concerned that if a vulnerability were ever found, the lack of activity means no one would fix it.
It’s wild how very good security work tends to share the stage with very shoddy work with equal deference by the broader tech industry.
It may not be completely crazy, depending on context. With something like a web app, if data is being sanitized in the client-side Javascript, someone malicious could absolutely comment that out (or otherwise bypass it).
With that said, many consultant-types are either pretty clueless, or seem to feel like they need to come up with something no matter how ridiculous to justify the large sums of money they charged.
In this case, there was file a, which is the backend file responsible for intake and sanitation. Depending on what’s next, it might go on to file b or file c. He modified file a.
His rationale was that every single backend file should do sanitation, because at some future point someone might make a different project and take file b and pair it with some other intake code that didn’t sanitize.
I know all about client side being useless for meaningful security enforcement.
I would love to see the exploit. There are vulnerabilities discovered everyday that amount to very little in terms of use in real world implementations.
Yes, recently we got a security “finding” from a security researcher.
His vulnerability required first for someone to remove or comment out calls to sanitize data and then said we had a vulnerability due to lack of sanitation…
Throughout my career, most security findings are like this, useless or even a bit deceitful. Some are really important, but most are garbage.
That’s so idiotic. Either that guy was a total amateur who couldn’t put together that “no shit, if you comment out the lines that do thing, it won’t do thing” or he was completely malevolent and disingenuous and just trying to justify his position by coming up with some crap that the big bosses are probably too stupid to recognize the idiocy of.
Either way, not someone I would want to be doing business with…
He had the persosctive that once you hop between source code files that constitutes a security boundary. If you had intake.c and user data.c that got linked together, well data.c needed its own sanitation… Just in case…
I suspect he used a tool that checked files and noted the risky pattern and the tool didn’t understand the relationship and be was so invested that he tortured it a bit to have any finding. I think he was hired by a client and in my experience a security consultant always has a finding, no matter how clean in practice the system was.
Another finding by another security consultant was that an open source dependency hasn’t had any commits in a year. No vulnerabilities, but since no one had changed anything, he was concerned that if a vulnerability were ever found, the lack of activity means no one would fix it.
It’s wild how very good security work tends to share the stage with very shoddy work with equal deference by the broader tech industry.
It may not be completely crazy, depending on context. With something like a web app, if data is being sanitized in the client-side Javascript, someone malicious could absolutely comment that out (or otherwise bypass it).
With that said, many consultant-types are either pretty clueless, or seem to feel like they need to come up with something no matter how ridiculous to justify the large sums of money they charged.
In this case, there was file a, which is the backend file responsible for intake and sanitation. Depending on what’s next, it might go on to file b or file c. He modified file a.
His rationale was that every single backend file should do sanitation, because at some future point someone might make a different project and take file b and pair it with some other intake code that didn’t sanitize.
I know all about client side being useless for meaningful security enforcement.