API安全,api安全厂商

php开发api接口,如何做才算是安全的

这个问题很深

安全，不敢当，因为web安全问题很多，不仅仅是PHP编码而已，有很多安全上的问题需要做处理，像服务器漏洞、端口开放都会导致被黑，这都是很正常的。

只能说 比如在我做PHP开发过程的一些安全保护和在网络安全公司开发时的工作要求：

1、最基础的，提供的api接口 要配置https。

2、api返回响应的信息，要尽可能使用消息加密返回，如高位数的 rsa加密内容。

3、接收的回调开放接口，尽可能做到使用回调黑、白名单，如加ip白名单放行，或ip黑名单禁止访问。

4、不要相信用户输入、输入信息要进行编码转换、转义、过滤、使用框架和插件进行处理，如MySQL查询的要进行参数绑定、如显示问题要避免xss攻击会进行过滤。

5、授权操作，错误限制设置阀值、超过阀值限制访问、如最基础的登录功能。

6、常见额弱口令问题导致漏铜，应设置高强度口令，避免程序爆破。

7、文件上传问题、应严格校验文件类型、后缀、格式、及文件目录权限设置，从而避免文件上传漏洞导致恶意代码或webshell攻击。

8、开发环境和生产环境隔开，不要再生产上面开debug、及时更新使用框架漏洞补丁如PHP国内常用 tp系列以前偶尔爆出漏洞（我用的较多就是tp5 ....），还有框架不要用最新要选择最稳定的。

最后注意不管是验证还是过滤，在客户端执行过一次也好，在服务端，都要再次执行验证和校验。

和盛之文 ?我的文章保存网站，欢迎访问学习或参考

08.如何保证API接口的安全性问题01

1.互联网Api接口到底如何保证安全性问题？

2.代码落地实战防御XSS、CSRF攻击

3.代码落地如何防御接口数据被黑客抓包篡改？

4.接口数据加密对称还是非对称加密好

XSS攻击通常指的是通过利用 网页 开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上也可以包括 Java 、 VBScript 、 ActiveX 、 Flash 或者甚至是普通的HTML。攻击成功后，攻击者可能得到包括但不限于更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。 [1]

脚本攻击：利用JavaScript 注入 到后台数据库中，在通过展示数据加载该脚本 该脚本中（

1.使用js获取cookie信息（jwt）

2.将该jwt数据 上传黑客服务器（ajax）

）

获取jwt---用户会话信息 让后模拟请求形式使用该jwt登录。

xss攻击典型网站：论坛、评论区

前端传递 js 脚本到服务器端

后端接口将该脚本存放数据库中

前端html

将用户前端所提交的参数进行过滤。

html 大于 小于号

该方式的缺陷：每个参数都需要像这样写 代码非常冗余

接口接受参数 ？传递参数形式---

传递参数都是json数据形式

spring mvc 接受 json数据提供 api回调

1.可以使用第三方抓包工具，对请求前后实现代理，可以修改参数请求内容和参数响应内容,抓包工具http调试工具

2.Fiddler4下载地址：

使用Fiddler4篡改请求之前：

使用MD5可以直接验证签名参数 MD5 属于单向加密，只能够暴力破解。

MD5应用场景 在nacos分布式配置中心中，使用MD5 比对文件内容是否发生改变

HasherPro比对文件内容是否发生改变。

MD5在线暴力破解地址：

String userName= "123456" ;

System. out .println( DigestUtils. md5Hex (userName));

黑客如何破解？自己需要根据参数内容 生成签名

如果只是改了参数内容---没有用的 所以我们需要该签名

{"password":"123456","phoneNumber":"phoneNumber","channel":"安卓","equipment":""}

{sign=325ab041d4889825a46d1e1e802ab5de, timestamp=1652537015771}

如何保障API安全？

派拉软件的api安全网关平台是基于微服务化、智能安全认证的API集成网关，提供稳定、高效、可扩展的自研平台。可以帮助企业提供完善的API分析，实现可视化、智能

化、一体化决策。提供完整云端API生命周期管理,提供灵活、无代码的API编排平台。

案例 - 知名快消企业的API安全治理之道

数字化趋势下，快消企业几乎把大部分业务包括核心业务都搬到了线上，并越来越依赖API整合大量系统，实现业务彼此之间的交互。但同时，通过API获取数据的攻击也越来越受到黑客的欢迎，传统安全产品在应对新型API攻击时也逐渐力不从心。

为了解决API面临的各种安全风险与挑战，弥补传统安全产品的不足，瑞数信息推出瑞数API安全管控平台（API BotDefender），从API的资产管理、敏感数据管控、访问行为管控、API风险识别与管控等维度，体系化保障API安全。

目前，瑞数API安全管控平台（API BotDefender）已成功应用在多个快消企业中，其中不乏行业头部企业。以下为两个典型的快消企业API安全治理实践案例。

案例一

某知名餐饮零售连锁企业

某知名餐饮零售连锁企业，拥有过亿的全球用户，其线上应用日活已超3000万。该企业基于行业领先的IT建设，采用了主流的动静分离架构，核心业务都在API接口上，同时为了保证业务安全，很早就部署了传统API网关、WAF、风控等安全产品。

