Security Think Tank: Top considerations to reduce application layer attacks

No two applications are the same. This is what makes securing them so difficult. A big firm like Microsoft will have an established application security function that extensively and continually tests their own applications, but how can the little guys even get close to this? Especially startups, that don’t have the million-dollar budget available to create and maintain secure applications?

I think it’s important to always remember that nobody is going to secure your applications for you. There isn’t going to be a magic patch you can apply every Tuesday that takes care of it for you. Likewise, there isn’t going to be anybody to continually analyse and research your applications, to ensure that an app that is secure one day isn’t insecure the next.

Think carefully about what your application does and where it sits. Simplicity is key on any application that is exposed to the internet. There is no point having an excessive number of input form fields, or application program interfaces (APIs) with a huge range of features that your business partners shouldn’t really be using.

Think seriously about using third-party libraries (bloatware) that introduce a heap of well-known security vulnerabilities to your application. If the code or function you need is that critical, write it yourself. Don’t import some Open Source code just to save time, because criminals are all over it trying to exploit it as they know so many people use it and they’ll have easy pickings.

Does Microsoft use open source code in their applications? Certainly not. Each line of code is independently written as part of their development ethos – which is a big ask for a startup, but is there really any other way to do things?

As an application security testing firm (sorry, cover blown!), we tend to breach applications through basic means. Exposed admin interfaces, badly written APIs that pretty much have full database administrator access; and indeed bloatware. The bloatware’s usually the easy bit, as someone has already researched and cracked it.

Last, but not least, is badly sanitised user input. Simple to fix, but terribly easy to exploit. If you do have user input, then try and think of it as somebody actually sat on your web server with a terminal console open.

Stuff that hackers put in input fields, for example, search boxes, is executed and run on your server. Anything malicious or crafted in a particular way can get through your web application server and access your database directly, if things aren’t written properly.

To reduce the likelihood of a successful attack, take time out. Sit down, work out how user input and data flows through your application. Risk assess, simulate and model threats. You’ll probably have a good idea as to how someone could attack you just by identifying the weak and risky areas of your application stack. Even a few hours of work on this can help mitigate the most significant threats.

But please don’t put untested applications on the net, or those that you’ve not risk or threat assessed. Someone will attack you; usually with a malicious script that attempts to compromise thousands of applications all at once. Don’t take it personally. Attacks are very rarely targeted, but you don’t want to fall into a script kiddies’ net.