你好，非常喜欢你们的作品。
在测试demo时发现了一个与 #985 相似的XSS漏洞
Issue
以现状来看，恶意负载并未存储在数据库中 所以漏洞归类为反射型XSS漏洞 风险比较低。
但如果将其嵌入到一个有数据库的应用程序中，或者说md可以储存起来，它就会变成存储型 XSS（Stored XSS），风险将显著提高。
这种漏洞常见于 WYSIWYG 编辑器。
恶意负载：
[XSS](javascript:alert%28document.domain%29)
以下是重现漏洞的方法：
直接注入
利用 ”添加链接“ 功能
添加引用链接
Recommendations
要彻底修复此问题，需要同时进行服务器端（server-side）和客户端（client-side）的输入验证。
目前注意到该模块只能实现客户端验证。
建议发布一个使用建议，提醒用户在服务器端也进行输入验证，仅依靠客户端验证是可以利用代理工具(burpsuite, caido, zap, yakit)绕过的。
建议参考以下文件来做修复：
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
你好，非常喜欢你们的作品。
在测试demo时发现了一个与 #985 相似的XSS漏洞
Issue
以现状来看，恶意负载并未存储在数据库中 所以漏洞归类为反射型XSS漏洞 风险比较低。
但如果将其嵌入到一个有数据库的应用程序中，或者说md可以储存起来，它就会变成存储型 XSS（Stored XSS），风险将显著提高。
这种漏洞常见于 WYSIWYG 编辑器。
恶意负载：
以下是重现漏洞的方法：
直接注入
利用 ”添加链接“ 功能
添加引用链接
Recommendations
要彻底修复此问题，需要同时进行服务器端（server-side）和客户端（client-side）的输入验证。
目前注意到该模块只能实现客户端验证。
建议发布一个使用建议，提醒用户在服务器端也进行输入验证，仅依靠客户端验证是可以利用代理工具(burpsuite, caido, zap, yakit)绕过的。
建议参考以下文件来做修复：
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html