Web攻击方式

一、Dos攻击（Denial of Service attack） 　　是一种针对服务器的能够让服务器呈现静止状态的攻击方式。有时候也加服务停止攻击或拒绝服务攻击。其原理就是发送大量的合法请求到服务器，服务器无法分辨这些请求是正常请求还是攻击请求，所以都会照单全收。海量的请求会造成服务器停止工作或拒绝服务的状态。这就是Dos攻击。
二、跨站点请求伪造（CSRF，Cross-Site Request Forgeries） 　　是指攻击者通过已经设置好的陷阱，强制对已完成认证的用户进行非预期的个人信息或设定信息等某些状态的更新。属于被动攻击。更简单的理解就是攻击者盗用了你的名义，以你的名义发送了请求。

　　一个CSRF最简单的例子就是用户A登录了网站A在虚拟账户里转账了1000块钱，用户A在本地生成了网站A的cookie，用户A在没有关闭网站A的情况下有访问了恶意网站B，恶意网站B包含请求A网站的代码，利用了本地的cookie经过身份验证的身份又向网站A发送了一次请求，这时你就会发现你在网站A的账户又少了1000块。这就是基本的CSRF攻击方式。
CSRF攻击防御：
1、将cookie设置为HttpOnly
CSRF攻击很大程度是利用了浏览器的cookie，为了防止站内XSS漏洞，cookie设置HttpOnly属性，JS脚本就无法读取到cookie中的信息，避免攻击者伪造cookie的情况出现。
HttpOnly Cookies是一个cookie安全行的解决方案。
在支持HttpOnly cookies的浏览器中（IE6+，FF3.0+），如果在Cookie中设置了”HttpOnly”属性，那么通过JavaScript脚本将无法读取到Cookie信息，这样能有效的防止XSS攻击，让网站应用更加安全。
但是J2EE4，J2EE5 的Cookie并没有提供设置 HttpOnly 属性的方法，所以如果需要设置HttpOnly属性需要自己来处理。

import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletResponse;

/*
Cookie工具类
*/
public class CookieUtil {

/**<br />     * 设置HttpOnly Cookie<br />     * @param response HTTP响应<br />     * @param cookie Cookie对象<br />     * @param isHTTPOnly 是否为HttpOnly<br />     */<br />    public static void addCookie(HttpServletResponse response, Cookie cookie, boolean isHttpOnly) {<br />        String name = cookie.getName();//Cookie名称<br />        String value = cookie.getValue();//Cookie值<br />        int maxAge = cookie.getMaxAge();//最大生存时间(毫秒,0代表删除,-1代表与浏览器会话一致)<br />        String path = cookie.getPath();//路径<br />        String domain = cookie.getDomain();//域<br />        boolean isSecure = cookie.getSecure();//是否为安全协议信息 
    StringBuilder buffer = new StringBuilder();
    buffer.append(name).append("=").append(value).append(";");
    if (maxAge == 0) {<br />            buffer.append("Expires=Thu Jan 01 08:00:00 CST 1970;");<br />        } else if (maxAge > 0) {<br />            buffer.append("Max-Age=").append(maxAge).append(";");<br />        }
    if (domain != null) {<br />            buffer.append("domain=").append(domain).append(";");<br />        }
    if (path != null) {<br />            buffer.append("path=").append(path).append(";");<br />        }
    if (isSecure) {<br />            buffer.append("secure;");<br />        }
    if (isHttpOnly) {<br />            buffer.append("HTTPOnly;");<br />        }
    response.addHeader("Set-Cookie", buffer.toString());<br />    }

}

值得一提的是，Java EE 6.0 中 Cookie已经可以设置HttpOnly了，所以如果是兼容 Java EE 6.0 的容器(例如如 Tomcat 7)，可以直接使用Cookie.setHttpOnly 的方法来设置HttpOnly：
cookie.setHttpOnly(true);
2、增加token
CSRF攻击之所以成功，主要是攻击中伪造了用户请求，而用户请求的验证信息都在cookie中，攻击者就可以利用cookie伪造请求通过安全验证。因此抵御CSRF攻击的关键就是，在请求中放入攻击者不能伪造的信息，并且信息不在cookie中。
鉴于此，开发人员可以在http请求中以参数的形式加一个token，此token在服务端生成，也在服务端校验，服务端的每次会话都可以用同一个token。如果验证token不一致，则认为至CSRF攻击，拒绝请求。
表单中增加一个隐藏域：

