Html Encoding in ASP.Net MVC (and avoiding XSS)

Stop using <%= %> syntax in your ASP.Net sites...

Cross-site script injection (XSS) attacks are the most common security issues associated with web applications. Guarding against cross-site scripting attacks is relatively easy; just make sure that rendered output is HTML encoded within a page. This helps ensures that any content that might have been input/modified by an end-user cannot be output back onto a page containing <script> elements.

Ways of encoding with ASP.Net

ASP.Net applications (especially those using ASP.Net MVC) often rely on using <%= %> code-nugget expressions to render output. You can use the Server.HtmlEncode() or HttpUtility.Encode() helper methods within these expressions to HTML encode the output before it is rendered; this however can be verbose and easily forgotten!
A more convenient way was introduced in ASP.Net 4 (MVC 2), and that's the <%: %> syntax, this takes care of the encoding for you. If you're using the Razor engine introduced in ASP.Net MVC 3 then this also takes care of the encoding for you.

<div id="old">
<%= HtmlUtility.Encode(Model.Message) %>
</div>

<div id="new">
<%: Model.Message %>
</div>

<div id="newRazor">
<%: Model.Message %>
</div>

Avoiding double encoding

While HTML encoding content is often a good best practice, there are times when the content you are outputting is meant to be HTML or is already encoded – in which case you don’t want to HTML encode it again. The smart guys on the ASP.Net team decided to introduce a new IHtmlString interface (along with a concrete implementation: HtmlString) that you can implement on types to indicate that its value is already properly encoded (or otherwise examined) for displaying as HTML, and that therefore the value should not be HTML-encoded again. The <%: %> and Razor syntax checks for the presence of the IHtmlString interface and will not HTML encode the output of the code expression if its value implements this interface. 

For example, with ASP.Net MVC 2: the Html.TextBox() helper method returns markup like <input type="text" />. With ASP.Net MVC 2 these helper methods now by default return HtmlString types – which indicates that the returned string content is safe for rendering and should not be encoded by <%: %> syntax. This allows you to use these methods within both <%= %> syntax blocks, within <%: %> syntax blocks and within Razor engine syntax blocks. In both cases above the HTML content returned from the helper method will be rendered to the client as HTML – the <%: %> and Razor engine syntax will avoid double-encoding it.

Always use the <%: %&gt or Razor engine syntax to encode your HTML output; there's no reason to use the <%= %> syntax anymore!

OWASP web application security cheat sheets

The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific web application security topics. These cheat sheets were created by multiple application security experts and provide excellent security guidance in an easy to read format.

https://www.owasp.org/index.php/Cheat_Sheets

Padding Oracle Crypto Attack (Update Released)

In case you missed it, you should by now all have updated your servers with the windows update to fix the Padding Oracle Crypto Attack:

• Update available via windows update
• Update manually

Points worth noting:

• You'll need to apply th fix to all your servers in the web farm as the encryption/decryption mechanism has changed.
• Your users will have to log in again - forms auth tickets issued by your app prior to the update will no longer be valid.

Padding Oracle Crypto Attack (Update)

The ASP.Net vulnerability that was announced prior to the EkoParty conference in Argentina last week, initially sounded a lot like a whole lot smoke and not much fire. I read the summary of the exploit and belittled it in a blog post, telling people not to panic. I did however decide to review the slides of the technique used to expose the vulnerability as it all sounded rather interesting. However, I wish I hadn't as it soon came to light that the vulnerability was more serious than previously thought. Microsoft agreed and released a security advisory.

What can the attack do?

The attack is relevant to all versions and flavours of ASP.Net and is able to decrypt ViewState data, not an issue as long as you don't store sensitive info in the ViewState - which you shouldn't!

The real issue arises if using ASP.Net 3.5 SP1 or above, the attacker could use this encryption vulnerability to request the contents of an arbitrary file within the ASP.Net application i.e. the web.config.

How the does it work?

The attack makes use of cryptographic oracles. An oracle in the context of cryptography is a system which provides hints as you ask it questions. ASP.Net acts as a padding oracle in this case. Allowing an attacker to send chosen cipher text to the server and learn if it was decrypted properly by examining which error code was returned by the server (and even time taken). If the attacker makes enough requests, they can learn enough to successfully decrypt the rest of the cipher text. The attacker can then alter the plain text and re-encrypt it as well.

Silence that Oracle!

By returning only one application error page no matter what the error effectively silences the oracle and the attacker can no longer gain the info they need to decrypt your encrypted site data. Not ideal in web apps,

Anything else?

Yeah actually! Any sensitive files on your server within your application should be encrypted. For example your connection strings or your username and passwords in your web.configs should be encrypted.

Useful links

• Conference Slides that disclosed the Padding Oracle attack
• Scott Gu's FAQ about the Padding Oracle Crypto Attack

Padding Oracle Crypto Attack Affects Millions of ASP.NET Apps

So I saw this headline on Slashdot IT and it immediately made me pay attention. So I loaded up the ASP.Net security vulnerability article detailing the exploit and started reading.

In short, it totally destroys ASP.NET security

It soon became obvious that the article was a little bit sensationalist to say the least (see quote above). Basically the exploit is low-risk. You should only be worried if your applications aren't communicating over SSL and if you have put sensitive information in you ASP.Net application's cookies and are trusting the cookie data blindly. Sensitive data should all be stored server side - but you knew that anyway!

Needless to say, I've not wrote any code lately that checks for an SuperUser=true value in the cookie!!!