3 ms·
> trivial for any highly skilled security tester to interface this way with your database. It's not if you're not doing dumb stuff.
by piranha 14y ago
> trivial for any highly skilled security tester to interface this way with your database.
It's not if you're not doing dumb stuff.
- shanelja 14y agoI suppose so, but this heavily relies on no one in your operation having made a mistake, or that mistake having been caught before it was pushed live. You have to be lucky every time, an attacker only needs to be lucky once.
- fusiongyro 14y agoAbove you are essentially saying every application has SQL injection vulnerabilities and any good security guy will find them. This is a very specific and dubious conclusion to draw from the more general principle that there will be some vulnerability, somewhere. SQL injection specifically is quite easy to avoid. With some frameworks it would actually be rather laborious to introduce an SQL injection vulnerability. This is what Alexander is alluding to. This does not imply that applications are easily secured, just that this attack vector isn't what it used to be.
- PeterisP 14y agoWell, statistics of pentests does show that, if tested, the vast majority of good quality, generally securely built applications have some vulnerabilities, and average applications have a huge multitude of vulnerabilities. SQL injections are just one class of many. There are ways to vastly reduce SQL injection risks but that still leaves many other venues of attack.
- papsosouid 14y agoNo, I never have to be lucky at all. I literally can not put an SQL injection vulnerability into production unless I do so deliberately, my code wouldn't compile. Not everyone uses terrible rails style "lets automagically do shit behind your back so security holes are hidden from you" frameworks.
- b6 14y agoYou're being too harsh. You seem to be talking about Haskell, so saying "not everyone" is a weird way to put it. You really mean a tiny fraction of people use Haskell to be safe in advanced ways. Well, Haskell is ahead of its time. Of course not that many people use it. Even Haskell is not a silver bullet against every kind of security problem. Didn't Snap have a directory traversal bug a while back?
- papsosouid 14y agoI don't understand what you are trying to convey. It appears like a deliberate red herring to try to distract from what I actually said. I personally use haskell, but you do not need to do so to get a complete guarantee against SQL injection. Nobody said anything about silver bullets or protecting against every security problem. I very clearly said SQL injection is a solved problem, in reply to someone claiming every single web app has SQL injection vulnerabilities in it and that any security researcher can easily sit down and exploit them, and the only way to deal with SQL injection is to be lucky over and over.
- b6 14y agoYou are being too harsh (again). Whatever problems you deal with, whatever mistakes you make in your professional work, are also solved problems, using some technology that is unacceptable to you (probably for very good reasons). You could have been informative and made your original point tactfully. Instead, you badmouthed a certain technology without even naming the stuff that was supposedly better. I'm a Haskell evangelist and agree with you 100%, and you came off like a jerk even to me.
- papsosouid 14y agoI think perhaps we are operating with very different definitions of harsh. If your response is simply intended to be a poor attempt at criticizing my tone, you did not make that clear. Obviously such vacuous nonsense would not warrant a response. Your assertion that whatever problems I deal with are solved problems is absolutely insane. Please, tell me how problems like interpreting customers requirements are "solved" and what technology I can use to ensure that all the code I write will 100% always match the users mental picture of what they wanted. Criticizing the choice to deliberately create security holes for convenience is not "badmouthing", and "I'm offended" is not a productive response. It literally conveys no useful information at all.