前端总结--网络

渣渣辉

http各版本

HTTP/0.9:功能捡漏,只支持GET方法,只能发送HTML格式字符串。
HTTP/1.0:支持多种数据格式,增加POST、HEAD等方法,增加头信息,每次只能发送一个请求(无持久连接)
HTTP/1.1:默认持久连接、请求管道化、增加缓存处理、增加Host字段、支持断点传输分块传输等。
HTTP/2.0:二进制分帧、多路复用、头部压缩、服务器推送

HTTP 版本区别

1.Http协议

1.1 Http结构图

clipboard.png

1.2 什么是Http协议

HTTP协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写,是用于从万维网服务器传输超文本到本地浏览器的传送协议。
HTTP 是基于 TCP/IP 协议通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)。它不涉及数据包(packet)传输,主要规定了客户端和服务器之间的通信格式,默认使用80端口
总结:建立了TCP连接,就可以基于http协议在服务端与客户端之间传递数据

clipboard.png

1.3 Http的特点

  1. 简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、HEAD、PUT、DELETE、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快
  2. 灵活:HTTP允许传输任意类型的数据对象。
  3. 无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。
  4. 无状态:HTTP协议是无状态的,HTTP 协议自身不对请求和响应之间的通信状态进行保存。任何两次请求之间都没有依赖关系。直观地说,就是每个请求都是独立的,与前面的请求和后面的请求都是没有直接联系的。协议本身并不保留之前一切的请求或 响应报文的信息。这是为了更快地处理大量事务,确保协议的可伸缩性,而特意把 HTTP 协议设计成如此简单的。

    1.4 Http报文

    1.4.1 请求(request)报文

    请求报文包括4个部分

  5. 请求行(request line)
  6. 请求头(header)
  7. 空行
  8. 请求体

    请求行

请求行包括3个部分,用来说明请求类型,要访问的资源以及所使用的HTTP版本

  1. 请求方法
  2. 请求url
  3. http及版本

    POST  /taobao.com/index.html HTTP/1.1
请求头

由关键字/值对组成,每行一对,关键字和值用英文冒号“:”分隔。
Host,表示主机名,虚拟主机;
Connection,HTTP/1.1增加的,使用keepalive,即持久连接,一个连接可以发多个请求;
User-Agent,请求发出者,兼容性以及定制化需求。

clipboard.png

空行

最后一个请求头之后是一个空行,这个行非常重要,它表示请求头已经结束,接下来的是请求正文。

请求体

可以承载多个请求参数的数据

name=tom&password=1234&realName=tomson

clipboard.png

1.4.2 响应(response)报文

响应报文包括4个部分

  1. 状态行
  2. 响应头部
  3. 空行
  4. 响应体
状态行
Status Code: 200 

clipboard.png

响应头部

clipboard.png

响应体

clipboard.png

1.5 HTTP请求方法

  1. GET 请求指定的页面信息,并返回实体主体。
  2. HEAD 类似于get请求,只不过返回的响应中没有具体的内容,用于获取报头
  3. POST 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。
  4. PUT 从客户端向服务器传送的数据取代指定的文档的内容。
  5. DELETE 请求服务器删除指定的页面。

1.6GET与POST区别

  1. GET在浏览器回退时是无害的,而POST会再次提交请求
  2. GET请求会被浏览器主动缓存,而POST不会,除非手动设置
  3. GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留
  4. GET请求在URL中传送的参数是有长度限制的,而POST没有限制
  5. GET参数通过URL传递,POST放在Request body中

1.7 Http状态码

1xx:指示信息--表示请求已接收,继续处理
2xx:成功--表示请求已被成功接收、理解、接受
3xx:重定向--要完成请求必须进行更进一步的操作
4xx:客户端错误--请求有语法错误或请求无法实现
5xx:服务器端错误--服务器未能实现合法的请求

1.8 持久连接

1.8.1 为什么需要持久连接

HTTP协议的初始版本中,每进行一次HTTP通信就要断开一次TCP连接。以当年的通信情况来说,因为都是些容量很小的文本传输,所以即使这样也没有多大问题。可随着 HTTP 的 普及,文档中包含大量图片的情况多了起来。比如,使用浏览器浏览一个包含多张图片的 HTML 页面时,在发送请求访问 HTML 页面资源的同时,也会请 求该 HTML 页面里包含的其他资源。因此,每次的请求都会造成无谓的 TCP 连接建立和断开,增加通信量的 开销。

