Implementing a Secure Web Site

for RuBoard

At this point, the site is designed, the security fundamentals ”such as SSL, authentication, and authorization ”are established, and everything has been tested . Now it's time to go over what is involved in implementing the secure Web site. Some of the items in the following paragraphs might seem to be a review of the steps that were completed previously, but in this section we will be discussing these items on a more global level.

First and foremost, implement the certificate to enable SSL. Then configure IIS to force SSL on the directory in which your application resides. Also, note that in the web.config file, you can make an entry for impersonation to be on by default. To increase security, it is recommended that you only impersonate what has to be. In other words, when a file is accessed, does it need permissions of another user , or is the ASP.NET account allowed to access it? If the first case holds true, you need to use impersonation; otherwise , it should not be needed. It is probably quite rare that an entire site needs to be run as the Administrator; however, it might be frequent to use this impersonation element to run an entire site with an account that has very limited permissions.

Protected Modules

Starting with Microsoft Transaction Server, the concept of allowing modules to have a "run as" environment has been possible. The .NET Framework has provided several enhancements to this, even to the point of how accessible impersonation now is through code.

When you have created code that might access a protected entity, it becomes important to secure that code to prevent it from being misused. Listing 27.7 shows a code snippet that uses the FileIOPermission class to grant all permissions to files in the c:\inetpub\ wwwroot directory. If the Demand method fails, an exception is raised.

Listing 27.7 FileIOPermission Snippet

 try { FileIOPermission fP = new FileIOPermission(FileIOPermissionAccess.AllAccess,_ "c:\ \  inetpub\ \ wwwroot"); fP.Demand(); } catch(SecurityException SecErr) { Response.Write(SecErr.ToString()); } 

In the previous sample, AllAccess was granted; in practice it is important to grant only what is absolutely necessary. Should you need to have code execute as a specific user regardless of who is logged into the site, you can always implement impersonation.

Using Application Logs to Uncover Security Breaches

At the beginning of this chapter, the URLScan ISAPI filter was explained to show how to block users from issuing malicious requests to your Web server. IIS also provides extensive information in its log files that can be analyzed to detect bogus requests and attempted brute force attacks on your Web server by those who attempt to constantly hit the Web site with bogus credentials. An example of this would be a multitude of listings with the same username attempting to gain access several times in a very short time period.

In applications that you create with ASP.NET, you can create an additional logging file that can keep track of data that is processed internally by your application. While some may initially gripe that this can cause a performance hit, that issue is minimal compared to tracking exactly what your application is doing.

TIP

While creating your own application log requires write access to a folder, it does not require execute permissions. Unless you plan to publicly distribute what you are logging, the ASP.NET user does not need read access either. Whenever creating customized logging functionality, never give the folder the files that are written to execute permissions because this can lead to serious security issues.

With ASP.NET, you can still write to the computer's event log; the only caution there is to not write so much that the event log is full of debugging information instead of really important information about your application, such as attempted security breaches.

NOTE

Additional information on this topic may be found at http://www.microsoft.com/technet/security/tools/iis5chk.asp?frame=true.

for RuBoard