Click here to Skip to main content
15,886,545 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi I have the task of parameterising an old Classic ASP web app. There are literally thousands of SQL strings in the app. My question is: Is it necessary to parameterise secondary/derived variables/data? For example, assuming there is a form that gets submitted by the user. Clearly all the user's input needs to be parameterised. Example: "Insert into Tbl1 (Col1, Col2) values (?, ?)" However, on many pages the app calls other data from the database based on the form data just captured (what I've called secondary/derived data) and this is then used to update/insert into other tables. Example: "Select Value1, Value2 from Tbl1 where Id=(Select Max(Id) from Tbl1)" then "Insert into Tbl2 (Col1, Col2) values (Value1?, Value2?)" where Value1? and Value2? were returned by the select statement.

So, is it necessary to parameterise secondary/derived variables? My thinking is that this is NOT necessary because any SQL injection would have caused the first SQL insert to fail and so the subsequent SQL calls will not get executed. Is this think right or flawed?

What I have tried:

Currently, I'm parameterising all input - primary, secondary and everything in between, but if I can reduce the workload by just parameterising the primary user input, I'd be most grateful.
Posted
Updated 7-Sep-16 18:33pm
Comments
Maciej Los 7-Sep-16 10:46am    
I'm not sure i understand you well, but your confusion araise due to lack of information about SQL. I'd suggest to use only stored procedures.

Generally, I'd say "Parameterise everything".
Think about it: if you SELECT a string that the user entered from a DB, that has the same risk when concatenated into an INSERT command as it was when it was first presented to the DB. Getting
x';DROP TABLES Clients;--
from a DB column doesn't make it any less dangerous than fetching it from a text box.
I parameterise DATETIME values as a matter of course, to avoid confusion between different system settings: passing a raw DateTime value is safer than passing a "stringified" version.
And I parameterise numbers because at some time in the future, it might get changed to a numeric and if it's already a parameter that doesn't cause a problem.

With your "Insert into Tbl2 (Col1, Col2) values (Value1?, Value2?)" query, it's save - provided that the values don't get concatenated in any way (but generally it's better to go with a INSERT INTO SELECT rather than separate the two:
SQL
INSERT INTO Tbl2 (Col1, Col2) SELECT Value1, Value2 FROM Tbl1 WHERE Id=(SELECT MAX(Id) FROM Tbl1)
 
Share this answer
 
I can't see any benefit of not using parameters, instead varying programming style introduces several problems:

1. Program changes, while in the beginning it could be that some of the statements would only be used internally by the program, what if the design changes. You may have completely valid, reusable statement and one could use it in a place where it's run with direct user input.

2. Complexity of choice, you would always need to carefully consider where the statement is used before deciding whether to use parameters or not. I'd say this would be waste of time.

3. Need to do conversions, think about decimals, dates, times, special characters such as ' and so on. You would need to properly take all these aspects into account when building the statement. For example with my regional settings if I'd concatenate a decimal number to an SQL statement, it would fail miserably since my delimiter dfor decimals is comma.

4. Plan re-usability, when parameters are used the database can more easily use an existing execution plan. If you use literals the database may need to do optimization for each statement separately or at least do extra work to identify the statement as an existing one when literals are used. With more complex statements the amount of time wasted is significant.

5. Statement re-usability, in case you need to execute the same statement several times with different values, you can use an exiting statement and command object. Just change the values of the parameters and execute. Otherwise you would need to at least change the statement of the command and this affects client side command cache (if applicable).

As said there are several reasons why to use parameters while I cannot think of any benefits of not using parameters. So:
Quote: Borg[^]
Resistance is futile. You will be assimilated.
:)
 
Share this answer
 
Your thinking is flawed. Parameterizing queries is not for preventing SQL injection attacks, though in some cases it does help.

You parameterize queries for a variety of reasons, some benefits of which are your code writing experience, code maintainability, easier debugging experience, query performance, data integrity and consistency, ...

Why should you NOT parameterize a query? I couldn't tell you. I gave that crap up a very long time ago.
 
Share this answer
 
Comments
Richard Deeming 7-Sep-16 15:58pm    
Surely you mean it's "not only for preventing" SQLi?

And if you do it properly, parameterized queries prevent SQLi in all cases.
Dave Kreskowiak 7-Sep-16 16:11pm    
"If" :)
Thanks to OriginalGriff, Mika and Dave for your valuable input. I guess there is no sortcut! Here goes...
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900