clipboard.png

1.8.2 持久连接的特点

为解决上述 TCP 连接的问题,HTTP/1.1 和一部分的 HTTP/1.0 想出了持久连接(HTTP Persistent Connections,也称为 HTTP keep-alive 或 HTTP connection reuse)的方法。持久连接的特点是,只要任意一端没有明确提出断开连接,则保持TCP连接状态。

clipboard.png

1.9 管线化

持久连接使得多数请求以管线化(pipelining)方式发送成为可能。从前发送请求后需等待并收到响应,才能 发送下一个请求。管线化技术出现后,不用等待响应亦可直接发送下一个请求。
这样就能够做到同时并行发送多个请求,而不需要一个接一个地等待响应了。通俗地讲,请求打包一次传输过去,响应打包一次传递回来。管线化的前提是在持久连接下。

clipboard.png

假如当请求一个包含 10 张图片的 HTML Web 页面,与挨个连接相比,用持久连接可以让请求更快结束。 而管线化技术则比持久连接还要快。请求数越多,时间差就越明显。客户端需要请求这十个资源。以前的做法是,在同一个TCP连接里面,先发送A请求,然后等待服务器做出回应,收到后再发出B请求,以此类推,而管道机制则是允许浏览器同时发出这十个请求,但是服务器还是按照顺序,先回应A请求,完成后再回应B请求。

于是在使用持久连接的情况下,某个连接上消息的传递类似于

请求1->响应1->请求2->响应2->请求3->响应3

管线化方式发送变成了类似这样:

请求1->请求2->请求3->响应1->响应2->响应3

1.10 参考

https://github.com/ljianshu/B...

2.TCP 三次握手

2.1 为什么要进行三次握手

  1. 在第一次通信过程中,A向B发送信息之后,B收到信息后可以确认自己的收信能力和A的发信能力没有问题。
  2. 在第二次通信中,B向A发送信息之后,A可以确认自己的发信能力和B的收信能力没有问题,但是B不知道自己的发信能力到底如何,所以就需要第三次通信。
  3. 在第三次通信中,A向B发送信息之后,B就可以确认自己的发信能力没有问题。

clipboard.png

持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销,减轻了服务器端的负载。另外, 减少开销的那部分时间,使 HTTP 请求和响应能够更早地结束,这样 Web 页面的显示速度也就相应提高了。
在 HTTP/1.1 中,所有的连接默认都是持久连接,但在 HTTP/1.0 内并未标准化。虽然有一部分服务器通过非 标准的手段实现了持久连接,但服务器端不一定能够支持持久连接。毫无疑问,除了服务器端,客户端也需 要支持持久连接。

2.2 第一次握手

client发送一个SYN(J)包给server,然后等待server的ACK回复,进入SYN-SENT状态(syn已发送状态)。p.s: SYN为synchronize的缩写,理解为序列号,其实就是一个随机数,ACK为acknowledgment的缩写,理解为确认号。

2.3 第二次握手

server接收到SYN(seq=J)包后就返回一个ACK(J+1),随机数+1,包以及一个自己的SYN(K)包,然后等待client的ACK回复,server进入SYN-RECIVED状态(syn已接收状态)。

2.4 第三次握手

client接收到server发回的ACK(J+1)包后,进入ESTABLISHED状态(建立连接状态)。然后根据server发来的SYN(K)包,返回给等待中的server一个ACK(K+1)包。等待中的server收到ACK回复,也把自己的状态设置为ESTABLISHED。到此TCP三次握手完成,client与server可以正常进行通信了。

2.5 参考

https://juejin.im/post/5a7835...

3.四次挥手

FIN:希望断开连接

clipboard.png

3.1 第一次挥手

client发送一个FIN(M)包,此时client进入FIN-WAIT-1状态(终止等待1),这表明client已经没有数据要发送了。

第二次挥手

server收到了client发来的FIN(M)包后,向client发回一个ACK(M+1)包,此时server进入CLOSE-WAIT状态(关闭等待),client进入FIN-WAIT-2状态(终止等待2)。

第三次挥手

server向client发送FIN(N)包,请求关闭连接,同时server进入LAST-ACK状态(最后确认)。

第四次挥手

