May 2005 - Posts

Little Known, Invaluable Methods and Properties in the .NET Framework Base Class Library
24 May 05 04:32 PM | Scott Mitchell

I've decided to create a running article series on little known, but invaluable methods/properties in the .NET Framework BCL, starting with this week's 4Guys article enumerating some of the more handy methods for working with file paths. Over the coming weeks I'm planning on adding additional topics and associated methods/properties that don't get much press in the ASP.NET developer world. The next topics I'm planning on addressing are:

  • Working with Colors, and
  • Parsing Strings

In the mean time, I am interested in any suggestions you might have for such methods and properties and/or general categories. As Julia Lerman has said before in her presentations on ASP.NET topics, “There's more to .NET than System.Web.“ I couldn't agree more, and this ongoing article is an attempt to help highlight some of the more useful elements in the BCL that ASP.NET developers can benefit from.

Read Little Known, Invaluable Methods and Properties in the .NET Framework Base Class Library.

Filed under:
More On Why I Don't Use DataSets in My ASP.NET Applications
16 May 05 08:38 PM | Scott Mitchell

A couple of weeks ago I wrote an article on 4Guys titled Why I Don't Use DataSets in My ASP.NET Applications, along with an accompanying blog entry. As of May 16th, 2005, that blog entry has racked up over sixty comments from readers, ranging from gung-ho agreement to cogent arguments against my thesis. In any event, I thought it would be worthwhile to highlight some of the more eloquent feedback along with correcting some apparent misconceptions. So I introduce to you my latest 4Guys article, More On Why I Don't Use DataSets in My ASP.NET Applications.

Filed under:
Bubbling Events
10 May 05 05:40 PM | Scott Mitchell

This morning a colleague of mine asked for information on bubbling events up the ASP.NET control hierarchy, a task is commonplace when developing DataBound ASP.NET templated server controls. I started out with my boilerplate recommendation for all server control developers: buy a copy of Developing Microsoft ASP.NET Server Controls and Components. I then pointed out a short discussion of bubbling events in an earlier article of mine, specifically in the “Detecting and Bubbling Up Events” in my article Building DataBound Templated Custom ASP.NET Server Controls, which not only discusses bubbling events but also looks at doing it in my free RssFeed server control.

Seeing as I needed to whip out an article for this week's WebWeekly newsletter on 4Guys I decided to turn this query into a full-blown article. For more information check out my latest article on 4Guys, Bubbling Events Up the Control Hierarchy. Enjoy!

Filed under:
Yesterday's Talk at the SoCal .NET Technical Summit
08 May 05 02:55 PM | Scott Mitchell
Yesterday I gave a talk at the SoCal .NET Technical Summit on HTTP Handlers and Modules in ASP.NET. The summit was a great success with over 450 attendees from Los Angeles, Orange, and San Diego counties. For those who are interested in the slide and sample code used in my talk, you can download it here. Thanks to those who attended my talk, y'all were very attentive and asked some great questions. For those who live in SoCal but could not attend yesterday's summit, there's the upcoming San Diego Technical Summit on Saturday, May 21st. (Not that I'll be speaking there, though; but there are three great speakers slated: Microsofties Matt Nunn and Steven Lees, along with Chris Kinsman.)
Filed under:
Latest MSDN Online Article Available: skmFAQs.NET!
07 May 05 09:03 AM | Scott Mitchell
My latest MSDN Online article is up at the ASP.NET Dev Center: skmFAQs.NET: An ASP.NET FAQ Application. skmFAQs.NET, which I've discussed before on this blog, is a free, open-source ASP.NET 1.x application designed to make creating a frequently asked questions site as easy as pie. The aim of skmFAQs.NET was to create an application that offerred a mix of security rights and features between a Wiki and blog, a sort of simplified Content Management System (CMS). If you need to quickly build a website that allows only a pre-defined set of users to add content, and those users have varying levels of access and permissions, then check out skmFAQs.NET! (You can give check out a live installation of skmFAQs.NET at the official website, http://skmFAQs.NET.)
GridView Examples Out the Wazoo
06 May 05 11:50 AM | Scott Mitchell

Since most “interesting” websites are data-driven sites, it comes as no surprise that the DataGrid is one of the most often used controls in ASP.NET 1.x applications. In fact (...shameless plug warning...), I've written an entire book on the DataGrid, ASP.NET Data Web Controls Kick Start). The DataGrid was a huge improvement over data display techniques used in classic ASP (namely, loops in server-side script intermixed with emitting HTML), making it super easy to display data and only slightly more difficult to add common data display tasks, such as formatting, paging, sorting, editing, deleting, and so on. Additionally, while binding data to a DataGrid was simply - just a few lines of code - it still required hammering out code. Bleh.

