Web项目开发中常见安全问题防范

Posted 2021-02-06 让心去旅行

计算机程序主要就是输入/输出，安全问题由此产生，凡是有输入的地方都可能带来安全风险。根据输入的数据类型，web应用主要有数值型、字符型、文件型。

要消除风险就要对输入的数据进行检查，对于web应用来说，检查的位置主要是前端和后端。前端检查只能防止正常状况，没法防止使用工具、程序绕开检查直接把数据发送给服务器。

输入检查

防止输入注入型攻击。所有的输入数据都要检查，除了前端检查外，为防止使用工具、程序绕开前端检查直接把数据发送给服务器，后端也要检查所有输入数据。

依据产品文档的要求进行合法性检查，数值型，手机号，时间，邮箱等；

检查文本型是否含控制字符，过滤掉控制字符；

检查文本型的长度；

URL字符串转义，使用 urlencode 函数处理；

文件上传

防止文件注入型攻击。

1、文件上传目录设置成不可执行；

2、判断文件类型。结合MIME type与文件扩展名，设置文件类型白名单。对于图片文件，可以利用图片库函数深层次检查是否真是图片；

3、重命名文件名；

4、文件服务器使用独立的域名；

输出转义

防止XSS（跨站脚本攻击）。向页面输出的文本型数据进行 html encode(转义)，即是将一些 html 中的特殊字符转义成普通字符，比如 & 转义成 &，< 转义成 <，"与"都要转义。对应的函数：javascriptencode，php的htmlentities。

同理xml数据包里的字符串值使用xmlencode，json数据包的字符串值使用jsonencode转义。

XSS处理

XSS的本质是HTML注入，用户输入的数据被当成Html代码执行了。

1、cookie 使用 HttpOnly 限制

使得在客户端的js代码不能读取cookie值，但是不能防止从 HTTP header里得到 cookie 值。

2、输出文本 HTML 转义

对网页上显示的文本内容使用 HtmlEncode 转义。js函数：OWASP ESAPI中的encodeCharacter。其它的如xmlencode、jsonencode等转义函数。

3、检查输入的URL

输入的 url 添加上 http: 或者 https:，然后转义输出到网页端

4、对传入js函数的文本型参数值进行 javascript 转义

先进行javascript转义再进行HTML转义

5、SQL注入

预防方法：数据与代码分离，即不用字符串拼凑SQL语句，使用SQL预处理方法（参数使用占位符？）；

6、XST处理

XST（跨站追踪）攻击，关闭Web服务器的TRACE方法；

7、CSRF攻击的防御

通常需要防御CSRF(Cross-Site Request Forgeries)攻击的页面是用户登录、修改/删除确认、订单确认等添加新数据、修改数据的页面，此外此类页面必须使用 POST 方式提交。

简要描述：

CSRF（跨站/域请求伪造）攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作；

解决方法：

使用验证码（安全性最强，但影响用户体验，不建议使用）；

使用同步随机token(安全性强)；

在一个请求中分别在 cookie 和 post 请求数据中提交session id 并在服务端做比对（安全性较强）；

检查 http 请求中 referer 的值（安全性偏强）；不在 URL 中暴露 SessionId 的值，sessionId仅存在cookie中，此外为了增强安全性，在用户登录成功后生成一个新的 SessionId 的值；

8、HTTP头注入

替换HTTP头字符值中的换行符；

9、Cookie安全

Cookie 仅保存 SessionId 的值，设置HttpOnly属性为On；

10、用户密码安全

使用安全的bcrypt替代MD5，bcrypt会产生随机盐 salt

11、权限控制

①.SSO单点登录，openId系统；

②.Spring Security的实现 - 基于角色的访问控制（Role-Based Access Control）RBAC；

③.基于数据的访问控制。比如将用户Id、对象id修改成另一个存在的id，如果没有检查当前登录用户是否是参数对应的id用户，就会产生修改别的用户数据的问题，也即是越权访问；

④.OAuth授权。OAuth第三方开源库；

⑤.SessionId。sessionId加密处理；