SLD Injection, it’s a thing

Reading Time: 4 minutes

I’m in the middle of preparing a session about security, and one topic you regularly bump into when thinking about security and writing code is SQL Injection. Although it is the year 2016, there are still people writing code which is vulnerable against SQL Injection.

But I’m not going to focus on SQL Injection here, I’m going to take it one step further. If you want to read up on SQL Injection, Bing/Google is your friend. Or just take a look at good old Bobby Tables.

People often think: “It’s called SQL Injection, but I’m not using SQL here, so I’m safe.”


From the moment you’re using any type of query or filtering language construct, you can introduce some form of SQL Injection in your code:

Another fun example uses the System.Linq.Dynamic NuGet package. This little gem allows you to use string expressions to filter on IEnumerable’s. And because it makes our developer life easier, we could use this to filter data in a Web API, for example. Take a look at this piece of code:

Yes, I know this is not the best code because you’re fetching all users from the database and then you reduce the result set, but bear with me. I’m making a statement here. Besides, this kind of code is still being written in production as well!

As you can see, you’re applying a filter to a list of User instances using System.Linq.Dynamic. That filter could be, for example, this:

This would reduce the results down to all users with an odd ID and where the surname starts with “n”. But someone could circumvent our fixed “odd ID” filter part, which would ignore our little security measure, by changing the filter a bit:

This filter value would make fullFilter look like this:

Because we’re missing parentheses around the user filter part, the ID filter will be ignored. One solution could be to add these parentheses.

Actually, you could solve that problem by moving the fixed filter part. That way, no matter what your user is requesting, he or she can’t get by the fixed filter anymore:

And to complete the story, you can look at using parameterized queries, which is also supported by System.Linq.Dynamic. Using parameters in your filter would take away some of the filtering power from the consumer of your API, but you could reintroduce that power by defining your own filters. This example shows a basic attempt at implementing this:


Cors.ConfigProfiles is here!

Reading Time: 1

After working on my previous blog post, where I had to use the EnableCorsAttribute, I thought: “Why can’t I make profiles for this in the web.config file, like you can for the OutputCacheAttribute?”

Enter my brand new, shiny NuGet package: Cors.ConfigProfiles! It enables you to use the EnableCorsAttribute just like you normally would, but you can also just give it one string parameter which then matches a profile inside the web.config file. So, for example, if you put this attribute on an API controller:

Then you can configure that profile in web.config like so:

And if you want to contribute or just inspect what I did (no unicorns involved though), the code is available on GitHub.


Adding an MVC layer on top of a Web API backend

Reading Time: 8 minutes

It might just be me, but I don’t seem to find a lot of examples out there showing how you can have an ASP.NET MVC website as a front end application using a Web API project as the backend service. Especially so when your front end is as basic as possible: I don’t want to end up storing user data twice because I need to request OAuth tokens and store refresh tokens and so on…

If you want to dive into the code that I’ve produced, you can head straight to GitHub and fetch it 🙂
For more explanation, read on.

Continue reading “Adding an MVC layer on top of a Web API backend”

Fluent API with Nullable this time :)

Reading Time: 2 minutes

Yesterday, I attended Kevin’s session about building a fluent API. One of the things he mentioned while building the API, was that he would have liked to constrain the use of the NotNull extension method to cases where it makes sense. And I thought I knew how, but it was already past 8 PM…

After he released the code for the session this morning, I took another go at it. And behold:

FluentAPI - Nullable


Now, to achieve this is actually really simple once you know the magic. The original code for the NotNull extension method was this:

Let’s first fix this one, so it only allows reference types. Easy: put another type constraint to make sure that TProp is a reference type:

Now, for Nullable types, we need to add another extension method. One where TProp is something nullable, of course.

The magic here is in the difference between TValue and TValue? (or Nullable<TValue>). When calling NotNull, we want to pass a struct or value type for the TValue type parameter, but the RuleBuilder will use the nullable one as property type. While we can’t define NotNull<T, TValue?> or use Nullable in the type constraint, we can pass it along to the RuleBuilder. The compiler is smart enough to deduce the rest using type inference 🙂



Localizing your Windows 8 apps – Part 1: Text

Reading Time: 3 minutes

Today, I gave my first MSDN webcast about how to localize a Windows 8 app. For those who missed it, and for the attendees that want to read what I was talking about, here is series of blog posts describing how to do it. You can also watch the session on Channel 9.

If you can’t wait and immediately want to dive in, or if you want to learn how to do this in HTML/JS, then take a look at this sample.

First of all: localizing an app is not hard or difficult. The hardest part is getting the design right if a text exceeds boundaries when it is displayed in another language. Let’s begin by localizing text on controls and in code.

When localizing text in XAML, you will have to assign a Uid to the controls. In XAML, the Uid property is in the xaml namespace, which typically has the prefix “x”; so to add the Uid, you’ll be using x:Uid="ControlUid".
You can freely choose the Uid, and it doesn’t have to be unique. For example, if you have a “Close” button appearing multiple times, you can assign a Uid named “CloseButton” and use that to provide a translation. This translation will then apply to all the different buttons with the Uid “CloseButton”. Also, you can leave your text or content in the XAML design. At run-time, your app will show the translated values instead of the ones specified at design-time.

XAML code example:

Now, to add translations, you’ll need a .resw file per language or culture that you want to localize your app in. I usually create a folder called Strings (and I’ve seen example apps doing the same thing) in which I’ll create subfolders per language. In my example, I’ve added a folder called “en” and one called “nl”, for English and Dutch resp. In each of these folders, I’ve then added a .resw file by right-clicking and selecting Add > New Item. You’ll find the Resources File item in the General tab.
When opening a resources file, you can add the Uid’s in this file and start overriding the properties per language:

  • For TextBlock and other pure text-based controls, you can add .Text to the Uid to change the text of the control.
  • For Buttons, you must use .Content to change the text.
  • For buttons in the AppBar that use a style based on AppBarButtonStyle, you must override the Name property of the AutomationProperties object.

For example:

AppTitle.Text My Application
A simple TextBlock control, so we override its Text property.
CancelButton.Content Cancel
A simple Button control, so we override its Content property.
NewFolderAppBarButton.[using:Windows.UI.Xaml.Automation]AutomationProperties.Name New Folder
A button in an App Bar. Here, we must change the Name property of the AutomationProperties object (this is an attached property).

You can also override other properties, like Margin, Width, etc. if necessary, to adjust your layout when text grows larger or smaller. To override attached properties, like the AutomationProperties.Name, you’ll need to add the namespace of the class of the attached property inside your resources file.
During the talk, someone asked if this syntax is the same for VB.Net, or if it would become [Imports:namespace]:
for both C# and VB.Net, you must use the [using:namespace] notation.

When you want to translate strings used in code, like group headers or error messages, you’ll need to create an instance of the ResourceLoader class. If you named your resources file Resources.resw, then you don’t need to specify a name in the constructor. If you have a resources file called Errors.resw, to organize your error messages for instance, then you’ll need to pass “Errors” into the constructor when retrieving strings from that resources file.
To retrieve a string, use the GetString method and pass in the name of the string, like “ErrNoInternetConnection”.

Finally, you’ll need to set the default language for your application. If the user doesn’t have any of the languages supported by your app set in the control panel, Windows will use the default language of your application. To set this, open the Package.appxmanifest file and change the “Default language” setting on the “Application UI” tab.

You can download the code that I used when giving my talk here. This code demonstrates localizing text.