Laravel项目被入侵了,请问该如何应对和解决呢?

大家好,前不久基于Laravel 7.0写了一个项目,后端主要是为客户端提供API接口来处理业务。API接口采用的是dingo + jwt

项目一直运行的没有问题,直到有一天,有用户反映号被盗了。具体表现就是用户没有进行任何操作,却发现自己的钱被提走了。

我们首先想到了是密码暴利破解,但是在观察了一下日志,却发现没有任何尝试密码登录的API接口日志。

而通过进一步分析日志发现,我们找到了黑客的IP,确实是黑客的IP 模拟了被盗号用户的Token,直接进行提现的。

JWT是我们一直在项目使用中使用的认证方式,而如今竟然被黑客“破解了”,因为他貌似知道用户ID,就可以模拟其TOKEN进行操作。

而JWT的秘钥一直存放在服务器上的,服务器走的是跳板机,理论上服务器本身是很难入侵的。那么他到底是怎么攻破系统的?

于是,我们继续分析日志,看到了这个IP曾经大量对我们的系统API接口进行各种注入和漏洞的渗透性测试,但是由于日志数据量过大和专业知识不足,我们目前不能得知黑客是通过哪一个接口漏洞最终破解了用户TOKEN。

虽然我们通过一些其他限制暂时保护了用户的资产安全,但是项目的漏洞一直存在,而且黑客近期也发送了邮件,进行了勒索,扬言不给钱就要销毁全部数据,公司老板也给了很大压力,认为PHP项目的安全性问题还是不足,当然我最终还是归结于自己知识能力的不足,无法应对这样的安全事件。

所以,我只得发帖,请教有经验和更专业的人士,给与我们一些技术性的指导和帮助?

目前,我们关注的就是如何能够查找和修复这个TOKEN漏洞,请求大家帮助~

附录 黑客尝试渗透的一些日志。

Laravel项目被入侵了,请问该如何应对和解决呢?

本帖已被设为精华帖!
附言 1  ·  2个月前

2020-08-04

昨天一天尝试了@fogwang 的建议,主要从JWT本身的问题上入手,尝试了NONE算法,公钥算法,以及KID攻击等手段,但由于只是储备不足,仍然没有破解出来。 希望有这方面经验的朋友给出一些建议。

本帖由 CrazyZard 于 2个月前 加精
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
最佳答案

可能是旁站攻击,网上有旁站扫描工具,根据你的服务器IP扫描该服务器上其它的项目,你公司服务器会不会有其他项目,比如使用过thinkPHP、dedeCMS等等有过重大安全漏洞的框架在运行?

2个月前 评论
L学习不停 2个月前
游离不2 2个月前
jasonz1987 (楼主) 2个月前
jasonz1987 (楼主) 2个月前
小李世界 2个月前
wangchunbo 2个月前
dancheng 1个月前
讨论数量: 110
  • 所有涉及到资金转移的操作,都要使用手机验证码或登录密码双重验证,这里可以根据是否常用设备,是否频繁登录等风险记录自动识别。牺牲一些体验性换安全性。
  • 针对现在这个事件
    • 更换服务的的秘钥
    • 增加接口节流设置
    • 查看项目相关目录权限是否合理,是否存在都是 777 权限的问题
    • 查看用户权限是否合理,是否用 root 用户来运行项目了
    • 日志中增加关键调试信息,主要是针对 Token 领取、验证、更新的环节
    • 是否开启了全站 HTTPS

另外你这个是什么类型的项目,如果是小程序或者App,那可以在前端后端统一做加密,或者通过用 OpenId 的方式和用户微信绑定一起做验证,基本可以杜绝这种问题出现。

2个月前 评论
24K大白羊 (作者) 2个月前
jasonz1987 (楼主) 2个月前
crackfan 2个月前
Liuzhipeng_laravel 2个月前
❤seven 2个月前
Trance 2个月前
Liuzhipeng_laravel 2个月前

观望

2个月前 评论

找第三方安全公司帮忙检测,或者找见网警?

2个月前 评论

关注中,希望能找到合理的方案

2个月前 评论

我不是专业人士,但你可以试着模拟黑客的操作,看一下可以得到什么结果。

我看到黑客也是在请求你们的接口 通过接口去操作系统文件(个人观点)

2个月前 评论

关注中,希望能找到合理的方案

2个月前 评论