ASP.NET 2.0 still includes the DataGrid for backwards compatibility, but chances are you'll never use it when creating a new ASP.NET 2.0 page. This is because the DataGrid has been greatly improved in 2.0's new GridView control. The GridView introduces more properties and events than the DataGrid and allows for paging, bi-directional sorting, editing, and deleting support without writing any code. Additionally, ASP.NET 2.0 includes data source controls, which are declarative controls that can be used to access data. The result? You can bind data to a GridView control in an ASP.NET 2.0 page without writing a lick of code. To put it another way: you can create a fully functional, aesthetically-pleasing data-driven Web page that allows updating, deleting, paging, and bi-directional sorting in about three minutes. Honest.

If you are wanting to learn more about the GridView check out my latest content on MSDN Online: GridView Examples for ASP.NET 2.0. There are a ton of examples, screenshots, code snippets... to give it some scale, the Word document that contained this content clocked in at over 120 printed pages. It's like a mini-book available online for free. Enjoy!

Filed under:
Don't Trust ViewState
03 May 05 05:03 PM | Scott Mitchell

Today I was pointed to a recent email to the BUGTRAQ mailing list (a mailing frequented by security experts) concerning replay attacks and ASP.NET view state. The email was posted by Michal Zalewski, titled: ASP.NET __VIEWSTATE crypto validation prone to replay attacks. As I describe in my article Understanding ASP.NET ViewState, The contents stashed in the hidden __VIEWSTATE form field are base-64 encoded and (by default) cryptographically signed to prevent view state tampering by a malicious client and ensure validity of the view state's contents across postback.

The signature occurs by salting the view state with both the HashCode for the virtual directory in which the page exists along the page's HashCode. This signature prevents a nefarious user from modifying the view state and posting it back. If such a situation unfolds, the ASP.NET runtime will not that the reposted view state's signature does not match up and throw an exception. Similarly, this mechanism prevents against replay attacks where the view state is taken, without modification, and posted back to a different page. Since the view state is signed by the page's HashCode, the signature wouldn't match up.

What Michal reasoned out, though, was that the view state was vulnerable to replay attacks to the same page. His example is a common one: you have an eCommerce site where the data loaded on the page is dependent upon querystring parameters, such as GetProduct.aspx?ID=productID. If things like price are stored in the view state (such as in a shopping cart DataGrid or put there programmatically), a frugal visitor could visit GetProducts.aspx?ID=cheapProduct, save the view state in the hidden form field, then repost that to GetProducts.aspx?ID=expensiveProduct. The end effect might be that the user could order the expensive product for the price of the cheap one. (Of course this would only be possible if the eCommerce site relied solely on the view state for pricing information when computing the final bill.)

The point is, don't trust view state (or the data that is put there by Web controls, such as the DataGrid). That is, if you have important information, such as pricing data, it's OK if it is placed in view state (such as in a row in a DataGrid), but don't grab the pricing data to charge by just poking around the view state (as in programmatically accessing the contents of a DataGrid). Instead, if you need to get pricing information (or any other important bit of information) for the final order processing, it is imperative that you requery the database.

Another point Michal made in his email was that view state can be used in a one-click attacks. That is, a nefarious hacker could pass along one view state through a third-party, the end effect being that the third-party sees a page with a view state they did not “create” themselves. Michal points out that to avoid this there needs to be someway to associate the view state with information particular to a user. This is possible in ASP.NET 1.1 via the ViewStateUserKey property, which is an additional, optional parameter that is used as a salt in the signature. You can assign this property to some unique user value to prevent the attack; see Improving Web Application Security: Threats and Countermeasures for more information.

The last point of Michal's email to BUGTRAQ was concerned unsigned view states. If you opt not to sign the view state (that is, if you set EnableViewStateMac to false), ASP.NET naively attempts to decode the view state passed in. This can be used as a denial of service vector by dumping in a very large hidden view state field, which can severely hamper the performance of the web server. (Of course, the web server is likely configured to reject any incoming request that's larger than 4 MB in size, but this is still an easy point of attack since crafting and posting a large view state is a trivial task from the attacker's point of view.) To protect yourself from this don't set EnableViewStateMac to false, if possible. There have been some claims that you need to set EnableViewStateMac to false in order to have Server.Transfer work properly. There is a workaround, as discussed in this KB article. It is my understanding, however, that you'll need to set EnableViewStateMac to false if you are using a web farm without server affinity.

I followed up Michal's email to BUGTRAQ with an offlist discussion. His main point, as I understand it, is that he in concerned because developers might think that view state is a safe place to put sensitive data or data that need not be revalidated due to the signing/encrypting options view state provides. However, as Michal's email shows, view state - even signed and/or encrypted view state - is not safe from replay attacks on sites where a single page's differs merely by the querystring. The short of it - don't trust that your view state information has not been modified and always requery the database before using information whose correctness is important.

More Posts


My Books

  • Teach Yourself ASP.NET 4 in 24 Hours
  • Teach Yourself ASP.NET 3.5 in 24 Hours
  • Teach Yourself ASP.NET 2.0 in 24 Hours
  • ASP.NET Data Web Controls Kick Start
  • ASP.NET: Tips, Tutorials, and Code
  • Designing Active Server Pages
  • Teach Yourself Active Server Pages 3.0 in 21 Days

I am a Microsoft MVP for ASP.NET.

I am an ASPInsider.