Bertrand Schmitt wrote:
>
> If you use Stored Procedure calls in your ASP pages this can't
> happen!! Manually creating SQL statements within ASP is poor design :
> not as efficient and secured as storing them in your database server
> (as stored procedures) and making a call to them without speaking
> of coding properly : you do you reuse these pieces of code?!
Actually, it can be argued that using stored procedures is in general bad
design, as it buries your business rules down in the database layer. At the
same time, reliance on stored procedures usually locks you into a single
database vendor, thereby making the system unportable.
A better design is middleware written in a proper, portable language that can
enforce your business rules and validate all input thoroughly, and narrows the
access to the database to a well-defined, well-protected interface. Programmers
can then make major mistakes in the interface code without risking database
compromise. In addition, using middleware gives you the opportunity of using a
language such as Perl that is well adapted to input validation and string
manipulation, and all the advantages of *real* code reuse.
I find the idea of transmitting unvalidated input directly to the database and
leaving validation to the unportable stored procedure code to be distinctly
unsettling, and of no benefit to security.
> Within product.asp dept_id is picked up and used to construct a SQL
> statement.
>
> "select a,b,c,d,e,f,g from table where dept_id = " & Request("Dept_ID")
>
> Further down the page a, b, c, d, e, f and g are response.writed to the
> page.
>
> Think about what happens if the URL above is modified to
>
> http://hostname/product.asp?dept_id=100000 union select
> credit_card_number,null,null,null,null,null, null from Credit_Card_table
--
Jefferson Ogata <jogataat_private> National Oceanographic Data Center
You can't step into the same river twice. -- Herakleitos
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:38:08 PDT