?

Search Help Board

PHP FAQ
PHP Articles
PHP Help
Bulletin Board

PHP Manual (NEW!)
First Time PHP'ers
Help with programming
Sql assignment help
PHP Homework Help


C# Help

?
?Re: PHP Post security
Author:??(---.scpe.powergate.ca)
Date:???02-18-04 05:14

Well, the simplest one to look at is the sql injection attacks. You can copy the form locally and insert your own values into the textboxes but assigning the value to the VALUE attribute of the text element.

The below is from an article on www.4guysfromrolla.com about ASP but the principle is the same for PHP. It makes for interesting reading and has some links to other articles.(link:http://www.4guysfromrolla.com/webtech/061902-1.shtml)

There are some PHP security articles here http://www.phpbuilder.com/columns/index.php3?cat=6&subcat=46

Login.htm

Username:

Password:




ExecLogin.asp
<%
Dim p_strUsername, p_strPassword, objRS, strSQL

p_strUsername = Request.Form("txtUsername")
p_strPassword = Request.Form("txtPassword")

strSQL = "SELECT * FROM tblUsers " & _
"WHERE Username='" & p_strUsername & _
"' and Password='" & p_strPassword & "'"

Set objRS = Server.CreateObject("ADODB.Recordset")
objRS.Open strSQL, "DSN=..."

If (objRS.EOF) Then
Response.Write "Invalid login."
Else
Response.Write "You are logged in as " & objRS("Username")
End If

Set objRS = Nothing
%>




At first glance, the code in ExecLogin.asp does not appear to contain any security holes. The user cannot log in without a valid username/password combination. However, this code is not safe, and is primed for a SQL injection attack. Specifically, the vulnerability is contained in the fact that user input is used to directly build the SQL statement, in effect enabling an attacker to control the statement executed.

An example of the vulnerability would be if the following string was entered into the username/password fields: ' or ''='. The SQL statement would then be executed as:

SELECT * FROM tblUsers WHERE Username='' or ''='' and Password = '' or ''=''


This query will return all records from tblUsers, and the script will proceed to log the user in as the first user identified by the first record in the table.

Another variation of the SQL injection attack exists when receiving querystring parameters to generate dynamic pages. Below is an example of an ASP page that accepts an ID through the querystring, and dynamically generates the page's content based on the ID:

<%
Dim p_lngID, objRS, strSQL
p_lngID = Request("ID")

strSQL = "SELECT * FROM tblArticles WHERE ID=" & p_lngID

Set objRS = Server.CreateObject("ADODB.Recordset")
objRS.Open strSQL, "DSN=..."

If (Not objRS.EOF) Then Response.Write objRS("ArticleContent")

Set objRS = Nothing
%>




Under normal circumstances, this script would display the content of the article whose ID was passed as a querystring parameter. For example, the page might be called as: http://www.example.com/Article.asp?ID=1055, thereby showing the dynamic content for article 1055.

Like our login example, this code opens itself to a SQL injection attack. A malicious user could substitute the valid Article ID for an unauthorized SQL command by passing into the ID something like: 0 or 1=1 (i.e., http://www.example.com/Article.asp?ID=0 or 1=1).

The SQL query would return all articles from the table for it would be executed as:

SELECT * FROM tblArticles WHERE ID=0 or 1=1


Of course, this example may not appear to be highly dangerous, but the attacker would then be able to manipulate the application even further by inserting malicious commands, such as DELETE statements. All of this could be done by simply manipulating the querystring! For example, anyone could call the page using a querystring like: http://www.example.com/Article.asp?ID=1055; DELETE FROM tblArticles.

The Implications of SQL Injection
The full implications of this vulnerability vary greatly based on environment and configuration. If the database connection uses the security context of dbo, it is possible to drop all tables in the database, create new tables, etc. If the database connection uses the security context of sa, it is possible to control the entire SQL Server, and under the right configuration even create user accounts to take control of the Windows server hosting the database.

Protecting Applications from SQL Injection
The first thing to do is to protect SQL queries by implementing sanitization techniques for all input received from any ASP request object (Request, Request.QueryString, Request.Form, Request.Cookies, and Request.ServerVariables). Your sanitization routines will vary based on your DBMS, but examples for MS SQL Server are given below.

In the login page example, the script was expecting two variables (txtUserName, txtPassword) of type string to be passed. When a single quote is inserted in a parameter, it allows the user to manipulate the command being executed. To combat the threat of SQL injection, escape the single quotes using the Replace function, like so:

p_strUsername = Replace(Request.Form("txtUsername"), "'", "''")
p_strPassword = Replace(Request.Form("txtPassword"), "'", "''")


In the second example, the script was expecting a variable (ID) of type long integer to be passed. Unauthorized SQL commands can be executed by appending SQL to the ID parameter. To combat this type of SQL injection, simply restrict the input to a long integer using CLng, like so:

p_lngID = CLng(Request("ID"))


If the user tries to pass in a string, the CLng function will generate an error.

To further reduce the risk of SQL injection, be sure to remove any technical information from client-delivered error messages. Error messages often reveal technical details that can enable an attacker to reveal vulnerable entry points. This includes any custom messages your application generates as well as IIS-generated errors. You can implement this by disabling detailed error messages in IIS and by creating non-technical custom error pages. (For more information on creating custom error pages in IIS be sure to read: Creating Custom ASP Error Pages.)

Finally, to limit the scope of a SQL injection attack, limit the permissions granted to the database user account the Web application is using. The application generally doesn't need dbo or sa permissions. The less permission granted to your database the better! Consider using a separate account for each component with data access capabilities to isolate vulnerabilities. For instance, a front-end public interface to your Web site needs more restricted DB access than an internal content management system.

?Topics Author? Date
?PHP Post security??new
Andrew Gibbs 02-17-04 01:16?
?Re: PHP Post security??new
bastien 02-17-04 09:18?
?Re: PHP Post security??new
Andrew Gibbs 02-17-04 10:34?
?Re: PHP Post security??new
bastien 02-17-04 14:20?
?Re: PHP Post security??new
Andrew Gibbs 02-18-04 01:35?
?Re: PHP Post security??new
bastien 02-18-04 05:14?
?Re: PHP Post security??new
shjock 02-18-04 03:50?
Go to Top??|??Go to Topic??|??Flat View??|??Search?
??|??
New Topic
?Reply To This Message
?Your Name:
?Your Email:
?Subject:
Email replies to this thread, to the address above.
??wrote: > > Well, the simplest one to look at is the sql injection > attacks. You can copy the form locally and insert your own > values into the textboxes but assigning the value to the > VALUE attribute of the text element. > > The below is from an article on www.4guysfromrolla.com about > ASP but the principle is the same for PHP. It makes for > interesting reading and has some links to other > articles.(link:http://www.4guysfromrolla.com/webtech/061902-1.shtml) > > There are some PHP security articles here > http://www.phpbuilder.com/columns/index.php3?cat=6&subcat=46 > > Login.htm >
> Username:
> Password:
> >
> > ExecLogin.asp > <% > Dim p_strUsername, p_strPassword, objRS, strSQL > > p_strUsername = Request.Form("txtUsername") > p_strPassword = Request.Form("txtPassword") > > strSQL = "SELECT * FROM tblUsers " & _ > "WHERE Username='" & p_strUsername & _ > "' and Password='" & p_strPassword & "'" > > Set objRS = Server.CreateObject("ADODB.Recordset") > objRS.Open strSQL, "DSN=..." > > If (objRS.EOF) Then > Response.Write "Invalid login." > Else > Response.Write "You are logged in as " & objRS("Username") > End If > > Set objRS = Nothing > %> > > > > > At first glance, the code in ExecLogin.asp does not appear to > contain any security holes. The user cannot log in without a > valid username/password combination. However, this code is > not safe, and is primed for a SQL injection attack. > Specifically, the vulnerability is contained in the fact that > user input is used to directly build the SQL statement, in > effect enabling an attacker to control the statement executed. > > An example of the vulnerability would be if the following > string was entered into the username/password fields: ' or > ''='. The SQL statement would then be executed as: > > SELECT * FROM tblUsers WHERE Username='' or ''='' and > Password = '' or ''='' > > > This query will return all records from tblUsers, and the > script will proceed to log the user in as the first user > identified by the first record in the table. > > Another variation of the SQL injection attack exists when > receiving querystring parameters to generate dynamic pages. > Below is an example of an ASP page that accepts an ID through > the querystring, and dynamically generates the page's content > based on the ID: > > <% > Dim p_lngID, objRS, strSQL > p_lngID = Request("ID") > > strSQL = "SELECT * FROM tblArticles WHERE ID=" & p_lngID > > Set objRS = Server.CreateObject("ADODB.Recordset") > objRS.Open strSQL, "DSN=..." > > If (Not objRS.EOF) Then Response.Write > objRS("ArticleContent") > > Set objRS = Nothing > %> > > > > > Under normal circumstances, this script would display the > content of the article whose ID was passed as a querystring > parameter. For example, the page might be called as: > http://www.example.com/Article.asp?ID=1055, thereby showing > the dynamic content for article 1055. > > Like our login example, this code opens itself to a SQL > injection attack. A malicious user could substitute the valid > Article ID for an unauthorized SQL command by passing into > the ID something like: 0 or 1=1 (i.e., > http://www.example.com/Article.asp?ID=0 or 1=1). > > The SQL query would return all articles from the table for it > would be executed as: > > SELECT * FROM tblArticles WHERE ID=0 or 1=1 > > > Of course, this example may not appear to be highly > dangerous, but the attacker would then be able to manipulate > the application even further by inserting malicious commands, > such as DELETE statements. All of this could be done by > simply manipulating the querystring! For example, anyone > could call the page using a querystring like: > http://www.example.com/Article.asp?ID=1055; DELETE FROM > tblArticles. > > The Implications of SQL Injection > The full implications of this vulnerability vary greatly > based on environment and configuration. If the database > connection uses the security context of dbo, it is possible > to drop all tables in the database, create new tables, etc. > If the database connection uses the security context of sa, > it is possible to control the entire SQL Server, and under > the right configuration even create user accounts to take > control of the Windows server hosting the database. > > Protecting Applications from SQL Injection > The first thing to do is to protect SQL queries by > implementing sanitization techniques for all input received > from any ASP request object (Request, Request.QueryString, > Request.Form, Request.Cookies, and Request.ServerVariables). > Your sanitization routines will vary based on your DBMS, but > examples for MS SQL Server are given below. > > In the login page example, the script was expecting two > variables (txtUserName, txtPassword) of type string to be > passed. When a single quote is inserted in a parameter, it > allows the user to manipulate the command being executed. To > combat the threat of SQL injection, escape the single quotes > using the Replace function, like so: > > p_strUsername = Replace(Request.Form("txtUsername"), "'", "''") > p_strPassword = Replace(Request.Form("txtPassword"), "'", > "''") > > > In the second example, the script was expecting a variable > (ID) of type long integer to be passed. Unauthorized SQL > commands can be executed by appending SQL to the ID > parameter. To combat this type of SQL injection, simply > restrict the input to a long integer using CLng, like so: > > p_lngID = CLng(Request("ID")) > > > If the user tries to pass in a string, the CLng function will > generate an error. > > To further reduce the risk of SQL injection, be sure to > remove any technical information from client-delivered error > messages. Error messages often reveal technical details that > can enable an attacker to reveal vulnerable entry points. > This includes any custom messages your application generates > as well as IIS-generated errors. You can implement this by > disabling detailed error messages in IIS and by creating > non-technical custom error pages. (For more information on > creating custom error pages in IIS be sure to read: Creating > Custom ASP Error Pages.) > > Finally, to limit the scope of a SQL injection attack, limit > the permissions granted to the database user account the Web > application is using. The application generally doesn't need > dbo or sa permissions. The less permission granted to your > database the better! Consider using a separate account for > each component with data access capabilities to isolate > vulnerabilities. For instance, a front-end public interface > to your Web site needs more restricted DB access than an > internal content management system. ">??

Provided By
Phorum