7 posts • joined Friday 8th August 2008 10:47 GMT
(PC mostly) But..
To name just four progs that allow to you travel universe (locally that is), just like a child. And you don't hav e to leave the living room.
Ta for that, wasn't sure. It worse though.
Any data sent back to their server could potentially be used to gather such intel. Anything big enough to store a unique id.
Hi again. Just in case you return to this topic.
In short, yes both descriptions above seem to be vunerable to SQL injection attack. Sorry. It took me a while to get back on this.
In ac's case the keyword is append. It may be a stored proc but appending in a raw input strings still seems dangerous to me. I cannot prove it. Not familar enough with JS ADO to given an example.
Dominic, I not sure how in_user, in_pwd get loaded with data. I see nothing to prevent raw input being executed by the SQL engine.
Try ' ; drop tables; drop database; '
Even from your description the input string seems to get directly into the SQL without checks. It may be my lack of understanding, but the query gets parsed then the bind variable/string is added directly. If the completed query is/was parsed then maybe its ok. It depends what parsed means. If parsing means; check the SQL syntax grammer is correct (normal), then trouble. If it means lexically strip for known bad characters (Not the normal meaning) then ok. Also, I would suggest this is better done before adding it into the query, because the query might legitmately have a semicolon in it.
More on semicolon stripping
@Steve Foster & Dominic
Yes early binding of variables ensure numerics and date type cannot be messed with, but it does not deal with plain old text/strings. I not sure parameterisation helps ala some MS help texts.
The semicolon allows SQl requests to run one after the other. e.g.
SELECT * FROM anytable; SELECT * FROM anytable2; SELECT * FROM anytable3;
Is legitimate SQL.
Combine it with singlequotes, the SQL string delimiter, and commenting --
You can insert your chosen damaging SQL instruction into any existing statement parameterised or not, if the input text box allows you enough characters!
The singlequote and semicolon close off the prebuilt/programmed first query. Allowing your query to run. The comment chucks away any remaining bit of
prebuilt/programmed first query.
As a victim, we are to blame! Just in case somebody reads this and does not know what to do!
Strip out the semicolons, single quotes and greaterthan and lessthan characters from all input passed to all SQL queries. I missed one input and got clobbered.
As mentioned on El Reg, before and often.