API’s are a convenient and handy way to get different computers systems to talk to each other, but often they are also an easy way to get in by the backdoor deep into computer systems. In this article, we look at few of the most common mistakes made and what you can do about it.
#1 – Assuming other code is checking validity
Quite often public API’s are used to ‘wrap’ existing systems and a lot of attention gets given to permission and authorization controls, as we do not want just anybody accessing the API. The trouble comes when we assume that a certain API operation is security checked in the ‘wrapped’ system when in reality it isn’t. For instance, a bounds or token check could have existed in the wrapped system, yet over time that check is removed (systems are updated over time); thereby permitting the API to do things it should not be able to.
The solution here is obvious, such checks should be taken up by the API layer itself in addition to what is being done in the wrapped system; this way a change of code responsibilities will not open a security hole in the system. Yes, it does double some of the work, but compared to the risk of opening a whole right into the back of your system – this is a minor cost.
#2 – Aliases and the like
Often it is convenient to support aliasing and multiple roles within a given API session. This saves having to keep re-authenticating and authorising again and again – the problem here is it can become confusing as to what or who is actually enacting a request at a given time; combine this with session caching and multiple internal caches and you have an ‘alias’ lag where some requests are seen in one auth space and others are seen in another. A hacker could carefully game this to create inconsistencies in behaviour that could be exploited – a sort of auth ‘race hazard’ if you will.
The solution is to make darn sure when you swap roles, etc – that you do a complete lock then clean down of effected auth models and caches. This often easier said than done on distributed systems.
#3 – Over Trusting 3rd party data
Just because you have a tight and legal relationship with some 3rd party via an API does not mean you should be fully trusting of everything you exchange with them. It could be that they get hacked and you start finding SQL injections coming back for datums you then use straight away in SQL queries – ouch!
The solution is, data-wise, to trust no one and always make sure the data you get back is what you expect (in effect a whitelist check, confirm what it is, not what it isn’t).
#4 – Debug should only work in Dev not Production
Too often a switch or control to enable debug output is able to be discovered and utilised in the Production environment – this is bad news all around, as often such code does more than just dump data, it will turn off various safeguards and restrictions at the same time (e.g. bypassing auth controls for starters).
The trick is here is to have an environment control switch (via a config file say) that is required set to enable ALL debug controls – and that is only set in the Dev environment and not in Production (in fact test it isn’t).
Writing API’s that can be secure and remain secure in the face of change requires a few small techniques and tricks – if you would like help with your API’s please get in touch.