cyphersec A blog about Web Application Security and .NET development best practices

Security Best Practices : ASP.NET Applications

Last Update: 2010/01/14

Securing web applications has always been a nightmare and probably it will always be. Working hacks for all major web development frameworks are into the wild and new vulnerabilities get discovered every day if not every hour.

Fortunately, .NET framework provides a good lists of defences that, if used and managed properly will allow you to create a defence wall between something valuable (your application) and the bad guys.

What follows is a list of all the .NET/ASP.NET security features, and best practices I’ve learned to be effective while coding web application during these years.

ASP.NET Application Security Guidelines

1. Security should not taken down in the name of simplicity and/or UI appeal.
2. Avoid, at all costs, client side validation (e.g. using Ajax or all JavaScript related validation libraries). JavaScript can and will, turned off and so your protections).
3. Validate everything that comes in. From HTTP Headers, to User Inputs (HttpHeaders, Cookies, ViewState and so on). Even if you don’t use them, keep an eye on them, bad formatted http headers could crash your web server for instance.
4. Assume that not only good guys will be using your applications.
5. Security through Obscurity never makes sense.
6. Validate user inputs in the application, promote the use of Regular Expressions (and be assured that they work the way they are meant to be)
7. If you are using AJAX, shield all your Ajax calls. Ajax hacking is a new kind of hacking into applications, be sure they are secure.
8. When using AJAX, be careful what you send back. Do not leak information. Do not return more information than is necessary to complete the request.
9. Use the principle of Encapsulation. Don’t abuse the public keyword. If something is marked as public there should be a valid reason for it. Promote the use of the internal and/or protected internal instead.
10. Pages with sensitive data should not be cached: page content is easily accessed using browser’s history.
11. Use Declarative and Imperative Security and don’t trust your own code. If your method is supposed to just read a file, use PermitOnly along with FileIOPermission.
12. Avoid using FullTrust, which means your application can do everything not only at application level by also at CLR level. Use Medium Trust or Low Trust depending on your application needs.
     

13. Use mature, well security tested algorithms.
14. Never compare passwords, compare the hash. Do not use MD5 which could be hacked using Rainbow tables, use RIPEMD160 instead.
15. Don’t rely on ViewState as a valid and secure storage. ViewState is by default base64 encoded, in a matter of seconds any clever hacker could hack it and use it against you. Encrypt it at page or application level using ViewStateEncryptionMode.
16. Make use of the HealthMonitoring system and trace your application behaviour. Use ViewStateFailureAuditEvent and make your application respond to such events.
17. Encrypt your connection strings using aspnet_regiis. This tool it’s so easy to use and requires simple steps to both encrypt and decrypt connection’s strings.
18. Promote the use of Gatekeepers, and never trust your application. If something have to deal with some other piece of code, it has to be authorised and authenticated first.
19. Don’t use Blacklists, but use Whitelists instead, teach your application what to accept not what to avoid.
20. Don’t try to sanitize a URI, if it doesn’t fit, reject it and let the user provide a valid one.
21. While creating a Web Service, use WSE. If you are using WCF instead, before writing an application on it read the WCF Security Guidance.
22. Don’t tell them anything. If your application throws an exception don’t provide technical details to the user. An hackers could read through the lines and craft a better working hack.
23. While storing a password or any sensitive string, use the SecureString object. Which is encrypted for privacy when being used, and deleted from computer memory when no longer needed.
24. Use platform features to manage keys where possible.
25. Do not pass sensitive data from page to page.
26. Do not cache sensitive data.
27. Do NOT use GET for anything that changes the server state or contains sensitive information. GET requests are logged in the web server access logs. They are also shown in the browser history.
28. DO use POST for every action that changes the server state and reject all non-POST methods. POST prevents unintentional actions, Most search engines won’t crawl POST forms and it also helps prevent duplicate submissions.
29. If using Cookies, mark them as HTTPOnly using System.Net.Cookie. Set the httpOnlyCookies attribute on the authentication cookie. Internet Explorer Service Pack 1 supports this attribute, which prevents client-side script from accessing the cookie from the document.cookie property.
30. Using slidingexpiration, is not always a good idea. A hacker could be possibly be logged in and won’t ever be kick out while trying to hack what’s next.
31. Do not echo any user input straight away. Encode it first. Do it only if required. ANY information you give to a hacker CAN and WILL be used to hack your website.
32. Learn how to use the Microsoft Anti-Cross Site Scripting Library to prevent XSS attacks.
33. Protect Audit and Log Files. Log files might be boring stuff to look at. From an hacker point of view, they are a goldmine as they could possible revel valuable information.
34. Don’t use Server.MapPath use Request.MapPath instead and mark the final parameter of to false. This means that a user cannot successfully supply a path that contains “..” to traverse outside of your application’s virtual directory hierarchy.
35. Use WindowsAuthentication instead of any custom authentication. Using WindowsAuthentication ensure you the password will never be transmitted over the network.
36. When constructing SQL queries, use type safe SQL parameters. AKA Use stored procedures or if you can not use parameterised queries in conjunction with Prepare statement. Using stored procedures it is always the best approach, from both technical and security point of views.
37. Robots.txt files are the first place hackers look at. Use access controls to protect them.
38. Secure your Web Service Definition Language WSDL. Your WSDL leaks the interface to your web service.
39. ASP.NET provides a very rich security features for protecting your pages against CSRF attacks. Using ViewStateUserKey in association with Session.SessionID as discussed here in the OWASP Cross Site Forgery Prevention Cheat. This value will be now validated in the postback and if the value provided does not match the value in the viewstate an exception is thrown. Note: This requires ViewState to be enabled and therefore cannot be used in ASP.NET MVC applications.
40. ASP.NET 1.1 and later include a ValidateRequest page directive that stops some malicious user input that could lead to XSS exploits. Since, ValidateRequest is enabled by default, all you have to do is ensure that you don’t explicitly disable it, either with page directives or configuration files. Note that ValidateRequest blocks any request that contain HTML or XML. If your page is intended to accept HTML or XML input from the user, you need to disable ValidateRequest, but be sure to follow the input validation discussed previously.
41. If you must use innerHTML to create elements in the document, create only those elements that are not available through the DOM (param is one example) or that are not generated by user input. To generate HTML elements, use the createElement, appendChild and setAttribute methods for greater safety.
42. If your site is constructed with frames, you can set the SECURITY attribute on untrusted FRAME and IFRAME elements to restricted. This set the security zone of the frame in the browser to the user’s restricted zone, which does not allow any script to run.