关注,公司项目跟楼主一样。 :cry:

2个月前 评论

和我前公司的经理一样,本身他是.net出身,让我们二开他源码站买的代码, 被攻击了就说是php辣鸡,不过我们碰到的是ddos攻击,后来买了高防就好了

2个月前 评论

mark一下,观望大佬

2个月前 评论
tangq

你们调用api使用https了没有啊?然后可以更改一下jwt密钥试试?

2个月前 评论
cbasil 2个月前
jasonz1987 (楼主) 2个月前

公司老板也给了很大压力,认为 PHP 项目的安全性问题还是不足

这句话欠妥。 :unamused:

2个月前 评论
jasonz1987 (楼主) 2个月前
leo

jwt 是怎么生成的,payload 里包含了哪些信息

2个月前 评论
jasonz1987 (楼主) 2个月前
leo (作者) 2个月前
jasonz1987 (楼主) 2个月前

一般项目的用户ID不都是自增的么,随便试也能试出来

2个月前 评论
檀烟 2个月前
crackfan 2个月前
月光

我觉得你应该找到最后一部分的日志放出来看看

2个月前 评论
jasonz1987 (楼主) 2个月前

观望 怎么会被破解

2个月前 评论

关注。希望看到合理的解决方案。

谢谢!

2个月前 评论

有没有可能你们的key被破解了,另外你们的api是否有限流限制。关于key破解,可以用这个流程测试一下。www.v0n.top/2019/11/01/%E6%B5%85%E...

2个月前 评论
jasonz1987 (楼主) 2个月前
jasonz1987 (楼主) 2个月前
crackfan 2个月前

建议直接报警!! :smile:

2个月前 评论
jasonz1987 (楼主) 2个月前

我只是提一下思路 你可以试试。你没有说用户是单个还是好几个。密钥隔离着,那么暂且认为黑客不知道密钥,那么黑客得到token就是根据登陆接口。我很早以前有碰到一个服务器被注马的项目,最后查找到原因是因为上传的图片等文件在服务器,黑客把木马藏在图片中上传,然后找到图片地址启动木马。你可以看看有没有类似的上传在服务器上,上传文件与服务器隔离就可以,图片的话对图片进行压缩等处理也可以消除危险。你现在先排除服务器有没有被注马,如果服务器注马,那么其他措施都不能解决问题。 然后说到用户,如果是单用户,那么要搞清是不是用户被注马,或者用户的密码简单被猜到。这样的的话就要通过异地登陆提醒,和密码设置策略,以及加设付款密码等措施来尽量保障用户。如果是多用户,那么极有可能就是直接攻克的服务器。这方面的话就要找专业的白客团队做一下安全测试寻找漏洞。

2个月前 评论
lipowei 2个月前
maliang47 (作者) 2个月前
lipowei 2个月前
llkllc 2个月前
Liuzhipeng_laravel 2个月前
lipowei 2个月前

可能是旁站攻击,网上有旁站扫描工具,根据你的服务器IP扫描该服务器上其它的项目,你公司服务器会不会有其他项目,比如使用过thinkPHP、dedeCMS等等有过重大安全漏洞的框架在运行?

2个月前 评论
L学习不停 2个月前
游离不2 2个月前
jasonz1987 (楼主) 2个月前
jasonz1987 (楼主) 2个月前
小李世界 2个月前
wangchunbo 2个月前
dancheng 1个月前

还有就是检查一下能获得用户信息的接口,有没有可以自定义返回数据字段的,或者以其他参数方式达到同样效果的

2个月前 评论

观望,等待大佬空降

2个月前 评论
mengdodo

先检查下服务器是否使用的默认22端口,是否存在ssh爆破,终端输入 last查看登录记录试试

2个月前 评论
jasonz1987 (楼主) 2个月前
阿神

围观学习中

2个月前 评论

换一台服务器重新部署 密钥也换一下 然后观察日志分析

2个月前 评论
小李世界

建议日志文本,而不是图片,不然转码都没法转

2个月前 评论

file 它是怎么定位这些路径的。。

2个月前 评论
Nella 2个月前
aa24615 2个月前

jwt 里面再加入一个签名

2个月前 评论

跳板机是啥?,不知道你们id有没有加密 :smirk:

2个月前 评论
jasonz1987 (楼主) 2个月前
Boxer 2个月前

提现这类敏感操作要验证密码+验证码+IP检测

