常见的安全性问题简单介绍
SQL注入问题
SQL注入的发生,通常是恶意用户通过在表单中填写包含SQL关键字的数据,来使数据库执行非常规逻辑的过程。简单来说,就是数据库越界做了超出代码控制范围的事情。这个问题的来源是,SQL数据库的操作是通过SQL语句来执行的,而无论是执行代码还是数据项都必须写在SQL语句之中,这就导致如果我们在数据项中加入了某些SQL语句关键字(比如说SELECT、DROP等等),这些关键字就很可能在数据库写入或读取数据时得到执行。
SQL注入示例
例:基于1 = 1 总为真
在下图中,模拟一次简单的用户登录过程。
在正常情况下输入的密码为 password
在使用SQL注入时 输入的密码为 "1" or "1" = "1"
那么当我们未对参数做任何校验时,直接将其拼接为SQL语句
最终得到的SQL语句为 select * from user where userName ="1" and passWord = "1" or "1" = "1"
此时,你去执行这句SQL语句本应该是失败的,却因为误判,返回了成功的指令。
SQL注入应对方法
使用正则表达式过滤传入的参数
正则表达式:例如下列表达式,过滤掉有or和and的参数
private String CHECKSQL = “^(.+)\sand\s(.+)|(.+)\sor(.+)\s$”;
利用ORM框架防止SQL注入
与传统的ORM框架不同,例MyBatis使用XML描述符将对象映射到SQL语句或者存储过程中,这种机制可以让我们更大的灵活度通过SQL来操作数据库对象,因此,我们必须小心这种便利下SQL注入的可能性。
这是MyBatis推荐的一种用法,注意参数符号#{id},使用#{}语法,MyBatis会通过预编译机制生成PreparedStatement参数,然后在安全的给参数进行赋值操作,因此就避免了SQL注入:例如下图所示
字符串过滤
比较简单的一个方法,过滤掉所有的SQL参数,和正则表达式的效果一致
CSRF
CSRF(Cross-site request forgery),中文名称:跨站请求伪造,也被称为:one click attack/session riding,缩写为:CSRF/XSRF。OWASP Top 10 2010排A5,OWASP Top 10 2013排A8。
CSRF的危害
攻击者盗用了你的身份,以你的名义发送恶意请求。CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账......造成的问题包括:个人隐私泄露以及财产安全
CSRF的原理
从上图可以看出,要完成一次CSRF攻击,受害者必须依次完成两个步骤:
- 登录受信任网站A,并在本地生成Cookie。
- 在不登出A的情况下,访问危险网站B。
看到这里,你也许会说:“如果我不满足以上两个条件中的一个,我就不会受到CSRF的攻击”。是的,确实如此,但你不能保证以下情况不会发生: - 你不能保证你登录了一个网站后,不再打开一个tab页面并访问另外的网站。
- 你不能保证你关闭浏览器了后,你本地的Cookie立刻过期,你上次的会话已经结束。(事实上,关闭浏览器不能结束一个会话,但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了……)
- 上图中所谓的攻击网站,可能是一个存在其他漏洞的可信任的经常被人访问的网站
CSRF应对方法
加验证码
验证码,强制用户必须与应用进行交互,才能完成最终请求。在通常情况下,验证码能很好遏制CSRF攻击。但是出于用户体验考虑,网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手段,不能作为主要解决方案。
Referer Check
Referer Check在Web最常见的应用就是“防止图片盗链”。同理,Referer Check也可以被用于检查请求是否来自合法的“源”(Referer值是否是指定页面,或者网站的域),如果都不是,那么就极可能是CSRF攻击。
但是因为服务器并不是什么时候都能取到Referer,所以也无法作为CSRF防御的主要手段。但是用Referer Check来监控CSRF攻击的发生,倒是一种可行的方法。
增加Token校验
这个Token的值必须是随机的,不可预测的。由于Token的存在,攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性,尽量把敏感操作由GET改为POST,以form或AJAX形式提交,避免Token泄露。
XSS攻击
XSS(Cross Site Scripting)攻击全称跨站脚本攻击,XSS是一种经常出现在web应用中的计算机安全漏洞,它允许恶意web用户将代码植入到提供给其它用户使用的页面中。
通俗的来说就是我们的页面在加载并且渲染绘制的过程中,如果加载并执行了意料之外的程序或代码(脚本、样式),就可以认为是受到了 XSS攻击。
XSS分类
反射型:
也叫非持久型XSS,交互数据一般不会被存在数据库里面,一次性,所见即所得。一般XSS代码出现在请求URL中,作为参数提交到服务器,服务器解析并响应,响应结果中包含XSS代码,最后浏览器解析并执行。
场景:
- 用户A给用户B发送一个恶意构造了Web的URL
- 用户B点击并查看了这个URL
- 用户B获取到一个具有漏洞的HTML页面并显示在本地浏览器中
- 漏洞HTML页面执行恶意JavaScript脚本,将用户B信息盗取发送给用户A,或者篡改用户B看到的数据等
存储型:
也叫持久型XSS,主要将XSS代码提交存储在服务器端(数据库,内存,文件系统等),下次请求目标页面时不用再提交XSS代码。当目标用户访问该页面获取数据时,XSS代码会从服务器解析之后加载出来,返回到浏览器做正常的HTML和JS解析执行,XSS攻击就发生了。
场景:
- 用户A在网页上创建了某个账户,并且账户信息中包含XSS代码。
- 用户B访问该网站查看XSS代码账户详情页面。
- 服务端返回账户详情页面,和带XSS账户信息。
- 用户B浏览器执行XSS代码,将用户B信息盗取发送给用户A,或者篡改用户B看到的数据等。
XSS示例
借助于http://xss.fbisb.com/网站进行例子模拟
图中例子说明
首先此题目意思是希望通过XSS攻击,将页面调整第二道题目
- 如图:url:http://xss.fbisb.com/yx/level1.php?name=qweqweqw,界面上显示欢迎用户qweqweqw
既,正常情况下name传参是什么,界面上显示的名字即为什么 - 查看页面源代码,发现页面上有一段script脚本,即执行script中的方法,就可以进入第二道题目
- 脚本编写:name=
- 此时url为 http://xss.fbisb.com/yx/level1.php?name=
- 回车后,完成一次简单的XSS攻击,此时url界面进行调整,并执行了alert()脚本
XSS防御
使用innerHTML(原生)、v-html(vue)、dangerouslySetInnerHTML(react)等直接渲染html的函数渲染请求数据时,需要先把字符串转义:
例如:
- 把 > 替换成 >
- 把 < 替换成 <
- 把 & 替换成 &
这样做浏览器是不会对该标签进行解释执行的,同时也不影响显示效果。
字符过滤:
1)过滤掉特殊的HTML标签,例如