特殊字符校验的背景

• SQL注入、XSS等常见的安全攻击场景会涉及到一些特殊字符的利用。尤其是界面输入框、API接口可支持输入字符串的情况，如果对来历不明的用户输入如果不加防范，很容易产生安全问题。

• 正确的做法是在根据业务流程在各个环节添加合适的安全防护、处理逻辑。例如：对于输入的字符串参数做一定的参数校验、对参与执行SQL操作的参数进行预编译、对于参与界面回显的参数针对回显的上下文领域做对应领域的编码等。

• 由于根据不同的业务流程需要针对特殊字符做的安全防护各有不同，相应的设计、实现等成本较高，所以通常大家会倾向于尽量在第一道防线（参数校验）上解决大部分的问题，降低后续流程处理的工作量跟难度。所以本文旨在分析探讨如何在参数校验阶段，设计好针对不可信字符串的校验、过滤，尤其是特殊字符相关的校验。

特殊字符校验的原则

参考华为Web应用安全开发规范：确保输入数据只包含允许的字符集，不包含不合法和危险的字符，尽可能采取“白名单”的方式进行输入校验。

总体思路是分两种情况：

1. 输入范围较为明确的字段，如XXid、XXname、邮箱、手机号等。可以明确列出允许输入范围的，要使用白名单的校验方式。例如如果对于用户名只允许包含字母、数字和下划线，则可以使用正则表达式对输入做白名单校验：^[0-9A-Za-z_]+$

2. 输入范围较大、较不明确的字段，如备注、富文本内容等，由于全量的特殊字符（包括键盘可直接输入、键盘不可直接输入）集数量还是非常大的，当业务上也没法通过简单的白名单枚举的方式枚举出合法字符的范围时，就需要根据业务流程，选择相关的危险字符，进行黑名单的过滤校验。例如，存在一个remark字段用户保存后会展示在界面上被其他用户看到，此时我们要对XSS做重点关注，我们可以通过如下正则校验字符串是否不包含指定的危险字符^[^”‘()/&=]+$。

延伸：注意，参数校验只是为了低成本的一次性解决大部分的问题，不能完全强依赖这个环节的校验，也不能强求这个校验把所有的有可能出现风险的字符都包含全。比如，上例的remark如果业务上就是需要输入（、）、=等符号怎么办？难道就是不允许输入吗？也是不合理的。所以对于XSS注入防护的终极方案依然是在渲染前做字符编码，这样既能支持多数字符的输入，又不会有安全问题。所以还是建议特殊字符校验只选择最通用危险的少量特殊字符，配合其它的安全防护（比如字符编码、SQL预编译等）。

常见安全场景对应的危险特殊字符表

使用指导：在做安全评估时，可将字母、数字、中文以及无安全攻击场景的字符作为安全最小集，如果不涉及自定义拼接SQL，可以忽略第一列。

• 微软Windows系统：每行结尾有“”，即“rn”

• Unix/Linux系统: 每行结尾只有“”，即”n”

• 苹果Mac系统： 每行结尾只有“”，即”r”

如果不清楚这些概念，很容易导致写错正则表达式。我们分别在window、linux系统上创建文件，内容为AB{换行}AB。如下，通过肉眼是看不出区别的：

在UE中按下Ctrl+H可查看二进制，如下可以看到window文件的换行符实际上为0D 0A，即rn。

linux文件的换行符只有一个0A，即n

通过代码将文件内容读取后，使用正则表达式做判断，发现^[ABnAB]+$只能成功匹配linux下的文件。