常见web攻击

what：

　　DDOS攻击：也叫分布式拒绝服务攻击。使很多的计算机在同一时间遭受到攻击，使攻击的目标无法正常使用。攻击的时候，可以对源IP地址进行伪造。从而影响用户的正常使用，同时造成的经济损失也是非常巨大的。

 

　　CC攻击：攻击者借助代理服务器（也叫肉鸡）生成指向受害主机的合法请求，实现DDOS和伪装就叫：CC(Challenge Collapsar)。

 

　　XSS攻击：跨站脚本攻击（Cross-Site Scripting），为了防止和“层叠样式表”（Cascading Style Sheets, CSS）混淆，顾将该缩写改为XSS。

　　　　　　攻击方式：攻击者将恶意代码植入到提供给其它用户使用的页面中，从而盗取存储在客户端的cookie或者其他网站用于识别客户端身份的敏感信息。

　　　　　　分类：

　　　　　　　　1、存储型XSS：一般出现在，第三方用户生产数据内容，供其他用户消费的场景中。大概流程是“恶意用户的Html输入Web程序->进入数据库->Web程序->用户浏览器”。消费用户在浏览器中浏览数据内容时，带有恶意脚本的内容，就会攻击消费用户；

　　　　　　　　2、反射型XSS：主要做法就是恶意用户在URL的参数中加上恶意脚本，在消费用户打开链接（点击链接）时，就会攻击消费用户

　　　　　　栗子：在网页中加上“<script>alert(document.cookie)</script>”，那么消费用户在页面就会将cookie展现出来，出现下图内容：

　　　　　　　　

 

　　　　　　规避方案：

　　　　　　　　1、过滤特殊字符：将用户所提供的内容进行过滤(如上面的script标签)。；

　　　　　　　　2、使用HTTP头指定类型：w.Header().Set("Content-Type","text/javascript")，可以让浏览器解析javascript代码，而不会是html输出；

 

　　SQL注入：

　　　　攻击者向服务器提交恶意的SQL查询语句，导致服务将恶意的SQL语句当作正常查询语句的一部分，从而改变原来查询语句的逻辑，最终执行了恶意的事情。

　　　　栗子：' OR '1'='1，当我们输如用户名 admin ，然后密码输入' OR '1'= '1的时候，本来要执行的是SELECT * FROM user WHERE username='admin' and password='',经过参数拼接后为SELECT * FROM user WHERE username='admin' and password='' OR '1'='1' 。由于1=1是成立，自然就跳过验证了。

　　　　规避方案：不要信用户输入的可靠性。

　　　　　　1、java使用预编译语句(PreparedStatement)，到了服务端的时候，这个伪造 SQL语句的参数也只是简单的字符；

　　　　　　2、对进入数据库的特殊字符（'"\尖括号&*;等）进行转义处理，或编码转换；

　　　　　　3、应用发布前，使用专业的SQL注入检测工具进行检测；

　　　　　　4、避免打印出SQL错误信息，以防信息泄露；

　　　　

　　SYN攻击：

　　　　在三次握手过程中，服务器发送 SYN-ACK 之后，收到客户端的 ACK 之前的 TCP 连接称为半连接(half-open connect)。此时服务器处于 SYN_RCVD 状态。当收到服务器 ACK 后，才能转入 ESTABLISHED 状态。如果无效的半连接数过多，从而导致正常的链接被丢弃，而产生服务慢，甚至统瘫痪。

　　　　具体参考：https://www.cnblogs.com/sfzlstudy/p/15109276.html

 

　　CSRF：

　　　　CSRF（Cross-site request forgery），中文名称：跨站请求伪造。

　　　　即：攻击者盗用了你的身份，以你的名义发送恶意请求。

　　　　关键点：借助本地cookie进行认证，伪造发送请求

 

　　　　根本原因：对于同样域名的每个请求来说，它的 cookie 都会被自动带上（这个是浏览器的机制决定的）

 

　　　　原理：

　　　　　　

 

　　　　从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

　　　　　　1、登录受信任网站A，并在本地生成Cookie。

　　　　　　2、在不登出A的情况下，访问危险网站B。

　　

　　　　demo：

　　　　　　

　　　　预防方案：

　　　　　　Tokens：在一次session中，产生一个csrf_token（服务端生产）。以后在请求服务端时都会获得一个随机的Token（是csrf_token加密后的，但是服务端可以恢复出原值）。在客户端提交请求时，在请求中增加一个隐藏的随机变化的 Token。提交到后台进行验证，如果验证通过则可以继续执行操作。

　　　　　　有效的原因：在请求中放入攻击者所不能伪造的信息，并且该信总不存在于 cookie之中。

　　　　　　　　网站 B 拿不到网站 A 表单里的 Token（或者说，不知道拿哪个数值作为Token）。因为cookie已经不安全了，因此把csrf_token值存储在local storage中（不同页面最好使用变化的token key，例如：服务生成key，返回客户，同时session中存；防止黑客获得key），然后每次表单提交时都从local storage取出来放到form表单的隐藏域中（如：POST 请求来说，要在 form 的最后加上 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>；get就放在url后面参数中），这样B网站不方便（如果配置XSS也是可以破解的）得到这个存储到local storage中的值。 

　　　　　　最好的方案是：核心操作需要用户再次合身；

　　　　　　token的原理如下：https://www.cnblogs.com/sfzlstudy/p/15906003.html