防止 xss 和 sql 注入而进行非法字符过滤， js 前端有什么几乎一劳永逸的方式？

[tctc4869]

网上有各种防止 xss 和 sql 注入的方案，前端的也有，后端的也有。各种方案太多太杂，看的我头疼。

我的策略是，前端负责非法字符的过滤，转换，显示，让过滤后的安全数据入库，以及能安全的显示给用户看。而后端处理非法字符，就很简单。一旦检测到非法字符就直接返回 404，403,400 等错误码。

那么问题来了，先不考虑富文本，就那种普通的文本框，假设每个用户用浏览器操作，在输入框里输入的内容中，都可能带有 sql 注入，xss 攻击所用的代码的一段文字或文章例，前端如何负责这些带有非法字符的过滤转换？让数据能安全的入库，然后在数据显示时，又能显示用户输入时的样子，又不出问题呢。

[zdhxiong]

@moonlord
看 v2 的 api 就行，返回的字符都是转义过的
https://www.v2ex.com/api/replies/show.json?topic_id=665687

[moonlord]

@zdhxiong
睁眼说瞎话？搜下<script>？

[moonlord]

@SilentDepth
题目问的一劳永逸……
所以你看 V2EX 的答案就是我的答案，不允许你输入 HTML，只允许你输入文本
你自己有特殊需求，那就需要什么 tag，就检验限制就完了啊，有啥好讨论的

[ikaros1997]

<img onerror="alert(111)"/>

[SilentDepth]

@moonlord #83 一劳永逸也得看需求啊。「如何一劳永逸地解决人口太多粮食不够吃的问题」，难道你的方案是别生孩子吗😓。本来我也觉得这个问题不至于讨论成这样……

另外，结合上面那位朋友提供的 API 来看，V2EX 压根儿也没限制你输入什么，谈不上「只允许你输入文本」。

[moonlord]

@SilentDepth
要想一劳永逸，那可不就是不生孩子嘛！

[SilentDepth]

@moonlord #86 大兄弟，你的思想很危险……😏

[u823tg]

问哈站长回复为啥不用富文本编辑器。-_-

[SilentDepth]

@u823tg #88 赌五毛是因为懒（

[mtrec]

@SilentDepth 就是你输入任何内容都当成是文本 没毛病 那老哥是冲了点 但是对的

[u823tg]

绝对的安全没可能，带套了还有那么 1%的可能怀孕，哈哈！！

[Leon6868]

@tctc4869 我的意思是，如果出现 xss 或者 sql 注入，那很可能是比较高级的攻击者进行攻击。如果你是用 post 或者 ajax 传入后端，他们可以再构造一个包，绕过你前端的检测。其实后端检测到后报告 404 或 403 就可以了。

10 楼的答案已经很好了，可以参考一下

[Leon6868]

@moonlord #21 我想知道你是前端还是后端还是产品经理。。。你去用工作台看看 v2 的"<>"，看看是不是被转码了。你再用 postman 发一个没被转码过的包，看看是否会被转码，再回来好吗？。。

[otakustay]

@Leon6868 tctc4869 说的并不全无道理，后端不搞过滤只搞拦截，安全性并没有什么损失

[SilentDepth]

@mtrec #90 是的，我没有说 #10 的做法是错的，我只是在说那个方案可行的前提是不允许用户输入包含 HTML 内容，但实际业务中不全是这种情况。想要「一劳永逸」就需要解决本质问题，而 XSS 的本质问题就是意外执行了用户提供的 脚本内容，那么把可能会被执行的内容转换成不可执行的普通文本就是最直接的做法。

[moonlord]

@Leon6868
我是全干工程师，怎么了
工作台是啥
还在说转码，看看 81 楼吧

https://www.v2ex.com/api/replies/show.json?topic_id=665687

[Leon6868]

@moonlord 确实，innerText 是可以避免的，确实是我的问题，学习了。不过 sql 注入一般是数据库操作，不就要返回服务端吗？但是返回服务端就需要通过请求啊，这些包是可以中途截下来的。（当然你可以用 token 来防止，但是攻击者可以修改你的代码，然后在按照自己的想法把包发去除嘛）

[tctc4869]

@Leon6868 我的策略是，数据转码，交给前端做。后端只负责"是不是有，有就别想进入";后端做请求过滤，那是多此一举。

[skyRival]

@ikaros1997 防住了。

[Leon6868]

@tctc4869 我也是这个意思