Mahmud's blog

Asp.net security best practices

2009-09-14T00:23:00Z

To help protect the site from intruders and attackers I have studied and explored Microsoft suggested best practices for security and based on that we should follow the measures listed below.

1. Input Data Validation

i. Do not make ValidateRequest = false in web.config file. Make it false at page level where required.

ii. Validate input for length, range, format an type.

iii. Validate input from different sources like QuesryString, Cookies, HTML controls etc.

iv. Do not rely on client side validation. Server side validation must be done.

v. If you need any file path from any file name Ensure that file paths only refer to files within your application's virtual directory hierarchy if that is appropriate. When checking file names, obtain the full name of the file by using the System.IO.Path.GetFullPath method.

vi. If you use MapPath to map a supplied virtual path to a physical path on the server, use the overloaded Request.MapPath method that accepts a bool parameter so that you can prevent cross-application mapping. The following code example shows this technique. Here is the sample code:

try

{

string mappedPath = Request.MapPath(inputPath.Text,

Request.ApplicationPath, false);

}

catch (HttpException)

{

// Cross-application mapping attempted

}

vii. If you write output that includes user input or data from a shared database or a local file that you do not trust, encode it. Echoing input directly back to the user makes your application vulnerable to cross-site scripting attacks. Encoding the data ensures that it is treated as literal text and not as script. You can use the HttpUtility.HtmlEncode method. Similarly, if you write URLs that might contain unsafe characters because they have been constructed from input data or data from a shared database, use HttpUtilty.UrlEncode to make them safe.

2. Forms Authentication

i. Validate user login information including user names and passwords for type, length, format, and range. Use regular expressions to constrain the input at the server. Do not use login details to dynamically construct SQL statements because this makes your code susceptible to SQL injection. Instead, validate the input and then use parameterized stored procedures.

ii. Do not store user passwords either in plaintext or encrypted format. Instead, store password hashes with salt. By storing your password with hashes and salt, you help prevent an attacker that gains access to your user store from obtaining the user passwords. If you use encryption, you have the added problem of securing the encryption key.

iii. If you must implement your own user stores (We are not still confirm if we can extend asp.net membership to fulfill our requirement. ), store one-way password hashes with salt. Generate the hash from a combination of the password and a random salt value. Use an algorithm such as SHA256. If your credential store is compromised, the salt value helps to slow an attacker who is attempting to perform a dictionary attack. This gives you additional time to detect and react to the compromise.

iv. Enforce Strong Passwords

v. Do Not Persist Authentication Cookies. Here is the sample code to do this:

// Parameter two set to false indicates non-persistent cookie

FormsAuthentication.RedirectFromLoginPage(username.Text, false);

vi. Set the secure property of the authentication cookie to ensure that browsers only send authentication cookies over HTTPS connections. By using SSL, you prevent an attacker from capturing the authentication cookie to gain spoofed access to your application.Set the secure property by using requireSSL="true" on the <forms> element as shown here. Here is the configuration:

3. Code Access Security (We will have to do more work to define CAS for OPLM)

i. Consider code access security for partial trust applications.

ii. Choose a trust level that does not exceed your application's requirements.

iii. Create a custom trust policy if your application needs additional permissions.

iv. Use Medium trust in shared hosting environments.

4. Data Access

i. Encrypt your connection strings.

ii. Use Least-Privileged Accounts for Database Access.

iii. When Using SQL Authentication, Use Strong Passwords. A strong password should be at least seven characters in length and contain a combination of alphabetic, numeric, and special characters.

iv. When Constructing SQL Queries, Use Type Safe SQL Parameters.

v. Avoid Dynamic Queries That Accept User Input

5. Exception Management

i. Use Structured Exception Handling

ii. Do Not Reveal Exception Details to the Client

iii. You should also use the <customErrors> section of the Web.config file as shown in the following code example to specify a default error page to display, along with other required error pages for specific HTTP response codes that indicate errors. Here is a sample configuration:

</customErrors>

iv. Use a Global Error Handler to Catch Unhandled Exceptions in Global.Asax file.

v. Use Microsoft Enterprize Library Exception Handling application block for handling exception.

6. Parameter Manipulation

i. Do Not Make Security Decisions Based on Parameters Accessible on the Client-Side. Do not trust input parameters, especially when they are used to make security decisions at the server. Also, do not use clear text parameters for any form of sensitive data. Instead, store sensitive data on the server in a session store and use a session token to reference the items in the store.

ii. Validate All Input Parameters.

iii. Avoid Storing Sensitive Data in ViewState.

iv. Use Page.ViewStateUserKey to counter one-click attacks. If you authenticate your callers and use ViewState, set the Page.ViewStateUserKey property in the Page_Init event handler to prevent one-click attacks. Here is the sample code:

void Page_Init (object sender, EventArgs e)

{

ViewStateUserKey = Session.SessionID;

}

7. Sensitive Data

i. Avoid plaintext passwords in configuration files.

