决战金三银四,大厂面试题汇总 | web安全篇

151 阅读24分钟

目录

  1. 介绍下数字签名的原理
  2. 当连接不安全外网时,可能会遇到页面注入广告信息等,该怎么解决(运营商劫持)
  3. 301、302 的 https 被挟持怎么办?
  4. 网页验证码是干嘛的,是为了解决什么安全问题?
  5. 对称加密和非对称加密的区别和用处
  6. 什么是 CSP?
  7. 运营商劫持
  8. 能不能说一说XSS攻击?
  9. 能不能说一说CSRF攻击?
  10. 说一下你理解的 HTTPS 中间人攻击 ?

介绍下数字签名的原理

数字签名

数字签名,它的作用跟手写签名其实是一样的,用来证明某个消息或者文件时本人认同的。我国在 2005 年就已经实行《电子签名法》,确立了电子签名(包括但不限于数字签名)的法律效力。那么数字签名是利用公钥加密系统保证不可伪造和不可抵赖两个特性。

常见的签名算法有:

  • RSA:基于大整数分解问题
  • DSA:基于离散对数问题
  • ECDSA:属于 DSA 的一个变种,基于椭圆曲线上的离散对数问题

原理

  • 加密采用非对称加密,sunny 有三把钥匙,两把公钥送给朋友,一把私钥留给自己。
  • A 或者 B 写邮件给 sunny:A 先用公钥对邮件加密,然后 sunny 收到邮件之后使用私钥解密。
  • sunny 写邮件给 A 或 B:
  • sunny 写完邮件,先用 hash 函数生成邮件的摘要,附着在文章上面,这就完成了数字签名,然后 sunny 在使用私钥加密,就可以把邮件发送出去了
  • A 或 B 收到邮件之后,先把数字签名取下来,然后使用自己的公钥解密即可。这时候取下来的数字签名中的摘要若和 sunny 的一致,那就以为是 sunny 发送过来的,在对比信件本身使用 hash 函数,将得到的结果与上一步得到的摘要进行对比。如果两者是一致的,那就证明这封信未被修改过。

如果一个页面突然出现一段广告,可能是什么原因,怎么解决?

什么是 XSS 攻击?

XSS 攻击一般指攻击者通过在网页注入恶意脚本,当用户浏览网页时,恶意脚本执行,控制用户浏览器行为的一种攻击方式。

XSS 攻击分类

  • 反射型 XSS 攻击

通过 URL 链接点击触发,是一次性行为, 本质上是服务器端没有对用户恶意输入做安全处理,直接反射输入内容。如输入baidu.com/?id=<script>alert(1)</script>,弹出弹窗内容为 1。谷歌这类安全性高的浏览器基本可以自动处理这类攻击。

  • 存储型 XSS 攻击

顾名思义,一般涉及后端数据存储,常见场景意见反馈模块,前端通过接口把用户信息传给后端,当后台管理系统展示反馈意见时,就会读取数据库中这些数据,当这些数据含有攻击的脚本,那就造成了存储型 XSS 攻击。这种攻击是持久性的。

  • DOM 型 XSS 攻击

  • 浏览器自带的防御 X-XSS-Protection

目前支持 IE、Chrome、Safari 浏览器,可检测到 XSS 攻击时,阻止页面加载。使用如下:

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>

X-XSS-Protection 为 0 表示禁止使用 XSS 过滤,为 1 表示允许使用 XSS 过滤。mode=block:若检测到 XSS 攻击,阻止页面加载。report=<reporting-URI>(仅限 Chromium):若检测到跨站点脚本攻击,浏览器将清理页面并报告违规行为。使用 CSP report-uri 指令发送报告。

  • HTML 标签

将标签符号<、>等全局转义