client收到server发送的FIN(N)包,进入TIME-WAIT状态(时间等待)。向server发送ACK(N+1)包,server收到client的ACK(N+1)包以后,进入CLOSE状态;client等待一段时间还没有得到回复后判断server已正式关闭,进入CLOSE状态。

3.1.2 参考

https://blog.csdn.net/qq_3895...

4.九种跨域

4.1 什么是跨域

4.1.1 什么是同源策略及其限制内

同源策略是一种约定,它是浏览器最核心也最基本的安全功能,如果缺少了同源策略,浏览器很容易受到XSS、CSRF等攻击。所谓同源是指"协议+域名+端口"三者相同,即便两个不同的域名指向同一个ip地址,也非同源。

clipboard.png

同源策略限制内容有

  1. Cookie、LocalStorage、IndexedDB 等存储性内容
  2. DOM 节点
  3. AJAX 请求发送后,结果被浏览器拦截了
    但是有三个标签是允许跨域加载资源

    <img src=XXX>
    <link href=XXX>
    <script src=XXX>

    4.1.2 常见跨域场景

    当协议、子域名、主域名、端口号中任意一个不相同时,都算作不同域。不同域之间相互请求资源,就算作“跨域”。常见跨域场景如下图所示:

clipboard.png

  1. 如果是协议和端口造成的跨域问题“前台”是无能为力的。
  2. 在跨域问题上,仅仅是通过“URL的首部”来识别而不会根据域名对应的IP地址是否相同来判断。“URL的首部”可以理解为“协议, 域名和端口必须匹配”。
请求跨域了,那么请求到底发出去没有?

跨域并不是请求发不出去,请求能发出去,服务端能收到请求并正常返回结果,只是结果被浏览器拦截了。你可能会疑问明明通过表单的方式可以发起跨域请求,为什么 Ajax 就不会?因为归根结底,跨域是为了阻止用户读取到另一个域名下的内容,Ajax 可以获取响应,浏览器认为这不安全,所以拦截了响应。但是表单并不会获取新的内容,所以可以发起跨域请求。同时也说明了跨域并不能完全阻止 CSRF,因为请求毕竟是发出去了。

4.2 9种跨域解决方案

4.2.1 jsonp

JSONP原理

利用 <script> 标签没有跨域限制的漏洞,网页可以得到从其他来源动态产生的 JSON 数据。JSONP请求一定需要对方的服务器做支持才可以

JSONP和AJAX对比

JSONP和AJAX相同,都是客户端向服务器端发送请求,从服务器端获取数据的方式。但AJAX属于同源策略,JSONP属于非同源策略(跨域请求)

JSONP优缺点

JSONP优点是简单兼容性好,可用于解决主流浏览器的跨域数据访问的问题。缺点是仅支持get方法具有局限性,不安全可能会遭受XSS攻击

4.2.2 cors

CORS 需要浏览器和后端同时支持。IE 8 和 9 需要通过 XDomainRequest 来实现。

浏览器会自动进行 CORS 通信,实现 CORS 通信的关键是后端。只要后端实现了 CORS,就实现了跨域。

服务端设置 Access-Control-Allow-Origin 就可以开启 CORS。 该属性表示哪些域名可以访问资源,如果设置通配符则表示所有网站都可以访问资源。

简单请求
只要同时满足以下两大条件,就属于简单请求
条件1:使用下列方法之一

  1. GET
  2. HEAD
  3. POST
    条件2:Content-Type 的值仅限于下列三者之一
  4. text/plain
  5. multipart/form-data
  6. application/x-www-form-urlencoded

复杂请求
不符合以上条件的请求就肯定是复杂请求了。
复杂请求的CORS请求,会在正式通信之前,增加一次HTTP查询请求,称为"预检"请求,该请求是 option 方法的,通过该请求来知道服务端是否允许跨域请求。
用PUT向后台请求时,属于复杂请求

node实例

  res.header('Access-Control-Allow-Origin', '*'); //这个表示任意域名都可以访问,这样写不能携带cookie了。
//res.header('Access-Control-Allow-Origin', 'http://www.baidu.com'); //这样写,只有www.baidu.com 可以访问。
  res.header('Access-Control-Allow-Headers', 'Content-Type, Content-Length, Authorization, Accept, X-Requested-With , yourHeaderFeild');
  res.header('Access-Control-Allow-Methods', 'PUT, POST, GET, DELETE, OPTIONS');//设置方法
  if (req.method == 'OPTIONS') {
    res.send(200); // 意思是,在正常的请求之前,会发送一个验证,是否可以请求。
  }
  else {
    next();
  }
});

