PHP 对用户注册的用户名只允许字母和数字是否完全可以过滤 xss？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1680 天前的主题，其中的信息可能已经有所发展或是发生改变。

php 新手，对 xss 感到恐惧，害怕 SQL 被注入了，只允许字母和数字是不是完全可以过滤 xss 了？

XSS

PHP

字母

过滤

25 条回复 • 2020-04-10 11:36:36 +08:00

littleylv

2020-04-09 11:08:18 +08:00

治标不治本。
你在前端的任何设置别人都可以 F12 给你改掉。
最重要的是在后端

ben1024

2020-04-09 11:08:27 +08:00

对于所有用户输入的入口都要做限制

sytnishizuiai

2020-04-09 11:11:35 +08:00

无论前端是否过滤，你后端都要过滤一遍，sql 用 pdo

star7th

2020-04-09 11:20:23 +08:00

虽然我没试过，但我的理解是可以的。就这么用着先吧。如果有用框架最好使用框架自身的过滤函数。

star7th

2020-04-09 11:21:00 +08:00

不要在前端过滤。任何过滤都需要在后端进行

dremy

2020-04-09 11:26:22 +08:00 via iPhone

什么年代只要拼接 SQL 就一定会有注入

susecjh

2020-04-09 11:57:40 +08:00

跟用户交互的地方尽量不要拼 sql 好吧

2020-04-09 12:13:07 +08:00

问题是：XSS 跟 SQL 注入并无直接关系啊？

ajaxfunction

2020-04-09 12:15:23 +08:00 via iPhone

pdo 了解一下？
XSS 和数据库貌似关系不大啊
XSS 是会污染前端页面吧

wh1012023498

2020-04-09 13:22:18 +08:00

惊了惊了,楼主问 xss,一群人回答 sql inject.

AngryPanda

2020-04-09 13:26:49 +08:00

XSS 和数据库关系不大。但是存储型 XSS 通常会利用数据库来存储数据。

learningman

2020-04-09 13:37:24 +08:00 via Android

@wh1012023498 因为楼主的理解就有点问题。

buffzty

2020-04-09 13:38:37 +08:00

我们前端用 react 了,随他怎么 xss,框架自动转义了. 没用框架之前 php 返回之前先转义

est

2020-04-09 13:43:23 +08:00

字母和数字一般来说是够了。这个白名单就是治本的操作。不要听 1 楼乱说。前提是你在后端用白名单。

还有正则会包含 unicode 可能会有一些猥琐技巧通过 unicode 来 XSS 。

falcon05

2020-04-09 13:47:25 +08:00 via iPhone

xss 话常用的 PHP 模板引擎比如 twig 默认就打开了 html 的转义，问题不大

yunye

2020-04-09 13:52:28 +08:00

Web 安全开发规范手册 V1.0
https://segmentfault.com/a/1190000017090860

web 应用常见安全漏洞一览
https://segmentfault.com/a/1190000018004657

baobao1270

2020-04-09 13:52:59 +08:00

1. XSS 和 SQL 注入不是一个东西，XSS 通过前端（ HTML/JS ）攻击，直接目标是其他用户； SQL 注入危害的是服务器，直接目标是网站服务器本身。
2. 通常，通过正则验证可以过滤很多有害内容
3. 所有用户输入必须在后端进行过滤后，才能储存到数据库中
4. XSS 通过 HTML 转义函数基本可以完全控制
5. SQL 注入应当通过具有 SQL 预处理功能的框架解决（基本可以解决所有 SQL 注入），自己拼接 SQL 是非常不可取的做法。

funbox

2020-04-09 14:38:08 +08:00

@falcon05 老司机

wysnylc

2020-04-09 15:13:13 +08:00

前后端统一过滤 > 可以干掉 99%的 XSS 无论是存储型还是反射型

zgzhang

2020-04-09 18:10:01 +08:00

@kisshere 很早以前的笔记,请参考
XSS 的防御需要在特定的场景下使用特定的方法:
1. 变量在 html 代码中输出，这时的应对方法应该是使用 htmlencode
所谓 htmlencode 就是让浏览器不把这部分信息当做 html 代码处理而是当做纯文本。这样就避免了对原有页面信息的污染。一般需要转义的字符包括以下：<、>、&、"、‘、/这六个。
2. 变量在 html 标签的属性中输出例如 <div id="abc" name=""><script>alert(1)</script ><""></div>
防御方法也是采用 html 编码
3. 在 script 内输出变量：
(1) 保证变量处在""内 "$test" 这样如果发起攻击的话，首先就要绕过双引号的封锁
(2)对变量进行 javascript 编码，对 script 内的特殊字符前加上\
4. 在事件内输出： <a href="#" onclick="funA('$var')"></a>可以通过如下方式绕过
<a href="#" onclick="funA('');alert('1');"></a>
也需要进行 javascript 编码
5. 在 css 内输出：首先要尽力控制这种情况，不要允许用户自定义 css 的 style 等内容，如果必须这样做需要用到 owasp 的 encodeForcss()函数
6. 输出到 URL，使用 urlencode 就可以避免了，但注意 http://这部分不要被转义否则不能完成功能
7. 处理富文本，由于富文本必须当做 html 解析，所以比较复杂：
(1)首先过滤掉比较危险的标签<form><iframe><base><script>，尽量使用白名单
(2) 尽量禁止用户自定义 css 样式 style 属性
(3)使用比较好的 xssFiter
8. Dom 型的 XSS：一般先进行一次 javascriptencode 再进行一次 htmlencode 才可以完全过滤