Can anyone explain how in earth could such legislation be approved in a democratic country ?
It seems to me that one could be thrown to jail for something that he _could_ do if he managed to actually build a gun from the blueprint.
I know that in some places there is the concept of "conspiracy to commit a crime" (or something like that), but usually the authorities must build their case on something more tangible...
No - I'm not a fool, but I do security reviews for a living, and this is the kind of stuff a see all the time.
Anyway, my point is about the misconception that parametrized SQLs can get you rid of all kinds of SQL injection. As you wrote, the basic problem is lack os proper user input sanitization.
You can't use parameters for things like table and column names, so you can't write stuff like an "advanced query", where you add additional clauses to a select statement in order, without some kind of string concatenation. This fact, in turn, opens the door to SQL Injections even if you use parametrized queries.
Another scenario is when you use parametrized SQL to call a stored procedure which is vulnerable to SQL injection.
Bottom line: Parametrized SQL helps, but does _not_ completely prevent SQL Injection.
http://en.wikipedia.org/wiki/Occam_programming_language
I remember using this languague back in late 80s. Very simple parallel _constructs_ available in the language itself, backed by machine level support available on the Transputer chips. One idea that comes to mind is to write a T800 emulator that can exploit todays multicore-processor capabilities.
literally don't know ANYONE who does any math, whatsoever, in Excel. Have you ever been in a investment bank, private equity, derivative/"high yield" funds ? ALL they use is Excel. I think that should explain one thing or two about subprime crisis...
If the company is willing to pay you, then they plan to make some profit on it. It's a tipical "build or buy decision".
Try to gather additional information on their intended use for your software. This way you should, at least, be able to begin a negotiation in a more knowledgeable position - a key factor in any negotiation.
Can anyone explain how in earth could such legislation be approved in a democratic country ? It seems to me that one could be thrown to jail for something that he _could_ do if he managed to actually build a gun from the blueprint. I know that in some places there is the concept of "conspiracy to commit a crime" (or something like that), but usually the authorities must build their case on something more tangible...
No - I'm not a fool, but I do security reviews for a living, and this is the kind of stuff a see all the time. Anyway, my point is about the misconception that parametrized SQLs can get you rid of all kinds of SQL injection. As you wrote, the basic problem is lack os proper user input sanitization.
You can't use parameters for things like table and column names, so you can't write stuff like an "advanced query", where you add additional clauses to a select statement in order, without some kind of string concatenation. This fact, in turn, opens the door to SQL Injections even if you use parametrized queries. Another scenario is when you use parametrized SQL to call a stored procedure which is vulnerable to SQL injection. Bottom line: Parametrized SQL helps, but does _not_ completely prevent SQL Injection.
http://en.wikipedia.org/wiki/Occam_programming_language I remember using this languague back in late 80s. Very simple parallel _constructs_ available in the language itself, backed by machine level support available on the Transputer chips. One idea that comes to mind is to write a T800 emulator that can exploit todays multicore-processor capabilities.
If the company is willing to pay you, then they plan to make some profit on it. It's a tipical "build or buy decision".
Try to gather additional information on their intended use for your software. This way you should, at least, be able to begin a negotiation in a more knowledgeable position - a key factor in any negotiation.