XML Character Support

One of the projects I'm working on heavily uses a ReST API and performs a lot of XML processing. Recently we've had some serialisation errors when processing some of the XML, resulting in a .Net error throwing:

System.InvalidOperationException: There is an error in XML document (1, XXX). ---> System.Xml.XmlException: XXX, hexadecimal value XXX, is an invalid character.

So I examined the XML payload and could see it contained a non-pritable/control character. I raised the case with the API developers but I found myself curious to find a definitive list of what characters are valid in XML documents. I soon found the Extensible Markup Language (XML) 1.0 Specification, which contained a section regarding the supported XML characters.

You can encode a massive range of characters in XML documents, but there are some non-pritable/control characters that are not supported. Legal non-pritable/control characters include tab (xx09), carriage return (xx0D) and line feed (xx0A). For printable characters it's the legal characters of Unicode and ISO/IEC 10646.

Useful Links

• UTF-8 encoding table and Unicode characters

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!!!

MailMessage's Subject ArgumentException

Just a quickie today... if you get an ArgumentException when setting the subject on the .Net MailMessage object (or on the constructor) like this...

System.ArgumentException: The specified string is not in the form required for a subject.

You'll want to cleanse your string input for non-printable characters. The most likely culprit is a carriage return or line feed. Which is "\r" or "\n" to the C# developers :)