Web安全包括以下方面:
认证和授权:确保只有经过身份验证和授权的用户可以访问敏感信息;输入验证:检查用户输入的数据是否合法,避免恶意用户通过输入恶意数据来攻击应用程序;防止跨站点脚本攻击(XSS):防止攻击者在Web页面上注入恶意脚本,从而获取用户信息或执行其他恶意操作;防止跨站点请求伪造(CSRF):防止攻击者利用受害者的Web浏览器发起伪造请求;以下以编码安全、逻辑安全、数据安全展开说明。
本文介绍编码安全,逻辑安全、数据安全在下一篇文章中介绍。

1. 什么是编码安全?
安全编码规范是一种定义编码要求的标准化方法。它确保代码是高质量、可重用和安全的。安全编码规范应该适用于代码开发、测试和维护的所有阶段。
安全编码规范应该涵盖以下方面:身份验证、授权、输入验证、输出编码、错误处理和安全配置管理等。
2. 编码安全-输入验证
任何来自客户端的数据,如 URL 和参数、HTTP 头部、Javascript 或其他嵌入代码提交的信息,都属于不可信数据。在应用外部边界或内部每个组件或功能边界,都将其当做潜在的恶意输入来校验。
输入验证通常采用以下几点:
a. 白名单
不可信数据可以设定白名单校验的,应接受所有和白名单匹配的数据,并阻止其他数据。
b. 黑名单
不可信数据中包含不良输入字符时,如空字节(%00)、换行符(%0d,%0a)、路径字符(../或..)等,建议直接阻止该数据,若需要接受该数据,则应做不同方式的净化处理。
c. 规范化/合法性校正
不可信数据需实施各种净化处理时,应彻底删除恶意字符,只留下已知安全的字符,或者在处理前对它们进行适当编码或“转义”,如数据输出到应用页面时对其进行HTML编码可防止脚本攻击、不可信数据的合法性校验包括:数据类型如字符。数字、日期等特征;数据长度等。
d. 防范SQL注入
不可信数据进入后端数据库揉作前,建议使用正确的参数化查询来处理,禁止拼接 SQL 语句,避免出现 SQL 注入。
e. 访问控制
不可信数据通过上述校验后,还应确认所提交的内容是否与用户的身份匹配,避免越权访问。
3. 编码安全-输出验证:
考虑目标编译器的安全性,对所有输出字符进行正确编码。
输入验证通常采用以下几点
a. 编码输出
不可信数据输出到前后端页面时,根据输出场景对其进行相关编码,如 HTML 实体编码、UR 编码。
b. 净化输出
针对操作系统命令、SQL 和 LDAP查询,净化所有输出的敏感信息,如银行卡、手机号、系统信息等
c. 规范输出
可以采用JSON 格式作为统一的返回值格式这样方便客户端和服务器端进行数据交换(包括返回的状态码、消息、数据等信息)
4. Sql注入
SQL注入就是在Web表单提交数据/传输数据时,将预先准备好的SQL语句添加进去,达到欺骗服务器、修改SQL语句执行结果,非法获取服务器端数据的目的。
4.1 Sql注入原理
攻击者猜测Web系统的数据验证过程,在输入数据的最后加上一段SQL语句,让服务器端的SQL执行出现偏差,从而欺骗服务器,甚至可获取数据库的管理权限,然后将数据库管理用户权限提升至操作系统管理用户权限,控制服务器操作系统,获取重要信息及机密文件
4.2 SQL注入流程
•判断是否存在注入,注入是字符型还是数字型
•猜解SQL查询语句中的字段数
•确定显示位置
•获取当前数据库
•获取数据库中的表
•获取表中的字段名
•下载数据
4.3 寻找SQL注入点
SQL注入可以出现在任何从系统或用户接收数据输入的前端应用程序中,这些应用程序之后被用于访问数据库服务器。如果要对一个网站进行SQL注入攻击,首先就需要找到存在SQL注入漏洞的地方,也就是寻找所谓的注入点。可能的SQL注入点一般存在于登录页面、查找页面或添加页面等用户可以查找或修改数据的地方。最常用的寻找SQL注入点的方法,是在网站中寻找如下形式的页面链接:http://www.abc.com/xyz.xxx?id=yy,其中“yy”可能是数字,也有可能是字符串,分别被称为整数类型数据或者字符型数据。
4.4 Sql注入判断
a.整型参数的判断
当输入的参数YY为整型时,通常xyz.asp中SQL语句原貌大致如下:
select from表名where字段=YY,所以可以用以下步骤测试SQL注入是否存在。
http://www.abc.com/xyz.xx?p=YY’(附加一个单引号),此时xyz.asp中的SQL语句变成了select from表名where字段=YY’,xyz.asp运行异常;
http://www.abc.com/xyz.xx?p=YYand 1=1,xyz.asp运行正常,而且与http://www.abc.com/xyz.xxp?p=YY运行结果相同;
http://www.abc.com/xyz.xx?p=YYand1=2,xyz.asp运行异常;
如果以上三步全面满足,xyz.asp中一定存在SQL注入漏洞。
b.字符串型参数的判断
当输入的参数YY为字符串时,通常xyz.asp中SQL语句原貌大致如下:
select from表名where字段='YY',所以可以用以下步骤测试SQL注入是否存在。
http://www.abc.com/xyz.xx?p=YY’(附加一个单引号),此时xyz.asp中的SQL语句变成了select from表名where字段=YY’,xyz.asp运行异常;
http://www.abc.com/xyz.xx?p=YY&nb...39;1'='1',xyz.asp运行正常,而且与http://www.abc.com/xyz.xx?p=YY运行结果相同;
http://www.abc.com/xyz.xx?p=YY&nb...39;1'='2',xyz.asp运行异常;
如果以上三步全面满足,xyz.asp中一定存在SQL注入漏洞
c.特殊情况的处理
有时程序员会在程序员过滤掉单引号等字符,以防止SQL注入。此时可以用以下几种方法试一试。
大小写混合法:某些语言并不区分大小写(如asp),此时可将SQL语句中的命令字进行大小写混合来规避过滤技术,如用wHeRe代替where等。
ASCII码法:将输入内容的部分或全部字符使用ASCII码来代替,这样也有可能规避过滤技术,如A=chr(65),a=chr(97)等
d.Sql注入示例
5. XSS攻击
5.1 什么是XSS攻击
XSS攻击又称为跨站脚本,XSS的重点不在于跨站点,而是在于脚本的执行。XSS是一种经常出现在Web应用程序中的计算机安全漏洞,是由于Web应用程序对用户的输入过滤不足而产生的,它允许恶意web用户将代码植入到提供给其它用户使用的页面中。
5.2 XSS漏洞的危害
a.窃取管理员帐号或Cookie。入侵者可以冒充管理员的身份登录后台,使得入侵者具有恶意操纵后台数据的能力,包括读取、更改、添加、删除一些信息。
b.窃取用户的个人信息或者登录帐号。对网站的用户安全产生巨大的威胁。例如冒充用户身份进行各种操作。
c.网站挂马。先将恶意攻击代码嵌入到Web应用程序之中。当用户浏览该挂马页面时,用户的计算机会被植入木马。
d.发送广告或者垃圾信息。攻击者可以利用XSS漏洞植入广告,或者发送垃圾信息,严重影响到用户的正常使用。
5.3 Xss漏洞分类
a.反射型XSS
反射型XSS,也称为非持久性XSS,是最常见的一种XSS。
XSS代码常常出现在URL请求中,当用户访问带有XSS代码的URL请求时,服务器端接收请求并处理,然后将带有XSS代码的数据返回给浏览器,浏览器解析该段带有XSS代码的数据并执行,整个过程就像一次反射,故称为反射型XSS。
该类攻击的主要特点是它的及时性和一次性,即用户提交请求后,响应信息会立即反馈给用户。该类攻击常发生在搜索引擎、错误提示页面等对用户的输入做出直接反应的场景中。
b.存储型XSS
存储型XSS,也称为持久性XSS。
在存储型XSS中,XSS代码被存储到服务器端,因此允许用户存储数据到服务器端的Web应用程序可能存在该类型XSS漏洞。攻击者提交一段XSS代码后,服务器接收并存储,当其他用户访问包含该XSS代码的页面时,XSS代码被浏览器解析并执行。
存储型XSS攻击的特点之一是提交的恶意内容会被永久存储,因而一个单独的恶意代码就会使多个用户受害,故被称为持久性XSS,它也是跨站脚本攻击中最危险的一类。二是被存储的用户提交的恶意内容不一定被页面使用,因此存在危险的响应信息不一定被立即返回,也许在访问那些在时间上和空间上没有直接关联的页面时才会引发攻击,因此存在不确定性和更好的隐蔽性。
这类攻击的一个典型场景是留言板、博客和论坛等,当恶意用户在某论坛页面发布含有恶意的Javascript代码的留言时,论坛会将该用户的留言内容保存在数据库或文件中并作为页面内容的一部分显示出来。当其他用户查看该恶意用户的留言时,恶意用户提交的恶意代码就会在用户浏览器中解析并执行。
c.DOM型XSS
DOM (Document Objet Model)指文档对象模型。
DOM常用来表示在HTML和XML中的对象。DOM可以允许程序动态的访问和更新文档的内容、结构等。客户端JavaScript可以访问浏览器的文档对象模型。也就是说,通过JavaScript代码控制DOM节点就可以不经过服务器端的参与重构HTML页面。
该类攻击是反射型XSS的变种。它通常是由于客户端接收到的脚本代码存在逻辑错误或者使用不当导致的。比如Javascript代码不正确地使用各种DOM方法(如document.write)和Javascript内部函数(如eval函数),动态拼接HTML代码和脚本代码就容易引发DOM型的跨站脚本攻击。
因此,DOM型XSS与前面两种XSS的区别就在于DOM型XSS攻击的代码不需要与服务器端进行交互,DOM型XSS的触发基于浏览器端对DOM数据的解析来完成,也就是完全是客户端的事情。
5.4 Xss漏洞分类判断
如何判断是哪一种XSS, 发送一次带XSS代码的请求,若只能在当前返回的数据包里发现XSS代码,则是反射型;若以后这个页面的返回包里都会有XSS代码,则是存储型;若在返回包里找不到XSS代码,则是DOM型。
5.5 XSS漏洞的检测与防御
a.手工检测
手工检测重点要考虑数据输入的地方,且需要清楚输入的数据输出到什么地方。
在检测的开始,可以输入一些敏感字符,比如“<、>、()”等,提交后查看网页源代码的变化以发现输入被输出到什么地方,且可以发现相关敏感字符是否被过滤。
手工检测结果相对准确,但效率较低。
b.工具检测
常用工具有AVWS(Acunetix Web Vulnerability Scanner)、BurpSuite等。还有一些专门针对XSS漏洞的检测工具,如:XSSer、XSSF(跨站脚本攻击框架)、BeEF(The Browser Exploitation Framework)等
c.防御
使用黑名单进行:
●对HTML标签或特殊字符进行过滤
●使用内容安全的CSP
●使用设计上就会自动编码的框架,如:OWASP ESAPI、React JS、JSOUP等,对于JAVA而言,可以使用ESAPI.encoder().encodeForHTML()对字符串进行HTML编码。
●对于反射型和存储型XSS,可以在数据返回给客户端浏览器时,将敏感字符进行转义,如:将单引号进行编码替换(十进制编码'、十六进制编码'、HTML编码&apos、Unicode编码\u0027等)。
●对于DOM型XSS,可以使用上下文敏感数据编码。如:在PHP中的htmlspecialchars()、htmlentities()函 数可以将一些预定义的字符转换为HTML实体,如:小于转化为<、大于转化为>、双引号转化为"、单引号转化为&apos、转化为&等。
●启用浏览器的HttpOnly特性可以组织客户端脚本访问cookie。如:在PHP中可以通过下面的代码设置cookie并启用HttpOnly。
案例1:某app搜索接口越权获取敏感信息
cloud/search/group/userstaff_id 可枚举,通过遍历将任意的用户拉入群聊,直接获取大量员工的个人敏感信息,涉及组织机构、手机号
案例2:“某某查”付费资源泄露
5. 文件管理-上传/下载
5.1 文件上传
a. 身份校验
进行文件上传时,在服务端对用户的身份进行合法性校验。
b. 文件类型限制
须在服务器端采用白名单方式对上传或下载的文件类型、大小进行严格的限制。仅允许业务所需文件类型上传,避免上传.jsp、.jspx、.class、.java 等可执行文件
c.禁止外部文件存储于可执行目录
禁止外部文件存储于 WEB 容器的可执行目录。建议保存在专门的文件服务器中。
d.隐藏文件路径
进行文件保存时,成功上传的文件需要进行随机化重命名,禁止给客户端返回保存的路径信息。
5.2 文件下载
a.身份校验
进行文件下载时,在服务端对用户的身份进行合法性校验。
b.文件访问设置
进行文件下载时,应以二进制形式下载,建议不提供直接访问(防止木马文件)。
c.目录跳转
禁止客户端自定义文件下载路径(如:使用../../../../../或..%2F..%2F..%2F..%2F 进行跳转)
下一篇更新逻辑安全和数据安全,敬请期待!