web安全入门

为什么要学习网络安全

首先要明确一下学习目的，作为前端工程师，要守好安全的第一道防线，了解web漏洞，做好web信息安全。

了解web安全的基础知识

信息安全粗略可以分为网络安全，软件安全和基础安全。

下面介绍一下网络安全中的web安全漏洞，作为前端安全防护的知识储备。

web安全漏洞大致可以分为入输出验证不充分，设计缺陷，环境缺陷以及其他不能划分到这3类的问题。

输入／输出验证(Input/output validation)

任何输入输出都有可能触发安全问题。

在处理输入时，以下内容都不可信：

来自用户的 UGC (User Generated Content) 信息
来自第三方的链接
URL 参数
POST 参数
Referer （可能来自不可信的来源）
Cookie （可能来自其他子域注入）

输入导致的常见问题有以下几种：

跨站脚本攻击(XSS)
1. 定义：XSS（Cross Site Script）攻击是页面被注入了恶意的代码。
2. 本质：跨站脚本漏洞是因为Web应用程序时没有对用户提交的语句和变量进行过滤或限制，攻击者通过Web页面的输入区域向数据库或HTML页面中提交恶意代码，当用户打开有恶意代码的链接或页面时，恶意代码通过浏览器自动执行，从而达到攻击的目的。
3. 漏洞
  - 在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入。
  - 在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。
  - 在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。
  - 在标签的 href、src 等属性中，包含 javascript: 等可执行代码。
  - 在 onload、onerror、onclick 等事件中，注入不受控制代码。
  - 在 style 属性和标签中，包含类似 background-image:url(“javascript:…”); 的代码（新版本浏览器已经可以防范）。
  - 在 style 属性和标签中，包含类似 expression(…) 的 CSS 表达式代码（新版本浏览器已经可以防范）。
4. 分类
  - 存储型 XSS 常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。
  - 反射型 XSS 常见于通过 URL 传递参数的功能，如网站搜索、跳转等。由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。
  - DOM 型 XSS
  前端 JavaScript 取出 URL 中的恶意代码并执行。恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
5. 防护
  - 输入过滤
    
    对于明确的输入类型，例如数字、URL、电话号码、邮件地址等等内容，进行输入过滤是必要的。其他内容在输入侧过滤会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。
  - 输出过滤
    
    用户可以通过表单向服务器提交任意文本，但在服务器要渲染用户输入内容时，必须进行反XSS过滤
  - 预防存储型和反射型 XSS 攻击
    - 改成纯前端渲染，把代码和数据分隔开。
    在很多内部、管理系统中，采用纯前端渲染是非常合适的。但对于性能要求高，或有 SEO 需求的页面，我们仍然要面对拼接 HTML 的问题。
    - 对 HTML 做充分转义。
    如果拼接 HTML 是必要的，就需要采用合适的转义库，对 HTML 模板各处插入点进行充分的转义。
  - 预防 DOM 型 XSS 攻击
    
    在使用 .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，很容易产生安全隐患，请务必避免。
  - Content Security Policy
    
    严格的 CSP 在 XSS 的防范中可以起到以下的作用：
    - 禁止加载外域代码，防止复杂的攻击逻辑。
    - 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。
    - 禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。
    - 禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。
    - 合理使用上报可以及时发现 XSS，利于尽快修复问题。
  - 输入内容长度控制对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度。
  - 主动检测和发现使用自动扫描工具寻找 XSS 漏洞，例如 Arachni、Mozilla HTTP Observatory、w3af 等。
  - 其他安全措施
    
    HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。验证码：防止脚本冒充用户提交危险操作。
