A weird scenario may come up where you want all requests to an application routed to just one controller action in an ASP.Net MVC application, here's the catch-all route you'll need :)
public static void RegisterRoutes(RouteCollection routes)
{
routes.MapRoute(
"Default", // Route name
"{*catchall}", // URL with parameters
new { controller = "Home", action = "Index" } // Parameter defaults
);
}
So you've split your apps into seperate app pools in IIS, which works well for app isolation on your web server and all is well until you start getting 403 HTTP status responses (with a substatus in the IIS logs of 18). This error is a result of your application running your application and the custom error page you've configured within different app pools.
I'm afraid you're going to have to edit the registry!!! So back it up first then create a registry key with the name IgnoreAppPoolForCustomErrors, of type DWORD and value 1 under the HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ folder.
You'll get this error from the .Net framework when it detects potentially harmful content in a web request submission. Want to disable this validation? Read on...
For normal ASP.Net Web forms apps you can disable request validation by setting validateRequest=false in the page directive (top of your aspx page) or in the configuration section.
For ASP.Net MVC apps add the [ValidateInput(false)] attribute to the appropriate controller action.
Be careful when turning off this value as you are making your site vulnerable by accepting potentially harmful input. You should explicitly validate your input in your code if you disable the built in .Net request validation.
Here's a little snippet I use quite a lot in my test projects to read out an embedded resource text file as a string. The resourceName parameter is the full namespace of the resource, e.g. myproject.files.MyEmbeddedTextFile.txt
internal string GetFromResources(string resourceName)
{
Assembly assem = this.GetType().Assembly;
using (Stream stream = assem.GetManifestResourceStream(resourceName))
{
using (var reader = new StreamReader(stream))
{
return reader.ReadToEnd();
}
}
}
P.S. You may want to add some error handling to the above ;)
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.
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.
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.
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.
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,
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.
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!!!
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 :)
So all has been quiet on the blog front for a few weeks now, but I have a valid reason this time - honest!
I've been busy getting to grips with my new role at Esendex as 'Head of Applications Development'. Neadless to say I'm very busy at the moment with planning, coding (although not as much coding as I'd like) and improving the applications team's agility. At the moment the days are passing me by very quickly!
I've got lots of blog post ideas so as soon as I get round to it they'll be up. Expect more Asp.Net MVC, TDD and hopefully some BDD posts popping up very soon indeed :)