blade ssti在laravel 9.x中虽非引擎漏洞，但因开发者误用{!! !!}、拼接用户输入到指令或组件路径等导致，可引发rce；修复核心是杜绝用户输入参与模板编译，严格区分数据与指令边界。
Blade 模板注入（SSTI）在 Laravel 9.x 中虽不常见，但一旦发生，风险极高——可能造成敏感信息泄露、远程代码执行甚至服务器沦陷。它不是 Blade 引擎本身的 CVE，而是开发者误用模板语法、绕过转义或混用危险操作导致的业务层漏洞。修复核心在于：**杜绝用户输入直接参与模板编译，严格区分数据与指令边界**。
禁用 {!! !!} 输出不可信内容
这是最常见、最危险的入口点。`{!! $user_input !!}` 完全跳过所有转义，等同于把用户提交的任意字符串当 HTML 渲染。如果该内容来自表单、URL 参数、数据库字段（如用户昵称、评论、富文本），攻击者可注入 `<script>alert(1)</script>` 或更隐蔽的 `{!! $app->make('request')->fullUrl() !!}` 实现服务端模板执行。
- 除非内容明确来自可信后台（如管理员编辑的静态页脚），否则一律改用 `{{ $user_input }}`
- 若必须渲染富文本（如文章正文），必须先用 HtmlSanitizer 过滤，而不是 `strip_tags()` 或正则替换——后者极易被绕过
- 切勿在 `@foreach`、`@if` 等指令中拼接用户输入作为条件逻辑，例如：
@if($user->role == '{{ $input }}')是严重错误写法
避免在模板中执行 PHP 表达式或函数调用
Laravel 9.x 的 Blade 允许在 `{{ }}` 中使用简单表达式（如 `{{ $a + $b }}`），但若变量本身含恶意构造，仍可能触发 SSTI。尤其要警惕以下模式：
- 禁止将用户输入传入 `@include`, `@extends`, `@component` 的参数名，例如：
@include('pages.' . $page)—— `$page` 若为 `../../.env` 就可能读取敏感文件 - 禁止在 `@php` 块中动态 `eval()`、`call_user_func()`、`class_exists()` 等反射类函数，哪怕变量看似可控
- 不要用 `{{ app()->call($callback) }}` 或 `{{ resolve($service) }}` 直接解析用户传入的服务名
安全传递变量到前端 JS 环境
很多 XSS 和模板注入混淆于此。把 PHP 变量塞进 `
