.NET

Remember view state? For that matter, do you even remember web forms?! I kid because although MVC is the new hotness in the world of building ASP.NET websites, web forms remains the predominant framework due to both the very long tail of sites already built on it and the prevalence of developers with skills in this area who haven’t made the transition to MVC (indeed some people argue that they can happily cohabit, but that’s another discussion for another day). Anyway, back to view state. When...

Here’s the thing about security – you can’t just “do it” then move on. What I mean by this is that it’s a continuous process and thinking that you only need to just implement some secure coding standards or scan the website once before go live leaves a great big hole in your process. For example, the other day I wrote about how insecurity is easy [https://www.troyhunt.com/2013/05/security-is-hard-insecurity-is-easy.html] where I talked about how Black and Decker had exposed ELMAH logs. This is...

Here’s a little magic trick in .NET: In ASafaWeb [https://asafaweb.com] I have a facility to schedule scans at a certain time of day. Because I want to be all warm and fuzzy and user friendly, when people sign up to the service I ask for their time zone then whenever they schedule a scan they enter the time of day they’d like it to happen in their local time and I pull some magic tricks to make it happen. The process has been working flawlessly since the middle of last year – until this weekend...

This content is now available in the Pluralsight course "Ethical Hacking: SQL Injection" [http://www.pluralsight.com/courses/ethical-hacking-sql-injection]Everybody knows the easiest way to save yourself from SQL injection is to use object relational mappers (ORMs such as Entity Framework) or stored procedures, right? Often I see this becoming a mantra: “You don’t need to worry about SQLi if you’re using [Entity Framework | stored procedures]”. I also see the mantra blindly repeated and it’s wro...

After a short exchange of friendly but accusatory cross-continental messages, I’ve learned something new about .NET projects today. Let me start with the symptoms as that’s the first thing I Googled for and how I suspect others will find this and save themselves some pain in the future. Let’s say you have a solution like this: This is a brand newie right out of the box to demonstrate the problem. The web project references the ClassLibrary project as a project reference. In other words, the...

There are two security principles which I hold dearly but are often counterintuitive: 1. Users should be able to create any conceivable password they desire – no limits! 2. All input should be treated as hostile and properly sanitised against a whitelist. This is counterintuitive advice in so far as that second point has always been partially supported natively by ASP.NET request validation. I say “partially” because it’s not the final word in request validation [http://www.asp.ne...

Remember hash DoS [https://www.troyhunt.com/2011/12/has-hash-dos-patch-been-installed-on.html]? This was that very clever yet equally nasty little attack which meant that if you formatted the parameters in a post request juuuuust right you could take down an ASP.NET website with a mere single request. Bugger. This made for a rather unpleasant Christmas and New Year period for a number of people at Microsoft as well as sys admins the world over. Microsoft had rapidly released a the MS11-100 [htt...

I started building ASafaWeb [https://asafaweb.com] – the Automated Security Analyser for ASP.NET websites – about a year back to try and automate processes I found I kept manually doing, namely checking the security configuration of ASP.NET web apps. You see, the problem was that I was involved in building lots of great apps but folks would often get little security configurations wrong; a missing custom errors page, stack traces bubbling up or request validation being turned off among numerous...

Last month I wrote about our password hashing having no clothes [https://www.troyhunt.com/2012/06/our-password-hashing-has-no-clothes.html] which, to cut to the chase, demonstrated how salted SHA hashes (such as created by the ASP.NET membership provider), offered next to no protection from brute force attacks. I’m going to assume you’re familiar with the background story on this (read that article before this one if not), but the bottom line was that cryptographic hashing of passwords needs to...

In the beginning, there was password hashing and all was good. The one-directional nature of the hash meant that once passed through a hashing algorithm the stored password could only be validated by hashing another password (usually provided at logon) and comparing them. Everyone was happy. Then along came those pesky rainbow tables. Suddenly, huge collections of passwords could be hashed and stored in these colourful little tables then compared to existing hashed passwords (often breached fro...