2个月前 评论
jasonz1987 (楼主) 2个月前
quyin2018

关注,等待大佬!

2个月前 评论
panda-sir

大兄弟 问下你们前端是不是用的cookie存储的token

2个月前 评论

同楼主,我前几天的项目上线8个小时就被搞了。。。和楼主情况差不多,冒充了用户的 token 然后提现。
不过我是简单的在数据库加了个 api_token 字段用自带的 auth:api 认证,怀疑可能是数据库被人搞到了。但是感觉如果对方搞到数据库可以直接修改自己的余额。所以想法又被自己否定了
现在用户认证换成了 JWT, 不知道对方还会不会搞

2个月前 评论
MIsakas (作者) 2个月前
嘿喵财运旺旺 2个月前
mengdodo 2个月前

防止lz没看到 我贴个 URL

翻译:[重要] Laravel 6.x 和 7.x 重大安全更新

不知会不会跟次有关?

2个月前 评论
小滕 2个月前
jasonz1987 (楼主) 2个月前
小滕 2个月前
jasonz1987 (楼主) 2个月前
小滕 2个月前
PHP-Coder 2个月前
jasonz1987 (楼主) 2个月前

关注,期待大佬们的解决方案!

2个月前 评论

关注,可以了解一下使用的相关依赖库的版本号么

2个月前 评论
jasonz1987 (楼主) 2个月前

单纯 token 还是有点难顶, 抓个包伪造下请求就 GG 了, 有条件的还是得用动态 token + ip + device Id 之类的验证

2个月前 评论
jasonz1987 (楼主) 2个月前
crazy (作者) 2个月前
jasonz1987 (楼主) 2个月前
crazy (作者) 2个月前

如果是 token 是用 cookie 存储,有可能被运营商卖到黑产了

2个月前 评论
jasonz1987 (楼主) 2个月前
symfonyluxury (作者) 2个月前
symfonyluxury (作者) 2个月前
  • 所有涉及到资金转移的操作,都要使用手机验证码或登录密码双重验证,这里可以根据是否常用设备,是否频繁登录等风险记录自动识别。牺牲一些体验性换安全性。
  • 针对现在这个事件
    • 更换服务的的秘钥
    • 增加接口节流设置
    • 查看项目相关目录权限是否合理,是否存在都是 777 权限的问题
    • 查看用户权限是否合理,是否用 root 用户来运行项目了
    • 日志中增加关键调试信息,主要是针对 Token 领取、验证、更新的环节
    • 是否开启了全站 HTTPS

另外你这个是什么类型的项目,如果是小程序或者App,那可以在前端后端统一做加密,或者通过用 OpenId 的方式和用户微信绑定一起做验证,基本可以杜绝这种问题出现。

2个月前 评论
24K大白羊 (作者) 2个月前
jasonz1987 (楼主) 2个月前
crackfan 2个月前
Liuzhipeng_laravel 2个月前
❤seven 2个月前
Trance 2个月前
Liuzhipeng_laravel 2个月前

mark,等大佬解答

2个月前 评论

首先 token是唯一、而且是一次性的,你们问题应该是出在提取token 也就是登录验证这块。

2个月前 评论
jasonz1987 (楼主) 2个月前

之前我用JWT做过多表登录(前台users表,后台admins表),我发现把users的token拿来 admins使用直接通过。后来发现要修改getJWTCustomClaims方法

2个月前 评论
jasonz1987 (楼主) 2个月前
converst 2个月前

先升级服务器防护,然后修改秘钥,敏感操作增加验证,生产环境秘钥不要上传其他地方,防止外泄,本质上jwt是不可逆的,除非秘钥泄露或者token泄露,还有问题那就是服务器内攻破了或者本身框架有漏洞,有这能力还会勒索吗?

2个月前 评论
jasonz1987 (楼主) 2个月前

mark,等方案吃经验

2个月前 评论

请问下secret的长度?

2个月前 评论
jasonz1987 (楼主) 2个月前

能否过滤出黑客 http 状态码是 200 的请求看看?

2个月前 评论
jasonz1987 (楼主) 2个月前
檀烟 2个月前

是已经能登录服务器了吗

2个月前 评论
jasonz1987 (楼主) 2个月前