const escapeHtml = (str) => {
  str = str
    .replace(/&/g, "&amp;")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/"/g, "&quto;")
    .replace(/'/g, "&#39;")
    .replace(/ /g, "&#32;");
  return str;
};
  • 白名单过滤

大体思路将 HTML 字符串解析成实体对象。若白名单里属性存在在该实体对象中则做相应的处理。这里使用 cheerio 将 HTML 解析成实体。

const whiteList = {
  img: ["src"],
};
const xssFilter = (html) => {
  if (!html) return "";
  const $ = cheerio.load(html, {
    normalizeWhitespace: true,
    xmlMode: true,
  });
  $("*").each((index, elem) => {
    if (!whiteList[elem.name]) {
      $(elem).remove();
      return;
    }
    for (var attr in elem.attributes) {
      if (whiteList[elem.name].indexOf(attr) === -1) {
        $(elem).attr(attr, null);
      }
    }
  });
  return $.html();
};
  • csp(Content Security Policy) 实质就是白名单制度,开发者明确告诉客户端哪些外部资源可以加载和执行。
<meta
  http-equiv="Content-Security-Policy"
  content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:"
/>

// 脚本:只信任当前域名
// <object>标签:不信任任何URL,即不加载任何资源。
// 样式表:只信任cdn.example.org和third-party.org
// 框架(frame):必须使用HTTPS协议加载
// 其他资源:没有限制

HTTP 挟持

什么是 HTTP 挟持?

在运营商的路由器节点上,设置协议检测,一旦发现是 HTTP 请求且是 HTML 类型请求,则拦截处理。常见有两种:

  • 返回 302 让用户浏览器跳转到另外的地址
  • 在服务器返回的 HTML 中插入 JS 或 DOM 节点
HTTP 劫持防御
  • 向运营商投诉
  • 在 HTML 上加上<meta http-equiv="Cache-Control" content="no-siteapp"> <meta http-equiv="Cache-Control" content="no-transform"/> 禁止转码
  • 使用 HTTPS,HTTPS 增加了 SSL 协议,会对数据进行加密。
  • 白名单过滤。大体思路是检查所有外链是否属于白名单。
  • 监听 DOM 节点插入及 DOM 节点移除事件
el.addEventListener("DOMNodeInserted", function (e) {
  console.log(e.srcElement);
});

el.addEventListener("DOMNodeRemoved", function (e) {
  console.log(e.srcElement);
});

301、302 的 https 被挟持怎么办?

合理使用 HSTS

什么是 HSTS 呢?HSTS(HTTP Strict Transport Security,HTTP 严格传输安全协议)表明网站已经实现了 TLS,要求浏览器对用户明文访问的 URL 重写成了 HTTPS,避免始终强制 302 重定向的延时开销。

HSTS 的实现原理

当浏览器第一次 HTTP 请求服务器时,返回的响应头中增加Strict-Transport-Security,告诉浏览器指定时间内,这个网站必须通过 HTTPS 协议来访问。也就是对于这个网站的 HTTP 地址,浏览器需要现在本地替换为 HTTPS 之后再发送请求。


网页验证码是干嘛的,是为了解决什么安全问题?

(1)区分用户是计算机还是人的公共全自动程序。可以防止恶意破解密码、刷票、论坛灌水
(2)有效防止黑客对某一个特定注册用户用特定程序暴力破解方式进行不断的登陆尝试

对称加密和非对称加密的区别和用处

  • 对称加密: 加密和解密的秘钥使用的是同一个
  • 非对称加密: 与对称加密算法不同,非对称加密算法需要两个密钥:公开密钥(publickey)和私有密钥(privatekey)。

对称加密算法

密钥较短,破译困难,除了数据加密标准(DES),另一个对称密钥加密系统是国际数据加密算法(IDEA),它比DES的加密性好,且对计算机性能要求也没有那么高.

优点:

算法公开、计算量小、加密速度快、加密效率高

缺点:

在数据传送前,发送方和接收方必须商定好秘钥,然后 使双方都能保存好秘钥。其次如果一方的秘钥被泄露,那么加密信息也就不安全了。另外,每对用户每次使用对称加密算法时,都需要使用其他人不知道的唯一秘钥,这会使得收、发双方所拥有的钥匙数量巨大,密钥管理成为双方的负担。

常见的对称加密算法有: DES、3DES、Blowfish、IDEA、RC4、RC5、RC6 和 AES

非对称加密算法

公开密钥与私有密钥是一对,如果用公开密钥对数据进行加密,只有用对应的私有密钥才能解密;如果用私有密钥对数据进行加密,那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥,所以这种算法叫作非对称加密算法。

非对称加密算法实现机密信息交换的基本过程是:甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开;得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方;甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。甲方只能用其专用密钥解密由其公用密钥加密后的任何信息。

优点:

安全

缺点:

速度较慢

常见的非对称加密算法有: RSA、ECC(移动设备用)、Diffie-Hellman、El Gamal、DSA(数字签名用)

Hash算法(摘要算法)

Hash算法特别的地方在于它是一种单向算法,用户可以通过hash算法对目标信息生成一段特定长度的唯一hash值,却不能通过这个hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。

常见的摘要算法有: MD2、MD4、MD5、HAVAL、SHA


什么是 CSP?

内容安全策略(CSP)

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

通常有两种方式来开启 CSP

  • 一种是设置 HTTP 首部中的Content-Security-Policy
  • 一种是设置 meta 标签的方式<meta http-equiv="Content-Security-Policy">

这里以设置 HTTP Header 来举例子

  • 只允许加载本站资源
Content-Security-Policy: default-src 'self'

只允许加载 HTTPS 协议图片

Content-Security-Policy: img-src https://*
  • 允许加载任何来源的框架
Content-Security-Policy: child-src 'none'

设置的属性还有很多,更多设置属性可以查看 MDN 文档

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


运营商劫持

网络劫持最主要的就是运营商层面的劫持。可以说,我们每个人随时随地都在与它打交道。

而运营商劫持又主要分两种:

  • DNS劫持:这种劫持会把你重新定位到其它网站,我们所熟悉的钓鱼网站就是这个原理。但是因为它的违法性,现在被严厉的监管起来,已经很少见。
  • HTTP劫持:虽然DNS劫持已经被监管了起来,但是还有HTTP劫持啊!当运营商发现你的是HTTP请求时,就会在里面插入一些奇奇怪怪的广告。并且这种现象十分常见,不信你可以试着随便打开一个网页,仔细看看你就会发现一些小尾巴,这就是被HTTP劫持了。

为什么会这样?

HTTP请求是在网络中是明文传输,而且必须经过运营商,于是运营商层面可以很轻松地修改响应的HTTP内容。比如在返回的HTML里直接加一段JS,JS可以直接在客户端执行实现任何想要的效果。

解决办法:

  • 如果是自己的站被劫持,直接全站HTTPS吧!并且在推广发布时带上协议头会有效果,因为80端口的301也有一定概率被劫持;
  • 如果只是作为单纯用户,基本无解;尝试访问同一个站时用不同的网络环境,WIFI/4G切下运营商,看看会不会都有这样的内容出现;只有某一个运营商有,可以尝试打运营商电话投诉。(很多人表示亲测有效)

能不能说一说XSS攻击?

什么是XSS攻击?

XSS全称是Cross Site Scripting[跨站脚本],为了和css区分,故叫它xss。XSS攻击是指浏览器中执行恶意脚本(无论是跨域还是同域),从而拿到用户的信息进行操作。

这些操作一般可以完成下面这些事情

  1. 窃取Cookie
  2. 监听用户行为,比如输入账号密码后直接发送到黑客服务器
  3. 修改DOM伪造登录表单
  4. 在页面中生成浮窗广告

通常情况下,XSS攻击的实现有三种方式

  • 存储型
  • 反射型
  • 文档型

存储型

存储型,将恶意脚本存储了起来,确实,存储型的XSS将脚本存储到了服务端的数据库,然后在客户端执行这些脚本,从而达到攻击的效果

常见的场景是留言评论区提交一段代码,如果前后端没有做好转义的工作,那评论内容存到了数据库,在页面渲染过程中直接执行,相当于执行一段位置逻辑的js代码,是非常恐怖的。这就是存储型的xss攻击

反射型

反射型xss指的是恶意脚本作为网络请求的一部分 比如我输入

http://baidu.com?q=<script>alert("你完蛋了")</script>

这样在服务端会拿到q参数,然后将内容返回给浏览器端,浏览器将这些内容作为HTML的一部分解析,发现是一个脚本,直接执行,这样被攻击了

之所以叫它反射型,是因为恶意脚本是通过作为网络请求的参数,经过服务器,然后在反射到HTML文档中,执行解析。和存储型不一样的是:服务器并不会存储这些恶意脚本

文档型

文档型的XSS攻击并不会经过服务端,而是作为中间人的角色,在数据传输过程劫持到网络数据包,然后修改里面的html文档,这样的劫持方式包括wifi路由劫持或者本地恶意软件

防范措施

明白三种xss攻击的原理,发现一个共同点:都是让恶意脚本直接能在浏览器中执行 那么要防范它,就是要避免这些脚本代码的执行,为了完成这一点,必须做到一个信念,两个利用。

一个信念

千万不要相信任何用户的输入! 无论是在前端和服务端,都要对用户的输入进行转码或过滤

<script>alert('你完了!')</script>

转码后变为:

&lt;script&gt;alert(&#39;你完蛋了&#39;)&lt;/script&gt;

这样的代码在html解析的过程中是无法执行的 当然也可以利用关键词过滤的方式,将script标签给删除。那么现在的内容只剩下。。。什么都没有

利用CSP

CSP(Content-Security-Policy)是一个HTTP response header, 它描述允许页面控制用户代理能够为指定的页面加载哪些资源, 可防止XSS攻击

CSP,即浏览器中的内容安全策略,它的核心思想就是服务器决定浏览器加载哪些资源,具体来说可以完成以下功能:

  1. 限制其他域下的资源加载
  2. 禁止向其他域提交数据
  3. 提供上报机制,能帮助我们及时发现XSS攻击

利用HttpOnly

很多XSS攻击脚本都是用来窃取Cookie,而设置Cookie的HttpOnly属性后,JavaScript便无法读取Cookie的值,这样也很好的防范XSS攻击。

总结

xss攻击是指浏览器中执行恶意脚本,然后拿到用户的信息进行操作。主要分为存储型、反射型和文档型。防范的措施包括:

  • 一个信念:不要相信用户的输入,对输入的内容转码或者过滤,让其不可执行
  • 两个利用:利用CSP,利用Cookie的HttpOnly属性

能不能说一说CSRF攻击?

image.png

什么是CSRF攻击?

CSRF(Cross-site request forgery),即跨站请求伪造,指的是黑客诱导用户点击链接,打开黑客的网站,然后黑客利用用户目前的登录状态发起的跨站请求。 举个例子,你在某个网站点击了黑客精心挑选的图片,你点击后进入一个新的页面。那么,恭喜你被攻击啦! 你可能对突然被攻击这件事很好奇,那么接下来就是进行拆解:当你点击了这个链接之后,黑客在背后做了哪些事情? 可能会做三件事情:

  • 1.自动发GET请求 黑客网页里面可能有一段这样的代码:
<img src="https://xxx.com/info?user=hhh&count=77">

进入页面后自动发送get请求,值得注意的是,这个请求会自动带上关于xxx.com的cookie信息(假设你已经登录过xxx.com的网站) 假如服务器端没有相应的验证机制,它可能以为发请求的是一个正常的用户,因为携带了相应的cookie,然后进行相应的各种操作,可以是转账汇款以及其他的恶意操作

  • 2.自动发POST请求 黑客可能自己填写了一个表单,写了一段自动提交的脚本。
<form id='hacker-form' action="https://xxx.com/info" method="POST">
  <input type="hidden" name="user" value="hhh" />
  <input type="hidden" name="count" value="100" />
</form>
<script>document.getElementById('hacker-form').submit();</script>

同样也会携带相应的用户cookie信息,让服务器误以为是一个正常的用户在操作,让各种恶意的操作变为可能

  • 3.诱导点击发送GET请求 在黑客的网站上,可能会放上一个链接,驱使你来点击
<a href="https://xxx/info?user=hhh&count=100" taget="_blank">点击进入修仙世界</a>

点击后,自动发送get请求,接下来和自动发GET请求部分同理 这就是CSRF攻击的原理,和XSS攻击做对比,CSRF攻击并不需要将恶意代码注入用户当前页面的html文档中,而是跳转到新的页面,利用服务器的验证漏洞和用户之前的登陆状态来模拟用户进行操作

防范措施

  1. 利用Cookie的SameSite属性

CSRF攻击中重要的一环就是自动发送目标站点下的 Cookie,然后就是这一份 Cookie 模拟了用户的身份。因此在Cookie上面下文章是防范的不二之选。恰好,在 Cookie 当中有一个关键的字段,可以对请求中 Cookie 的携带作一些限制,这个字段就是SameSite。

SameSite可以设置为三个值,Strict、Lax和None。

  • 1.在Strict模式下,浏览器完全禁止第三方请求携带Cookie。比如请求zhufeng.com网站只能在zhufeng.com域名当中请求才能携带 Cookie,在其他网站请求都不能。
  • 2.在Lax模式,就宽松一点了,但是只能在 get 方法提交表单况或者a 标签发送 get 请求的情况下可以携带 Cookie,其他情况均不能。
  • 3.在None模式下,也就是默认模式,请求会自动携带上 Cookie。
  1. 验证来源站点

这就需要要用到请求头中的两个字段: Origin和Referer。 其中,Origin只包含域名信息,而Referer包含了具体的 URL 路径。 当然,这两者都是可以伪造的,通过 Ajax 中自定义请求头即可,安全性略差。

  1. CSRF Token

Django 作为 Python 的一门后端框架,如果是用它开发过的同学就知道,在它的模板(template)中, 开发表单时,经常会附上这样一行代码:

{% csrf_token %}

这就是CSRF Token的典型应用。那它的原理是怎样的呢?

首先,浏览器向服务器发送请求时,服务器生成一个字符串,将其植入到返回的页面中。 然后浏览器如果要发送请求,就必须带上这个字符串,然后服务器来验证是否合法,如果不合法则不予响应。这个字符串也就是CSRF Token,通常第三方站点无法拿到这个 token, 因此也就是被服务器给拒绝

  1. 验证码

几乎100%防范,但体验略差。。

总结

CSRF(Cross-site request forgery), 即跨站请求伪造,指的是黑客诱导用户点击链接,打开黑客的网站,然后黑客利用用户目前的登录状态发起跨站请求。 CSRF攻击一般会有三种方式:

  • 自动 GET 请求
  • 自动 POST 请求
  • 诱导点击发送 GET 请求

防范措施: 利用 Cookie 的SameSite 属性验证来源站点CSRF Token验证码


说一下你理解的 HTTPS 中间人攻击 ?

https

大家可能都听说过 HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密,而加密过程是使用了非对称加密实现。但其实,HTTPS 在内容传输的加密上使用的是对称加密,非对称加密只作用在证书验证阶段。

HTTPS的整体过程分为证书验证和数据传输阶段,具体的交互过程如下:

image.png

① 证书验证阶段

  1. 浏览器发起 HTTPS 请求

  2. 服务端返回 HTTPS 证书(包含公钥)

  3. 客户端验证证书是否合法,如果不合法则提示告警

② 数据传输阶段

  1. 当证书验证合法后,在本地生成随机数

  2. 通过公钥加密随机数,并把加密后的随机数传输到服务端

  3. 服务端通过私钥对随机数进行解密

  4. 服务端通过客户端传入的随机数构造对称加密算法,对返回结果内容进行加密后传输

为什么数据传输是用对称加密?

首先,非对称加密的加解密效率是非常低的,而 http 的应用场景中通常端与端之间存在大量的交互,非对称加密的效率是无法接受的;

另外,在 HTTPS 的场景中只有服务端保存了私钥,一对公私钥只能实现单向的加解密,所以 HTTPS 中内容传输加密采取的是对称加密,而不是非对称加密。

为什么需要 CA 认证机构颁发证书?

HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器,而 HTTPS 协议主要解决的便是网络传输的安全性问题。

首先我们假设不存在认证机构,任何人都可以制作证书,这带来的安全风险便是经典的“中间人攻击”问题。

image.png

过程原理:

  1. 本地请求被劫持(如DNS劫持等),所有请求均发送到中间人的服务器

  2. 中间人服务器返回中间人自己的证书

  3. 客户端创建随机数,通过中间人证书的公钥对随机数加密后传送给中间人,然后凭随机数构造对称加密对传输内容进行加密传输

  4. 中间人因为拥有客户端的随机数,可以通过对称加密算法进行内容解密

  5. 中间人以客户端的请求内容再向正规网站发起请求

  6. 因为中间人与服务器的通信过程是合法的,正规网站通过建立的安全通道返回加密后的数据

  7. 中间人凭借与正规网站建立的对称加密算法对内容进行解密

  8. 中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输

  9. 客户端通过与中间人建立的对称加密算法对返回结果数据进行解密

由于缺少对证书的验证,所以客户端虽然发起的是 HTTPS 请求,但客户端完全不知道自己的网络已被拦截,传输内容被中间人全部窃取。

浏览器是如何确保 CA 证书的合法性?

  1. 证书包含什么信息?
  • 颁发机构信息
  • 公钥
  • 公司信息
  • 域名
  • 有效期
  • 指纹
  • ......
  1. 证书的合法性依据是什么?

首先,权威机构是要有认证的,不是随便一个机构都有资格颁发证书,不然也不叫做权威机构。

另外,证书的可信性基于信任制,权威机构需要对其颁发的证书进行信用背书,只要是权威机构生成的证书,我们就认为是合法的。所以权威机构会对申请者的信息进行审核,不同等级的权威机构对审核的要求也不一样,于是证书也分为免费的、便宜的和贵的。

  1. 浏览器如何验证证书的合法性?

浏览器发起 HTTPS 请求时,服务器会返回网站的 SSL 证书,浏览器需要对证书做以下验证:

  1. 验证域名、有效期等信息是否正确。证书上都有包含这些信息,比较容易完成验证;
  2. 判断证书来源是否合法。每份签发证书都可以根据验证链查找到对应的根证书,操作系统、浏览器会在本地存储权威机构的根证书,利用本地根证书可以对对应机构签发证书完成来源验证;

  1. 判断证书是否被篡改。需要与 CA 服务器进行校验;

  2. 判断证书是否已吊销。通过CRL(Certificate Revocation List 证书注销列表)和 OCSP(Online Certificate Status Protocol 在线证书状态协议)实现,其中 OCSP 可用于第3步中以减少与 CA 服务器的交互,提高验证效率

以上任意一步都满足的情况下浏览器才认为证书是合法的。

这里插一个我想了很久的但其实答案很简单的问题:

  • 既然证书是公开的,如果要发起中间人攻击,我在官网上下载一份证书作为我的服务器证书,那客户端肯定会认同这个证书是合法的,如何避免这种证书冒用的情况?

其实这就是非加密对称中公私钥的用处,虽然中间人可以得到证书,但私钥是无法获取的,一份公钥是不可能推算出其对应的私钥,中间人即使拿到证书也无法伪装成合法服务端,因为无法对客户端传入的加密数据进行解密。

  1. 只有认证机构可以生成证书吗?

如果需要浏览器不提示安全风险,那只能使用认证机构签发的证书。但浏览器通常只是提示安全风险,并不限制网站不能访问,所以从技术上谁都可以生成证书,只要有证书就可以完成网站的 HTTPS 传输。例如早期的 12306 采用的便是手动安装私有证书的形式实现 HTTPS 访问

本地随机数被窃取怎么办?

证书验证是采用非对称加密实现,但是传输过程是采用对称加密,而其中对称加密算法中重要的随机数是由本地生成并且存储于本地的,HTTPS 如何保证随机数不会被窃取?

其实 HTTPS 并不包含对随机数的安全保证,HTTPS 保证的只是传输过程安全,而随机数存储于本地,本地的安全属于另一安全范畴,应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。

用了 HTTPS 会被抓包吗?

HTTPS 的数据是加密的,常规下抓包工具代理请求后抓到的包内容是加密状态,无法直接查看。

HTTPS 只防止用户在不知情的情况下通信被监听,如果用户主动授信,是可以构建“中间人”网络,代理软件可以对传输内容进行解密。

防范方法

服务器在发送浏览器的公钥中加入 CA 证书,浏览器可以验证 CA 证书的有效性;(现有 HTTPS 很难被劫持,除非信任了劫持者的 CA 证书)。