STI Handbok Databaskommunikation

Databas

Protokoll

API

Säkerhet

MySQL Workbench

Resurser

Explore

Säkerhet

Best Practices

Common Attacks Against Web APIs

(Veta vad det är)

Injections

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:

SQL injections

HTML injections

Code injections

Command injections

Content injections

Cross-site scripting (XSS)

While it's true that XSS is often executed on the clients computer, the API is often the first line of defence when it comes to stored

XSS attacks⁠

which can be very damaging. These attacks allow the bad actor to execute malicious (often javascript) code and it's the API's job to filter out these malicious values but we all know how easy it is to forget one and the bad actors only need that 1 chance to strike.

(Veta vad det är)

Distributed denial-of-service (DDoS)

DDoS attacks can be devastating as they cripple your application, system or even whole network. A

DDoS attack⁠

is executed by flooding the system with more requests than it can handle and usually by many different "zombies" as we call them. A zombie is an infected computer that is being controlled by the attacker and will be used to send out requests along with all the other "zombies" to our system. This can easily overwhelm even the most robust systems if enough traffic is generated.

(Veta vad det är)

Lack of Resources & Rate Limiting

This draws into our previous example which can be made even worse by not implementing proper rate limiting. This would allow the attacker to cripple our systems even faster than before by requesting unreasonable amounts of data in a very short timeframe.

(Veta vad det är)

Improper Assets Management

Some of the biggest threats come from that what is not known. A lot of organisations will put heavy emphasis on the security of the visible components in their system but completely loose sight of shadow API's. A shadow API is an API that is in production but is not known to anyone. These API's can cause great damage as they are not actively maintained and often overlooked when creating new features which could lead to unauthorised access of data for example or even worse, remote code execution.

‍

Top 10 best practices

So after knowing all of this you might be a bit worried but with these best practices you can be sure that your security will increase by many factors.

(Veta vad det är, ha implementerat)

Use a strong authentication and authorisation solution

It often occurs that broken API's do not properly check that the user is authorised to execute they action they want to take or that are even authenticated at all. This can cause major problems like data leaks by IDOR's and BAC. Since API's often form the gate to the companies data, which is arguably one it's most valuable assets, we need to be extra cautious in that we do not expose anything to the wrong people.

Prioritise security

I often hear the argument that security is not foreseen in the current budget but that makes me wonder what the budget is for a real data leak. The costs of a proper attack can reach many times that of the costs of proper security measures and it's important we also take security into consideration and even put it in the first place when designing our system's requirements or building up the code.

Inventory and manage your APIs

As we've talked before, shadow API's can be a real problem. To combat this, make sure that you have a proper inventory of your API's and that this is regularly updated. This is best done by automatic tools which can inspect traffic and perform enumeration scans to discover uncharted API's.

(Veta vad det är, ha implementerat)

Practice the principle of least privilege

The principle of least privilege states that we should only give our API's exactly as much access as it needs and no more. This ensures that even if our API's get hacked, the damage will be limited to the scope of that API and will not spread to other parts of our system.

(Veta vad det är)

Encrypt traffic using TLS

TLS stands for Transport Layer Security and is the successor to SSL which you may be more familiar with. It allows us to encrypt traffic in a very secure manner which does not leave any more room for man-in-the-middle attacks where the bad actors try to read the traffic between our front-end systems and our back-end API's.

(Veta vad det är, ha implementerat)

Remove information that’s not meant to be shared

When API's are developed we have to pay special attention to the fact they can contain secrets which are a much sought after commodity for hackers. Things such as API keys, usernames and passwords should always be put into secure storage solutions such as environment variables. This step is often overlooked which is why it pays off to automate this process. Besides scanning items before they are uploaded into code sharing solutions such as repositories we can also scan those repositories periodically to ensure no values got out from under our watchful eye.

(Veta vad det är, ha implementerat)

Don’t expose more data than necessary

Developers will often expose more data than is strictly needed for debugging purposes in testing environments but we have to ensure all these extra values are removed before entering a production environment. As an ethical hacker i can ensure you that information is a very valuable commodity in our world and the less data is exposed, the less of an attack surface we leave exposed for bad actors.

Validate input

One of the biggest reasons vulnerabilities happen in production environments is because developers forget to validate and sanitise input. We should always have redundant validation systems and never rely on the front-end systems to block off invalid input. As an ethical hacker i do not care very much about front-end systems unless it comes to XSS or CSTI. I am talking to an API when I am hacking and i always say that front-end validations only serve to protect the users from their own mistaken input.

⁠

⁠

(Veta vad det är)

Use rate limiting

This issue type is by far one of the most reported issue types out there in bug bounties which means it is often missed in penetration testing. Improper rate limiting or lack of any rate limiting at all can cause our applications to go offline because a bad actor might be requesting too much data or they might overload our API's by having them process too much information. If we use third party services this can even lead to extremly high bills being racked up by bad actors trying to execute as many requests as possible to the third party systems which might bill per x number of requests.

Use a web application firewall

One of the most effective ways to stop bad actors is a

WAF⁠

. This is a type of firewall that focusses on only inspecting web traffic and they are often based on rulesets which will filter out traffic that is not allowed. This can be requests with attack vectors in them for example. While a WAF is a very effective technique to stop bad actors, it should never be relied upon fully and we should still keep into account all of the things we have already talked about

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.