Posts in category .net - page 12

Language Integrated Query: An introduction talk tomorrow

I’m just finishing up the slides, notes and writing code samples for my LINQ presentation at the Guernsey Software Developer Forum tomorrow evening.

Hopefully the broader scope of this presentation will mean a few new faces – the previous talks on Subversion and web application security might have been a little specific for a such a small audience (Guernsey is around 70,000 people on an island 9 miles long).

As always I will put the presentation up here afterwards but will also revise the older ones with the new style and put up both PowerPoint and Keynote versions under an open license as well as a couple of cheat sheets.

Is there any interest in adding audio narration and transcripts?

This presentation is now available on-line.

[)amien

LINQ presentation at Guernsey Developer Forum

I will be giving a talk at the Guernsey Software Developer Forum at the end of the month on Microsoft’s new Language Integrated Query (LINQ) with particular emphasis on the capabilities and object-relational mapping characteristics of LINQ to SQL.

Now confirmed for:

  • Date & time **Tuesday 29th January, 6pm**
  • Location **Guernsey Training Agency above Smith Street Post Office**
  • Open to **everybody**

This presentation is now available on-line.

[)amien

Thoughts on awareness of security vulnerabilities & full disclosure

HTML, SQL and XSS injection vulnerabilities aren’t new but they are still largely ignored by developers.

My first encounter with these issues was in 1999 whilst writing an extranet e-commerce web site. Back then the ASP fix consisted of Server.HtmlEncode for all output and a Replace(“‘”, “””) for strings heading to SQL (other types headed there via CInt/CLong/CDate and I wasn’t aware of parametrized queries).

Convincing co-workers on the severity of the issue and what to do about it for several years can be a draining process when you work with such a variety of different developer personalities and projects and you would rather be spending the time on more exciting things

Over the last few months I’ve been trying hard to push the message further afield via presentations at the local user group, articles here on my blog, discussions in Redmond as well as forums and private mailing lists.

More than once I’ve had the feeling I should give it a rest in case people think I have nothing else to talk about and at a few times I’ve considered publishing a few scripts I had in my head to really show the sort of things available. Of course doing such a thing would both highlight the problem but also provide a dangerous tool to people who might use it to actually exploit sites which is a problem with full disclosure. In the end my article How dangerous is HTML injection was a much neutered version without a killer payload.

Thankfully some great people are now on the case including Rob Conery and Phil Haack who I believe in to push this from inside and Steve Sanderson who came up with an elegant prototype on how to handle this at the source.

That will be all the HTML injection posts for a while I hope for there are many other things I want to work on and write about.

[)amien

5 signs your ASP.NET application may be vulnerable to HTML injection

If you don’t encode data when using any of the following methods to output to HTML your application could be compromised by unexpected HTML turning up in the page and modifying everything from formatting though to capturing and interfering with form data via remote scripts (XSS). Such vulnerabilities are incredibly dangerous.

Using MonoRail or Microsoft’s MVC does not make you automatically immune – use {! } in MonoRail’s Brail engine and the HtmlHelpers in Microsoft’s MVC to ensure correct encoding.

Just imagine post.Author contains “><script src=”http://abadsite.com”></script> after an unscrupulous user entered that into a field your application uses and it got into the database. The following typical ASP.NET techniques would leave you open.

1. You use <%= %> or <%# %> tags to output data

Example showing outputting literals with <%= %> :

// Vulnerable
<p>Posted by <%= post.Author %></p>
// Secure
<p>Posted by <%= HttpUtility.HtmlEncode(post.Author) %></p>

2. You use Response.Write

Example showing writing out attributes with Response.Write and String.Format, again post.Author could contain

// Vulnerable
Response.Write(String.Format("<input type=\"text\" value=\"{0}\" />", post.Author);
// Secure
Response.Write(String.Format("<input type=\"text\" value=\"{0}\" />", HttpUtility.HtmlAttributeEncode(post.Author));

3. You set HRef or Src on HtmlAnchor, HtmlImage or HtmlnputImage controls

In general the HtmlControls namespace are very well behaved with encoding but there is a bug in the code that attempts to adjust the relative url’s for href and src attributes which causes those properties to bypass encoding (I’ve reported this to Microsoft).

Example showing anchor HRef attribute abuse:

// Vulnerable
outputDiv.Controls.Add(new HtmlAnchor() { Text = "Test", HRef = post.Author } );
// Secure
outputDiv.Controls.Add(new HtmlAnchor() { Text = "Test", HRef = HttpUtility.HtmlAttributeEncode(post.Author) } );

4. You set the Text property of WebControls/WebForms

You would imagine the high-level WebForms controls would take care of encoding and you’d be wrong.

Example showing the Label control being so easily taken advantage of:

// Vulnerable
outputDiv.Controls.Add(new Label() { Text = post.Author } );
// Secure
outputDiv.Controls.Add(new Label() { Text = HttpUtility.HtmlEncode(post.Author) } );

The one exception to this is the Text property of input controls – as they put the value into an attribute and therefore call HttpUtility.HtmlAttributeEncode for you.

5. You use the LiteralControl

LiteralControl is a useful control for adding text to the output stream that doesn’t require it’s own tag. It also helpfully, and uncharacteristically, provides a useful constructor. Unfortunately it fails encode the output.

Example showing poor LiteralControl wide open:

// Vulnerable
outputDiv.Controls.Add(new LiteralControl(post.Author));
// Secure
outputDiv.Controls.Add(new LiteralControl(HttpUtility.HtmlEncode(post.Author)));
Do not: 1. Encode data in the database – your contaminated data will be difficult to use elsewhere and will end up double-encoded 2. Look for script on submit – you won’t catch every combination and it might prevent valid data 3. Trap entry with client-side code – it is trivially bypassed

Just encode the output :)

[)amien

PS: The samples use .NET 3.5 object initializer syntax for brevity as many affected controls do not have useful constructors)