跨站请求伪造 CSRF (Cross-site request forgery)
1. 定义：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
2. 本质：登录受信任网站A，并在本地生成Cookie。在不登出A的情况下，访问危险网站B。黑客利用登录Cookie冒用用户身份，发送请求。
3. 防护：
  - 阻止不明外域的访问
    - 同源检测
      
      禁止外域（或者不受信任的域名）对我们发起请求。
      1. 可以判断请求是否来自外域：使用Origin Header确定来源域名或使用Referer Header确定来源域名。
      2. 无法确认来源域名情况：建议直接进行阻止，特别是如果您没有使用随机CSRF Token（参考下方）作为第二次检查。
      同源验证是一个相对简单的防范方法，能够防范绝大多数的CSRF攻击。但这并不是万无一失的，对于安全性要求较高，或者有较多用户输入内容的网站，我们就要对关键的接口做额外的防护措施。
    - Samesite Cookie Google起草了一份草案来改进HTTP协议，那就是为Set-Cookie响应头新增Samesite属性，它用来标明这个 Cookie是个“同站 Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方Cookie，Samesite 有两个属性值，分别是 Strict 和 Lax。
      
      如果SamesiteCookie被设置为Strict，浏览器在任何跨域请求中都不会携带Cookie，新标签重新打开也不携带，所以说CSRF攻击基本没有机会。
      
      但是跳转子域名或者是新标签重新打开刚登陆的网站，之前的Cookie都不会存在。尤其是有登录的网站，那么我们新打开一个标签进入，或者跳转到子域名的网站，都需要重新登录。对于用户来讲，可能体验不会很好。
      
      如果SamesiteCookie被设置为Lax，那么其他网站通过页面跳转过来的时候可以使用Cookie，可以保障外域连接打开页面时用户的登录状态。但相应的，其安全性也比较低。
      
      Samesite Cookie是一个可能替代同源验证的方案，但目前还并不成熟，其应用场景有待观望。
  - 提交时要求附加本域才能获取的信息
    - CSRF Token 要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也可以防范CSRF的攻击。
      
      Token的生成采用Encrypted Token Pattern方式。这种方法的Token是一个计算出来的结果，而非随机生成的字符串。这样在校验时无需再去读取存储的Token，只用再次计算一次即可。
      
      Token是一个比较有效的CSRF防护方法，只要页面没有XSS漏洞泄露Token，那么接口的CSRF攻击就无法成功。
      
      但是此方法的实现比较复杂，需要给每一个页面都写入Token（前端无法使用纯静态页面），每一个Form及Ajax请求都携带这个Token，后端对每一个接口都进行校验，并保证页面Token及请求Token一致。这就使得这个防护策略不能在通用的拦截上统一拦截处理，而需要每一个页面和接口都添加对应的输出和校验。这种方法工作量巨大，且有可能遗漏。
      
      验证码和密码其实也可以起到CSRF Token的作用。
    - 双重Cookie验证使用双重提交Cookie。利用CSRF攻击不能获取到用户Cookie的特点，我们可以要求Ajax和表单请求携带一个Cookie中的值。
      
      安全性还是没有CSRF Token高。
  - 防止自己的网站被利用成为攻击的源头
    - 严格管理所有的上传接口，防止任何预期之外的上传内容（例如HTML）。
    - 添加Header X-Content-Type-Options: nosniff 防止黑客上传HTML内容的资源（例如图片）被解析为网页。
    - 对于用户上传的图片，进行转存或者校验。不要直接使用用户填写的图片链接。
    - 当前用户打开其他用户填写的链接时，需告知风险（这也是很多论坛不允许直接在内容中发布外域链接的原因之一，不仅仅是为了用户留存，也有安全考虑）。
SQL注入

定义：用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据

本质：由于Web应用程序没有对用户输入数据的合法性进行判断，攻击者通过Web页面的输入区域(如URL、表单等) ，用精心构造的SQL语句插入特殊字符和指令，通过和数据库交互获得私密信息或者篡改数据库信息。

防护
1. 字符串长度验证，仅接受指定长度范围内的变量值。sql注入脚本必然会大大增加输入变量的长度，通过长度限制，比如用户名长度为 8 到 20 个字符之间，超过就判定为无效值。
2. 对特殊字符 ` ‘，”，\，<，>，&，*，; ` 等sql注释符号进行转义处理，或编码转换。基本上所有的后端语言都有对字符串进行转义处理的方法，比如 lodash 的 lodash._escapehtmlchar 库。
3. 对接收的参数进行类型格式化，如id参数值获取后，进行int类型转换
4. 永远不要使用动态拼装SQL。
  
  所有的查询语句建议使用数据库提供的参数化查询（Parameterized Query）接口，参数化的语句使用参数而不是将用户输入变量嵌入到 SQL 语句中，即不要直接拼接 SQL 语句。例如 Node.js 中的 mysqljs 库的 query 方法中的 ? 占位参数。
