SQL 注入,顾名思义就是通过注入 SQL 命令来进行攻击,更确切地说攻击者把 SQL 命令插入到 web 表单或请求参数的查询字符串里面提交给服务器,从而让服务器执行编写的恶意的 SQL 命令。
对于 web 开发者来说,SQL 注入已然是非常熟悉的,而且 SQL 注入已经生存了 10 多年,目前已经有很成熟的防范方法,所以目前的 web 应用都很少会存在漏洞允许进行 SQL 注入攻击。 除非是入门开发人员,在开发的时候仍使用旧的技术去实现(比如 Java 的 Statement 和 PreparedStatement)
从上面可知,SQL 注入是通过让服务器执行了恶意的 SQL 命令从而进行攻击的,那么主要问题就出在于服务器是如何生成 SQL 语句的。其实绝大多数拥有 SQL 注入漏洞的 Web 系统,在生成 SQL 语句的时候,采用的是拼接字符串的方式,并且没有对要组装成 SQL 语句的参数进行检验和过滤。
下面就以一个用户登陆的场景来讲解
现在我们的数据库中有一个用户表(t_user),假设表里面只有两个元素,分别是用户名和密码
然后在 web 应用中,一般在用户登录时,验证的方法一般都是通过账号和密码去获取数据表中是否存在这样的记录,存在则返回用户,不存在则返回 null;
那么我们的 SQL 语句大概就会像这样
SELECT username FROM t_user WHERE username = ‘xxx’ AND password = ‘xxx’
以 Java 为例(使用拼接字符串的形式)
那么此时我在登陆页面输入以下信息
账号: 1’ or 1
密码: xxx(随意)
那么服务器会生成这样的 SQL 语句
SELECT username from t_user where username = ‘1’ or 1 and password = ‘xxx’
知道一点关系逻辑的人都知道这样的条件查询总会返回记录,有记录则代表登陆成功,则用户不需要知道正确的账号密码就能登陆系统,如果是登陆前台,那可能还好;可如果他拿到了后台管理的链接,登陆进去了后台,那么你的系统可能就会被恶意破坏了。
从代码中可以看到若是采用这种拼接字符串的形式来生成 SQL 语句,那么这就会给 SQL 注入提供了机会。
那么此时我在登陆页面输入以下信息
账号: 1’ or 1
密码: xxx(随意)
那么服务器会生成这样的 SQL 语句
SELECT username from t_user where username = ‘1’ or 1 and password = ‘xxx’
知道一点关系逻辑的人都知道这样的条件查询总会返回记录,有记录则代表登陆成功,则用户不需要知道正确的账号密码就能登陆系统,如果是登陆前台,那可能还好;可如果他拿到了后台管理的链接,登陆进去了后台,那么你的系统可能就会被恶意破坏了。
从代码中可以看到若是采用这种拼接字符串的形式来生成 SQL 语句,那么这就会给 SQL 注入提供了机会。
在开发 web 应用时,应当尽量避免使用拼接字符串的方式来生成 SQL 语句,而且要特别注意检查含有拼接字符串类型的参数的 SQL 语句,尽可能地去测试是否会有 SQL 注入漏洞。
XSS ,全名:cross-site scripting(跨站点脚本),是当前 web 应用中最危险和最普遍的漏洞之一。攻击者尝试注入恶意脚本代码到受信任的网站上执行恶意操作,用户使用浏览器浏览含有恶意脚本页面时,会执行该段恶意脚本,进而影响用户(比如关不完的网站、盗取用户的 cookie 信息从而伪装成用户去操作)等等。
他与 SQL 注入很类似,同样是通过注入恶意指令来进行攻击。但 SQL 注入是在服务器端上执行的,而 XSS 攻击是在客户端上执行的,这点是他们本质区别。
XSS 的种类
XSS 攻击的分类没有标准,但普遍分为三类:
下面将直接以一些小例子来说明以上三种类别的 XSS 攻击分别是怎样的
反射型 XSS(非持久性跨站攻击)
一般是利用网站某些页面会直接输出请求参数的特性,通过在 url 的请求参数包含恶意脚本,导致用户打开该 url 的时候,执行恶意脚本。
例:http://localhost:8080/test.jsp?abc=
用户在访问这个页面的时候,就会触发弹窗
当然,一般的 XSS 攻击不会这么简单的就让你弹个窗,可能他会让你不断弹窗(对你恶作剧),也可能会盗取你的信息等;而且一般这种形式的 url 会感觉很奇怪,哪有用户会去打开这种奇怪的 url,所以一般会经过一定的包装来欺骗用户。
存储型 XSS(持久性跨站攻击)
该种类型的攻击一般是通过表单输入(比如发布文章、回复评论等功能中)插入一些恶意脚本,并且保存到数据库,待其他用户加载对应的页面的时候,该段脚本就会被加载并执行。
与反射型 XSS 相比,该类的攻击更具有危害性,因为它影响的不只是一个用户,而是大量用户,而且该种类型还可进行蠕虫传播;就如之前的贴吧和微博事件,用户访问了含有恶意脚本的页面,用户的 cookie 信息被盗取了,并且立刻使用用户的账户去发表新的帖子或微博同时注入恶意脚本,使得该恶意脚本不断被传播下去。
DOM Based XSS(基于 Dom 的跨站点脚本)
基于 DOM 的跨站点脚本与前面两种类型有什么区别呢?其实它注入的方式是基于前面两种类型的方式的,只不过是注入的脚本是通过改变 DOM 来实施的。采用该种方式有一个好处就是从源代码中不易被发现而已。
主要原因与 SQL 注入很类似,都是由于开发人员没有对用户输入进行编码和过滤。另一个原因是,这种攻击方法有很多变体,要设计出一个能完全防御的 XSS 过滤器是非常困难的。
基于上面漏洞产生的原因,我们若要想防御该种攻击,就需要从源头抓起(用户输入),制定一套合理且安全的 XSS 过滤规则。
以下介绍一些过滤方法
对 HTML 标签及一些特殊符号进行转义
该种方法是一种非常简单的过滤方法,仅仅是通过转义的方式将一些 HTML 标签和属性转义,比如 < 转义成 < ;, 这样像的脚本就运行不了。当然简单的过滤方式也就代表很容易就会被绕过。
另外如果需要使用含有富文本的功能时,使用这样的过滤就会使富文本失去作用。
使用白名单、黑名单的方式进行过滤
白名单、黑名单顾名思义是要定义哪些东西是可通过的,哪些东西不可通过。比如常见 、
; 、< 等等标签,不可通过的比如 javascript、、