ii. Avoid using any of the client-side state management options, such as ViewState, cookies, query strings, or hidden form-field variables, to store sensitive data. The data can be tampered with and viewed in clear text. Use server-side state management options, such as a SQL Server database to help protect data exchange.

iii. If your page contains data that is sensitive, such as a password, credit card number, or account status, the page should not be cached.

8. Session Management

i. As so far we do not have any decision to use state server or sql server based session management we are safe here. If we need to switch one of those 2 we will have to explore the security measures for that.

9. Auditing and Logging

i. Use health monitoring to log and audit events.

ii. Instrument for user management events.

iii. Instrument for unusual activity.

iv. Instrument for significant business operations.

v. Consider using an application-specific event source.

vi. Protect audit and log files.

vii. We will use Microsoft Enterprise Library Instrumentation Application Block for this.

Ref:

Query XL file from SqlServer 2005 management studio using distributed query

2009-08-06T09:13:00Z

Backgroud:

Number of times in my life I worked in dataloading from XL file to sql server database. Whenever you get this type of work in hand, the first thing you need to do is analyzing the data of the xl file to check 1. How many rows already exists in the database 2. How many rows are new 3. How many rows has corrupted data 4. How many rows do not satisfy the business rule etc. There could be diffrent check points in different scenaio. To check a big XL file manually is almost impossible. So, what I used to do is, I exported those data to a database table and then query to it. Lot of times I had to struggle and face hassle to do this DTS based export from XL to table. I always felt, if I could have a way to directly query the xl file, that would make the life lot easier.

Querying XL file from SQLServer:

This time when I have got yet another XL file for data upgrade and synchronisation purpose I decided to find the way to query the xl file directly from management studio.

There are basically 2 ways I found to do this. One option is to use linked server and another one is to use distributed query. Linked server is aprropriate if you need this from your applicaion frequently. but if you just need to query the xl file for data analyzing, distrbuted query is the best option. Here is the way to do it:

1. You need to enable Ad Hoc Distributed Queries option by using sql server surface area configuration or by using the following query:

sp_configure 'show advanced options', 1

reconfigure

sp_configure 'Ad Hoc Distributed Queries', 1

reconfigure

2. Now here is the query:

select * from OPENDATASOURCE('Microsoft.Jet.OLEDB.4.0','Data Source=E:\Public_Folder\Users.xls;Extended Properties=Excel 8.0')...[sheet1$]

3. You can join this to any table of your database to analyze the data as follows:

SELECT

xl.serial

FROM

Contact con

INNER JOIN

users u

u.contact_id = con.contact_id

INNER JOIN

OPENDATASOURCE('Microsoft.Jet.OLEDB.4.0','Data Source=E:\Public_Folder\Users.xls;Extended Properties=Excel 8.0')...sheet1$ xl

xl.Last_Name = con.Last_name

AND xl.First_Name = con.First_name

So, happy dataload from now on J

The directory 'App_GlobalResources' is not allowed because the application is precompiled.

2009-07-20T09:10:00Z

Problem Scope:

This issue came to my hand from an Ektron project which is deployed as precomplied. Ektron (http://www.ektron.com) is a cms developed in dotnet. In one of the features of this CMS the global resource files (.resx) were parsed as XML from the physical location. but when the site was compiled the App_GlobalResources was also compiled and no physical folder exist in the deployed site. So the code writen for XML transformation was not being successfull.

Problematic Code:

string strGlobalResources = Server.MapPath("~/App_GlobalResources/ContentDesigner/");

string xsltfile = Server.MapPath(ResolveUrl("resxdata.xslt"));

string strLang = System.Threading.Thread.CurrentThread.CurrentUICulture.Name;

string xmlfile = strGlobalResources + strResourceName + "." + strLang + ".resx";

if (!System.IO.File.Exists(xmlfile))

{

strLang = System.Threading.Thread.CurrentThread.CurrentUICulture.Parent.Name;

xmlfile = strGlobalResources + strResourceName + "." + strLang + ".resx";

if (!System.IO.File.Exists(xmlfile))

{

xmlfile = strGlobalResources + strResourceName + ".resx";

}

string strXml = Ektron.Cms.EkXml.XSLTransform(xmlfile, xsltfile, true, true, null, true, null);

litOutput.Text = strXml;

If you examine the above code you will see a resx file is tried to be transformed using xslt. But as in the precoimpiled project we do not have these files physically exist the operation fails.

What I Tried:

Getting the issue, without giving too much thinking I just copied the App_GlobalResources folder to the root of precompiled site and was expecting it would be fixed. But after doing this I got the error “The directory 'App_GlobalResources' is not allowed because the application is precompiled.” Then, I realized this is not a solution. After thinking on this for a few minute I came to 2 solutions of the problem. One is staright rollback to the uncomplied version and the other is doing a trick.

Solution:

Step 1: Rename the App_GlobalResources folder to something else like “AppGlobalResources”.

Step 2: Change your code so that the resx file is taken from the newly named folder instead of App_GlobalResources.

The above 2 steps should solve the problem. This is actually an workaround. But Ektron should not have writen the code in this way. Instead it should have been done through dot net API.

J Get Going J