看被注入的参数,有点类似这个攻击
3、magic_quotes_gpc = on
举一个典型的SQL注入示例,假如SQL语句用如下方式拼接:
1
select * from user where pass=’ “. $_GET[‘passwd’]. “‘ and user=’” . $_GET[‘username’] .”‘;
假如用户提交一个login.php?passwd=p&username=’ or ‘1’=’1请求,代码中的SQL语句将变成:

这就造成一个SQL注入漏洞。避免此问题出现的正确思路是开发者在拼接SQL语句之前过滤所有接收的数值,并严格执行这种编码规范,但是并不是所有的开发者都会意识到这种问题的存在,而此时,如果将php.ini的magic_quotes_gpc设置为On时,PHP将对所有GPC参数($_GET,$_POST,$_COOKIE)进行addslashes处理[既转义单引号、双引号、反斜线和nullbyte],该SQL语句将是:

由于’已经被转义,SQL语句不能被成功执行,从而防止SQL注射。

另外,以小节2中的http://HostA/test.php为例,当magic_quotes_gpc= Off的情况下,用户提交一个example.php?param=../../../etc/passwd%00请求,由于代码中限制的文件后缀(.php)将被%00截断,就会通过require_once尝试读取/etc/passwd文件。

值得注意的是,magic_quotes_gpc配置为On时,有以下缺点:

1、PHP此时会对所有GPC参数做addslashes处理,会有比较大的性能损耗。

2、当GPC参数被用于其他操作如逻辑关系判断之前就必须先做strislashes处理,否则结果必然是不正确的。

考虑到开启此选项带来的性能损耗和代码的复杂化,可以在使用时灵活设置,对于一些不规范或者无人维护的代码,可以开启此选项;更好的做法是将此值设置为Off,由开发者严格过滤来自用户的输入。

转自:www.cnblogs.com/52php/p/5677789.ht...

2个月前 评论
24K大白羊 2个月前
xujinhuan 2个月前
crackfan 2个月前

换个思路: 从最基本的登录逻辑慢慢一层层的做检测 不要把简单问题复杂化 或许有所发现(ps 想法简单请勿喷!)

2个月前 评论
黄志成

mark一下

2个月前 评论
黑将军

坐等大神解答

2个月前 评论

会不会是用户自己下小黄片 导致电脑中毒 token被人拿到

2个月前 评论
jasonz1987 (楼主) 2个月前
xujinhuan 2个月前
junson (作者) 2个月前
jasonz1987 (楼主) 2个月前
Yzzzzz 1个月前
mengdodo

再次关注

2个月前 评论

有没有可能是用户密码过于简单?

2个月前 评论
jasonz1987 (楼主) 2个月前

我觉得重点检查生成token的接口。看你有没有通过模型生成token

2个月前 评论
jasonz1987 (楼主) 2个月前

重要操作之前使用短信验证, 这个比登录管用, 或者再次数次支付密码

别使用None算法, 用sha265应该就管用了, 我不太相信能从这个地方破解了秘钥.

确保校验token的数据的时候同时校验的算法

  1. 账号被偷, token被无限制盗用, 这个不太可能, 你说黑客能不断换 id
  2. 用户的 token 被劫持, 然后黑客收集了一批的 token, 所以就能达到你说的不断换id, 其实是黑客有一批token(判断的办法, 把用户生成使用过的token收集起来,然后分析一下到底是token被盗用还是token被恶意生成)

如果真怕秘钥被盗, 重新生成key,不过对用户影响不好,每个用户都要重新登录了.


重要的事情还是要说一句, 应该有一个支付密码~

2个月前 评论
jasonz1987 (楼主) 2个月前
jasonz1987 (楼主) 2个月前
seth-shi (作者) 2个月前
jasonz1987 (楼主) 2个月前
crackfan 2个月前
crackfan 2个月前
seth-shi (作者) 2个月前
seth-shi (作者) 2个月前

jwt本身是无状态的,所以安全性这块得自己保护,payload里的sub不能直接放自增的uid,这就跟url上带uid同时还是自增同一个道理,其次接口得另外加签,所有接口在进入控制器之前,加个签名校验。

然后对方可能是给了烟雾弹,是不是其他地方的漏洞导致项目密钥泄漏?这还得全面排查。

2个月前 评论

扫一下所有文件,看一下有没有改动的,有没有上传有后门

2个月前 评论
xujinhuan 2个月前
Atzcl

