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

观望

关注/。

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

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

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

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

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

mark

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

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

mark一下，观望大佬

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

交易所？

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

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

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

观望 怎么会被破解

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

谢谢！

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

建议直接报警！！ :smile:

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

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

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

观望，等待大佬空降

关注

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

围观学习中

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

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

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

jwt 里面再加入一个签名

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

关注

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

关注，等待大佬！

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

防止lz没看到 我贴个 URL

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

不知会不会跟次有关？

关注，期待大佬们的解决方案！

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

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

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

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

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

关注中

mark，等大佬解答

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

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

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

mark,等方案吃经验

请问下secret的长度？

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

是已经能登录服务器了吗

看被注入的参数，有点类似这个攻击
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...

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

mark一下

mark 一下

坐等大神解答

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

再次关注

关注

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

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

mark

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

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

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

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

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

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

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

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

mark

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

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

持续关注。

用公司的项目（也用了 jwt 和 dingo），尝试了一下提到的可能的针对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]+');

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

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

mark，坐等大佬

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

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

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

mark

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

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

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

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

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

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

楼主最后怎么解决的那？

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

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

关注一下。

试试aes把请求包加密呢

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

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

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

关注一下~

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

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

顶上去

mark 以下

mark

mark下 看后续

怀疑你们服务器的 APP_KEY 、 JWT_SECRET 泄露了

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

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

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

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

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

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

mark

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

好多人啊 关注一波

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

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

@邪恶的咖啡 英雄所见略同

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

后来咋样了？？

:flushed:有没有可能，客户自导自演？

虚拟货币交易所项目。去年我这边一大批项目被入侵直接导致大量客户流失。损失惨重，咱们被入侵的方式有点不同，但是基本逻辑是一样的。服务器并没有被爆破但是数据被篡改。解决办法就是 关闭debug 。及时更新composer包。laravel 有时候会做一些很重要的安全更新。及时更新很重要。还有一个就是钱包要分离。建议使用第三方钱包。币不过平台。还有就是做这种项目线上服务器不能让第二个人知道密钥密码，宝塔之类的信息， 没有人能对几十万上百万的USDT 抵制诱惑。你可以但是别人不一定行。安全第一

我觉得这都是黑客的障眼法，首先他自己在你们系统注册小号，然后用其他IP登录提走，谎称被盗，至于你log抓的请求，子虚乌有的障眼法，然后你收到邮件更觉得此事蹊跷，放心大胆的，jwt没你想的那么弱，否则中国用laravel的海了，那黑客岂不是发财了。

马一下