- Input validation is a key for secure applications. In all topics you should consider INPUT VALIDATION. Use an “accept known good” validation strategy.
- Use strongly typed parametrized query APIs with placeholder substitution markers, even when calling stored procedures.
- Enforce least privilege when connecting to databases and other back-end systems.
- Avoid detailed error messages that are useful to an attacker. Don’t forget that attacker accumulate clues from your error messages.
SQL Injection Attack
- Weak input validation.
- Dynamic construction of SQL statements without the use of type-safe parameters.
- Use of over-privileged database logins.
The web application is using following query to display data in a page.
Suppose the catID required by the SQL query is passed using a query string as follows:
SELECT * FROM Products WHERE CategoryID = 1 or 1=1
Obviously 1=1 always evaluates to true so the filter by category is entirely invalidated. Rather than displaying only beverages we’re now displaying products from all categories.
This is just a small example of SQL injection the same above query can be used to get more information about other tables and its data. The only thing the hacker will require is some common sense and combination of data which will either pass or fail.
Suppose now it modifies the query string as follows:
http://localhost:8000/MyProductList.aspx?CategoryID=1;update products set productname=ProductHacked
SELECT * FROM Products WHERE CategoryID = 1;update products set productname= ProductHacked
You are really hacked now. There is no limit to this and hacker can go beyond our imaginations.
- Constrain input. All input must be validated against a white-list of acceptable value ranges.
- Use parameters with stored procedures.
- Use parameters with dynamic SQL. Use Named SQL parameters.
- Use ORM like Entity Framework, N Hibernate, LINQ to SQL etc
- Applying the principle of least privilege
XML Injection and XPath Injection
- This can be prevented in a similar way to SQL Injection. The best way is to carefully sanitize user input. Any data received from a user should be considered unsafe. Removing all single and double quotes should remove most types of this kind of attack.
- Beware that removing quotes can have side effects, such as when usernames might contain valid quotes. Imagine common names such as O’Malley, which contains a legitimate quote and may be input on a name request form. In these cases, the input should be escaped, often by adding a \ in front of quotes. Check with your specific library and XML software for the proper syntax.