api安全测试⼯具_API安全测试
api安全测试⼯具
API测试的最佳做法 (Best Practices for API Testing)
RESTful APIs have become a fundamental part of modern web application development in recent years. The RESTful approach is far more simple and scalable than the legacy variants of web API that preceded it — such as SOAP (Simple Object Access Protocol).
近年来，RESTful API已成为现代Web应⽤程序开发的基本部分。 RESTful⽅法⽐它之前的Web API的遗留变体(例如SOAP(简单对象访问协议))简单得多且可扩展。
The only implementation of REST is on top of HTTP — the protocol that powers the web. This means that vulnerable REST APIs expo similar risks to traditional web sites and applications, while being more challenging to test with automated web curity scanners.
REST的唯⼀实现是在HTTP之上-HTTP是为Web供电的协议。 这意味着易受攻击的REST API向传统的⽹站和应⽤程序暴露了类似的风险，同时使⽤⾃动Web安全扫描程序进⾏测试更具挑战性。
什么是REST API？ (What is a REST API?)
Before we discuss the challenges of effective curity testing of REST APIs, we should clarify what we’re talking about.
在讨论有效的REST API安全测试所⾯临的挑战之前，我们应该弄清楚我们在说什么。
An API is a mechanism of transferring information between two computer systems. An API can be implemented either at
the code level or at the network level, depending on whether or not the two systems are running on the same machine.
API是在两个计算机系统之间传输信息的机制。 可以在代码级别或在⽹络级别实现API，具体取决于两个系统是否在同⼀台计算机上运⾏。
In a commercial context, an API almost always refers to an interface across the web, which is the most common way of connecting disparate computer systems.
在商业环境中，API⼏乎总是指Web上的接⼝，这是连接不同计算机系统的最常⽤⽅法。
Modern Web APIs are usually implemented using REST (REprentational State Transfer). REST is
an architectural style in which all of the information necessary to access or change the ‘state’ of a web rvice can be made in a single API call —such as getting a data record or updating a databa.
现代Web API通常使⽤REST (表⽰状态传输)来实现。 REST是⼀种体系结构样式，其中访问或更改Web服务的“状态”所需的所有信息都可以在单个API调⽤中完成，例如获取数据记录或更新数据库。
RESTful APIs offer a clean paration of concerns between the front-end (prentation layer) and the back-end (data-access layer). The RESTful style has been recognid as the international standard becau a single REST API can be consumed simultaneously by mobile devices, web applications and IoT devices without any alterations, making it the cheapest and most flexible way to build modern applications.
RESTful API在前端(表⽰层)和后端(数据访问层)之间提供了清晰的关注点分离。 RESTful样式已被公认为国际标准，因为移动设备，Web 应⽤程序和IoT设备可以同时使⽤单个REST API，⽽⽆需进⾏任何更改，这使其成为构建现代应⽤程序的最便宜，最灵活的⽅式。
亚眠大学
RESTful API安全性测试原理 (Principles of RESTful API Security Testing)只剩下伤痛
There are only four core principles to performing curity tests on RESTful APIs. As is often the ca however, the principles can be difficult to put into practice.
在RESTful API上执⾏安全性测试只有四个核⼼原则。 但是，通常情况下，这些原则可能难以付诸实践。
The simple principles are as follows, and can be implemented trivially into a web rver:
简单原理如下，并且可以在Web服务器中轻松实现：
1. Inputs of an incorrect type must be rejected.
类型不正确的输⼊必须被拒绝。
a. Corollary: Inputs that are null (empty), when a null is unacceptable, must be rejected.
⼀个。 结果：如果不接受null，则必须拒绝为null(空)的输⼊。
2. Inputs of an incorrect size must be rejected.
2. ⼤⼩错误的输⼊必须被拒绝。
职责是什么意思The more difficult principles require an intimate understanding in the range of acceptable values and urs, which can be hard to infer without understanding how a REST API will be consumed.
⽐较困难的原则要求您在可接受的值和⽤户范围内进⾏深⼊了解，⽽如果不了解如何使⽤REST API，就很难推断出这⼀点。
3. For a given input value, the API must provide the expected output.
3. 对于给定的输⼊值，API必须提供预期的输出。苏洵
This can be easy to test when the input domain and the output range are simple (e.g integers or phone numbers). This becomes extremely difficult when building permissive RESTful APIs that enable urs to submit their own content (e.g in a chat application).
当输⼊域和输出范围很简单(例如整数或电话号码)时，这很容易测试。 当构建允许⽤户提交⾃⼰的内容(例如在聊天应⽤程序中)的允许的RESTful API时，这变得极为困难。
4. Input values outside the expected domain must be rejected.
4. 必须拒绝超出预期范围的输⼊值。
Once again, this is easy when the domain is simple (e.g input values should be integers above zero), but becomes complex when urs can supply content (e.g a file upload endpoint could prent a significant challenge to cure).
同样，当域很简单(例如，输⼊值应为零以上的整数)时，这很容易，但是当⽤户可以提供内容时(例如，⽂件上载终结点可能会给安全性带来巨⼤挑战)，这变得很复杂。
5. For a given ur, the API must provide only the data that they are authorized to access.
5. 对于给定的⽤户，API必须仅提供他们有权访问的数据。
If permissions are already defined and are resources stratified in accordance with their permission level, this can be easy to implement. In practice however, authorization is a hard problem — with veral multi-billion dollar companies (like Okta) around to solve it.
如果已经定义了权限，并且资源根据其权限级别进⾏了分层，则可以轻松实现。 然⽽，实际上，授权是⼀个难题，有多家数⼗亿美元的公司(如Okta)来解决它。
Most APIs aren’t properly tested to ensure they meet this criteria. Becau of this, breaches occur frequently and entire industries exist to offer a protection layer on top of APIs.
⼤多数API均未经过适当测试以确保符合此条件。 因此，经常发⽣违规⾏为，并且整个⾏业都存在着在API之上提供保护层的功能。
A well designed APIs should prent the first-line of defen against attack, and so effective testing should be a top priority.
设计良好的API应该是抵御攻击的第⼀道防线，因此有效的测试应该是当务之急。
API安全测试 (API Security Tests)
There are three main types of testing that compo the curity auditing process, designed to cure an API against external threats.
有三种主要类型的测试组成安全审核过程 ，旨在保护API免受外部威胁。
观潮教学设计安全测试 (Security Testing)子宫偏大
Security testing validates whether basic curity requirements have been met. The include the following questions:
安全测试验证是否满⾜基本的安全要求。 这些包括以下问题：
1. What kind of authentication is necessary to consume the API, i.e how do you evaluate the identity of an end ur?
使⽤API需要进⾏哪种⾝份验证，即如何评估最终⽤户的⾝份？
2. What sort of encryption is ud on the stored data, and at which points are the data decrypted for transmission?
对存储的数据使⽤哪种加密⽅式，在什么时候解密数据以进⾏传输？
3. Under what conditions are urs allowed to access resources?
在什么情况下允许⽤户访问资源？
This stage of the audit process comes first, and will help prevent the major vulnerabilities.
审核过程的这⼀阶段排在第⼀位，这将有助于防⽌重⼤漏洞。
渗透测试 (Penetration Testing)
Penetration testing enables you to harden the external surface of your application from vulnerabilitie
s that may have crept in during development.
渗透测试使您能够增强应⽤程序的外表⾯，使其免受开发期间可能出现的漏洞的侵害。
In this step, external aspects of the API are attacked in a deliberate fashion in a controlled environment. This can be done using automated tools such as Netspark or Acunetix.
在此步骤中，在受控环境中以故意的⽅式攻击了API的外部⽅⾯。 可以使⽤Netspark或Acunetix等⾃动化⼯具来完成此操作。
When organising a Penetration Test, the following steps should be taken:
组织渗透测试时，应采取以下步骤：
1. Identify a list of potential vulnerabilities applicable to the application (e.g does it have resources like images which
手颈could expo a directory traversal attack?)
确定适⽤于该应⽤程序的潜在漏洞列表(例如，它是否具有诸如图像之类的资源，可能会暴露⽬录遍历攻击？)
2. Order the items in accordance with their risk. You can u the OWASP Top 10 website to get a better understanding of
the risk associated with each type of vulnerability.
根据风险订购物品。 您可以使⽤OWASP Top 10⽹站来更好地了解与每种类型的漏洞相关的风险。
3. Engineer requests and ssions that incorporate the attacks, and nd them at the system — ideally from within the
network as well from outside.
⼯程师将合并攻击的请求和会话发送给系统，最好是从⽹络内部以及外部发送。
4. If unauthorid access to the system is made, file a vulnerability report and go back to patch the issue.
如果对系统进⾏了未经授权的访问，请提交漏洞报告并返回以解决该问题。
模糊测试 (Fuzz Testing)
Fuzz testing is the final aspect of a curity auditing process, in which an API is pushed to its limits. This can be done by nding vast request volumes at it, attempting to vary the data in as many creative ways as possible to cover the possibilities of vulnerabilities emerging at high volume which could compromi curity.
模糊测试是安全审核过程的最后⼀个⽅⾯，在该过程中，API达到了极限。 为此，可以发送⼤量请求，并尝试以尽可能多的创新⽅式更改数据，以涵盖⼤量出现的可能危及安全性的漏洞。
Such vulnerabilities could be exploited by Denial Of Service or Overflow attacks.
可以通过拒绝服务或溢出攻击来利⽤此类漏洞。
如何在API上执⾏安全性测试 (How to perform a Security Test on an API)
Testing an API means submitting requests using client software to an endpoint of the application that is being evaluated. This is almost always a HTTP client, and there are many free options available.
测试API意味着使⽤客户端软件将请求提交到正在评估的应⽤程序的端点。 这⼏乎总是⼀个HTTP客户端，并且有许多可⽤的免费选项。
The most popular clients are Postman or Insomnia. Insomnia is the best choice for smaller APIs, as it is easy to work with and requires little configuration. Postman is better for more complex APIs, as it stores authentication parameters and enables you to create collections of requests. Postman also has the capacity to automate testing through ‘monitors’, which is uful if the underlying application is constantly changing.
最受欢迎的客户是邮递员或失眠者。 失眠是较⼩的API的最佳选择，因为它易于使⽤且⼏乎不需要配置。 Postman更适合更复杂的API，因为它存储⾝份验证参数，并使您能够创建请求集合。 Postman还具有通过“监视器”⾃动进⾏测试的能⼒，这在基础应⽤程序不断变化的情况下⾮常有⽤。
Automating parts of the Security Audit process can speed up the DevOps lifecycle. The two parts that are easiest to automate are the Fuzz Test, and the Security Test that was discusd in the previous ction.
使安全审核过程的各个部分⾃动化可以加快DevOps的⽣命周期。 最容易⾃动化的两个部分是Fuzz测试和上⼀节中讨论的安全测试。
Step 1: Determine Security Requirements. In order to plan a curity test on an API, you must first understand the general requirements. This means asking questions like:
步骤1 ： 确定安全要求。 为了计划对API的安全测试，您必须⾸先了解⼀般要求。 这意味着要提出以下问题：
Should the API u a TLS/SSL certificate, and be accesd over HTTPS?
API是否应该使⽤TLS / SSL证书并可以通过HTTPS访问？
What permission groups exist for different resources in the application?
应⽤程序中针对不同资源存在哪些权限组？
What is the authentication flow? Is an external OAUTH provider ud?
什么是认证流程？ 是否使⽤外部OAUTH提供程序？
What is the attack surface of the API? Where could a malicious actor subvert the application.
API的攻击⾯是什么？ 恶意参与者会在哪⾥破坏应⽤程序。
As part of asking the above questions, it is important to have a good understanding of what constitutes pass vs failure of your test.
作为提出上述问题的⼀部分，重要的是要对什么构成通过测试与未通过测试有很好的了解。
Step 2: Set up a testing environment. Once the scope of the test has been developed, it is time to prepare an application environment for testing. For smaller applications it’s reasonable to u the standard staging environment. For larger applications with a lot of internal state, it is better to t up a parate environment for the test — either by replicating all resources in the staging environment, or by using a tool such as WireMock to mock them out.
步骤2：建⽴测试环境。 ⼀旦确定了测试范围，就可以准备⽤于测试的应⽤程序环境了。 对于较⼩的应⽤程序，使⽤标准暂存环境是合理的。 对于具有很多内部状态的⼤型应⽤程序，最好通过在暂存环境中复制所有资源，或者使⽤诸如WireMock之类的⼯具来模拟它们，为测试设置⼀个单独的环境。
Step 3: Sanity check your API. Send a few requests at the API to ensure that everything has been t up correctly.
第3步：理智地检查您的API。 在API上发送⼀些请求，以确保⼀切均已正确设置。
Step 4: Define the input domain. Before developing individual test cas, it is important to understand what each parameter does, and the different combinations that each parameter is allowe
d to be. This enables you to define edge-cas (values that are barely valid), and determine the parameters which are most vulnerable to injection attacks (like SQL injections).
步骤4：定义输⼊域。 在开发单个测试⽤例之前，了解每个参数的功能以及允许每个参数的不同组合⾮常重要。 这使您能够定义边缘情况(⼏乎⽆效的值)，并确定最容易受到注⼊攻击(例如SQL注⼊)的参数。
Step 5: Develop and execute the test cas. Once you have prepared the test environment, and understand possible edge-cas, you can create and execute tests — comparing the actual output with the expected output. As a matter of best practi, you should group the depending on the type of test that is being undertaken. Some examples are as follows:
步骤5：开发和执⾏测试⽤例。 准备好测试环境并了解可能的极端情况后，就可以创建和执⾏测试-将实际输出与预期输出进⾏⽐较。 作为最佳实践，您应根据要进⾏的测试类型将它们分组。 ⼀些⽰例如下：
Can resources be accesd using HTTP as well as HTTPS?
是否可以使⽤HTTP和HTTPS访问资源？
Do all endpoints require authentication?
所有端点都需要⾝份验证吗？
If you support file upload, what happens if you upload a potentially malicious file, with the mimetype that is expected by the application?
组织活动方案
如果您⽀持⽂件上传，那么如果您上传的潜在恶意⽂件具有应⽤程序期望的模仿类型，会发⽣什么情况？
If the web-app that consumes the API embeds ur-supplied information (e.g a name) on the page, what happens if you supply a HTML/JS element instead?
如果使⽤该API的Web应⽤程序在页⾯上嵌⼊了⽤户提供的信息(例如名称)，那么如果您提供HTML / JS元素怎么办？
Can you access resources that your token isn’t authorized to access?
您可以访问令牌⽆权访问的资源吗？
If you follow the instructions, you should have a good understanding of the curity posture of your application, and a toolkit for ensuring that no significant curity issues end up in a production deployment.
如果遵循这些说明，则应该对应⽤程序的安全状况有充分的了解，并拥有⼀个⼯具包，以确保在⽣产部署中不会出现重⼤的安全问题。
api安全测试⼯具
