CKEditor存入数据库的数据是否能抵御XSS攻击？Laravel非转义输出场景问询

结论：这种场景下依然存在XSS攻击风险，绝对不能认为完全安全 #

风险点主要来自以下几个方面：

• 前端过滤可被直接绕过
  CKEditor默认开启的高级内容过滤（ACF）确实会对输入的危险标签做转义处理，你测试的<script>被转义为<script就是该机制的作用，但所有前端层面的校验都是不可信任的。恶意攻击者可以完全绕开页面的CKEditor组件，直接向后端接口提交未经过滤的恶意HTML代码，只要后端没有做二次校验过滤，恶意内容就会直接存入数据库，用{!! $post->body !!}渲染时就会触发XSS攻击。
• CKEditor过滤规则存在绕过可能
  如果CKEditor配置不当，比如关闭了ACF、放宽了允许的标签和属性范围，很多非script标签的恶意Payload依然可以注入成功。比如允许img标签但没有过滤onerror等事件属性时，<img src=x onerror=alert('xss')> 这类Payload不会被CKEditor拦截，渲染时会直接执行脚本；未过滤javascript伪协议的场景下，<a href="javascript:alert('xss')">测试链接</a> 也可以正常触发攻击。
• 富文本XSS变种多，很难完全覆盖
  富文本场景下的XSS攻击Payload变种非常多，包括SVG标签注入、内联样式中的危险语法、各种新增的HTML事件属性等，仅靠CKEditor的默认过滤规则很难覆盖所有攻击场景，一旦存在规则遗漏就会出现安全漏洞。

推荐的加固方案：

• 保持CKEditor的ACF过滤开启，根据业务需求最小化配置允许的HTML标签、属性、样式，明确禁止所有事件属性、javascript/vbscript伪协议、iframe/script/frame等危险标签。
• 后端必须增加HTML内容的二次过滤，Laravel场景下可以使用HTML Purifier这类成熟的过滤组件，对用户提交的富文本内容做服务端的安全校验，过滤所有危险内容后再存入数据库。
• 若业务允许，优先使用Markdown代替直接提交HTML的方式，渲染Markdown时使用安全的解析器输出转义后的内容，从根源降低XSS风险。

内容的提问来源于stack exchange，提问作者Alphy Gacheru