如果不是 jwt 秘钥外泄(要检查下是怎么外泄的,是服务器被爆破了还是被渗透了),那么就检查一下会不会是 xss、 iframe 钓鱼等等在客户端进行的攻击行为

2个月前 评论

用公司的项目(也用了 jwtdingo),尝试了一下提到的可能的针对JWT破解的几个方法,似乎不能复现漏洞,找不到绕过的方法,感觉应该不是JWT的问题

很有可能是先注入数据库,然后获取了存在jwts表里的数据,jwt表里的只要是未超时 token 拿出来就能直接访问,注入的地方应该是项目中其它某个接口

  1. 是否直接使用了原生查询: Wiki:Laravel 安全:避免 SQL 注入

  2. Dingo URL 里面的 id 应该要合规校验,比如必须为数字 0-9:

    ApiRoute::get('user/{id}/info', 'UserController@detail')->where('id', '[0-9]+');

以上两点其实我们公司也没有都完全避免,,存在注入风险,,,

2个月前 评论
嘿喵财运旺旺 2个月前
Tabll (作者) 2个月前
嘿喵财运旺旺 2个月前

不用jwt,自己动手撸一个,用户登录后,根据时间戳和用户UID 用AES加密生成token,前端根据token操作时,后端可以解密token,获得UID和时间戳,这样还可以根据时间戳来限制token过期时间。一般黑客看到这种非主流的授权方式,都不会感兴趣的,

2个月前 评论
黑将军 2个月前

抓日志不要抓4xx的,用awk先筛选出2xx的看看

2个月前 评论

首先极有可能是黑客把你的token给搞到了,要分析你token存储在哪个地方 如果存在本地,服务器有没有被黑的可能,可以查服务器的登录日志。看看有没有异常的ip 如果有存在数据库,那么数据库的账号密码有没有被泄露的可能,从而得到了token。 还有按现在的分析,黑客说要删数据,我大胆猜测,极有可能数据这块的账号信息有可能泄露了,或者有可能只是吓人,但是这个还是得重视起来。不能有侥幸心理。 目前的止损方法是:

  1. 更换token
  2. 重新生成数据库账号
  3. 重新生成服务器的登入密码
  4. 用户转款多设置转款密码和短信确认
2个月前 评论

首先呢,损失超过1万找当地派出所报警 其次,我就说个大概吧

  • 找个 WebShell 工具扫描线上的项目,看看是否有常见的漏洞
  • 检查目录权限以及运行用户,看是否有被黑的文件生成了
  • 确认是否是用户账号密码被撞库
  • 检查 mysql, redis或其他服务以及服务器是否存在漏洞或被黑的可能
  • 检查 服务器 是否存在异常或未知的进程
2个月前 评论

楼主,别执着想为什么会被黑客破解了,建议先不动声息的把所有你们数据库存的用户数筛一遍,我可以负责人的告诉你,凡是这种情况90%是你们的某个用户做的,这人并不是什么高级黑客,无非是懂一点技术,无意中察觉了你们的一个漏洞。另外多关注谁最近提现次数多,谁提现数额较大,最近新注册的人是谁,注意设置提现上限和提现次数,以及短信验证。

2个月前 评论

涉及到金额的项目最好把服务器登录设置为SSH,把密码登录关闭。把服务器重要文件设置为不可读写。

2个月前 评论

可以在redis中存入token,有效时间,用户IP,涉及到金额接口不仅仅要验证token,还需验证token请求的IP,如果IP不一样,需要手机验证。然后在更新redis。提现必须加上支付密码

2个月前 评论

使用JWT加密时请问你使用的是HS256还是RS256,建议使用RS256,安全性上更高一点。

2个月前 评论

楼主最后怎么解决的那?

2个月前 评论

百度搜索 JWT攻击手册:如何入侵你的Token,或许能给你启发

2个月前 评论

我提个思路,从数据库入手看看。既然你们自己的账户也泄露了,定位到泄露的时间,试试看能不能从 mysql 的 binlog 入手,看看是否有异常更新数据的操作存在。同样,看看在被恶意提现之前,nginx 日志有没有用户异常登录调用的过程?这样可以分析是账号密码泄露了,还是直接拿了 token 跳过登录使用的。

2个月前 评论

关注一下。

2个月前 评论

试试aes把请求包加密呢

2个月前 评论

可以問一下您的入口文件是配置在項目根目錄還是在public下面 您有把入口文件移動到項目根目錄嗎

