.png)
I love drawing inspiration from real life and todays article is no different. I often get asked the question on how to hack an API but what some people don't realise is that almost everything is connected to an API these days, even the smart fridges in our homes that pass on our groceries to the store have to pass that data to somewhere. Today i would like to take a moment to show you my top 10 best practices in API testing. To do this however we first need to know exactly what an API is.
People often hear the story about how many invisible waves have come to cover us such as WiFi and microwaves but those stories often neglect that with the dawn of the internet, engineers needed a way to make our fridges play flappybird and pass along the highscore to a server so that everyone can see how little of a life we have.
All jokes aside, API’s are everywhere around us. API stands for Application Programming Interface, now i don’t know about you but those words needs some analysing for me. In the core an API seems to be something that allows two applications to talk to each-other and if we define it like that, we can see why API’s are so broadly distributed. Not only do all our websites talk to an API these days but pretty much anything that is connected to the internet is dynamic and thus needs to talk to an API.
It's important to know the distinction between the SOAP and REST as both desire a slightly different approach to security. SOAP stands for Simple Object Access Protocol whereas REST stands for Representational State Transfer. SOAP was designed first followed by REST and we can state that SOAP is a protocol whereas REST is an architectural pattern. An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context while a protocol is an established set of rules that determine how data is transmitted between different devices and the API.
This is a very technical explanation which boils down to the fact that SOAP only works with XML formats and REST will work with plain text, XML, HTML and JSON. We can also invoke the well known HTTP verbs of GET, POST, PUT and DELETE for working with the required components. In SOAP we have a WSDL document that will contain all the specifications we need to talk to the API whereas REST will rely on the URLs to find the correct data.
A big advantage of REST is that it will often use less bandwith as it usually uses JSON where SOAP is constraint to XML which contains a lot of bulky extra's describing the document.
{"name":"Actor","Country":"Belgium"}
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV
="<http://www.w3.org/2001/12/soap-envelope>"
SOAP-ENV:encodingStyle
=" <http://www.w3.org/2001/12/soap-encoding>">
<soap:Body>
<Demo.thexssrat.com
xmlns="<http://thexssrat.org/>">
<name>Actor</name>
<Country>Belgium</Country>
</Demo.thexssrat.com>
</soap:Body>
</SOAP-ENV:Envelope>
It's very important to note that REST is a stateless architectural solution which means there can no proper information flow from one function to the other. If we need to have that we need to use a SOAP protocol.
Companies have already made great steps in securing their infrastructure in recent years but they still have a long way to go. One of the key threats that loom over organisations these days is the lack of information itself. A program will often consist of many micro api's that all communicate with one another and often security gets pushed to the back or overlooked entirely. There is a choice that companies have to make and it can be a thin line they have to walk.
We have to make sure that we spend enough time on our security infrastructure but at the same time it can become a real big burden if we don't manage this properly. We need to keep a current overview of our full API structure and all of the possible attack avenues while also making sure that we don't put any more stress on the system and it's components than it can handle. We need to know which API's are active and what endpoints they expose so that we can keep an overview of the possible attack vectors into our systems. This is no easy task and it can easily overwhelm us if we need to do it manually.
One common type of attack against API's is injections. This can be anything from command injections to SQL injections and the impact can range from trivial to critical. Several different types of injection attacks can be very harmful for a server and while the API is usually not the weak point that executes the attack, rather passing it on to other systems where the attack is executed, it's often the first line of defence against an attack from the outside. Some things we have to watch out for are: