IIS 5 & IIS 6
Anyone know about www.nihaorr1.com/1.js?
Re: Anyone know about www.nihaorr1.com/1.js?
May 18, 2008 06:38 PM|DavidReabow|LINK
I would still suggest using parameter objects. There are two main reasons for this;
1. You can set the data type of the parameter object and achieve the same "error checking" as you would with CInt.
2. SQL Server treats parameters slightly different to executing a single "string" statement. When a string is executed it is first interpreted or it has to be "prepared" by SQL server for execution and any mal formed character strings that can be interpreted
as executable will be executed. When parameter are passed into a statement they are treated a parameters and mal formed data is not executed.
This takes care of the interface between your development language and SQL Server. I have seen Stored Procedures that take character strings and within the stored procedure build Dynamic SQL statments. If anyone is doing this you are in danger of being attacked
the same way within your SP. This is particularly true where the SP accepts large character strings. To fix this you can also use parameters within TSQL (also known as prepared statements).
I know it isn't always possible as some applications will have to accept long strings but where possible you should also limit the length of your character data.
A combination of many of the previously mentioned solutions would be best. All you really need to achieve is to "break" the execution of the malicious code. Some people have mentioned detecting specific strings from this attack and acting on that. The problem
with this approach is that the attacker could easily change something, All he/she/they need to do is add an extra %20 and your detection will fail.
I still believe that one of the most important things is to use parameter objects at your code level and paremeters (prepared statements) within your SP's.