Belmode

@moon548834 #8

首先，我说以下一般实现，现在很多网站或者说产品，都没有专门设置 CSRF token 的，都不是通过这种手段来避免跨站攻击。
在你例子中，用户从钓鱼网站 B 触发的网站 C 的请求，携带了 Cookie 到目标服务器，但是服务器是不会认可`此次请求已被授权的`，因为不是从网站 C 页面上发起的，所以网站 C 的 JS 没有执行，没有讲 Cookie 中的 token 部分提取出来，放到 Header 中，并拼上`Bearer`之类的符号，所以这次请求，就和用户第一次访问网站 C 一样，是安全的。

这其中关键在于，网站 C 服务端，不认可从其他网页发起的 http 请求，只认可自己页面的，所以借助 Ouath2.0 令牌模式的机制，避免了 CSRF 。

当然你自定义任何方式都可以，只要类似我#6 的说法。

PS1： 理论上令牌可以放到任何位置，但是一般放到 localStorage 里，因为浏览器请求在没有 JS 处理的情况下，不会携带这些信息，有一定安全性。
PS2： 我说的只是一种最简单的模型理论，实际上企业中，预防 CSRF 的手段特别多，因为用户信息和权限的校验步骤非常多，也非常复杂，不是那一种方式就能完成的，都是多种手段并用。
PS3：V 站用了 CSRF token ，并且这个 token 有实效，过期了，页面都直接时效了，可以参考。

因为 Android 上没有对应的 php 运行时和 php 基础库的支持。
你要愿意，可以用 android 的 so 库实现 php 运行时，开发一个能跑 php 的 app ，在 app 内借助 java Bridge ，来渲染 activity ，来套娃开发页面，也是可以的。

类似 autojs 的独立 Ui 模式，它就是用的 js Bridge 。

本质上可以，但是没有意义，花活而已。

@Belmode OP 提问中的疑问的答案是肯定的。你那样操作，是可以避免 CSRF 攻击的。

我觉得 CSRF 无非是避免浏览器，在非法跨站请求携带默认参数时，导致的权限问题。那`认证信息`放哪都无所谓了，放 cookie 也可以，放本地存储也可以，提交的时候放 header 也行，放 cookie 也行。只要保证存储和使用时有标记不一样，并且服务端只认带这个标记的`认证信息`。

楼上说的，Bearer Token 就是。`认证信息`存任何地方都行，但是放在请求头上时，Authorization: Bearer <token>。这样就确保，是自己站点的页面执行了 js 发送的请求，不是跨站请求。

所以用 OAuth2.0 之类的认证方式，只要提交请求认证信息时做点不一样的操作，都不用特别考虑 CSRF 攻击，因为从机制上已经避免了。

1. 解锁 bootloader
2. 刷入 Magisk
3. 备份 system 分区
4. 导入 PC ，反编译，修改 UI ，重新打包压缩 bin
5. 修补 system 分区
6. 重新刷入修补后的 system 分区

@Davic1 #9

"Windows 上没有找到很好用的端口转发工具，就用 Powershell 写了一个脚本" ❌

"我开发了一个很好用的脚本工具，要跟大家炫耀一下" ✔️

@chensuiyi #19 你这想法就大错特错。你要不为挣钱，怎么做都可以，随心所欲。但是你要是为了当副业盈利，必须考虑读者！

你要为读者想看什么而去写作，不能特异独行，只写自己的想法。就是为了迎合读者，增加受众，才能有收益，否则就等着光速太监或者无限单机吧。

手动临时变更环境变量

@fengshils 可以参考一下 eggjs 的 cluster 实现，他们做好了。