Secure Development Tips and Techniques for use in Asp.net websites and web applications

, posted: 16-Jan-2012 16:42

When developing any type of website or web application in .Net there are plenty of tips to help make sure your creation is protected against hackers and scanners.

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
Web.config transforms






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.

Your name:

Your e-mail:

Your webpage:

About the Visual Studio blog

In the years since the hugely successful release of Visual Studio 2005, Microsoft has used developer feedback from all over the world to introduce new features in later releases.

This sponsored blog will bring Visual Studio tips and tricks from well known developers in the New Zealand tech community directly to you.

Every second day during November and December 2011 you will find something new here. Make sure you bookmark this blog or subscribe to its RSS feed.    

Join us on Twitter

Find us on Facebook

Tags

Blog...
Database...
Techniques...
Testing...
Tools...
User Interface...
Windows Phone...


Other blog posts

Winners of Windows Phone compe...
Customise your Visual Studio 2...
NuGet Package Manager extensio...
Competition: be in to win one ...
Consuming JSON web APIs with V...
Recommended documentation add-...
Test driven development in Vis...
Web.config transforms...
Getting Started with Visual St...
Welcome to the Visual Studio b...


Recent comments

kiwiandy on Winners of Windows Phone competition announced, mo: mm the first one I try... ASB.. isnt there!?...

chiefie on Winners of Windows Phone competition announced, mo: Hmm the ASB Bank app is MIA....

Daniel Ballinger on Recommended documentation add-on for Visual Studio: Personally I don't find much value from a tool like GhostDoc if the generated do...



Disclaimer

The Visual Studio blog is sponsored by Microsoft NZ. The blog posts are the authors' genuine accounts of their experiences with Visual Studio, Windows Phone SDK and Windows Azure Platform and are not influenced or filtered by Microsoft New Zealand in any way.