Security vulnerabilities in RESTful APIs (Application Programming Interfaces) introduce the same risks as security issues in websites and other web applications: sensitive data theft, manipulation, and more. Therefore, it is very important to know how to test them efficiently. However, some characteristics of REST APIs make it difficult to perform proper REST API security testing using automated web application security scanners. Acunetix is a good tool for this purpose because it has useful features that let you circumvent these difficulties.
What Is a REST API
APIs and web services separate the front end and the back end of an application. Web services also separate web application functions from one another, making their management easier. The same API endpoints can be used by different clients, for example, a web application and a mobile application. For these reasons, most web applications are based on web services and APIs.
REST (REpresentational State Transfer) is one of the architectural styles that can be used to build APIs. It is very appealing because it is based on common web languages and protocols. RESTful APIs expose functions using HTTP methods (also called HTTP verbs:
RESTful APIs are easy to implement and understand, and therefore many developers choose REST when building Single Page Applications (SPAs). REST is rapidly replacing older web service technologies such as SOAP APIs (Simple Object Access Protocol).
Automatically Scanning REST APIs
An automated black-box web security scanner must know the structure of the web service before it can test it. This can be difficult with RESTful APIs because not all of them have a web front end that can be examined to learn this structure.
If the RESTful web service has a Single Page Application (SPA) front-end, you can point the scanner directly to the SPA and scan it. The crawler interacts with the front-end application and issues requests to the web server end as a regular user would. The structure identified by the crawler can be further used to test underlying web services for vulnerabilities.
RESTful web services may also use the Web Application Definition Language (WADL). If they do, you can provide WADL definitions directly to the Acunetix scanner. However, if there is no WADL definition, you have to use a different method to teach the scanner about the API structure.
If you have an API client that you cannot scan, you can record requests made by that client in a format that can be consumed by automated tools. Acunetix supports a number of formats, including HTTP Archive (HAR) files, Acunetix Proxy Log files, Telerik Fiddler SAZ files, and Portswigger Burp Suite state files. In the case of applications that have end-to-end test suites designed for API testing, you can just run these test suites through an HTTP proxy that can generate one of the above formats and then import the result into Acunetix. Acunetix will automatically detect the input scheme and individually test all API endpoints for a variety of vulnerabilities such as susceptibility to SQL injection attacks.
Authentication and Rate Limiting
REST APIs usually require the client to authenticate using an API key. In most cases, the authentication mechanism is based on an HTTP header passed in each HTTP request. With Acunetix, you can define custom headers, which are then used during a crawl or a scan of a published API.
The final obstacle to REST API security testing is rate limiting. Rate limits define the maximum number of requests that can be sent in a given time window. If you cannot disable rate limiting during a scan, you can throttle Acunetix scans by adjusting the scan speed on the main target screen.
*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Ian Muscat. Read the original post at: http://feedproxy.google.com/~r/acunetixwebapplicationsecurityblog/~3/ztQy7qAWOj0/