Adventure Works Cycles Storefront Documentation | |
Security NotesSecuring an internet-based application is critical to the success of that application. The Adventure Works Cycles Storefront sample demonstrates several recommended practices with regard to security:
For comprehensive information about securing SQL Server and ASP.NET based application, see Building Secure ASP.NET Applications.
Avoiding SQL injection attacksThe key to avoiding SQL injection attacks is to never permit anything the user types to end up being executed as valid SQL statements. The problem most commonly comes up when the user is permitted to type in text for searching the contents of the database. There are several approaches to avoiding injection attacks including always using parameters for query strings and stored procedure calls, or appropriatly quoting user input. The former approach is used in the product search feature in this sample. See the Search Results Page for general information about this sample's search mechanism. The SearchProductDescriptions method in ProductsDB.cs is an example of how to invoke a stored procedure using parameters. Never construct query strings or stored procedure invocations with String.Format.
Keeping user passwords secureIt is more secure to never transmit clear text passwords between tiers of the application, and never store clear text passwords in the database. Also, application developers should use security practices which foil dictionary attacks whenever possible. This sample achieves these objectives by salting passwords (concatenating a random string to the password specified by the user), and one-way hashing those salted passwords using a cryptographically strong hashing algorithm. See the following methods in CusomersDB.cs to understand how to implement these techniques in your application:
Validating user inputThroughout this application's user interface there are limits on the length and checks on the content of user input. This helps guard against denial of service attacks, and also provides valuable feedback to the user as to what is expected in a given field. For example, in the Login.aspx file, the user's email address is constrained to 25 characters, the user's email must be specified, and it must match a plausible pattern for email addresses. Here are the relevant lines from the source code: <asp:TextBox size="25" id="email" runat="server" /> <asp:RequiredFieldValidator id="emailRequired" ControlToValidate="email" Display="dynamic" Font-Name="verdana" Font-Size="9pt" ErrorMessage="'Name' must not be left blank." runat="server" /> <asp:RegularExpressionValidator id="emailValid" ControlToValidate="email" ValidationExpression="[\w\.-]+(\+[\w-]*)?@([\w-]+\.)+[\w-]+" Display="Dynamic" ErrorMessage="Must use a valid email address." runat="server" />
Using SSL to protect confidential informationWhen transmitting confidential information such as passwords or credit card information over the internet it is important to use SSL to encrypt this information. No code changes are required to use SSL. It is only necessary to obtain a certificate from a well-known authority, install the certificate on the server, and configure the IIS virtual directory to require a secure channel (SSL). The details on how to do this are in the the "How To: Set Up SSL on a Web Server" chapter in Building Secure ASP.NET Applications.
Choosing a robust cross-tier authentication mechanismA common problem in deploying a multi-tier internet application revolves around passing valid credentials from the middle tier to the data tier. Even if a user has proper credentials (such as in an Intranet scenario), it may not be appropriate or even possible (without multi-hop Kerberos enabled) to pass those credentials along to the data tier. A simple and effective approach which may be used with this application is to manually assign the same strong password to the local ASPNET account on both the middle tier and data tier machine. This involves setting the password of the local ASPNET account on both machines to the same strong password, editing the password attribute in the processModel tag in the machine.config file on the middle tier machine to contain that password, and then ensuring the ASPNET account has login and appropriate database access privileges in SQL Server. For more information on this approach, see "How To: Create a Custom Account to Run ASP.NET" in Building Secure ASP.NET Applications. Another approach is to use impersonation if more than one web site is hosted on the same middle tier machine.
Logical vs. Physical tier deploymentThe installer for this sample deploys the software for all the logical tiers of the application onto a single box which is very convenient for a developer who wants to easily view and try out the application. However, for a production deployment it is recommended that multiple servers and firewalls be used. In particular it is considered very important to use separate boxes for the web server and database server, and to avoid directly exposing either box to the Internet. For extra security, the web server should be deployed behind a firewall, and the database server behind yet another firewall as depicted in the diagram below.
Please see Perimeter Firewall Design for more details about how to set up a secure production environment for Internet applications. For more information about how to deploy multi-tier architectures which involve SQL Server, please see SP3 Security Features and Best Practices: Secure Multi-tier Deployment. |