Web Server Security Guidelines

1. Deny extended URLs. Excessively long URLs can be sent to Microsoft IIS servers, causing the server to fail to log the complete request. Unless specific applications require long URLs, set a limit of 2048 characters. Microsoft IIS will process request over 4096 bytes long, but will not place the contents of the request in log files. Modify %windir%\system32\inetsrv\urlscan\urlscan.ini and ensure “MaxQueryString'=2048” is present. This requires URLScan to be installed (read below)
2. Use URLScan v2.5 or 3.1.
   URLScan v3.1 is a security tool that restricts the types of HTTP requests that Internet Information Services (IIS) will process. By blocking specific HTTP requests, URLScan helps prevent potentially harmful requests from being processed by web applications on the server. URLScan v3.1 has feature upgrades and fixes from its predecessor (v2.5) such as the ability to scan query strings, the ability to custom tailor rules that scan parts of your HTTP requests and many others. URLScan v3.1 will install as an ISAPI filter on IIS 5.1 and later, including the latest IIS 7.0 for Windows Server 2008
3. Disable Directory listing.
4. Your webserver should always be patched with the last updates.
5. Scan your webserver using tools like Nikto. Nikto is an Open Source (GPL) web scanner which performs comprehensive tests against web servers for multiple items, including over 3500 potentially dangerous files/CGIs.
6. Use SSLs were possible, this will encrypt and protect your data while on the wire. Using SSL doesn’t necessary means you are secure. It simply means your data is encrypted while on the go. If using SSL, restrict authentication tickets to HTTPS connections only.
7. Ensure that the application pool identity is not granted sensitive privileges or unnecessary rights to access resources.
8. Do not use highly privileged or administrative identities for IIS application pools
9. Consider using a lower privilege identity.
10. Separate code with different privilege requirements into different application pools
11. When using anonymous authentication, configure the anonymous user to be the application pool identity.
12. Use the principle of least privileged account. Create and associate your application with a low privileges user that fills all your applications needs.

SQL Server Security Guidelines

1. Disable access to the xp_cmdshell functions within SQL Server using EXEC sp_dropextendedproc ‘xp_cmdshell’.
2. Choose Windows Authentication when you can. It enforces strong passwords, password policies and other interesting stuff.
3. Use a least privileges user. Create a SQL Server login for the account. Map the login to a database user in the required database. Place the database user in a database role. Grant the database role limited permissions to only those stored procedures or table your application really needs. By using a database role, you avoid granting permissions directly to the database user. This isolate you from potential damage to the database.
4. If you are really paranoid, or asked to be, use the last line of defence. Database Cryptography.