然而，该企业已有的API网关更多是在鉴权层面起到作用，缺少API安全层面的发现和管控。部署的传统WAF基于规则库，则对于该企业来说是个黑盒子，只能看到拦截效果，无法透视业务威胁，也无法从业务角度进行安全分析。而风控产品，由于缺乏和安全平台的联动，无法帮助该企业识别恶意行为。

因此，该企业采用了瑞数API安全管控平台（API BotDefender），以对API安全进行全方位的管理和保护。部署后，通过瑞数API资产管理功能，该企业很快发现了一批未被清点、临时接口未关闭的API资产；通过API异常行为管控功能，更发现了大量异常行为和背后的异常账号设备，并实施了批量封堵处理。

例如，该企业采用一种线上下单、店内取货的模式，经瑞数API安全管控平台溯源发现，某用户的手机号码在24小时内就连续下单超过50次，这显然不符合正常用户的使用逻辑。同时，瑞数API BotDefender还发现涉及这种异常行为的设备高达230个，其中有80个设备在1小时内使用了5个以上的账号进行下单，总共涉及1540个手机号——这些传统安全产品无法识别的异常行为，都在瑞数API BotDefender平台上清晰地展示出来，并能够被实时拦截。

此外，除了API资产管理和API异常行为管控功能，瑞数API BotDefender还为该企业提供了全生命周期的API安全能力，不仅覆盖OWASP API Security Top10的攻击防御，并且通过API业务威胁模型，可以快速应对诸如爬虫、撞库等一系列API的业务安全攻击，为该企业的API安全提供了全面防护。

案例二

某知名保健美容零售连锁企业

某知名 健康 美容零售连锁企业在全球拥有数千万活跃会员，其庞大的业务体量，使得该企业一直将信息安全作为其IT建设中的重中之重。为了保护线上业务安全，该企业自2017年起一直采用瑞数动态应用保护系统 Botgate，对大量机器人攻击行为、薅羊毛、安全攻击等行为进行了有效防护。

随着该企业更多的业务交易从线下转移到线上，数字化营销程度不断深入，微信小程序成为其开展业务和营销活动的主要线上渠道之一，API接口数量随之快速增长，通过API接口发起的攻击也越来越多。攻击者试图通过API越权访问会员信息，批量获取用户隐私信息，这让该企业意识到应迅速加强API防护。

2020年，该企业在原有的瑞数动态应用保护系统基础上，扩展了API BotDefender模块，补充API防护能力， 在以下四方面获得了立竿见影的效果：

数字化浪潮中，快消企业必须面对愈加复杂的网络安全环境，与黑产进行持续升级的对抗。瑞数API BotDefender作为API防护的创新方案，基于瑞数独有的“动态安全+AI”核心技术，能够为快消企业建立完整的API资产感知、发现、监测、管控能力，有效保护企业的业务安全和数据安全。

JWT-token—前后端分离架构的api安全问题

前后端分离架构带来的好处一搜一大堆，我们来看一下分离后后端接口的安全问题。

前后端分离架构现状：

这样的情况后端api是暴露在外网中，因为常规的web项目无论如何前端都是要通过公网访问到后台api的，带来的隐患也有很多。

1.接口公开，谁都可以访问

2.数据请求的参数在传输过程被篡改

3.接口被重复调用

...

session和cookie都是客户端与服务端通讯需要提供的认证，当客户端的值和服务器的值吻合时，才允许请求api，解决了第1个问题，但是当攻击者获取到了传输过程中的session或者cookie值后，就可以进行第2、3种攻击了

JWT标准的token包含三部分：

头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等

将上面的JSON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Header

Payload也是一个JSON对象。包含了一些其他的信息

这里面的前五个字段都是由JWT的标准所定义的。

将上面的JSON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Payload

将上面的两个编码后的字符串都用句号 . 连接在一起（头部在前），就形成了

最后，我们将上面拼接完的字符串用 HS256算法 进行加密。在加密的时候，我们还需要提供一个 密钥（secret） 。如果我们用 mystar 作为密钥的话，那么就可以得到我们加密后的内容

这一部分叫做 签名

最后将这一部分签名也拼接在被签名的字符串后面，我们就得到了完整的JWT

签名解决了数据传输过程中参数被篡改的风险

一般而言，加密算法对于不同的输入产生的输出总是不一样的，如果有人 对Header以及Payload的内容解码之后进行修改，再进行编码的话，那么新的头部和载荷的签名和之前的签名就将是不一样的。 而且，如果不知道服务器加密的时候用的密钥的话，得出来的签名也一定会是不一样的。

解决了篡改数据的问题，还有第3个问题，那就是攻击者不修改数据，只是重复攻击

比如在浏览器端通过用户名/密码验证获得签名的Token被木马窃取。即使用户登出了系统，黑客还是可以利用窃取的Token模拟正常请求，而服务器端对此完全不知道， 因为JWT机制是无状态的。

可以在Payload里增加时间戳并且前后端都参与来解决：