```
 mysql.query(`SELECT * FROM user WHERE username = ? AND psw = ?`, [username, psw]);
```
5. 永远不要使用管理员权限的数据库连接(sa、root、admin)，为每个应用使用单独的专用的低特权账户进行有限的数据库连接。使用其他更安全的方式连接SQL数据库。例如已修正过SQL注入问题的数据库连接组件。
6. 不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。这样对方就算获取到整个表的数据内容，也没什么价值。
7. 应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装，把异常信息输出到日志而不是在页面中展示。
8. 做好XSS跨站攻击的防护，防止攻击者伪造管理员信息进入系统后台
9. 不管客户端是否做过数据校验，在服务端必须要有数据校验（长度、格式、是否必填等等）
10. 使用SQL防注入框架开发。
11. 在应用发布之前建议使用专业的 SQL 注入检测工具进行检测，以及时修补被发现的 SQL 注入漏洞。网上有很多这方面的开源工具，例如 sqlmap、SQLninja 等。
12. 避免网站打印出 SQL 错误信息，比如类型错误、字段不匹配等，把代码里的 SQL 语句暴露出来，以防止攻击者利用这些错误信息进行 SQL 注入。
13. 不要过于细化返回的错误信息，如果目的是方便调试，就去使用后端日志，不要在接口上过多的暴露出错信息，毕竟真正的用户不关心太多的技术细节，只要话术合理就行。
命令行注入

定义：指的是攻击者能够通过 HTTP 请求直接侵入主机，执行攻击者预设的 shell 命令。

本质：通过URL发起请求，在Web服务器端执行未授权的命令，获取系统信息，篡改系统配置，控制整个系统，使系统瘫痪等。

例子：如果 params.repo 传入的是 https://github.com/zoumiaojiang/zoumiaojiang.github.io.git 当然没问题了。可是如果 params.repo 传入的是 https://github.com/xx/xx.git && rm -rf /* && 恰好你的服务是用 root 权限起的就惨了。

发生情况：
- 通过目录遍历漏洞，访问系统文件夹，执行指定的系统命令；
- 攻击者提交特殊的字符或者命令，Web程序没有进行检测或者绕过Web应用程序过滤，把用户提交的请求作为指令进行解析，导致执行任意命令
防护：
- 后端对前端提交内容需要完全选择不相信，并且对其进行规则限制（比如正则表达式）。
- 在调用系统命令前对所有传入参数进行命令行参数转义过滤。
- 不要直接拼接命令语句，借助一些工具做拼接、转义预处理，例如 Node.js 的 shell-escape npm 包。
文件上传(网页挂马)

定义：非法文件上传产生的主要原因就是在服务器端没有对用户上传的文件类型做校验或者校验不完整，导致用户可以上传恶意脚本到服务器。

防护：
- 白名单检查文件扩展名，不属于白名单内的，不允许上传。
- 上传文件的保存目录不可解析jsp、php等脚本语言
- 文件名随机命名。如UUID、GUID，不允许用户自定义。
- 如果允许，对上传的图片文件进行渲染
- 记录日志

信息泄露

定义：由于Web服务器或应用程序没有正确处理一些特殊请求，泄露Web服务器的一些敏感信息，如用户名、密码、源代码、服务器信息、配置信息等。

原因

  Web服务器配置存在问题，导致一些系统文件或者配置文件暴露在互联网中；
  Web服务器本身存在漏洞，在浏览器中输入一些特殊的字符，可以访问未授权的文件或者动态脚本文件源码；
  Web网站的程序编写存在问题，对用户提交请求没有进行适当的过滤，直接使用用户提交上来的数据。

分类

  Web方面：用户信息泄露、服务器路径信息泄露、员工信息泄露、数据库信息以及服务器信息泄露。
  APP方面：敏感域名泄露、密码泄露。

