Do you think IIT Guwahati certified course can help you in your career?
Introduction
ReadyAPI is an API testing tool which offers a wide range and variety of testing services. For anyone who is developing any sort of API, Ready API is a comprehensive and powerful tool to test the API in various ways. You can perform functional tests, security tests, performance tests, and more.
ReadyAPI offers robust functionality, such as setting up Authorization, Environments, and even integration with CI-CD workflows. We can send requests over HTTP and HTTPS and configure SSL certificates for the same.
In this blog, we will see in detail the security tests provided by ReadyAPI. We will discuss what they are and what they guard against. Let's get started!
Security Tests
Security Tests are tests we run against an API to ensure that it will stand against any attack that hackers may pose against it. There are many security tests, and we will look at the major ones in this article.
But, there is so much internet security already in use. HTTPS, TLS, and SSL are all widely used. Do we still need to test our APIs?
Yes, we do. So let's first see why security tests are necessary.
Need for Security Tests in APIs
We can create Web APIs to access your website, database, or other online resources. You should always be aware that people will try to hack into these. There are multiple ways of protection against hackers, the most common being by making the requests authenticated. This is done by adding a username and password to each request.
This generally works well, but – attackers can also hack APIs themselves! This means that even without a username and password, the hacker might be able to gain access to your online resource. They just have to exploit the security errors in the API you have developed for it. Sometimes, the purpose is not to gain access - but just to cause harm to the resource.
For example, suppose you create a website for a gaming application. Users can earn coins and spend them on various things inside the game. Whenever a user spends coins, you send a request to https://yourgame.com/api/user?action=spendCoins&value=value
In the value field, you add the actual value.
In the backend, this request deducts valueamount of coins from the user's virtual wallet and saves it. Suppose a hacker figured out this API URL using the network tab from Browser debugging tools. Directly, he sends this request: https://yourgame.com/api/user?action=spendCoins&value=-100
The hacker is trying to spend a negative amount of money! Inside the game, you handled this using front-end code that ensured value could never be negative. But the hacker sent a direct request to your API. Now, in the database, you will deduct -100 coins from the hacker's wallet, which means he will now have 100 more coins than he initially did.
This was a very basic example. A hacker could launch many more sophisticated attacks, such as SQL injection attacks, Cross-Site Scripting, etc. We will see many of them in this article.
Security Tests in Ready API
Let's see which security tests the Ready API allows us to test against:
Boundary Test
Cross-Site Scripting
Fuzzing
Invalid Types
Malformed XML
Malicious Attachments
SQL Injection
XML Bomb
Xpath Injection
We will look at all of these in detail.
Boundary Test
This is like the video game coin case we covered earlier. Boundary tests check your API's response when it sends values that are outside the expected range. Generally, what happens is the system ends up revealing information about itself through error messages and stack traces.
ReadyAPI's boundary test checks against this by sending various unexpected inputs. It might send a negative price, a “minutes per hour” value beyond 60, or marks beyond 100%.
Cross-Site Scripting
This test checks if your service can handle malicious injections into different web pages. With this kind of attack, the attackers usually target your website's users instead of the website itself.
Suppose you have a social media website on which people can post posts, and a hacker posted the following post :
<script language = “JavaScript”> window.location.href = “http://thehackerswebsite.com” </script>
This would redirect the user to the hacker's website's URL by setting the window.location.href property, which gives the current URL active in the browser. By changing it, the browser opens the new value of the URL instead. This property should generally only be set by the web site's developers. Still, the hacker has allowed himself to set that property on your website by posting this.
The ReadyAPI test checks against this as well. However, to prevent loss of data and security to your users, it does not send malicious scripts - it merely sends scripts similar in nature to the harmful strings that attackers may use.
Fuzzing Scan
This scan checks how your API will respond when it is sent a large amount of random input.
Sometimes, hackers try to overwhelm APIs with random values to cause unexpected behaviour. If an error occurs, it is sometimes revealed by the system stack traces, which are mistakenly sent as a response to the request.
ReadyAPI does a Fuzzing scan by sending completely random input data repeatedly and continuously for an extended period of time.
Invalid Types
This scan checks what happens when your API is provided with invalid data. For example, a text or string value is sent instead of an integer value as price. Once more, the attacker's target is to expose the system's internal working, by making it reveal errors through stack traces and error messages.
Malformed XML
XML stands for Extensible Markup Language. It is a markup language, similar in syntax to HTML, that is used for transporting and storing data. A lot of online services and APIs communicate via XML. This scan checks what happens when the XML your API is sent is not in the correct format.
For example:
<tagA>
<tagC>
</tagB>
</tagA>
This XML is incorrect in multiple ways:
tagC isn't closed
tagB doesn't have an opening tag, but it is closed.
We may also generate malformed XML by adding tags that should not exist, for example:
Here, the product smartphone shouldn't have any tag no_of_pages, which may cause the server to generate an error.
Malicious Attachment Scan
This scan checks if your API can handle malicious attachments. Your API requires the user to upload a profile picture, a PDF file, or anything else. These files can be malicious and may have viruses, trojans, or other malicious intent in them.
A few different methods may do this:
Trying to crash the server by sending corrupted or huge files
Sending viruses or malicious code inside the files
Passing harmful code through the server to another client
ReadyAPI checks against this by sending large and invalid files. If any error happens, it will be detected and notified to you.
SQL Injection
This is one of the most popular forms of attack. Sadly, even though it is well known, many applications remain vulnerable to it. It is performed in a very clever yet simple way.
Suppose you have an SQL database with tables for users, products, orders, etc.
It is easy to guess that those tables will be named - users, products and orders, respectively.
Now suppose you are asking a user for their username. If a hacker was filling out this form, he might write something in the form of:
John Doe)”; DROP TABLE USERS;--
Now, on the backend - you must have written a query of the format:
“INSERT INTO USERS (username) values (” +username+“);”
Where username is the variable that you fetched from the front-end, which is equal to the string “John Doe)”; DROP TABLE USERS;--” entered by the hacker. When inserted into your query, the entire query string becomes:
“INSERT INTO USERS (username) values (John Doe)”; DROP TABLE USERS;--);”
Let us look at how SQL will parse this string:
INSERT INTO USERS (username) values (John Doe)”;
DROP TABLE USERS;
--);”
The first statement will insert the username, John Doe, into the users table.
The second statement will deletethe users table altogether
The third statement begins with a -- , which is SQL syntax for a comma -, so the parser will ignore everything after that.
The hacker has thus deleted your SQL table by just entering a username value. These are generally protected against by validating the input first and ensuring it doesn't contain anything harmful. A better way is to escape all special characters (such as “ and ;) entered by the user by adding a \ before them. Several libraries are already available for this, and we are recommended to use them.
ReadyAPI tests against this by sending similarly styled inputs to your APIs, and checking if they result in anything harmful.
XML Bomb
XML Bombs, also known as Billion Laughs Attack, are a way to overwhelm the server by sending an XML document that expands recursively into a huge document when being parsed. This attack generally consists of defining 10 entities (you can think of them as variables), each of which is the previous entity repeated 10 times.
When parsed, the parser sees that the document has one string - lol9
But lol9 is defined as lol8 10 times
lol8 is again defined as lol7 10 times, and so on, until lol
When recursed, this leads to the string lol9 having 1 billion copies of the first entity - lol. This is where the name billion laughs attack comes from.
The ReadyAPI scan sends a similar XML bomb to your server in the message or as an attachment. It then checks if the server was able to respond or if an error occurred (servers may even shut down because of this)
XPath Injection
XPath is a language used to query XML documents. Let's say I have my users stored in an XML document, and I want to get the user corresponding to a username and password. Let the example XML file be:
Suppose the user enters his username as:lol' or 1=1 or 'a'='a
And the password as lol
The final query string would be:
//User[UserName/text()='lol' or 1=1 or 'a'='a' And Password/text()='lol']
Which is equivalent to:
//User[(UserName/text()='lol' or 1=1) or ('a'='a' And Password/text()='lol')]
We all know how boolean expressions work, and it is easy to see that this condition will always be true. Thus the hacker may gain access to the entire XML document itself.
ReadyAPI scans against this by sending similarly styled inputs and checking the responses.
Frequently Asked Questions
Can databases like MongoDB be attacked using injections too?
The answer is yes! Even modern databases like MongoDB are not safe from injection attacks. MongoDB can be injected, and these attacks are known as MongoDB Injection, or more generally - a NoSQL injection. Some people consider NoSQL injections more challenging to secure against than SQL injections since NoSQL databases are newer. Thus the format of attacks will be unknown.
Can the billion laughs attacks be done in other formats except for XML?
Yes, it can be done in any language that supports Macros. Notably, the Kubernetes software was attacked with the billion laughs attack via the YAML format, which Kubernetes uses for configuration files.
What is the point of securing my API if only I am going to use it?
A rule to be always followed is - never assume all the calls to your backend will come from your own frontend. As we have seen, someone might figure out the API URLs and call them using malicious, invalid, or harmful data.
Conclusion
This blog has explored what ReadyAPI is and what security tests it offers. We have also seen in detail what those security risks are, how they are exploited, and how ReadyAPI checks against them.
We hope you leave this article with a broader knowledge of ReadyAPI, Internet security and network attacks. We recommend that you explore our different articles on these topics as well, such as:
19+ registered 
