I have compiled a check list of tips and techniques that I have built up in the years of development in .Net – So I’m here to share them with you all – so that you can also develop more securely in your own projects.
1. Configuration – SSL and services
Once your website is live to the public, it’s a good idea if you have control of the server to uninstall or disable services that aren’t required. Anything other than HTTP/HTTPS left open to the public is a risk. Try to enforce SSL for parts of your website that you wish to encrypt the data for. The SSL connection will ensure the data between the webserver and the client browser is encrypted end to end. Normal situations for this include payment processing etc.
2. Deployment – Release Build
Once you have done your testing – make sure you only deploy a “release” build of your website. It will remove all the debug code that is automatically injected when you are normally testing the website. It means if anything does happen/crash, there will be less information displayed to the user on-screen.
3. Deployment – Exception Handling
Inside the Global.asax file that is generated with all website projects in .Net, put code in the Application_Error function to capture any exception that may occur that isn’t handled properly in the website code. There are always scenarios that we can’t/don’t test, and slip through the gaps. Get the code to log the issues internally, and display a User-Friendly error page to the user. Do not reveal any error specific information in the Error Page.
4. Database – Queries
When accessing data to and from the database, make sure you use Stored Procedures instead of generating SQL queries dynamically. Because the query is outside the code base – there is no potential for the query to be altered/re-written. It does happen in attacks through a series of different attacks like Cross-Site scripting (XSS) and SQL Injection. If there is potential for the query to change, you have to assume that it might happen.
5. Database – Sanitization
When storing any strings/data in the database – you should sanitize your data by using the built in Server.HTMLEncode/Server.HTMLDecode functions to store the data safely. It will remove any script injections from being readable.
6. Field Input – Sanitization
All fields on a screen can be changed, even if they are labels or disabled textboxes through scripts/man-in-the-middle attacks (MITM). All data inputted must be validated correctly for format, and for XSS/Sql Injection input. Microsoft provides a library that can help deal with this – called Microsoft Anti-XSS (http://msdn.microsoft.com/en-us/library/aa973813.aspx). Funnily enough it’s been around since 2005/2006 and still hasn’t been incorporated into Visual Studio yet.
7. Password requirements
Ensuring users make it more difficult for anyone to guess their password; you need to enforce decent rules for a valid password. There needs to be a mix of upper/lowercase, symbols and numbers with at least 1 or 2 of each and a minimum length of 8-16 characters. The longer the harder it is to guess.
8. Login functionality
They should never reveal what exactly is wrong with the credentials – leave room for ambiguity. “Wrong Login or Password” is more secure than “Wrong Password for this Login”. Similar principle applies to Forgotten Password pages – never inform the user that the email/user specified was found – but more like “If the user/email exists, then a password will be sent to the user.”
9. Brute Force attempts
A method to prevent this from happening/affecting your website – Every failed attempt to login is counted by IP Address, once this hits a set limit (I used 3 attempts), does a lockout for the attack for 5 minutes. Each attempt returns the same error message “Invalid Login or Password” – even once the lockout has occurred. The user has no idea that the system isn’t even checking the login or password anymore since you have missed it too many times. Every sequential attempt during the lockout period restarts the lockout delay. This method prevents tools that are attempting brute-force attempts, as they keep trying different combinations and read the output on the page to understand it has a wrong Login/password combination. All attempts should be logged with Login attempted, date attempted and IP Address it came from. You can easily see when someone has attempted to brute-force your login system without gaining entry.
Take all those in account when creating new or building on existing Asp.net websites/web applications – and you’ll be helping provide a more secure and safe website.
Download a trial of Visual Studio 2010.
About the author
Stephen Aitchison is senior developer at Aura Redeye Security Ltd. You can find him on Twitter as @NZCoderGuy and on Geekzone as well.
Other related posts:
Consuming JSON web APIs with Visual Studio
Add a comment
Please note: comments that are inappropriate or promotional in nature will be deleted.
E-mail addresses are not displayed, but you must enter a valid e-mail address to confirm your comments.
Are you a registered Geekzone user? Login to have the fields below automatically filled in for you and to enable links in comments. If you have (or qualify to have) a Geekzone Blog then your comment will be automatically confirmed and shown in this blog post.