防护：

  登录、付款这样的页面要用HTTPS保护传输。密码可采用单向加密，信用卡账号采用可逆的加密方式。

  加密方式

  * Base64算法：Base64只是一种编码方式，并不是一种加密算法，不要使用Base64来加密数据。
  * Hash算法：具有不可逆性是一种单向密码体制，只能加密不能解密，可以用来加密用户登录密码等凭证。有的开源项目采用md5加盐的方式加密如md5(md5(pwd)+salt)，但是不建议使用MD5等算法，MD5可用因子碰撞暴力破解，建议采用SHA-256算法。不要使用哈希函数作为对称加密算法的签名，字符串串接后再做哈希要注意（URL签名）。
  * 对称加密：加解密使用同一个密钥，计算耗时短，通常用来加密数据。推荐使用AES算法
  * 非对称加密：加解密使用不同的密钥，计算耗时长，通常利用来加密密钥。注意密钥长度不要低于512，建议2048位的密钥长度。

  为了确保安全性，有时多种加密算法混合使用。如非对称->hash->对称

整数溢出

定义：当程序中的数据超过其数据类型的范围，则会造成溢出，整数类型的溢出被称为整数溢出。

防护：用bignumber.js处理数字。或者限制输入数字的长度。
XXE（XML External Entity Injection）

定义：即XML外部实体注入。是一种针对XML终端实施的攻击，黑客想要实施这种攻击，需要在XML的payload包含外部实体声明，且服务器本身允许实体扩展。这样的话，黑客或许能读取WEB服务器的文件系统，通过UNC路径访问远程文件系统，或者通过HTTP/HTTPS连接到任意主机。

防护
```
  * 使用开发语言提供的禁用外部实体的方法

  * 过滤用户提交的XML数据，过滤关键词：`<!DOCTYPE，<!ENTITY，SYSTEM，PUBLIC`。
```

设计缺陷

越权漏洞

分类：垂直越权漏洞和水平越权漏洞。
- 垂直越权漏洞
  
  定义：也称为权限提升，是一种“基于URL的访问控制”设计缺陷引起的漏洞。
  
  本质：由于Web应用程序没有做权限控制或者仅在菜单上做了权限控制，导致恶意用户只要猜测其他管理页面的URL，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。
- 水平越权漏洞
  
  定义：是一种“基于数据的访问控制”设计缺陷引起的漏洞。
  
  本质：由于服务器端在接收到请求数据进行操作时没有判断数据的所属人而导致的越权数据访问漏洞。如服务器端从客户端提交的request参数（用户能够控制的数据）中获取用户id，恶意攻击者通过变换请求ID的值，查看或修改不属于本人的数据。
防护：配置FILTER拦截器，对请求所有URL进行拦截，对于需要进行授权的URL进行权限校验，防止用户越权访问系统资源。
目录遍历

定义：又称目录穿越、恶意浏览、文件泄露等。指通过在 URL 或参数中构造 ../，./ ，或者附加“../”的一些变形（如“..\”或“..//”）和类似的跨父目录字符串的 ASCII 编码、unicode 编码等，完成目录跳转，读取操作系统各个目录下的敏感文件，也可以称作「任意文件读取漏洞」。

原理：程序没有充分过滤用户输入的 ../ 之类的目录跳转符，导致用户可以通过提交目录跳转来遍历服务器上的任意文件。使用多个.. 符号，不断向上跳转，最终停留在根 /，通过绝对路径去读取任意文件。

防护
```
  * 对 URL 或者参数进行 ../，./ 等字符的转义过滤。
  * 要下载的文件地址保存至数据库中。
  * 文件ID使用随机数命名
  * 文件路径保存至数据库，用户提交文件对应ID下载文件。
  * 下载文件之前做权限判断。
  * 记录文件下载日志。
```
物理路径泄漏

定义：系统报错 500 的错误信息直接返回到页面可见导致的漏洞。得到物理路径有些时候它能给攻击者带来一些有用的信息，比如说：可以大致了解系统的文件目录结构；可以看出系统所使用的第三方软件；也说不定会得到一个合法的用户名（因为很多人把自己的用户名作为网站的目录名）。

防护：做好后端程序的出错处理，定制特殊的 500 报错页面。
源码暴露漏洞

定义：和物理路径泄露类似，就是攻击者可以通过请求直接获取到你站点的后端源代码，然后就可以对系统进一步研究攻击。

原因：基本上就是发生在服务器配置上了，服务器可以设置哪些路径的文件才可以被直接访问的

分类：
- .hg源码泄漏
- .git源码泄漏
- .DS_Store文件泄漏
- 网站备份压缩文件
- SVN导致文件泄露
- WEB-INF/web.xml泄露
- CVS泄漏
防护：所有的服务器都提供了静态资源机制，所以在通过服务器配置静态资源目录和路径的时候，一定要注意检验，不然很可能产生漏洞。
点击劫持(Click jacking)

