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里增加时间戳并且前后端都参与来解决: