Web programming blog

When you start programming, you can find beginners mistakes in misspelling, missing “;”, … But leter you’ll find there exists logical errors too. Your code has no errors or warnings, but application behavior is different. It is so called logical errors. This post is about some security mistakes which .net developer makes.

1-st Mistake: SQL Injection
SQL injection is passing SQL code into an application. These potential attack strings are parts of SQL query that can be executed on the database server if the Web application uses the string when forming a SQL statement without first parsing out certain characters.

For example, problems can arise when a developer does not protect against potentially malicious input such as a ” ‘ “, which could close the SQL string and give the user unintended system and application access. The simple and most common SQL query which developer use during login process looks like:

SELECT userID, fname, lname from users WHERE username = $username and password = $password

An example of SQL injection would be for the user to enter the following strings for the username and password:

‘ OR ‘1′ = ‘1

The SQL statement passed to the database now reads like this:

SELECT CustomerID FROM Customers WHERE EmailAddress = '' OR '1' = '1'
AND Password = '' OR '1' = '1'
SELECT userID, fname, lname from users WHERE username = '' OR '1' = '1' and password = '' OR '1' = '1'

Since the WHERE clause of the SQL statement will be satisfied by the always-true condition ‘1′ = ‘1′, the SQL statement will login you successfully.
Here is another example of a more destructive SQL injection. You may have text field for entering email address for newsletter. And what if someone put this for e-mail address.

'; DELETE FROM Customers;

The SQL now reads:

SELECT CustomerID FROM Customers WHERE EmailAddress = ”; DELETE FROM Customers;

If you really have table named Customers, all data will be erased.

2-nd Mistake : Cross-Site Scripting
Each user input must be validated. Especially if you show entered data to page in next screen.
Taking user input and returning it to the user without proper encoding causes cross-site scripting. Cross-site scripting occurs when dynamically generated Web pages display input that is not properly validated. This is also knows as XSS or CSS scripting. For cross-site scripting demonstartion, enter the following text into any form field whose value will be displayed on the page after it is posted back (for example, it can be a search filed):

<script>alert(’Some Message’)</script>

If, when the page posts back, you see a pop-up message box with the message “Some Message”, then that page is vulnerable to cross-site scripting.

How to solve it in .NET? By passing all user input through the Server.HTMLEncode() function, the cross-site scripting hole is automatically fixed.

3-hd Mistake: Enabling Debug Options in the Web.Config File
The section of the Web.Config file tells a .NET application how to deal with errors. An application should never show an end user a detailed error message. Instead, it should show a “friendly” message that says the site is having technical difficulties, and not give any technical details.

Attackers can get some valuable information from error messages. That means you have to enable detailed error messages. This is one of possible settings for tag in Web.config file.