定义：点击劫持是一种视觉上的欺骗手段，攻击者使用一个透明的、不可见的iframe，覆盖在一个网页上，然后诱使用户在该网页上进行操作，此时用户在不知情的情况下点击了透明的iframe页面。通过调整iframe页面的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上。

防护：

配置FILTER拦截器，在服务器端返回请求中，使用一个HTTP头“X-Frame-Options”值为SAMEORIGIN-同源策略，则frame页面的地址只能为同源域名下面的页面，防止点击劫持漏洞发生。

X-Frame-Options HTTP响应头是用来给浏览器指示允许一个页面能否在<frame>、<iframe>、<object>中展现的标记
非授权对象引用

定义：当开发人员公开对内部实现对象的引用（例如URL或FORM参数中的文件，目录或数据库键）时，就会发生这种情况。攻击者可以使用此信息访问其他对象，并可以创建将来的攻击来访问未经授权的数据。

防护
- 实施访问控制检查。
- 避免在URL中公开对象引用。
- 验证对所有引用对象的授权。
业务逻辑缺陷

关注点：账户信息安全、业务数据安全、业务流程安全、业务接口安全

环境缺陷

* 框架漏洞票；

	例如：Struts 2 远程代码执行漏洞，Java反序列化漏洞

* 基础环境漏洞

其他

服务端请求伪造 SSRF（Server-Side Request Forgery）

定义：一种由攻击者构造形成由服务端发起请求的一个安全漏洞

本质：是由于有些应用（网页分享、站长工具、图片搜索等）提供了通过URL 获取其他站点资源的功能，当这种功能没有对协议、网络边界等做好限制，导致这种功能被滥用，攻击者可以利用这种缺陷获取内网敏感数据、DOS 内网服务器、获取内网服务器权限、读取文件等。

防护
- 过滤内网服务器对公网服务器请求的响应。如果Web应用是获取某一类型的文件，在把返回结果展示给用户之前应先验证返回的信息是否符合文件类型标准，比如返回信息应为图片，如果返回信息是HTML，则停止将返回信息返回客户端。
- 统一错误提示信息，避免用户可以根据错误信息来判断远端服务器的端口状态。
- 在内网服务器的防火墙上限制公网服务器的请求端口为HTTP等协议常用端口，如：80、443、8080、8090。
- 若公网服务器的内网IP与内网无业务通信，建议将公网服务器对应的内网IP列入黑名单，避免应用被用来获取内网数据。
- 内网服务器禁用不必要的协议，仅允许HTTP和HTTPS请求，防止类似于file:///、gopher://、ftp:// 等协议引起的安全问题。

DDoS 攻击

定义：又叫分布式拒绝服务，全称 Distributed Denial of Service，其原理就是利用大量的请求造成资源过载，导致服务不可用

分类：从层次上可分为网络层攻击与应用层攻击。网络层 DDos 攻击包括 SYN Flood、ACK Flood、UDP Flood、ICMP Flood 等。