4.2.3 Node中间件代理(两次跨域)

vuecli中的proxyTable

clipboard.png

4.2.4 nginx

实现原理类似于Node中间件代理,需要你搭建一个中转nginx服务器,用于转发请求。

4.2.5 websocket

4.2.6 window.name + iframe

4.2.7 location.hash + iframe

4.2.8 document.domain + iframe

4.2.9 postMessage

5.Web安全

5.1 XSS

5.1.1什么是XSS

xss(Cross-Site Scripting):跨站脚本攻击是指通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或JavaScript进行的一种攻击。
跨站脚本攻击有可能造成以下影响:

  1. 利用虚假输入表单骗取用户个人信息
  2. 利用脚本窃取用户的Cookie值,被害者在不知情的情况下,帮助攻击者发送恶意请求。
  3. 显示伪造的文章或图片

XSS 的原理是恶意攻击者往 Web 页面里插入恶意可执行网页脚本代码,当用户浏览该页之时,嵌入其中 Web 里面的脚本代码会被执行,从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的。

5.1.2非持久型 XSS(反射型 XSS )

<select>
    <script>
        document.write(''
            + '<option value=1>'
            +     location.href.substring(location.href.indexOf('default=') + 8)
            + '</option>'
        );
        document.write('<option value=2>English</option>');
    </script>
</select>

攻击者可以直接通过 URL (类似:https://xxx.com/xxx?default=<script>alert(document.cookie)</script>) 注入可执行的脚本代码。不过一些浏览器如Chrome其内置了一些XSS过滤器,可以防止大部分反射型XSS攻击。

非持久型 XSS 漏洞攻击有以下几点特征

  1. 即时性,不经过服务器存储,直接通过 HTTP 的 GET 和 POST 请求就能完成一次攻击,拿到用户隐私数据。
  2. 攻击者需要诱骗点击,必须要通过用户点击链接才能发起
  3. 反馈率低,所以较难发现和响应修复
  4. 盗取用户敏感保密信息

5.1.3 持久型 XSS(存储型 XSS)

持久型 XSS 漏洞,一般存在于 Form 表单提交等交互功能,如文章留言,提交文本信息等,黑客利用的 XSS 漏洞,将内容经正常功能提交进入数据库持久保存,当前端页面获得后端从数据库中读出的注入代码时,恰好将其渲染执行。

clipboard.png

主要注入页面方式和非持久型 XSS 漏洞类似,只不过持久型的不是来源于 URL,referer,forms 等,而是来源于后端从数据库中读出来的数据 。持久型 XSS 攻击不需要诱骗点击,黑客只需要在提交表单的地方完成注入即可,但是这种 XSS 攻击的成本相对还是很高。

攻击成功需要同时满足以下几个条件:

  1. POST 请求提交表单后端没做转义直接入库
  2. 后端从数据库中取出数据没做转义直接输出给前端。
  3. 前端拿到后端数据没做转义直接渲染成 DOM。

持久型 XSS 有以下几个特点:

  1. 持久性,植入在数据库中
  2. 盗取用户敏感私密信息
  3. 危害面广

5.1.4 如何防御

对于 XSS 攻击来说,通常有两种方式可以用来防御。

1.CSP

CSP 本质上就是建立白名单,开发者明确告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则,如何拦截是由浏览器自己实现的。我们可以通过这种方式来尽量减少 XSS 攻击。

通常可以通过两种方式来开启 CSP

  1. 设置 HTTP Header 中的 Content-Security-Policy
  2. 设置 meta 标签的方式

这里以设置 HTTP Header 来举例

  1. 只允许加载本站资源

    Content-Security-Policy: default-src 'self'
  2. 只允许加载 HTTPS 协议图片

    ontent-Security-Policy: img-src https://*
  3. 允许加载任何来源框架

    Content-Security-Policy: child-src 'none'

    对于这种方式来说,只要开发者配置了正确的规则,那么即使网站存在漏洞,攻击者也不能执行它的攻击代码,并且 CSP 的兼容性也不错。

2.转义字符
用户的输入永远不可信任的,最普遍的做法就是转义输入输出的内容,对于引号、尖括号、斜杠进行转义

function escape(str) {
  str = str.replace(/&/g, '&amp;')
  str = str.replace(/</g, '&lt;')
  str = str.replace(/>/g, '&gt;')
  str = str.replace(/"/g, '&quto;')
  str = str.replace(/'/g, '&#39;')
  str = str.replace(/`/g, '&#96;')
  str = str.replace(/\//g, '&#x2F;')
  return str
}

但是对于显示富文本来说,显然不能通过上面的办法来转义所有字符,因为这样会把需要的格式也过滤掉。对于这种情况,通常采用白名单过滤的办法,当然也可以通过黑名单过滤,但是考虑到需要过滤的标签和标签属性实在太多,更加推荐使用白名单的方式。

const xss = require('xss')
let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
console.log(html)   // -> <h1>XSS Demo</h1>&lt;script&gt;alert("xss");&lt;/script&gt;

以上示例使用了 js-xss 来实现,可以看到在输出中保留了 h1 标签且过滤了 script 标签。

3. HttpOnly Cookie。
这是预防XSS攻击窃取用户cookie最有效的防御手段。Web应用程序在设置cookie时,将其属性设为HttpOnly,就可以避免该网页的cookie被客户端恶意JavaScript窃取,保护用户cookie信息。

5.2CSRF

CSRF(Cross Site Request Forgery),即跨站请求伪造
它利用用户已登录的身份,在用户毫不知情的情况下,以用户的名义完成非法操作。

5.2.1 CSRF攻击的原理

clipboard.png

完成 CSRF 攻击必须要有三个条件

  1. 用户已经登录了站点 A,并在本地记录了 cookie
  2. 在用户没有登出站点 A 的情况下(也就是 cookie 生效的情况下),访问了恶意攻击者提供的引诱危险站点 B (B 站点要求访问站点A)。
  3. 站点 A 没有做任何 CSRF 防御

例子: 当我们登入转账页面后,突然眼前一亮惊现"XXX隐私照片,不看后悔一辈子"的链接,耐不住内心躁动,立马点击了该危险的网站(页面代码如下图所示),但当这页面一加载,便会执行submitForm这个方法来提交转账请求,从而将10块转给黑客。

5.2.2 如何防御

防范 CSRF 攻击可以遵循以下几种规则

  1. Get 请求不对数据进行修改
  2. 不让第三方网站访问到用户 Cookie
  3. 阻止第三方网站请求接口
  4. 请求时附带验证信息,比如验证码或者 Token

1.SameSite

可以对 Cookie 设置 SameSite 属性。该属性表示 Cookie 不随着跨域请求发送,可以很大程度减少 CSRF 的攻击,但是该属性目前并不是所有浏览器都兼容。

2. Referer Check

HTTP Referer是header的一部分,当浏览器向web服务器发送请求时,一般会带上Referer信息告诉服务器是从哪个页面链接过来的,服务器籍此可以获得一些信息用于处理。可以通过检查请求的来源来防御CSRF攻击。正常请求的referer具有一定规律,如在提交表单的referer必定是在该页面发起的请求。所以通过检查http包头referer的值是不是这个页面,来判断是不是CSRF攻击。

但在某些情况下如从https跳转到http,浏览器处于安全考虑,不会发送referer,服务器就无法进行check了。若与该网站同域的其他网站有XSS漏洞,那么攻击者可以在其他网站注入恶意脚本,受害者进入了此类同域的网址,也会遭受攻击。出于以上原因,无法完全依赖Referer Check作为防御CSRF的主要手段。但是可以通过Referer Check来监控CSRF攻击的发生。

3. Anti CSRF Token

目前比较完善的解决方案是加入Anti-CSRF-Token。即发送请求时在HTTP 请求中以参数的形式加入一个随机产生的token,并在服务器建立一个拦截器来验证这个token。服务器读取浏览器当前域cookie中这个token值,会进行校验该请求当中的token和cookie当中的token值是否都存在且相等,才认为这是合法的请求。否则认为这次请求是违法的,拒绝该次服务。

这种方法相比Referer检查要安全很多,token可以在用户登陆后产生并放于session或cookie中,然后在每次请求时服务器把token从session或cookie中拿出,与本次请求中的token 进行比对。由于token的存在,攻击者无法再构造出一个完整的URL实施CSRF攻击。但在处理多个页面共存问题时,当某个页面消耗掉token后,其他页面的表单保存的还是被消耗掉的那个token,其他页面的表单提交时会出现token错误。

4.验证码
应用程序和用户进行交互过程中,特别是账户交易这种核心步骤,强制用户输入验证码,才能完成最终请求。在通常情况下,验证码够很好地遏制CSRF攻击。但增加验证码降低了用户的体验,网站不能给所有的操作都加上验证码。所以只能将验证码作为一种辅助手段,在关键业务点设置验证码。

5.3 点击劫持

点击劫持是一种视觉欺骗的攻击手段。攻击者将需要攻击的网站通过 iframe 嵌套的方式嵌入自己的网页中,并将 iframe 设置为透明,在页面中透出一个按钮诱导用户点击。

5.3.1 特点

  1. 隐蔽性较高,骗取用户操作
  2. "UI-覆盖攻击"
  3. 利用iframe或者其它标签的属性

    5.3.2 点击劫持的原理

用户在登陆 A 网站的系统后,被攻击者诱惑打开第三方网站,而第三方网站通过 iframe 引入了 A 网站的页面内容,用户在第三方网站中点击某个按钮(被装饰的按钮),实际上是点击了 A 网站的按钮。
接下来我们举个例子:我在优酷发布了很多视频,想让更多的人关注它,就可以通过点击劫持来实现

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Document</title>
    <style>
        iframe {
            width: 1440px;
            height: 900px;
            position: absolute;
            top: -0px;
            left: -0px;
            z-index: 2;
            -moz-opacity: 0;
            opacity: 0;
            filter: alpha(opacity=0);
        }
        
        button {
            position: absolute;
            top: 270px;
            left: 1150px;
            z-index: 1;
            width: 90px;
            height: 40px;
        }
    </style>
</head>

<body>
    <button>点击脱衣</button>
    <img src="http://pic1.win4000.com/wallpaper/2018-03-19/5aaf2bf0122d2.jpg">
    <iframe src="http://i.youku.com/u/UMjA0NTg4Njcy" scrolling="no"></iframe>
</body>

</html>

从上图可知,攻击者通过图片作为页面背景,隐藏了用户操作的真实界面,当你按耐不住好奇点击按钮以后,真正的点击的其实是隐藏的那个页面的订阅按钮,然后就会在你不知情的情况下订阅了。

clipboard.png

5.3.2 如何防御

1.X-FRAME-OPTIONS

X-FRAME-OPTIONS是一个 HTTP 响应头,在现代浏览器有一个很好的支持。这个 HTTP 响应头 就是为了防御用 iframe 嵌套的点击劫持攻击。

该响应头有三个值可选,分别是

  1. DENY,表示页面不允许通过 iframe 的方式展示
  2. SAMEORIGIN,表示页面可以在相同域名下通过 iframe 的方式展示
  3. ALLOW-FROM,表示页面可以在指定来源的 iframe 中展示

2.JavaScript 防御
对于某些远古浏览器来说,并不能支持上面的这种方式,那我们只有通过 JS 的方式来防御点击劫持了。

<head>
  <style id="click-jack">
    html {
      display: none !important;
    }
  </style>
</head>
<body>
  <script>
    if (self == top) {
      var style = document.getElementById('click-jack')
      document.body.removeChild(style)
    } else {
      top.location = self.location
    }
  </script>
</body>

以上代码的作用就是当通过 iframe 的方式加载页面时,攻击者的网页直接不显示所有内容了

5.4 URL跳转漏洞

5.4.1什么是URL跳转漏洞

借助未验证的URL跳转,将应用程序引导到不安全的第三方区域,从而导致的安全问题
黑客利用URL跳转漏洞来诱导安全意识低的用户点击,导致用户信息泄露或者资金的流失。其原理是黑客构建恶意链接(链接需要进行伪装,尽可能迷惑),发在QQ群或者是浏览量多的贴吧/论坛中。
安全意识低的用户点击后,经过服务器或者浏览器解析后,跳到恶意的网站中。

clipboard.png

恶意链接需要进行伪装,经常的做法是熟悉的链接后面加上一个恶意的网址,这样才迷惑用户。

诸如伪装成像如下的网址,你是否能够识别出来是恶意网址呢?

http://gate.baidu.com/index?act=go&url=http://t.cn/RVTatrd
http://qt.qq.com/safecheck.html?flag=1&url=http://t.cn/RVTatrd
http://tieba.baidu.com/f/user/passport?jumpUrl=http://t.cn/RVTatrd

clipboard.png

5.4.2实现方式

  1. Header头跳转
  2. Javascript跳转
  3. META标签跳转

这里我们举个Header头跳转实现方式:

<?php
$url=$_GET['jumpto'];
header("Location: $url");
?>
http://www.wooyun.org/login.php?jumpto=http://www.evil.com

Javascript跳转

function jumpTo(url) {
    var reg = /id=(\d*)/gi;    //正则匹配初始地址的id
    var id = url.match(reg)[0];    //获得id字符串,了解一下match的返回值
    location.href = "http://" + location.hostname + "/n/nshow.aspx?" + id;
    //字符串拼接并跳转
}
 
var url = location.href;    //获取当前的地址
jumpTo(url);    //执行函数

这里用户会认为www.wooyun.org都是可信的,但是点击上述链接将导致用户最终访问www.evil.com这个恶意网址。

5.4.3如何防御

1.referer的限制
如果确定传递URL参数进入的来源,我们可以通过该方式实现安全限制,保证该URL的有效性,避免恶意用户自己生成跳转链接

  1. 加入有效性验证Token
    我们保证所有生成的链接都是来自于我们可信域的,通过在生成的链接里加入用户不可控的Token对生成的链接进行校验,可以避免用户生成自己的恶意链接从而被利用,但是如果功能本身要求比较开放,可能导致有一定的限制。

5.5 SQL注入

5.5.1 SQL注入的原理

一个万能钥匙的例子来说明其原理

clipboard.png

<form action="/login" method="POST">
    <p>Username: <input type="text" name="username" /></p>
    <p>Password: <input type="password" name="password" /></p>
    <p><input type="submit" value="登陆" /></p>
</form>

这是我们经常见到的登录页面,但如果有一个恶意攻击者输入的用户名是 admin' --,密码随意输入,就可以直接登入系统了。why! ----这就是SQL注入

我们之前预想的SQL 语句是:

SELECT * FROM user WHERE username='admin' AND password='123456'

clipboard.png

但是恶意攻击者用奇怪用户名将你的 SQL 语句变成了如下形式:

SELECT * FROM user WHERE username='admin' -- AND password = '123456'

clipboard.png
在 SQL 中,' --是闭合和注释的意思,-- 是注释后面的内容的意思,所以查询语句就变成了

SELECT * FROM user WHERE username='admin'

clipboard.png

5.5.2如何防御

  1. 严格限制Web应用的数据库的操作权限,给此用户提供仅仅能够满足其工作的最低权限,从而最大限度的减少注入攻击对数据库的危害
  2. 后端代码检查输入的数据是否符合预期,严格限制变量的类型,例如使用正则表达式进行一些匹配处理。
  3. 对进入数据库的特殊字符(',",\,<,>,&,*,; 等)进行转义处理,或编码转换。基本上所有的后端语言都有对字符串进行转义处理的方法,比如 lodash 的 lodash._escapehtmlchar 库。
  4. 所有的查询语句建议使用数据库提供的参数化查询接口,参数化的语句使用参数而不是将用户输入变量嵌入到 SQL 语句中,即不要直接拼接 SQL 语句。例如 Node.js 中的 mysqljs 库的 query 方法中的 ? 占位参数。

5.6 OS命令注入攻击

6. 正向代理,反向代理

参考

https://blog.csdn.net/zhangha...
https://juejin.im/post/5c737a...

7. https

参考

https://www.oschina.net/trans...

8.负载均衡

//nginx.conf

http {
    upstream testServer{
        server 192.168.153.128:3001;
        server 127.0.0.1:3002;
        server 127.0.0.1:3003;
        server 127.0.0.1:3004;
    }
    server {
     listen 8080;
     location / {
       proxy_pass http://testServer;
}

https://mp.weixin.qq.com/s?__...

9.nginx

  1. 代理
  2. 判断pc还是移动端
  3. 二级域名(一个端口对应一个二级域名)
  4. gzip
  5. 过滤,禁止某些ip仿问
  6. 负载均衡
  7. https
阅读 3.8k
1.3k 声望
144 粉丝
0 条评论
1.3k 声望
144 粉丝
文章目录
宣传栏