About Links Archives Search Feed Albums of Note

DDD Southwest Session Notes 3 : Defensive Programming 101

The third session of my day at DDD Southwest [/post/2012/05/29/DDD-Southwest.aspx] was a talk by Niall Merriganentitled Defensive Programming 101. Or, as it turned out, “Top 10 Things You Shouldn’t Forget To Do To Start Securing Your Website”. This was probably my favourite of the sessions I attended at DDD Southwest. Niall’s a funny bloke with useful things to teach so if you get a chance to see him talk, do.

Further information and resources can be found on Niall’s site here at http://www.certsandprogs.com/2012/05/dddsw-roundup-and-resources.html. You can contact him on Twitter at @nmerrigan [http://twitter.com/nmerrigan]

Writing secure code is hard and takes time. Sales people do not care and we trust each other  that our code is secure. Not that many people try to screw up a site they are visiting. We write for general users.

The Top 10 “Screwables” 10. Restrict your HTTP Headers. It can tell those who care too much, such as the webserver being used, .net version etc. Don’t forget also to restrict easy access to sensitive files. Kill elmah.axd, trace.axd. Search for the phrase googlehacks and you’ll find the number of ways google can help the hacker attack your site simply because you’ve allowed them to index your .axd files, .pst files etc.

  1. Passwords. Don’t use the same password for every single site. Cross-pollination hurts. Don’t save passwords in plain text connection strings. Encrypt them, change them regularly and don’t ell them to others. NB You can’t encrypt your password in a connection string when using the entity framework.

  2. Patching. Try and follow the server patch bulletins sent out by Microsoft and make sure you test your web applications with new patches attached as they can break.

  3. Validation. Don’t rely only on client-side scripting for validation. Turn off javascript in your browser and make sure server-side validation is working. Prefer whitelists to blacklists. Validate to RFC rules. Use a central validation source – i.e. a single place to update validation rules.

Search for e.g. RFC email - shoud point to ISO standard validation routine

  1. Email & Custom Errors. Email presents too much information to users, and not enough to developers. Error messages should only show users what they expect to see. No stacktraces etc. Very ditto for emails. Turn CustomErrors ON IN PRODUCTION with pages handling specific error codes – 404, 500 etc. Use web config transforms to kill it or set it to localonly and set up custom errors. Handle your errors correctly.

  2. Database and AppPool Permissions. Don’t use sa in your connection string. Don’t create a user and set it to dbo. Use two connection strings, one for reading, one for writing. Never run AppPools as *Admin user accounts. Always use the minimum permissions. Don’t give access to SQL tables if sprocs and views are all that’s required. Perhaps give user only execute permissions if you only use sprocs. (Yes this should include insert perms. Oh, and don’t use dynamic sql in sprocs)

  3. Directory traversal. How do I send a file to client that opens a save as dialog? Ans: Whatever you do, don’t do something like this: download.aspx?file.txt. Because download.aspx?...config will work. IIS isn’t handling and therefore automatically blocking the request at this point, your handler is. You could probably download the whole source code in dll files and decompile it. If you used the asp.net website template, you can get all the cs files as well. In short, don’t use a file name for downloads. Use a GUID or include a hash for the file to check you’re downloading the file you think it is.

Find link on blog to WAM_USER WAM_PASSWORD metabase vulnerability on Niall’s site,

  1. Injection attacks. Addition of scripts to your site against your will. Don’t set enablePageValidation to false. Very silly. Don’t use cookieless sessions. Only make cookie on server-side readonly.

  2. SQL Injection. nuff said. Don’t allow naked SQL in your code.

  3. Users will never do what you think they are going to do.

Posted on May 30, 2012   #Attending Events     #Geek Stuff  

← Next post    ·    Previous post →