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:
<forms loginUrl="Secure\Login.aspx" requireSSL="true" ... />
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 mode="On" defaultRedirect="ErrDefault.aspx">
<error statusCode="401" redirect="ErrUnauthorized.aspx" />
<error statusCode="404" redirect="ErrPageNotFound.aspx" />
<error statusCode="500" redirect="ErrServer.htm" />
</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:
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
ON
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
ON
xl.Last_Name = con.Last_name
AND xl.First_Name = con.First_name
So, happy dataload from now on J