防护网络层 DDoS 防御

  网络层的 DDoS 攻击究其本质其实是无法防御的，我们能做得就是不断优化服务本身部署的网络架构，以及提升网络带宽。当然，还是做好以下几件事也是有助于缓解网络层 DDoS 攻击的冲击：

  * 网络架构上做好优化，采用负载均衡分流。
  * 确保服务器的系统文件是最新的版本，并及时更新系统补丁。
  * 添加抗 DDos 设备，进行流量清洗。
  * 限制同时打开的 SYN 半连接数目，缩短 SYN 半连接的 Timeout 时间。
  * 限制单 IP 请求频率。
  * 防火墙等防护设置禁止 ICMP 包等。
  * 严格限制对外开放的服务器的向外访问。
  * 运行端口映射程序或端口扫描程序，要认真检查特权端口和非特权端口。
  * 关闭不必要的服务。
  * 认真检查网络设备和主机/服务器系统的日志。只要日志出现漏洞或是时间变更,那这台机器就可能遭到了攻击。
  * 限制在防火墙外与网络文件共享。这样会给黑客截取系统文件的机会，主机的信息暴露给黑客，无疑是给了对方入侵的机会。

  应用层 DDoS 防御

  应用层 DDoS 攻击不是发生在网络层，是发生在 TCP 建立握手成功之后，应用程序处理请求的时候，现在很多常见的 DDoS 攻击都是应用层攻击。应用层攻击千变万化，目的就是在网络应用层耗尽你的带宽，下面列出集中典型的攻击类型：CC 攻击、DNS Flood、HTTP 慢速连接攻击。

  * 判断 User-Agent 字段（不可靠，因为可以随意构造）
  * 针对 IP + cookie，限制访问频率（由于 cookie 可以更改，IP 可以使用代理，或者肉鸡，也不可靠)
  * 关闭服务器最大连接数等，合理配置中间件，缓解 DDoS 攻击。
  * 请求中添加验证码，比如请求中有数据库操作的时候。
  * 编写代码时，尽量实现优化，并合理使用缓存技术，减少数据库的读取操作。

  应用层的防御有时比网络层的更难，因为导致应用层被 DDoS 攻击的因素非常多，有时往往是因为程序员的失误，导致某个页面加载需要消耗大量资源，有时是因为中间件配置不当等等。而应用层 DDoS 防御的核心就是区分人与机器（爬虫），因为大量的请求不可能是人为的，肯定是机器构造的。因此如果能有效的区分人与爬虫行为，则可以很好地防御此攻击。

流量劫持

定义：流量劫持基本分两种：DNS 劫持和 HTTP 劫持，目的都是一样的，就是当用户访问网站的时候，给你展示的并不是或者不完全是该网站提供的 “内容”。

防护：

DNS 劫持

DNS 劫持，也叫做域名劫持。DNS 的作用是把网络地址域名对应到真实的计算机能够识别的 IP 地址，以便计算机能够进一步通信，传递网址和内容等。如果当用户通过某一个域名访问一个站点的时候，被篡改的 DNS 服务器返回的是一个恶意的钓鱼站点的 IP，用户就被劫持到了恶意钓鱼站点，然后继而会被钓鱼输入各种账号密码信息，泄漏隐私。

这类劫持，要不就是网络运营商搞的鬼，一般小的网络运营商与黑产勾结会劫持 DNS，要不就是电脑中毒，被恶意篡改了路由器的 DNS 配置，基本上做为开发者或站长却是很难察觉的，除非有用户反馈，现在升级版的 DNS 劫持还可以对特定用户、特定区域等使用了用户画像进行筛选用户劫持的办法，另外这类广告显示更加随机更小，一般站长除非用户投诉否则很难觉察到，就算觉察到了取证举报更难。无论如何，如果接到有 DNS 劫持的反馈，一定要做好以下几件事：
- 取证很重要，时间、地点、IP、拨号账户、截屏、URL 地址等一定要有。
- 可以跟劫持区域的电信运营商进行投诉反馈。
- 如果投诉反馈无效，直接去工信部投诉，一般来说会加白你的域名。
HTTP 劫持

HTTP 劫持主要是当用户访问某个站点的时候会经过运营商网络，而不法运营商和黑产勾结能够截获 HTTP 请求返回内容，并且能够篡改内容，然后再返回给用户，从而实现劫持页面，轻则插入小广告，重则直接篡改成钓鱼网站页面骗用户隐私。

HTTPS 协议就是一种基于 SSL 协议的安全加密网络应用层协议，可以很好的防止 HTTP 劫持。将你的站点全站改造成 HTTPS。
IP登录限制绕过

定义：系统根据客户端提交的x-forwarded-for值来判断内网登陆还是外网登陆，当客户端请求携带x-forwarded-for值为127.0.0.1时，可直接使用内网登陆方式登陆系统。
异常调试信息泄露

本质：代码中使用e.printStackTrace()打印异常错误信息，在系统发生异常时，如未自定义错误页面，系统就会将发生异常的详细信息打印出来。

防护：不要使用e.printStackTrace()
邮件/短信轰炸

本质：主要由于邮件订阅或短信验证接口没有做好防护

防护：在发送邮件或短信的表单中操作增加输入验证码功能，包括服务器端验证码或短信验证码。另外，短信验证码要限制发送时间间隔，比如1分钟以后允许重发