Issues with sql statements built with web inputs 
Author Message
 Issues with sql statements built with web inputs

Our web site serves .asp pages. These pages accept input from the user over
Web forms, construct a select SQL statement and run it against the database.
We wonder if a user can mimic our Web forms, change the
values of the input parameters and insert "funny code" into our SQL
statement. If this can happen, does anybody know what is the best practice
to check for input arguments and other things to protect the integrity of
the constructed SQL statement?

For example, our .asp page expects an argument called "user", and constructs
the following statement.
(The code snippet is written in server-side JScript).
<%
    var usr = Request("user") + "";
    var sqlstmt = "select * from USER where USER_ID = '" + usr + "'";
    runtodatabase (sqlstmt);
%>
What we worry is that somebody can change our web form, and make user =
"billgates'; drop table USER";
In this case our sqlstmt will do the select statement and then execute the
drop table statement.

Thanks for any help,
Nhom Nguyen



Sat, 29 May 2004 05:23:59 GMT
 Issues with sql statements built with web inputs

Hmm, one of the strengths of ASP code is it is server-side. In order for
someone to change the ASP code to drop users, grant permissions, that
individual would need the ability to change the ASP code on your server.
Usually, this level of permissions is not assigned to users and only the IIS
account IUSR_<machinename> has direct access to the source files. In
otherwords, you should be able to lock down your ASP source with NTFS
permissions.

Steve

Quote:
> Our web site serves .asp pages. These pages accept input from the user
over
> Web forms, construct a select SQL statement and run it against the
database.
> We wonder if a user can mimic our Web forms, change the
> values of the input parameters and insert "funny code" into our SQL
> statement. If this can happen, does anybody know what is the best practice
> to check for input arguments and other things to protect the integrity of
> the constructed SQL statement?

> For example, our .asp page expects an argument called "user", and
constructs
> the following statement.
> (The code snippet is written in server-side JScript).
> <%
>     var usr = Request("user") + "";
>     var sqlstmt = "select * from USER where USER_ID = '" + usr + "'";
>     runtodatabase (sqlstmt);
> %>
> What we worry is that somebody can change our web form, and make user =
> "billgates'; drop table USER";
> In this case our sqlstmt will do the select statement and then execute the
> drop table statement.

> Thanks for any help,
> Nhom Nguyen



Sat, 29 May 2004 22:29:15 GMT
 Issues with sql statements built with web inputs
Hung,

This is a very real threat that I spend a great deal of time counseling
developers on.

A good security plan  includes several layers of security starting with the
ASP pages.  First,  use server side filters based upon VB's regular
expression object and filter the incoming data for appropriateness (both
content and length).  Filters should never allow ticks or semicolons to
reach the database.  Never count on client side javascript to do input
filtering.  Also, force their to be some kind of a session variable present
on the users session in order to make a query to the database.  This will
prevent decompiling (view source) simple web poisoning attempts.

Secondly, don't put your connectionstring to your database on your weberver.
Although this is not always possible, by removing connections to the
database from the first data tier, you impliment a level of physical
security between your first two tiers.  Your database server should sit
behind two firewall.  One in front of your web server, the other behind.  By
communicating with an application server also behind the second firewall you
remove direct connectivity to the database from the web tier.

Thirdly, manage permissions on your tables with a hot iron.  Impliment a
stategy where all data is accessed from stored procedures, and revoke all
access to the tables (Select, Insert ....).  Grant the application servers
user role access to execute the stored procedures only.

Lastly, do not use DCOM, use SOAP to communicate with your application
server.  That will allow you to close port 135 on your web server and
shutdown administrtative remote access to your webserver.

I recommend this as a good scenerio for depth and defense.

Geoffrey Lee
Information Security Specialist


Quote:
> Our web site serves .asp pages. These pages accept input from the user
over
> Web forms, construct a select SQL statement and run it against the
database.
> We wonder if a user can mimic our Web forms, change the
> values of the input parameters and insert "funny code" into our SQL
> statement. If this can happen, does anybody know what is the best practice
> to check for input arguments and other things to protect the integrity of
> the constructed SQL statement?

> For example, our .asp page expects an argument called "user", and
constructs
> the following statement.
> (The code snippet is written in server-side JScript).
> <%
>     var usr = Request("user") + "";
>     var sqlstmt = "select * from USER where USER_ID = '" + usr + "'";
>     runtodatabase (sqlstmt);
> %>
> What we worry is that somebody can change our web form, and make user =
> "billgates'; drop table USER";
> In this case our sqlstmt will do the select statement and then execute the
> drop table statement.

> Thanks for any help,
> Nhom Nguyen



Mon, 21 Jun 2004 12:46:12 GMT
 
 [ 3 post ] 

 Relevant Pages 

1. Build SQL statement from ComboBox inputs?

2. Build Sql string with input and output parameter

3. need help inputting two parameters for my sql statement in dts task please

4. Recordset object as input for second SQL statement

5. web.sql form input problem

6. Input Host Variables for SQL statements!

7. build sql-statement dynamically within a stored procedure

8. building SQL statement in a stored procedure

9. Building sql statement string with null values using VB

10. Build char SQL statement and execute it

11. Building SQL statement dynamically for cursor in 6.5

12. Building a sql statement dynamically


 
Powered by phpBB® Forum Software