Webman是PHP框架而非Python工具,安全加固需在PHP层、Swoole运行时、HTTP协议层和配置层协同完成:禁用硬编码敏感信息,强制参数化查询防SQL注入,输出前按上下文转义防XSS,手动实现CSRF Token校验,并严格配置Cookie属性。

webman 是 PHP 生态中基于 Swoole 的高性能框架,不是 Python 工具 —— 这一点必须先厘清。网上有混淆它和同名 Python 工具的误导信息,但你正在用的 webman 是纯 PHP 框架,所有安全加固都应在 PHP 语言层、Swoole 运行时、HTTP 协议层和配置层协同完成。
避免在 config/ 中硬编码敏感信息
直接把数据库密码、Redis 密钥写死在 config/database.php 或 config/redis.php 里,等于把钥匙挂在门把手上。一旦代码被泄露或服务器被入侵,攻击者能立刻连上你的核心服务。
- 改用
$_ENV或getenv()读取环境变量,例如:'password' => getenv('DB_PASSWORD') ?: '' - 确保
.env文件不在 Web 可访问路径下(如放在项目根目录外,或通过 Web 服务器规则禁止访问.env) - 部署时用
phpdotenv加载,但别在生产环境启用Dotenv::createUnsafeImmutable()—— 它会绕过权限检查
强制使用参数化查询防 SQL 注入
webman 自带的 think-orm 或 illuminate/database 都支持预处理,但开发者仍可能手滑拼接 SQL。比如在 app/model/User.php 中写 "WHERE name = '" . $name . "'",就等于给攻击者开了后门。
Webman 2.2.0版本强化了 TCP/UDP 服务支持,优化路由组管理,并增强异步任务处理能力。结合协程与连接池技术,Webman 能轻松应对高并发场景,适用于网站、接口服务、即时通讯、物联网及游戏开发,兼具高性能、灵活扩展与稳定可靠,是多场景 PHP 服务开发的理想选择。
- 永远用
where()、when()等构建器方法,而不是字符串拼接 - 若必须原生 SQL,只用
DB::select($sql, $bindings)形式,$bindings必须是数组,不能是空或 null - 禁用
DB::statement()执行用户可控的 DDL(如DROP TABLE),这类操作应仅限运维脚本
输出前必须做上下文敏感转义
XSS 不只发生在 <script></script> 标签里。攻击者可以把恶意 payload 塞进 href、onerror、甚至 CSS url() 中。你在 app/controller/IndexController.php 里 echo 用户昵称时,如果没处理,就可能触发存储型 XSS。
- HTML 内容用
htmlspecialchars($str, ENT_QUOTES, 'UTF-8'),不要只用htmlentities()(它不处理单引号) - JS 上下文用
json_encode($str, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG),再包裹在''或""中 - URL 参数必须用
urlencode(),不是rawurlencode()(后者编码 / 和 ?,破坏路由)
启用并校验 CSRF Token(尤其表单和 AJAX)
webman 默认不内置 CSRF 中间件,但它的中间件机制完全支持手动实现。很多项目跳过这步,结果登录态被钓鱼页面悄悄复用,执行转账、删库等操作。
- 在表单中插入
<input type="hidden" name="_token" value="{{ csrf_token() }}"> - 自定义中间件检查
POST/PUT/DELETE请求的_token是否匹配session('csrf_token') - AJAX 请求需在请求头加
X-XSRF-TOKEN: {{ csrf_token() }},并在中间件中读取验证 - 注意:CSRF Token 必须随 session 绑定,不能存在 Redis 共享缓存中供多实例复用(除非你做了分布式 session 同步)
StaticFile 中间件能防部分路径遍历,但它对 /.git/config 这类请求无感;session 配置里的 http_only 和 secure 必须为 true,否则 Cookie 可被 JS 读取或明文传输。这些细节不手动核对,很容易漏掉。

















