Often web applications also offer APIs as well as parts of their functionality via so-called REST interfaces. We should implement and secure these interfaces just as robustly as we do for the rest of the application. This includes filtering and validating inputs and outputs as well as the secure and reliable retrieval and verification of users and their rights. Depending on the data formats our interfaces use (for example, JSON or XML), filter routines are required to supplement specific security functions for the particular format.
7.1 What are the threats facing us and our customers?
|Unauthorized Access to Data and Functions
If APIs or REST interfaces are not fully and robustly implemented in our applications and accessible to strangers, data may be manipulated or deleted by unauthorized users.
Unauthorized access to data or functions via such interfaces directly compromises the confidentiality, integrity and availability of our users‘ data, and can also be a threat to our IT infrastructure.
7.2 What should we consider during development?
|Filter Requests and Parameter:: Whitelisting
To prevent attacks on manipulated client requests or manipulated parameters, all incoming data should be filtered and, if possible, checked using a whitelist (list of legitimate values). The Whitelist should be created as restrictively as possible and contain only allowed values and strings.
Many frameworks provide APIs and REST interfaces for filtering or whitelisting, often in conjunction with scaffolding and automated generation of source code for APIs and REST interfaces. The filter rules and whitelists created by the framework should be rechecked by the developer.
|Use of Transport Encryption, if appropriate
The use of SSL / TLS ensures that data (especially important tokens, log-on or session data) between the server and the client are always exchanged encrypted, thus preventing interception and / or manipulation by third parties.
The transport encryption thus contributes significantly to the confidentiality and integrity of the data of our customers. For the implementation of SSL / TLS, sufficient time should be scheduled, since a misconfiguration and others may lead to scenarios where attackers can reach sensitive data through SSL / TLS downgrade attacks or missing certificate checks despite transport encryption.
|Do not Encode Sensitive Information in URL
Sensitive information such as user names, passwords, and security tokens should not be encoded in the URL so that they are not stored in the browser history or in unencrypted connections in our server logs.
7.3 Further Information
|Best Practices (=pattern) for securing REST:
https://www.owasp.org/index.php/REST_Security_Cheat_SheetInformation about XML documents as attack vector:
https://www.owasp.org/index.php/XML_Security_Cheat_SheetWhite Paper about attacks on APIs and possible protective measures:
http://www.ca.com/us/~/media/Files/whitepapers/Protecting-your-apis-against-attack-and-hijack.pdfGuide to implement REST interfaces: