返回介绍
文江博客 开发文档 Web 前端面试题 文章详情

网络及安全防护

发布于 2024-08-09 21:34:50 字数 65761 浏览 0 评论 0 收藏 0

1. Http 状态码，Http2 是什么

答案：

200 欢迎回来，主人 （正常；请求已完成。）

301 人家搬家了 （已移动 — 请求的数据具有新的位置且更改是永久的。）

307 不是这里，换个地方啦 （重新请求的 URL，客户端自动重新请求新的地址）

400 不要把奇怪的东西给人家嘛 （错误请求 — 请求中有语法问题，或不能满足请求。）

403 这里不可以啦！（禁止 — 即使有授权也不需要访问。）

404 这里什么都没有 --- 人家是平的啦。 （找不到 — 服务器找不到给定的资源；文档不存在。）

405 打开方式不对 （资源被禁止）

414 这... 太长了啦 （请求 - URI 太长）

500 服务姬坏掉了啦 （内部错误 — 因为意外情况，服务器不能完成请求。）

503 不要...人家还没准备好啦 （无法获得服务 — 由于临时过载或维护，服务器无法处理请求。）

101 服务姬傲娇中 （服务器将遵从客户的请求转换到另外一种协议）

100 人家... 还要... （初始的请求已经接受，客户应当继续发送请求的其余部分。）

HTTP/2（超文本传输协议第 2 版，最初命名为 HTTP 2.0），是 HTTP 协议的的第二个主要版本，使用于万维网。HTTP/2 是 HTTP 协议自 1999 年 HTTP 1.1 发布后的首个更新，主要基于 SPDY 协议（是 Google 开发的基于 TCP 的应用层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验）。

与 HTTP 1.1 相比，主要区别包括

  • HTTP/2 采用二进制格式而非文本格式
  • HTTP/2 是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行
  • 使用报头压缩，HTTP/2 降低了开销
  • HTTP/2 让服务器可以将响应主动“推送”到客户端缓存中

解析：

状态码类别描述
1xxInformational（信息状态码）接受请求正在处理
2xxSuccess（成功状态码）请求正常处理完毕
3xxRedirection（重定向状态码）需要附加操作已完成请求
4xxClient Error（客户端错误状态码）服务器无法处理请求
5xxServer Error（服务器错误状态码）服务器处理请求出错

2. http1.1 时如何复用 tcp 连接（网易）

答案：在发送 http 的请求头中设置 Connection: keep-alive

3. Http 请求的整个过程

答案：

简洁版： 1.域名解析 --> 2.发起 TCP 的 3 次握手 --> 3.建立 TCP 连接后发起 http 请求 --> 4.服务器响应 http 请求，浏览器得到 html 代码 --> 5.浏览器解析 html 代码，并请求 html 代码中的资源（如 js、css、图片等） --> 6.浏览器对页面进行渲染呈现给用户

4. http 缓存配置怎么设置

答案：

前端设置 http 缓存,前端设置 html 页面缓存方法：静态的 html 页面想要设置使用缓存需要通过 HTTP 的 META 设置 expires 和 cache-control

设置如下网页元信息:

<meta http-equiv="Cache-Control" content="max-age=7200" />
<meta http-equiv="Expires" content="Mon, 20 Jul 2013 23:00:00 GMT" />

解答: cache-control：||no-cache||no-store||max-age

1.no-cache：

表面意为“数据内容不被缓存”，而实际数据是被缓存到本地的，只是每次请求时候直接绕过缓存这一环节直接向服务器请求最新资源，由于浏览器解释不一样，

例如 ie 中我们设置了 no-cache 之后，请求虽然不会直接使用缓存，但是还会用缓存数据与服务器数据进行一致性检测(也就是说还是有几率会用到缓存的),

firefox 中则完全无视 no-cache 存在，详细解释见 no-store;

2.no-store：

指示缓存不存储此次请求的响应部分。与 no-cache 比较来说，一个是不用缓存，一个是不存储缓存;按理来说这个设置更加粗暴直接禁用缓存，

但是具体实现起来 浏览器之间差异却特别大，一般不会直接用该字段进行设置，不过 no-store 是为了防止缓存被恶意修改存储路径导致信息被泄露而设置的，

毕竟有它的用处，在 firefox 中实现缓存是通过文件另存为将缓存副本保存到本地，直接利用 no-cache 对其是无效的，如果加上 no-store 设置的话 则可以起到与 no-cache 一样的效果;

即：cache-control:no-cache,no-store;可以确保在支持 http1.1 版本中各大浏览器回车后退刷新无缓存；

再加上 Pragma: no-cache 设置兼容版本 1.0 即可(不过为了防止一致性检测时候的万一我们还是最好加上一致性检测的内容，如下所示几种方式)；

3.max-age：

例如 Cache-control: max-age=3；表示此次请求成功后 3 秒之内发送同样请求不会去服务器重新请求，而是使用本地缓存；同样我们如果设置 max-age=0 表示立即抛弃缓存直接发送请求到服务器

以下内容来自:http://www.runoob.com/tags/att-meta-http-equiv.html

HTML

http-equiv 属性 HTML meta 标签参考手册 HTML标签

实例 每隔 30 秒刷新一次文档：

<head>
  <meta http-equiv="refresh" content="30" />
</head>

扩展：

与缓存有关的 header 我们来看看每个 header 的具体含义。

  • Request

Cache-Control: max-age=0 以秒为单位 If-Modified-Since: Mon, 19 Nov 2012 08:38:01 GMT 缓存文件的最后修改时间。 If-None-Match: "0693f67a67cc1:0" 缓存文件的 Etag 值 Cache-Control: no-cache 不使用缓存 Pragma: no-cache 不使用缓存

  • Response

Cache-Control: public 响应被缓存，并且在多用户间共享， （公有缓存和私有缓存的区别，请看另一节） Cache-Control: private 响应只能作为私有缓存，不能在用户之间共享 Cache-Control:no-cache 提醒浏览器要从服务器提取文档进行验证 Cache-Control:no-store 绝对禁止缓存（用于机密，敏感文件） Cache-Control: max-age=60 60 秒之后缓存过期（相对时间） Date: Mon, 19 Nov 2012 08:39:00 GMT 当前 response 发送的时间 Expires: Mon, 19 Nov 2012 08:40:01 GMT 缓存过期的时间（绝对时间） Last-Modified: Mon, 19 Nov 2012 08:38:01 GMT 服务器端文件的最后修改时间 ETag: "20b1add7ec1cd1:0" 服务器端文件的 Etag 值

5. 常见的浏览器端的存储技术有哪些， 以及它们的优缺点和使用场景？

答案：

1. cookie

h5 之前，存储主要用 cookies，缺点是在请求头上带着数据，导致流量增加。大小限制 4k

操作方式：

document.cookie = "username=John Doe; expires=Thu, 18 Dec 2013 12:00:00
GMT;path=/" // 设置 cookie document.cookie = "username=; expires=Thu, 01 Jan
1970 00:00:00 GMT" // 删除 cookie

设置 cookie 的方法比较简单，其中有几个参数可以添加

expires 过期时间，当过了到期日期时，浏览器会自动删除该 cookie，如果想删除一个 cookie，只需要把它过期时间设置成过去的时间即可 比如希望设置过期时间一年：new Date().getTime() + 365 24 60 60 1000

如果不设置过期时间，则表示这个 cookie 生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie 就消失了。

path 路径，值可以是一个目录，或者是一个路径。

如果 cc.com/test/index.html 建立了一个 cookie，那么在 cc.com/test/目录里的所有页面，以及该目录下面任何子目录里的页面都可以访问这个 cookie。因此在 cc.com/test/test2/test3 里的任何页面都可以访问 cc.com/test/index.html 建立的 cookie。若 cc.com/test/ 若想访问 cc.com/test/index.html 设置的 cookes，需要把 cookies 的 path 属性设置成“/”。 在指定路径的时候，凡是来自同一服务器，URL 里有相同路径的所有 WEB 页面都可以共享 cookies。

domain 主机名，是指同一个域下的不同主机，例如：www.baidu.com 和 map.baidu.com 就是两个不同的主机名。默认情况下，一个主机中创建的 cookie 在另一个主机下是不能被访问的，但可以通过 domain 参数来实现对其的控制：document.cookie = "name=value;domain=.baidu.com" 这样，所有*.baidu.com 的主机都可以访问该 cookie。

2. localStorage

以键值对(Key-Value)的方式存储，永久存储，永不失效，除非手动删除。IE8+支持，每个域名限制 5M

打开同域的新页面也能访问得到

操作方式：

window.localStorage.username = 'hehe' // 设置 window.localStorage.setItem('username', 'hehe') // 设置 window.localStorage.getItem('username') // 读取 window.localStorage.removeItem('username') // 删除 window.localStorage.key(1) // 读取索引为 1 的值 window.localStorage.clear() // 清除所有 可以存储数组、数字、对象等可以被序列化为字符串的内容

3. sessionStorage

sessionStorage 操作的方法与 localStroage 是一样的，区别在于 sessionStorage 在关闭页面后即被清空，而 localStorage 则会一直保存。很多时候数据只需要在用户浏览一组页面期间使用，关闭窗口后数据就可以丢弃了，这种情况使用 sessionStorage 就比较方便。

注意，刷新页面 sessionStorage 不会清除，但是打开同域新页面访问不到

4. cookie、localStorage、sessionStorage 之间的区别

他们都是保存在浏览器端的存储方式，他们之间的区别：

cookie 数据始终在同源的 http 请求中携带（即使不需要），即 cookie 在浏览器和服务器间来回传递。而 sessionStorage 和 localStorage 不会自动把数据发给服务器，仅在本地保存。cookie 数据还有路径（path）的概念，可以限制 cookie 只属于某个路径下。 存储大小限制不同，cookie 数据不能超过 4k，同时因为每次 http 请求都会携带 cookie，所以 cookie 只适合保存很小的数据，如会话标识。sessionStorage 和 localStorage 虽然也有存储大小的限制，但比 cookie 大得多，可以达到 5M 或更大。 数据有效期不同，sessionStorage：仅在当前浏览器窗口关闭前有效，自然也就不可能持久保持；localStorage：始终有效，窗口或浏览器关闭也一直保存，因此用作持久数据；cookie 只在设置的 cookie 过期时间之前一直有效，即使窗口或浏览器关闭。 作用域不同，sessionStorage 不在不同的浏览器页面中共享，即使是同一个页面；localStorage 在所有同源窗口中都是共享的；cookie 也是在所有同源窗口中都是共享的。 Web Storage 支持事件通知机制，可以将数据更新的通知发送给监听者。 Web Storage 的 api 接口使用更方便，cookie 的原生接口不友好，需要自己封装。

5. 安全性

需要注意的是，不是什么数据都适合放在 Cookie、localStorage 和 sessionStorage 中的，因为它们保存在本地容易被篡改，使用它们的时候，需要时刻注意是否有代码存在 XSS 注入的风险。所以千万不要用它们存储你系统中的敏感数据。

6. 在浏览器多个 tab 页中，cookie、localStorage 可以共享数据，sessionStorage 仅保存在当前 tab 页中不能共享

6. 在 HTTP 响应 Header 中，set-cookie 选项有哪些，分别代表什么含义？

答案：

Set-Cookie: <cookie-name>=<cookie-value>

  • Expires=<date>
  • Max-Age=<non-zero-digit>
  • Domain=<domain-value>
  • Path=<path-value>
  • Secure
  • HttpOnly
  • SameSite=Strict
  • SameSite=Lax
name = name; // 需要设置cookie的值(name不能使用";"和","号),有多个name值时用";"分隔例如：name1=name1;name2=name2;name3=name3

expires; //cookie的有效期限,格式为:expires="Wdy,DD-Mon-YYYY HH:MM:SS"

path; //设置cookie支持的路径,如果path是一个路径，则cookie对这个目录下的所有文件及子目录生效，例如：path="/cgi-bin/"，如果path是一个文件，则cookie指对这个文件生效，例如：path="/cgi-bin/cookie.cgi"

domain; //对cookie生效的域名，例如：domain="gzdzw.51.net"

secure; //如果给出此标志，表示cookie只能通过SSL协议的https服务器来传递,cookie的接收是通过设置环境变量HTTP_COOKIE来实现的，CGI程序可以通过检索该变量获取cookie信息

解析：Cookie 相关的 Http 头

有两个 Http 头部和 Cookie 有关：Set-Cookie 和 Cookie

  • Set-Cookie 由服务器发送，它包含在响应请求的头部中。它用于在客户端创建一个 Cookie
  • Cookie 头由客户端发送，包含在 HTTP 请求的头部中。注意，只有 cookie 的 domain 和 path 与请求的 URL 匹配才会发送这个 cookie。

参考

7. 何为跨域？ 跨域请求数据有几种方式？图片/脚本 等资源有什么跨域问题。如何解决？跨域请求时如何携带 cookie

答案：

1. 何为跨域？

  • 由于浏览器同源策略，凡是发送请求 url 的协议、域名、端口三者之间任意一与当前页面地址不同即为跨域。
  • 同源策略限制了一个源(origin)中加载文本或脚本与来自其它源(origin)中资源的交互方式。同源指的是协议、域名、端口相同，同源策略是一种安全协议。

2.跨域请求数据有几种方式？

（1）JSONP 动态创建 script 标签

但缺点是只支持 get 请求，并且很难判断请求是否失败（一般通过判断请求是否超时）。

（2）Proxy 代理

这种方式首先将请求发送给后台服务器，通过服务器来发送请求，然后将请求的结果传递给前端。

（3）CORS 跨域

是现代浏览器提供的一种跨域请求资源的方法，需要客户端和服务器端的同时支持。整个 CORS 通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS 通信与同源的 AJAX 通信没有差别，代码完全一样。浏览器一旦发现 AJAX 请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。因此，实现 CORS 通信的关键是服务器。只要服务器实现了 CORS 接口，就可以跨源通信。

3.图片/脚本 等资源有什么跨域问题。如何解决？

4.跨域请求时如何携带 cookie

8. 简要描述 HTTPS 的安全机制，以及在 web 服务工程实践中需要注意的问题。描述 http2 和 https 的关系

答案：

  • HTTP 协议通常承载于 TCP 协议之上，在 HTTP 和 TCP 之间添加一个安全协议层（SSL 或 TSL），这个时候，就成了我们常说的 HTTPS。
  • 默认 HTTP 的端口号为 80，HTTPS 的端口号为 443。

9. 什么是点击劫持？如何防范？

答案：

什么点击劫持？最常见的是恶意网站使用 <iframe> 标签把我方的一些含有重要信息类如交易的网页嵌入进去，然后把 iframe 设置透明，用定位的手段的把一些引诱用户在恶意网页上点击。这样用户不知不觉中就进行了某些不安全的操作。

有两种方式可以防范：

  1. 使用 JS 防范： if (top.location.hostname !== self.location.hostname) { alert("您正在访问不安全的页面，即将跳转到安全页面！"); top.location.href = self.location.href; }

  2. 使用 HTTP 头防范： 通过配置 nginx 发送 X-Frame-Options 响应头，这样浏览器就会阻止嵌入网页的渲染。更详细的可以查阅 MDN 上关于 X-Frame-Options 响应头的内容。 add_header X-Frame-Options SAMEORIGIN;

10. 什么是 CSRF, 怎么造成的，有什么防御方法？

答案：

CSRF 概念：CSRF 跨站点请求伪造(Cross—Site Request Forgery)，跟 XSS 攻击一样，存在巨大的危害性，你可以这样来理解： 攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。 如下：其中 Web A 为存在 CSRF 漏洞的网站，Web B 为攻击者构建的恶意网站，User C 为 Web A 网站的合法用户。

CSRF 攻击攻击原理及过程如下：

   1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

   2.在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

   3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

   4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；


   5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

防御 CSRF 攻击：

   目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。

解析：

CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者 Session Riding，通常缩写为 CSRF 或者 XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与 XSS 非常不同，XSS 利用站点内的信任用户，而 CSRF 则通过伪装来自受信任用户的请求来利用受信任的网站。与 XSS 攻击相比，CSRF 攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比 XSS 更具危险性。

特点

  • 依靠用户标识危害网站
  • 利用网站对用户标识的信任
  • 欺骗用户的浏览器发送 HTTP 请求给目标站点
  • 另外可以通过 IMG 标签会触发一个 GET 请求，可以利用它来实现 CSRF 攻击。

防御

  • 通过 referer、token 或者验证码来检测用户提交。
  • 尽量不要在页面的链接中暴露用户隐私信息。
  • 对于用户修改删除等操作最好都使用 post 操作 。
  • 避免全站通用的 cookie，严格设置 cookie 的域。

11. 请简述如何在 HTML 中开启和关闭 DNS 预读取?

答案：

DNS 预读取

概念：

浏览器主动去执行域名解析功能。

当浏览网页时，浏览器会对网页中的域名进行解析缓存，这样当单击当前网页中的连接时就无需进行 DNS 解析，减少用户等待时间，提高用户体验。

范围：

图片、CSS、JS 或 html 上的 link 等 URL。

开关和使用：

<meta http-equiv="x-dns-prefetch-control" content="off" />

<link rel="dns-prefetch" href="//www.spreadfirefox.com" />

前端优化：

减少 DNS 请求次数；

进行 DNS 预获取；

12. 什么是回源？域名回源的含义是什么？

答案：在搜索引擎中所谓的域名回源就是搜索引擎的蜘蛛在爬行的过程中直接抓取源地址上的内容而不是存在各个节点（CDN）上的缓存内容。

解析：

CDN 回源率计算方法

如何计算回源比？

回源比分为回源请求数比例及回源流量比例两种

回源请求数比：统计数据来自所有边缘节点上的请求记录，其中，对于没有缓存或缓存过期（可缓存）的请求以及不可缓存的请求，均计入回源请求中，其他直接命中缓存的，则为命中请求。

回源流量比：回源流量是回源请求文件大小产生的流量和请求本身产生的流量 回源流量比=回源流量/回源流量+用户请求访问的流量

源站内容有更新的时候，源站主动把内容推送到 CDN 节点。 常规的 CDN 都是回源的。即：当有用户访问某一个 URL 的时候，如果被解析到的那个 CDN 节点没有缓存响应的内容，或者是缓存已经到期，就会回源站去获取。如果没有人访问，那么 CDN 节点不会主动去源站拿的。

回源域名一般是 cdn 领域的专业术语，通常情况下，是直接用 ip 进行回源的，但是如果客户源站有多个 ip，并且 ip 地址会经常变化，对于 cdn 厂商来说，为了避免经常更改配置（回源 ip），会采用回源域名方式进行回源，这样即使源站的 ip 变化了，也不影响原有的配置。

CDN 本来是给我们的网站加速的，但是有时会因为不合适的回源策略给服务器带来负担，只有选择正确的策略才能给自己的网站带来更高的访问效率。

13. https 实现原理

答案：

HTTPS 在通讯过程中的原理，总共分为 8 步 STEP 1: 客户端发起 HTTPS 请求 STEP 2: 服务端的配置 STEP 3: 传送证书 STEP 4: 客户端解析证书 STEP 5: 传送加密信息 STEP 6: 服务端解密信息 STEP 7: 传输加密后的信息 STEP 8: 客户端解密信息

14. HTML5 的离线储存怎么使用，工作原理能不能解释一下

答案：

如何使用：只要在在页面头部加入 mainfest 的属性就行了。

<!DOCTYPE html>
<html manifest="cache.manifest"></html>

工作原理：HTML5 的离线存储是基于一个新建的.appcache 文件的缓存机制（不是存储技术），通过这个文件上的解析清单离线存储资源，这些资源就像 cookie 一样被存储下来。当无网时，浏览器会通过被离线存储的数据进行展示

15. XSS

答案：

XSS 是什么

XSS 是一种经常出现在 web 应用中的计算机安全漏洞，它允许恶意 web 用户将代码植入到提供给其它用户使用的页面中。
比如这些代码包括 HTML 代码和客户端脚本。攻击者利用 XSS 漏洞旁路掉访问控制——例如同源策略(same origin policy)。
这种类型的漏洞由于被黑客用来编写危害性更大的网络钓鱼(Phishing)攻击而变得广为人知。
对于跨站脚本攻击，黑客界共识是：跨站脚本攻击是新型的“缓冲区溢出攻击“，而 JavaScript 是新型的“ShellCode”。

示例：
<script>alert(document.cookie)</script>

特点

能注入恶意的 HTML/JavaScript 代码到用户浏览的网页上，从而达到 Cookie 资料窃取、会话劫持、钓鱼欺骗等攻击。 <攻击代码不一定（非要）在中>

原因

  • Web 浏览器本身的设计不安全。浏览器能解析和执行 JS 等代码，但是不会判断该数据和程序代码是否恶意。
  • 输入和输出是 Web 应用程序最基本的交互，而且网站的交互功能越来越丰富。如果在这过程中没有做好安全防护，很容易会出现 XSS 漏洞。
  • 程序员水平参差不齐，而且大都没有过正规的安全培训，没有相关的安全意识。
  • XSS 攻击手段灵活多变。

危害

  • 盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
  • 控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
  • 盗窃企业重要的具有商业价值的资料
  • 非法转账
  • 强制发送电子邮件
  • 网站挂马
  • 控制受害者机器向其它网站发起攻击

如何防范

  • 将重要的 cookie 标记为 http only, 这样的话 Javascript 中的 document.cookie 语句就不能获取到 cookie 了.
  • 表单数据规定值的类型，例如：年龄应为只能为 int、name 只能为字母数字组合。。。。
  • 对数据进行 Html Encode 处理
  • 过滤或移除特殊的 Html 标签， 例如:

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。
列表为空，暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文