web网站中常见攻击手法与原理
web网站中常见攻击手法与原理
01, 跨站脚本攻击(xss)
恶意攻击者通过往Web页面里插入恶意html代码，当用户浏览该页时，嵌入Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。
分析一下xss的特点：
1、耗时间
2、有一定几率不成功
3、没有相应的软件来完成自动化攻击
4、前期需要基本的html、js功底，后期需要扎实的html、js、actionscript2/3.0等语言的功底
5、是一种被动的攻击手法
6、如果website有http-only、crossdomian.xml, 则没有用
<html>
<head>head>
<body>
<span style="font-size:14px;">
<meta http-equiv="Content-Type" content="text/html;charset=" utf-8"="" /> <title>xss原理重现title>
<center>
<h6>把我们输入的字符串 输出到input里的value属性里h6>
<form action="" method="POST">
<h6>请输入你想显现的字符串h6>
<input type="text" name="xss_input" value="输入" />
<br />
<input type="submit" />
form>
<hr />
'; }else{ echo '
<input type="type" value="输出" />'; } ?>
center> span>
body>
html>我们在输入框里输入 ">
分析这一段的代码，前面的">是为了闭合前面的`input，这个输入就可以使弹窗出现
我们也可以输入 " onclick="alert('xss')
因为onclick是鼠标点击事件，也就是说当你的鼠标点击第二个input输入框的时候，
就会触发`onclick 事件，然后执行xss
Js可以干很多的事，可以获取cookies(对http-only没用)、控制用户的动作(发帖、私信什么的)等等。
比如我们在网站的留言区输入下面的代码：
当管理员进后台浏览留言的时候，就会触发，然后管理员的cookies和后台地址还有管理员浏览器版本等等你都可以获取到了
下面是XSS攻击方法：
Stored XSS
Stored XSS是存储式XSS漏洞，由于其攻击代码已经存储到服务器上或者数据库中，所以受害者是很多人
例如一个网站 a.com 可以发文章，我登录后在 a.com 中发布了一篇文章，文章中包含了恶意代码
保存文章
这时Tom和Jack看到了我发布的文章，当在查看我的文章时就都中招了
他们的cookie信息都发送到了我的服务器上，攻击成功！
这个过程中，受害者是多个人。
Stored XSS漏洞危害性更大，危害面更广。
XSS防御方法：
完善的过滤体系
永远不相信用户的输入。需要对用户的输入进行处理，只允许输入合法的值，其它值一概过滤掉
假如某些情况下，我们不能对用户数据进行严格的过滤，那我们也需要对标签进行转换
| less-than character (<) | < |
|---|---|
| greater-than character (>) | > |
| ampersand character (&) | & |
| double-quote character (“) | " |
| space character( ) | |
比如用户输入
保存后最终存储的会是
<
在展现时浏览器会对这些字符转换成文本内容显示，而不是一段可执行的代码
02, SQL 注入
所谓SQL注入，就是把SQL命令插入到Web表单提交, 或输入域名, 或页面请求的查询字符串，最终达到欺骗服务器执行恶意SQL命令的目的
具体来说，它是利用现有应用程序，将恶意的SQL命令注入到后台数据库引擎执行
它可以通过在Web表单中输入SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者的意图去执行SQL语句
举个例子，你要登录一个网站，上面让你输入用户名字和密码。
那么，假如你输入的用户名是 admin ，但是你不知道密码，你就输入了一个 1' OR '1' = '1
那么，你就提交了两个参数给服务器。
假如，服务器拿这两个参数拼SQL语句
SELECT T.* FROM XXX_TABLE T WHERE T.USER_ID = '/*param1*/'AND T.PASSWORD = '/*param2*/'
那么，你提交的两个参数就使SQL语句变成了
SELECT T.* FROM XXX_TABLE T WHERE T.USER_ID = 'admin' AND T.PASSWORD = '1' OR '1' = '1'
那么，这个SQL原来的校验功能就被你绕过去了，你的这种行为就称之为SQL注入
为了成功注入SQL命令，攻击者必须将开发者现有的sql命令转化成合法的sql语句，当然，要盲注总是有难度的，但一般都是
'OR1=1– 或者 ')OR1=1--
总结一下SQL注入的思路
- SQL注入漏洞的判断，即寻找注入点
- 判断后台数据库类型
- 确定
XP_CMDSHELL可执行情况；若当前连接数据的帐号具有SA权限, 且master.dbo.xp_cmdshell扩展存储过程(调用此存储过程可以直接使用操作系统的shell)能够正确执行，则整个计算机可以通过几种方法完全控制，也就完成了整个注入过程
否则继续
- 发现WEB虚拟目录
- 上传ASP木马
- 得到管理员权限
对SQL注入的防御方法
- 使用参数化的过滤性语句
- 避免出现详细的错误信息
- 使用专业的漏洞扫描工具
- 避免使用解释程序
- 在web应用程序开发过程的所有阶段实施代码的安全检查
03, Cookie 攻击
通过Java Script 非常容易访问到当前网站的cookie
你可以打开任何网站，然后在浏览器地址栏中输 入：javascript:alert(doucment.cookie)
立刻就可以看到当前站点的cookie（如果有的话）
攻击者可以利用这个特性来取得你的关键信息
例如，和XSS攻击相配合，攻击者在你的浏览器上执行特定的Java Script脚本，取得你的cookie
假设这个网站仅依赖cookie来验证用户身份，那么攻击者就可以假冒你的身份来做一些事情。
现在多数浏览器都支持在cookie上打上HttpOnly的标记, 凡有这个标志的cookie就无法通过
Java Script 来取得,如果能在关键cookie上打上这个标记，就会大大增强cookie的安全性
以下是获取Cookie信息的主要途径：
直接读取磁盘的Cookie文件，Windows系统的Cookie信息存放目录是
C:/Documents and Settings/%yourname%/CookiesFireFox的Cookie信息是在FireFox的
Profiles目录中使用网络嗅探器来获取网络上传送的Cookie
使用一些Cookie管理工具获取内存或者文件系统中的Cookie
使用跨站脚本来盗取别人的Cookie
假如我们成功获取了cookie信息，那下一步理所当然地就是要进行攻击了
常用的攻击步骤有：
- 查看Cookie信息，对Cookie信息进行分析
- 修改Cookie中的逻辑判断类信息，比如一些boolean标志，01标志等等，访问服务器，观察服务器的反应。
- 修改Cookie信息中数字类型的信息，比如id, number等等这类的值，观察服务器反应。
- 获取别人的Cookie信息，然后根据别人的Cookie信息修改自己本地的Cookie信息，看服务器是否会把自己识别为其他人。
那我们应该如何防范利用Cookie进行的攻击呢？
- 不要在Cookie中保存敏感信息
- 不要在Cookie中保存没有经过加密的或者容易被解密的敏感信息
- 对从客户端取得的Cookie信息进行严格校验
- 记录非法的Cookie信息进行分析，并根据这些信息对系统进行改进。
- 使用SSL/TLS来传递Cookie信息
04, HTTP Headers 攻击
凡是用浏览器查看任何WEB网站，无论你的WEB网站采用何种技术和框架，都用到了HTTP协议
HTTP协议在Response header和content之间，有一个空行，即两组CRLF（0x0D 0A）字符
这个空行标志着headers的结束和content的开始
攻击者可以利用这一点, 只要攻击者有办法将任意字符“注入”到headers中，这种攻击就可以
发生
以登陆为例:有这样一个url
http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex
当登录成功以后，需要重定向回page参数所指定的页面。
下面是重定向发生时的`response headers
HTTP/1.1 302 Moved
Temporarily Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4
FrontPage/5.0.2.2635 Location: http://localhost/index
假如把URL修改一下，变成这个样子
http://localhost/login?page=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E
那么重定向发生时的reponse会变成下面的样子：
HTTP/1.1 302 Moved
Temporarily Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4
FrontPage/5.0.2.2635 Location: http://localhost/checkout
这个页面可能会意外地执行隐藏在URL中的javascript
类似的情况不仅发生在重定向（Location header）上，也有可能发生在其它headers中
如`Set-Cookie header
这种攻击如果成功的话，可以做很多事，例如：执行脚本、设置额外的cookie （ 等
避免这种攻击的方法，就是过滤所有的response headers，除去header中出现的非法字符，尤其是CRLF(空行)
05, 文件上传攻击
文件上传漏洞就是利用对用户上传的文件类型判断不完善，导致攻击者上传非法类型的文件，从而对网站进行攻击。
比如可上传一个网页木马，如果存放文件的目录刚好有执行脚本的权限，那么攻击者就可以得到一个webshell
攻击者要想成功实施文件上传攻击，必须要满足以下三个条件：
- 可以上传任意脚本文件，且上传的文件能够被Web服务器解析执行，具体来说就是存放上传文件的目录要有执行脚本的权限
- 用户能够通过Web访问这个文件。如果文件上传后，不能通过Web访问，那么也不能成功实施攻击
- 要知道文件上传到服务器后的存放路径和文件名称，因为许多Web应用都会修改上传文件的文件名称，那么这时就需要结合其他漏洞去获取到这些信息。如果不知道上传文件的存放路径和文件名称，即使你上传了也无法访问
主流的文件上传检测方式有以下五种：
1, 客户端javascript检测
客户端检测通常在上传页面里含有专门检测文件上传的javascript代码，在文件被上传之前进行检测，最常见的就是检测上传文件的文件类型和大小是否合法
2, 服务端MIME类型检测
这类检测方法通过检查http包的Content-Type字段中的值来判断上传文件是否合法
3.服务端文件扩展名检测
这类检测方法通过在服务端检测上传文件的扩展名来判断文件是否合法
4.服务端目录路径检测
这类检测一般通过检测路径是否合法来判断
5.服务端文件内容检测
那么如何设计出一个安全的文件上传功能呢？
1, 设置保存上传文件的目录为不可执行
只要Web服务器无法解析该目录下的文件，即使攻击者上传了脚本文件，服务器本身也不会受到影响，此点至关重要。
2, 判断文件类型
在判断文件类型时，可以结合使用MIME Type、后缀检查等方式。在文件类型检查中，强烈建议采用白名单的方式。此外，对于图片的处理可以使用压缩函数或者resize函数，在处理图片的同时破坏图片中可能包含的恶意代码。
3.使用随机数改写文件名和文件路径
文件上传如果要执行代码，则需要用户能够访问到这个文件。在某些环境中，用户能上传，但不能访问。如果采用随机数改写了文件名和路径，将极大地增加攻击成本。与此同时，像
webshell.asp;1.jpg这种文件，将因为文件名被改写而无法成功实施攻击。