When it comes to security, it’s better to learn from examples.

Failure is a good thing when we learn from it. In fact, if we’re not failing, then we’re not trying new things. And because a lot of programming will be new to us, we can expect to fail a lot. Especially when we’re just getting started with programming.

Now a normal failure might mean that your new design doesn’t work the way you expect. But some failures can be taken advantage of to cause something unexpected in your code. Or at least, unexpected to you. For the person taking advantage of the error, the behavior is exactly what an attacker wants.

There’s a whole class of attacks that take advantage of the filesystem. These attacks can be caused by mistakes in how your code uses the filesystem. Under normal usage, you might never notice. Until, for example, an attacker sets up a few files with some special names.

This episode explains a very important and simple piece of advice. Always test for things that you want instead of things you don’t want.

If you try to test for unexpected situations and then block them, then you’re going to be surprised. Once you know what to look for, then you need to consider the best way to compare input with what you expect. And you’ll also learn some tips to help you work with various cultures and locales.

Have you heard about the “Turkish I Problem” which can cause your code to fail certain security checks? It’s all because we sometimes want to provide some flexibility in uppercase vs. lowercase file names. The Turkish letter ‘i’ doesn’t follow the rules you might expect and in particular does not match the uppercase letter ‘I’. This can cause your security checks to fail whenever a name contains the letter ‘i’. Even the word “file” has an ‘i’ in it.

You’ll need to understand the differences between an Ordinal string comparison vs. OrdinalIgnoreCase vs. InvariantCulture when deciding if filenames are what you think they are.