code syntax

The MvcHtmlString class:
Represents an HTML-encoded string that should not be encoded again. This class contains some interesting methods from security perspective like:

Create	Creates an HTML-encoded string using the specified text value.
ToHtmlString	Returns an HTML-encoded string that represents the current object.

The MvcHtmlString.Create method:
The Create method of the MvcHtmlString class in System.Web.Mvc namespace creates an HTML-encoded string using the specified text value in the parameter.

The method signature for the Create method is:

The <%: %> code syntax for the MVC ASPX engine:
<%: %> is a new syntax for HTML Encoding output in ASP.NET 4 and ASP.NET MVC 2. This syntax renders output like <%= %> blocks do, but at the same time, also automatically HTML encodes it before rendering.

Considering that ASP.NET 4 introduced a new IHtmlString interface (along with a concrete implementation: HtmlString) that a developer can implement on types to indicate that its value is already properly encoded for displaying as HTML, and that therefore the value should not be HTML-encoded again, a possibility of Double Encoding arises when <%:%> and instances of IHtmlString are used together.

To avoid this, <%: %> code-nugget syntax checks for the presence of the IHtmlString interface implementation and will not HTML encode the output of the code expression if its value implements this interface.

The @model.<…> syntax for the MVC Razor engine:
This syntax automatically encodes value that is represented by <…>. Only exceptions will be when <…> is of MvcHtmlString type.

Possible permutations:

<%: MvcHtmlString %>	<%:%> will not encode the MvcHtmlSTring to avoid double encoding as this is assumed to be already encoded
<%: NormalString %>	<%:%> will Html encode the NormalString before rendering the same.
@model. <somethingNonMvcHtmlString>	This will be HTML encoded and rendered.
@model. <somethingMvcHtmlString>	This will be not get HTML encoded as this is assumed to be already encoded somethingMvcHtmlString is already assumed to be encoded.

So why document these when these details are already available in MSDN/TechNet/web?
Because MvcHtmlString.Create method is not generating an HTML-encoded string as documented. And when these strings gets rendered within the <%:%> or @model.<…> syntax, they are not encoded and as a result a non-encoded string gets rendered into the browser.

Demo:
A small MVC 3 application is created just to check the workings of the Create method of MvcHtmlString class.
The application takes a user string and renders it into the browser. It provides us an option to render as a normal string or as a HtmlMvcString. The UI looks as below:

Once I click on Test, the content entered is rendered as below:

The view code that handles this rendering part is:

The strUserString is a normal string object.
The data model to which this view is bound has the following code:

Now to check the encoding behaviour, we pass some script values and try to render it in the browser.
Behaviour for Normal String:

This text is encoded and rendered as below:

Now the same text is rendered as an MvcHtmlString type:

The output looks as below:

The MvcHtmlString.Create method did not encode the string as documented. This needs to be taken care of during code reviews particularly when values of type MvcHtmlString is rendered within the <%: %> code nugget expressions or in @Model.<…> in ASP.NET 4 and ASP.NET MVC 2 onwards.
<%: %> and @Model.<…> will NOT automatically encode an object of type MvcHtmlString.

Some points to keep in mind when reviewing ASP.NET 4 and ASP.NET MVC onwards:
1. Check for <%: %> and MvcHtmlString usage.
2. Check for @Model.XXXX and MvcHtmlString usage
3. If found, check the type of value that is being rendered between the <%: %> code nugget expressions. Same for @Model.XXXX
4. If the type is normal string, <%: %>/@Model.XXXX will HTML encode the value. But if the type is MvcHtmlString then the value rendered within <%: %> will not be encoded. So if you see <%: %> in code do not assume that every value within it is encoded by default.

References:
1. http://weblogs.asp.net/scottgu/archive/2010/04/06/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2.aspx
2. http://stevesmithblog.com/blog/default-encoding-of-strings-in-asp-net-mvc-2/

ASP.Net validateRequest page attribute should never be the single point of check against scripting inputs

ValidateRequest is a good feature that ASP.Net provides to help developers to code well to protect their applications against the menace of the all prevalent web application security issue – XSS.

ValidateRequest is a page attribute that is intended to get or set a value that determines whether ASP.NET examines input from the browser for dangerous values. If that is enabled and the input in the browser contains any “dangerous” tags – ones that can be used to execute scripts/write code that the browser will execute then an error is generated:

The above error is generated when the url contains the script segment as a query string parameter. The query string looks something like this for test purpose:

<asp:MenuItem NavigateUrl="~/About.aspx?h=123&y=alert(‘sp@wned’);” Text=”About”/>

So I just wanted to check the extent of usability of validateRequest. In the “About.aspx” page, I have a script snippet that parses the url and evaluates the querystring parameters to arrange the display of the page. If I want to bypass the validateRequest limitation imposed, I need to make my querystring parameter free of any script tags. Considering that the script code in my page uses a java script Eval, I changed the query string parameter as below and validateRequest did not complain:

So it is not a very good idea to put too much trust on validateRequest to do the magic of input validation for an application. It can be easily and effectively bypassed.

Cross Site Scripting – PART 1

Hi there…I have been looking around for XSS related information and most of the demos I saw are either around displaying an alert in a web page or too advanced for a beginner like me. So as a toddler in the security world I tried to create my own dummy application to see how this attack is executed. What I write below is a documentation of my learning: there may be faults as I am still learning.

So feel free to drop a comment incase anything is not correct, I will surely incorporate any suggestions.

Cross Site Scripting – A little exploit demo to help understand the basics of this attack – I

Application background:

1. We have a simple web forum that uses Form based authentication.
2. The users can comment on the topics discussed by other users.
3. New users visiting this site are required to register by creating a new user name and password.
4. A registered user can: view/write the posts, write comments on the posts and view the comments written by other users.
5. The following code snippet is added to the web.config file for this application. Please note that when request validation is disabled, any content can be submitted to a page; it is the responsibility of the page developer to ensure that content is properly encoded or processed.

Use Scenario:
1. A malicious user registers and logs in to the forum.
2. He picks a topic and clicks on Write comments. Here is what he writes and submits:

This comment will appear as below on the view comments page:

To a normal user this looks like a perfectly harmless piece of text that directs you to another location that has more information around, eh…well Cross Site scripting exploit!
So a good user (let’s call him GoodUser) logs in and clicks on the hyperlink “here” to get some more information around this type of exploits. Here is what he will see:

In our example we used a simple alert statement but in real world scenarios this can contain scripts that can steal your cookie, other important information, etc. These stolen information can be used to impersonate a user, launch a more knowledgeable attack on the application or its user and also can case loss of data that can have financial and reputational implications on both the end user as well as the web site owner.

Hope someone will find this useful to understand how XSS can be exploited. I will posting my rendezvous with XSS.

Happy Reading!