Main Area and Open Discussion > General Software Discussion

Lizamoon Attack Targets SQL Injection Vulnerability

<< < (3/3)

wraith808:
^ True... that was just a simplistic example from the past :)  But yes, it could be legitimate in some situations.

Renegade:
If you use bound arguments, btw, scrubbing for the various SQL keywords shouldn't be necessary - and it might not be a good idea to scrub for it where you're doing, Wraith - stuff like "update" or "delete" could very well be valid in a lot of situations... but even with bound arguments, some data validation/scrubbing is a good idea, you might be interfacing with a system where the rest of the components are retarded. And depending on what you do, there might even be more cases of scrubbing you need to do (dealing with HTML tags being one very common and important subject).

Btw, it's almost always a bad idea to use regular expressions for this - for single-word deletes/replacements you can go faster without, and for more complex scenarios you'll need a proper parsing engine to not fight a hopeless battle.
-f0dder (April 03, 2011, 03:13 PM)
--- End quote ---

+1

CWuestefeld:
What Renegade said.

There is absolutely no excuse for SQL Injection attacks to work. The kind of programming that sets up this vulnerability is just bad programming. *Every* communication with the DB should pass data via out-of-band parameters, rather than with the values concatenated in, no exceptions. And doing so is easy, at least on any decent development platform.

Doing it the right way


* Is secure, which should be all the reason you need. It's very difficult to cover all the possibilities if you don't do it this way, far harder than actually doing it right.
* Is more performant. Many database engines (including MS SQL Server up to SQL 2005, iirc) are able to cache query plans if the data is parameterized, but if the query is hard-coded (from the DB's point of view), it gets cached with those specific values.
* Is a better user experience. Anytime you've got to sanitize the user's input, it means that you're either forbidding the user from entering some set of values that he might want, or mangling his data. The naive example (that you still see occasionally) is the removal of quotes, like changing someone's name from O'Reilly to OReilly.
Bottom line: if you want to work on my team, at least, you will do it the right way, or you won't work here. Period.

Stoic Joker:
I gotta go with barney here, much vehemence is coming from the pulpit ... but no details.

Sure specific general statements are made about do X not Y ... But no how is given.

Many of the concepts mentioned in this thread could take a great deal of time to explain, or research, I'm sure. But if (say) 3 - 5 lines of code were posted with them outlining what is to should be happening. Well... That could ge a long way towards being part-of-the-solution ...Don't Ya think?


While wraith808's example might not have been the most perfectly correct answer. It was at least one of the best attempts at a clear straight answer I've seen yet.

Navigation

[0] Message Index

[*] Previous page