2个月前 评论
  • 个人认为,换一下jwt-secret ,让所有用户重新走登录流程,观察是否还会有用户被攻击的情况。
  • 如果是token发生挟持状态,金融项目的话牺牲体验加固安全的话,必须要考虑token分发时的用户ip与请求ip是否能对上等一些操作。
  • 每个账户如果要确保只有一个登陆token的话,就把token对应用户存储到redis去,虽然原则上这是未被的jwt的签发机制,不过也稍微一定意义上回收那些超时token。
2个月前 评论
aa24615

看图是在扫路径,黑客在尝试是否可读系统文件进一步的破解,光凭一张图,很正常,我以前的站每天几万几万的被人扫描,一般问题不大,注意,你比较重要的站独立放一个服务器上,开启waf,基本上别人扫不进来了

2个月前 评论
panda-sir

你们没有在验证token的合法性之前私自base64_decode第二段信息把 如果不经验证私自解析这个第二段的信息拿来使用 或者在验证之前解析第二段信息拿来使用 很可能会被人伪造token的第二段信息

2个月前 评论
振翅飞翔 2个月前

现在就是过度依赖各种框架和插件,token验证这一块完全可以自己写,自己定义token算法,一般来说用密码+id+时间戳进行几层md5加密都可以,再或者之后加些乱七八糟的加密就行

2个月前 评论
振翅飞翔 2个月前

mark 以下

2个月前 评论

mark下 看后续

2个月前 评论

怀疑你们服务器的 APP_KEYJWT_SECRET 泄露了

2个月前 评论

如果你有本地文件上传,请检测上传漏洞,重点查一下有 eval()函数的文件。我感觉可以破解掉token的人,如果不是巨大的利益是不会攻击你的。一般常见的都是脚本小子,撒大网捕鱼,一旦你服务器被上传木马文件后,就会对你进行比特币勒索,亲身经历

2个月前 评论

首先确定一下所用的laravel内核是否存在新曝光漏洞,然后验证一下JWT密钥的安全性。你发的只是单纯的目录扫描部分,真正的攻击流量你也没发出来,没法判断。注意内部业务逻辑,包括支付过程的支付金额正负判断,权限设置是否得当,是否存在越权。你有需要可以私信联系我帮你看看

2个月前 评论

说说和黑产斗智斗勇采用过的机制; 1 关闭数据库远程链接端口, 数据库链接走内网; 2 后台ip白名单机制 3 生成token时加上ip, 若ip不一致则token失效 4 ssh采用跳板机登陆 5 敏感操作需要谷歌GA验证,后台敏感操作只能是指定用户 基本上,除非服务器被攻破, 就算客户账号密码被泄露, 绑定了谷歌GA. 大多数情况下也不会发生事故

2个月前 评论

你们流程的漏洞太大了,我们项目也有提现功能,提现只能提现微信钱包,提现必须实名认证,认证的时候微信会校验微信号,手机号,身份证是否匹配,不匹配认证不过的,认证不过不能提现,认证通过提现也要后台审核(前面的微信已经确定是本人了,后面这个其实不做也没太大关系)。

2个月前 评论

@jasonz1987 我说的这个可能比较麻烦 在jwt payload中加入自定义key,value为用户的ip+浏览器UA信息(只要能识别用户的唯一信息的字段都可以),然后对其进行加密保存(使用laravel自带HASH加密),使用全局中间件,获取登录用户的payload自定义key,并获取用户的IP+UA信息 进行验签,验签不通过视为非法用户。希望可以帮到你。

1个月前 评论

另外建议你分析下黑客的攻击日志 有200响应码的攻击 可以在本地尝试模拟一下 看一下是不是接口有安全漏洞 后期对请求日志这一块做一下储备 在出问题的时候 可以进行分析

1个月前 评论

是不是贼喊捉贼,你们公司有谁知道secret的 。模拟黑客操作了一波,其实是监守自盗

1个月前 评论

好多人啊 关注一波

1个月前 评论

@zgnMark 哈哈,其实我一开始想的也是这样

1个月前 评论

确实是黑客的 IP 模拟了被盗号用户的 Token,直接进行提现的? 提现不需要实名认证? 不需要手机号验证??

1个月前 评论

就问一个问题是不是用的 宝塔?

1个月前 评论
wsljmxs 1个月前

后来咋样了??

1个月前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!