1
在服务端session中添加token：
HttpSession session = request.getSession();
Object token = session.getAttribute(“_token”);
if(token == null || “”.equals(_token){
session.setAttribute(“_token”,UUID.randomUUID().toString());
}
12345
3、通过Referer识别
Http头中有一个字段Referer，它记录了Http请求来源地址。但是注意不要把Rerferer用在身份验证或者其他非常重要的检查上，因为Rerferer非常容易在客户端被改变。
（火狐的一个插件RefControl修改Referer引用）
三、SOL注入攻击 　　是指通过对web连接的数据库发送恶意的SQL语句而产生的攻击，从而产生安全隐患和对网站的威胁，可以造成逃过验证或者私密信息泄露等危害。
SQL注入的原理是通过在对SQL语句调用方式上的疏漏，恶意注入SQL语句。

String sql = “select * from user where nick = ‘“ + nickname + “‘ and password = ‘“ + password + “‘“;

Statement st = (Statement) conn.createStatement();

ResultSet rs = st.executeQuery(sql);
12345
上述代码是校验用户名、密码是否有效，查询结果记录数大于0则表示有效。正常逻辑是用户名、密码匹配数据库记录；但攻击者会利用http参数进行SQL注入攻击，即password参数输入’ or ‘1’ = ‘1，导致SQL语句变为
select * from user where nick = ‘zhangshan’ and password = ‘’ or ‘1’ = ‘1’;
1
上述语句的执行结果就相当于用户能够绕过登录验证。

SQL注入常见的两个例子：
1、私密信息泄露
　　假如一个出版书籍的网站，具有根据作者姓名查询已出版书籍的功能，作者未出版的书籍不能被普通用户看到，因为版权属于隐私的问题。那么假设请求是用HTTP的GET请求来完成的，其地址栏请求内容为：www.book.com?serach=echo
完成此功能的SQL语句为简单的根据条件查找：select from book where author = ‘echo’ and flag = 1; flag等于1代表书籍已出版。
这时如果有的用户直接地址栏里输入www.book.com?serach=echo’— 这样请求会发生什么？？
这样的请求传到服务器里的状态会是这样子的 select from book where author = ‘echo’ — and flag = 1;在SQL语句中—代表注释，会自动忽略掉后面的内容，所以这个请求是骗过服务器把作者为echo的已出版和未出版的书籍全部显示在网页上。造成网站违背开发者的意图，造成信息泄露。
SQL注入防范
1、使用预编译语句
Java原生的预编译语句为PreparedStatement，是Java.sql中的一个接口，继承自Statement。

2、使用ORM框架
ORM框架如MyBatis http://www.mybatis.org/mybatis-3/，在Mapper XML配置的语句如下：
SELECT * FROM PERSON WHERE ID = #{id}

123456789
有两种参数传递的方式：#{}、${}，两者的差异就在于，#是在预编译后，执行语句时再传递参数，$是先传递参数，然后再执行编译，再执行语句，SQL注入就是利用这种方式。
四、XSS（Cross Site Scripting）跨站脚本攻击，为了不与层叠样式表（CSS）混淆，故将跨站脚本攻击缩写为XSS。原理即在网页中嵌入恶意脚本，当用户打开网页时，恶意脚本便开始在用户浏览器上执行，以盗取客户端cookie、用户名、密码，甚至下载木马程式，危害可想而知。
以一个表单输入举例说明

1
倘若用户在表单中输入恶意脚本，即对输入做些处理，如：
<!— “/>
1

其实攻击的形式还有很多，比如将脚本伪装进URL，然后将URL进行URLEncode编码，当用户点击链接后，脚本就会被执行。
XSS防范：
之所以会发生XSS攻击，是因为用户输入的数据变成了代码， 因此需要对用户输入的数据进行HTML转义处理，将输出的“尖括号”、“单引号”、“引号”之类的特色符号进行转义。

五. session攻击，会话劫持
一句话概括：

用某种手段得到用户session ID，从而冒充用户进行请求

原因： 由于http本身无状态，同时如果想维持一个用户不同请求之间的状态，session ID用来认证用户
三种方式获取用户session ID：

预测：PHP生成的session ID足够复杂并且难于预测，基本不可能
会话劫持： URL参数传递sessionID； 隐藏域传递sessionID；比较安全的是cookie传递。但同样可以被xss攻击取得sessionID
会话固定： 诱骗用户使用指定的sessionID进行登录，这样系统不会分配新的sessionID
防御方法：

每次登陆重置sessionID
设置HTTPOnly，防止客户端脚本访问cookie信息，阻止xss攻击
关闭透明化sessionID
user-agent头信息验证
token校验
六、DDOS
概念
分布式拒绝服务攻击（Distributed Denial of Service），简单说就是发送大量请求是使服务器瘫痪。DDos攻击是在DOS攻击基础上的，可以通俗理解，dos是单挑，而ddos是群殴，因为现代技术的发展，dos攻击的杀伤力降低，所以出现了DDOS，攻击者借助公共网络，将大数量的计算机设备联合起来，向一个或多个目标进行攻击。
案例
SYN Flood ,简单说一下tcp三次握手，客户端先服务器发出请求，请求建立连接，然后服务器返回一个报文，表明请求以被接受，然后客户端也会返回一个报文，最后建立连接。那么如果有这么一种情况，攻击者伪造ip地址，发出报文给服务器请求连接，这个时候服务器接受到了，根据tcp三次握手的规则，服务器也要回应一个报文，可是这个ip是伪造的，报文回应给谁呢，第二次握手出现错误，第三次自然也就不能顺利进行了，这个时候服务器收不到第三次握手时客户端发出的报文，又再重复第二次握手的操作。如果攻击者伪造了大量的ip地址并发出请求，这个时候服务器将维护一个非常大的半连接等待列表，占用了大量的资源，最后服务器瘫痪。
CC攻击，在应用层http协议上发起攻击，模拟正常用户发送大量请求直到该网站拒绝服务为止。
被攻击的原因
服务器带宽不足，不能挡住攻击者的攻击流量
预防
最直接的方法增加带宽。但是攻击者用各地的电脑进行攻击，他的带宽不会耗费很多钱，但对于服务器来说，带宽非常昂贵。
云服务提供商有自己的一套完整DDoS解决方案，并且能提供丰富的带宽资源

参考《常见Web攻击手段和预防》：https://blog.csdn.net/loongshawn/article/details/88047373