开放 API 接口的安全问题 5

其实，我有一个相对简单的方法。

当应用调用后端接口时，将登录应用的用户名和密码拼接到参数字符串中，并使用RSA公钥对参数字符串进行加密并传递给后端。 获取该参数后，后端接收轮裸口使用私钥解密数据，并与数据库中的文件用户名和密码进行比对，如果匹配，则表示为正常访问。

你认为这可行吗？

现在很多**都要用API接口，有些程序和**通信也要用接口。 但是，接口最重要的安全问题是逻辑判断问题，比如最常见的是支付接口，支付接口。 例如，这是对支付接口的判断处理。

它只是 bug 的简化版本，只能部分提取，好吧，orderid 被称为 orederid。 凑合着用它，然后写一个 html 模拟帖子提交是一种声誉。

不过，现在部分支付接口已经修复了这个漏洞，并且已经改为主动查询服务器上的支付状态，而不是被动等待服务器返回 但是还是有一些支付公司没有修复这个漏洞，比如国外机房的面板，这个面板还是很多人使用的充电面板 他的信用卡支付场所没有验证， 如果有账单，选择信用卡来扭曲这个，使用Firebug之类的东西来更改别人的信用卡ID，可以用别人的信用卡支付（强烈推荐！！和 bs 这种行为）还有一个漏洞就是程序与web通信，上次在上面看到它的时候，我看了他在和web通信时写的界面进行验证，没有对SQL注入进行任何过滤

谢谢！！

API安全主要包括三个方面：信息安全、网络安全、应用安全

信息安全是您希望确保系统中的所有信息在其整个生命周期内都受到保护和安全的。

所谓全生命周期，包括信息从创建、存储、转换、备份，甚至销毁。

应用程序旨在抵御攻击并防范风险。

确保信息仅由目标用户访问。

防止未经授权的创建、修改和删除。

当用户需要访问 API 时，服务始终可用。

假装成某人[例如，我不是系统管理员，但我假装是系统管理员，然后我想做任何我想做的事]。

更改您不希望被修改的数据、消息或设置（例如，要更改法定货币订单的状态，在用户支付款项后，允许用户将订单状态从未付款更改为已付款，但不允许用户在修改自己的订单时修改其他人的订单）。

拒绝承认已经做了什么[例如，用户需要退款，然后我们退款，但他拒绝承认他已经退款了]。

泄露您想要保密的信息（例如，用户信息泄露）。

拒绝用户访问信息和服务（最常见的是 DDoS 攻击，它会破坏您的服务、阻止您的服务并阻止您向用户提供服务）。

做你不想让他做的事。

解决了拒绝服务的 API 安全风险。

限制可防止用户请求淹没您的 API

解决了欺骗的 API 安全风险。

身份验证可确保您的用户或客户端确实是他们自己的一方。

解决了可否认的 API 安全风险。

审计确保所有操作都被记录下来，以便进行可追溯性和监控。

解决信息泄露、干预和未经授权访问的 API 安全风险。

授权可确保对 API 的每次访问都获得授权。

解决信息泄露的API安全风险。

加密可确保进出 API 的数据是私密的。

所谓认证，就是验证用户身份是否合法的过程;

身份验证的目的是验证来自该用户的用户的身份（例如，验证用户发送的授权标头）。

另一方面，登录是用户获取身份的过程[供用户获取身份]。

授权用于访问控制。

要遵循最小授权原则【用户只给他必要的权限，不给他不想要的权限，必要时再申请橙色草稿】。

1.您的请求是否需要身份验证或权限控制

2.确定您是否具有权限

1. acl【acess control lists】

1.该 API 被恶意调用。

1）我们可以使用timestamp方法来解决问题。在服务层，将接口传递的时间戳与当前时间进行比较，例如，将请求的有效期设置为 60 秒。

2）根据需要对时间戳进行加密，防止攻击者模拟对时间戳的攻击。

2.接口数据已被篡改。

1）使用签名机制对上传的接口参数数据进行加密，生成签名。服务器端使用相同的算法来验证签名，以保证数据的一致性。

2）加密算法为：sign = md5 （md5（a=1120）+md5（b=1144）），a，b为具体上传的数据。

3.界面敏感清晰，数据被盗。

对上传的敏感数据（如密码）进行加密。 加密算法尽量对噪声做出响应，后端处理可以加盐，进一步提高加密水平。

最后，我们也可以直接使用HTTPS协议来增强API的安全性。