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:


CSP: we’re not there, yet.

Reading Time: 3 minutes

CSP, or Content Security Policy, is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. In short, you can add this policy using either a <meta> tag or by setting additional headers in your HTTP response, and using the policy you’ll limit the origins for resources for that HTTP request. For example:

  • script-src ‘self’ allows loading scripts from the current domain
  • child-src allows the use of <iframe> tags pointing towards YouTube
  • style-src ‘self’ allows loading CSS files from the current source and from a CDN.

If you want to read up on CSP, I suggest heading over to

Now, I was trying out some things concerning CSP and inline scripts. You could add ‘unsafe-inline’ to the script-src source list to allow all inline scripting (except eval and other bad stuff, you need ‘unsafe-eval’ in that case), but that is exactly what you would want to avoid. Instead, you can opt to do one of these things:

  1. Move all inline JavaScript into .js files and load them using <script src=””></script> tags, while adding ‘self’ to script-src if that wasn’t already the case. The easiest solution, but not always possible.
  2. Generate a nonce for each inline script. A nonce means: a unique and hard to predict stream of bytes, different for each script, each page and each request!
    A nonce could be base64 encoded and look like RJ6bGjm5EO/X8pImZjvjeAexFVei9IvzNFCGw5lQUa0=
    You would need to add that nonce to the script using the nonce attribute, and also to the script-src source list using ‘nonce-RJ6bGjm5EO/X8pImZjvjeAexFVei9IvzNFCGw5lQUa0=’
  3. Calculate the SHA256, SHA384 or SHA512 digest of each inline script (including all whitespace, but excluding the opening and closing script tags). Like the nonce, you’d need to add these digests to the script-src source list using ‘sha256-0ZMofb7eMqkB9IFHnGVZ6Z4chjplAavgi09shinNehs=’ for example.

Continue reading “CSP: we’re not there, yet.”