一个网站建立以后,如果不注意安全方面的问题,很容易被人攻击,下面就讨论一下几种常见的漏洞的简介与原理分析
一.跨站脚本攻击(xss)
恶意攻击者通过往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。下面我们来分析一下xss的特点：
1、耗时间
2、有一定几率不成功
3、没有相应的软件来完成自动化攻击
4、前期需要基本的html、js功底，后期需要扎实的html、js、actionscript2/3.0等语言的功底
5、是一种被动的攻击手法
6、对website有http-only、crossdomian.xml没有用
但是这些并没有影响黑客对此漏洞的偏爱，原因不需要多，只需要一个。
Xss几乎每个网站都存在，google、baidu、360等都存在。
下面来看一个例子：
xss原理重现
把我们输入的字符串 输出到input里的value属性里
';
}else{
echo '';
}
?>
我们在输入框里输入 ">
分析这一段的代码，前面的">是为了闭合前面的input，这个输入就可以使弹窗出现
我们也可以通过输入 " οnclick="alert('xss')
因为onclick是鼠标点击事件，也就是说当你的鼠标点击第二个input输入框的时候，
就会触发onclick事件，然后执行
Js可以干很多的事，可以获取cookies(对http-only没用)、控制用户的动作(发帖、私信什么的)等等。
比如我们在网站的留言区输入下面的代码：
当管理员进后台浏览留言的时候，就会触发，然后管理员的cookies和后台地址还有管理员浏览器版本等等你都可以获取到了
那假如说网站禁止过滤了script 这时该怎么办呢，记住一句话，这是我总结出来的“xss就是在页面执行你想要的js”不用管那么多，只要能运行我们的js就OK，比如用img标签或者a标签。我们可以这样写
当找不到图片名为1的文件时，执行alert('xss')
点击s时运行alert('xss')
利用iframe的src来弹窗
下面是XSS攻击方法：
Stored XSS
Stored XSS是存储式XSS漏洞，由于其攻击代码已经存储到服务器上或者数据库中，所以受害者是很多人。
场景二：
a.com可以发文章，我登录后在a.com中发布了一篇文章，文章中包含了恶意代码，
，保存文章。
这时Tom和Jack看到了我发布的文章，当在查看我的文章时就都中招了，
他们的cookie信息都发送到了我的服务器上，攻击成功！这个过程中，受害者是多个人。
Stored XSS漏洞危害性更大，危害面更广。
XSS防御方法：
完善的过滤体系
永远不相信用户的输入。需要对用户的输入进行处理，只允许输入合法的值，其它值一概过滤掉。
Html encode
假如某些情况下，我们不能对用户数据进行严格的过滤，那我们也需要对标签进行转换。
less-than character () >
ampersand character (&) &
double-quote character (") "
space character( )
Any ASCII code character whose code is greater-than or equal to 0x80 &#, where is the ASCII character value.
比如用户输入：，保存后最终存储的会是：
<script>window.location.href=";</script>在展现时浏览器会对这些字符转换成文本内容显示，而不是一段可执行的代码。
其它
下面提供两种Html encode的方法。
1.使用Apache的commons-lang.jar
StringEscapeUtils.escapeHtml(str);// 汉字会转换成对应的ASCII码，空格不转换
2.自己实现转换，只转换部分字符
二.SQL注入(sql injection)
所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。
先举个例子，你要登录一个网站，上面让你输入用户名字和密码。那么，假如你输入的用户名是 admin ，但是你不知道密码，你就输入了一个 1' OR '1' = '1 ，那么，你就提交了两个参数给服务器。假如，服务器拿这两个参数拼SQL语句：SELECT T.* FROM XXX_TABLE TWHERE T.USER_ID = '/*param1*/'AND T.PASSWORD = '/*param2*/'
那么当你遭到语言攻击时在线阅读，你提交的两个参数就使SQL文变成了：SELECT T.* FROM XXX_TABLE TWHERE T.USER_ID = 'admin'AND T.PASSWORD = '1' OR '1' = '1'
那么，这个SQL原来的校验功能就被你绕过去了，你的这种行为就称之为SQL注入
为了成功注入SQL命令，攻击者必须将开发者现有的sql命令转化成合法的sql语句，当然，要盲注总是有难度的，但一般都是
'OR1=1–
或者
')OR1=1--
总结一下SQL注入的思路
1. SQL注入漏洞的判断，即寻找注入点
2. 判断后台数据库类型
3. 确定XP_CMDSHELL可执行情况；若当前连接数据的帐号具有SA权限，
且master.dbo.xp_cmdshell扩展存储过程(调用此存储过程可以直接使用操作系统的shell)能够正确执行，则整个计算机可以通过几种方法完全控制，也就完成了整个注入过程
否则继续：
1. 发现WEB虚拟目录
2. 上传ASP木马；
3. 得到管理员权限
对SQL注入的防御方法：
1.使用参数化的过滤性语句
2.避免出现详细的错误信息
3.使用专业的漏洞扫描工具
4.避免使用解释程序
5.企业要web应用程序开发过程的所有阶段实施代码的安全检查
三.跨站请求攻击(CSRF)
尽管听起来像跨站脚本( XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
简单来说就是，攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。
下图简单阐述了CSRF的原理
几种类型的CSRF
1.GET类型的CSRF
在访问含有这个img的页面后，成功向发出了一次HTTP请求。所以，如果将该网址替换为存在GET型CSRF的地址，就能完成攻击了
2.POST类型的CSRF
访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作
CSRF的防御
CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。
1.服务端进行CSRF防御
服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。
(1).Cookie Hashing(所有表单都包含同一个伪随机值)：
这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了
在表单里增加Hash值，以认证这确实是用户发送的请求。
然后在服务器端进行Hash值验证
四.COOKIE攻击
通过Java Script非常容易访问到当前网站的cookie。你可以打开任何网站，然后在浏览器地址栏中输 入：javascript:alert(doucment.cookie),立刻就可以看到当前站点的cookie（如果有的话）。攻击者可以利用这个特性来取得你的关键信息。例如，和XSS攻击相配合，攻击者在你的浏览器上执行特定的Java Script脚本，取得你的cookie。假设这个网站仅依赖cookie来验证用户身份，那么攻击者就可以假冒你的身份来做一些事情。
现在多数浏览器都支持在cookie上打上HttpOnly的标记,凡有这个标志的cookie就无法通过Java Script来取得,如果能在关键cookie上打上这个标记，就会大大增强cookie的安全性
以下是获取Cookie信息的主要途径：
1. 直接读取磁盘的Cookie文件，Windows系统的Cookie信息存放目录是C:/Documents and Settings/%yourname%/Cookies,FireFox的Cookie信息是在FireFox的Profiles目录中。
2. 使用网络嗅探器来获取网络上船速的Cookie
3. 使用一些Cookie管理工具获取内存或者文件系统中的cookie
4. 使用跨站脚本来盗取别人的cookie
假如我们成功获取了cookie信息，那下一步理所当然地就是要进行攻击了，常用的攻击步骤有：
1. 查看Cookie信息，对Cookie信息进行分析
2. 修改Cookie中的逻辑判断类信息，比如一些boolean标志，01标志等等，访问服务器，观察服务器的反应。
3. 修改Cookie信息中数字类型的信息，比如id, number等等这类的值，观察服务器反应。
4. 获取别人的Cookie信息当你遭到语言攻击时在线阅读，然后根据别人的Cookie信息修改自己本地的Cookie信息，看服务器是否会把自己识别为其他人。
那我们应该如何防范利用Cookie进行的攻击呢？
1. 不要在Cookie中保存敏感信息
2. 不要在Cookie中保存没有经过加密的或者容易被解密的敏感信息
3. 对从客户端取得的Cookie信息进行严格校验
4. 记录非法的Cookie信息进行分析，并根据这些信息对系统进行改进。
5. 使用SSL/TLS来传递Cookie信息
