WEB网络安全

       在学习网络安全之前，必须要先知道一个组织——OWASP。 OWASP是一个开源的、非盈利的全球性安全组织，致力于应用软件的安全研究。我们基于该组织公布的技术文档来学习相关网络攻击原理和预防措施，web安全的核心是——永远不要相信用户传过来的数据：

常见的 web 攻击方式有如下这些：

1. google hack

2. 网页爬虫

3. 暴力猜解

4. web 漏洞扫描

5. 错误信息利用

6. 利用服务器配置漏洞

7. 文件上传下载

8. 构造恶意输入（sql注入攻击、命令注入攻击、跨站脚本攻击等）

9. http 协议攻击

10. 拒绝服务攻击

11. 其他攻击利用（web service、flash 、ajax 等）

1. sql 注入攻击

1.1 简单注入

1. 数值型注入方式：例如我们后台有这样一个查询sql: 

SELECT * from user_info WHERE id= 

那么我们可以通过修改前端的值位：-1 or 1=1 来实现查询所有的数据，其中-1表示永远不可能存在的数据。

2. 字符串注入的方式：通过注释字符实现绕道

由于# / --通常标识注释，因此可以在输入用户名的时候加上’#，然后输入任意的密码，这样后面查询密码的sql 被注释掉，直接绕过密码校验实现登录；

因此要保证前后台输入框格式的绝对校验。另外严格禁止sql拼接，必须使用占位符

2. XSS攻击

跨站脚本攻击，是代码注入的一种，它允许恶意用户将代码注入到网页，其他用户在浏览网页时就会受到影响；将用户输入的数据当作了html语句放到了页面上执行

2.1 反射性XSS攻击

定义 —— 页面发出请求时，XSS代码出现在URL中，作为输入提交到服务器端，服务器端解析后响应，XSS代码随响应内容一起传回给浏览器，最后浏览器解析执行XSS代码。

demo 如下：

当访问项目时候，加上 xss 的参数就会有如下页面展示：

我们将 xss 的值改动一下：http://127.0.0.1:8080/tomatocc/?xss=  会弹出如下的界面框，这种攻击的前提是：必须将地址中的参数在页面解析，如果不进行解析的话，那么这种攻击方式也就毫无意义。

这种攻击又包含三种方式：

1. 主动攻击：上述的加img标签就是主动攻击。

2. 引诱攻击：如果参数值为：<p onclick="alert('点我了')">点我</p>，这种引诱用户去点击的攻击，则为引诱攻击。

3. iframe方式：如果参数值为：<iframe src="https://baidu.com/t.html"></iframe>，那么将会直接将某个网站渲染到该页面。

2.1 存储性XSS攻击

1. 假设这是一个交流论坛，其中一个页面中有留言的文本输入框，我们将具有攻击性的脚本写到文本框中，然后提交到服务端。（该脚本的含义表示，获取客户端的cookie，并发送到指定地址）。

2. 后台服务已经将我们提交的数据存储到数据库中。当其他用户在自己计算机中登陆这个网站的时候，服务端会将我们之前写入具有攻击性的XSS脚本留言渲染到HTML页面，从而将该用户页面中的cookie信息发送到我们预留的网站中。

3.接下来，我们就可以用这个人的cookie信息在该网站中“替代”他进行一系列的操作；一个简单的存储型XSS攻击(cookie欺骗)就完成。

针对js获取cookie的解决方案：在cookie中设置了HttpOnly属性为true，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击

2.3 XSS攻击的防御措施

1. 转义html:  常用的模板引擎，如 doT.js、ejs、FreeMarker 等，对于 HTML 转义通常只有一个规则，就是把 & < > " ' / 这几个字符转义掉，确实能起到一定的 XSS 防护作用

2. 过滤：在使用 .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量使用 .textContent、.setAttribute() 等。如果用 Vue或者React技术栈，并且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 阶段避免 innerHTML、outerHTML 的 XSS 隐患。DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等，<a> 标签的 href 属性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免。

3.  校正：避免直接对HMTL 转义，我们需要更完善的转移策略