CSP（Content Security Policy）可以解决什么问题？

是什么

​ CSP（Content Security Policy）是为了解决 Web 应用程序中的安全问题而创建的一种规范。CSP 通过限制 Web 应用程序能够加载和执行的内容，来减少恶意攻击的成功率。具体来说，CSP 允许 Web 应用程序管理员定义哪些来源可以加载资源和运行 JavaScript 等代码。这些源可以是域名、协议或端口号等。CSP能够用于规定，我们的网站只接受我们指定的请求资源。默认配置下不允许执行内联代码等，如<script>、eval()、setTimeout()等。

​ 当浏览器尝试加载一个 Web 页面时，它会检查页面是否包含 CSP 头，并根据该头信息确定允许加载哪些资源。如果某个资源的来源不在允许列表内，则浏览器将停止加载该资源并向用户发出警告。这样就可以防止注入恶意代码并帮助保护用户隐私和身份。

CSP的使用方式

  • 通过定义在HTTP响应头中使用
1
"Content-Security-Policy: default-src 'self'"
  • 通过定义在HTML中使用
1
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

CSP在HTTP响应头的工作流程

  • 客户端请求 Web 页面。
  • 服务器返回 Web 页面及相关资源，并设置 CSP 头。
  • 浏览器解析 Web 页面，并根据 CSP 头信息确定允许加载哪些资源。
  • 如果某个资源的来源不在允许列表内，则浏览器将停止加载该资源并向用户发出警告。

CSP 的使用方法

需要注意的是，在实际应用中，Web 开发人员需要谨慎设置 CSP 规则，以确保不会限制正常的 Web 应用程序功能。此外，开发人员也需要定期审核 CSP 规则，以确保其仍然适用于最新的 Web 应用程序版本。
总之，CSP 的原理是通过限制 Web 应用程序能够加载和执行的内容，来减少恶意攻击的成功率。它可以帮助保护用户隐私和身份，并提高 Web 应用程序的安全性。

XSS（Cross Site Scripting）跨站脚本攻击

是什么

​ XSS（Cross Site Scripting）跨站脚本攻击，是指通过存在安全漏洞的 Web 网站注册用户的浏览器内运行非法的 HTML 标签或 JavaScript 进而对网站进行的各种攻击。XSS 攻击通常指的是通过利用网站没有对用户提交数据进行转义过滤就直接输出在页面上的漏洞进行的攻击。XSS 攻击的危害是非常严重的，它不仅能够破坏网站的正常功能，还可能窃取用户的各种信息。

XSS的分类

  • 反射型 XSS
    反射型XSS只是简单地把用户输入的数据“反射”给浏览器。也就是说，黑客往往需要诱使用户“点击”一个恶意链接，才能攻击成功。通常反射型XSS的恶意代码存在URL里，通过URL传递参数的功能，如网站搜索、跳转等。由于需要用户主动打开恶意的URL才能生效，攻击者往往会结合多种手段诱导用户点击。
  • 存储型 XSS
    存储型 XSS 会把用户输入的数据“存储”在服务器端。比较常见的一个场景就是，黑客写下一篇包含有恶意 JavaScript 代码的博客文章，文章发表后，所有访问该博客文章的用户，都会在他们的浏览器中执行这段恶意的 JavaScript 代码。
  • 基于DOM的 XSS

XSS攻击防御

  • HttpOnly
    浏览器将禁止页面的JavaScript访问带有HttpOnly属性的Cookie。所以我们需要在http的响应头set-cookie时设置httpOnly，让浏览器知道不能通过document.cookie的方式获取到cookie内容。
  • 输入检查
    对于用户输入的内容，我们需要进行检查，对于不符合规范的内容，我们需要进行过滤。比如对于用户输入的内容，我们可以使用正则表达式进行检查，如果不符合规范，我们就不接受用户的输入。
1
2
3
4
5
6
7
8
9
const htmlEncode = function (handleString){
    return handleString
    .replace(/&/g,"&amp;")
    .replace(/</g,"&lt;")
    .replace(/>/g,"&gt;")
    .replace(/ /g,"&nbsp;")
    .replace(/'/g,"&#39;")
    .replace(/"/g,"&quot;");
}
  • 输出检查
    在变量输出到HTML页面时，可以使用编码或转义的方式来防御XSS攻击.

Websocket存在的安全问题

是什么

​ WebSocket是HTML5开始提供的一种浏览器与服务器间进行全双工通讯的网络技术。

安全问题

  • 认证
    WebSocket 协议没有规定服务器在握手阶段应该如何认证客户端身份。服务器可以采用任何 HTTP 服务器的客户端身份认证机制，如 cookie认证，HTTP 基础认证，TLS 身份认证等。在WebSocket应用认证实现上面临的安全问题和传统的Web应用认证是相同的。
  • 授权
    WebSocket协议没有指定任何授权方式，应用程序中用户资源访问等的授权策略由服务端或开发者实现。
  • 拒绝服务
    WebSocket协议没有指定任何拒绝服务的机制，应用程序中拒绝服务的策略由服务端或开发者实现。
  • 中间人攻击
    WebSocket使用HTTP或HTTPS协议进行握手请求，在使用HTTP协议的情况下，若存在中间人可以嗅探HTTP流量，那么中间人可以获取并篡改WebSocket握手请求，通过伪造客户端信息与服务器建立WebSocket连接。
  • 输入校验
    WebSocket应用程序中，服务端对客户端输入的数据没有进行校验，导致服务端应用程序存在XSS漏洞。

鉴权

Session-Cookie认证

过程

​ 服务端生成一个session，将session的id返回给客户端，客户端将session的id保存在cookie中，下次请求时，将cookie中的session的id发送给服务端，服务端根据session的id找到对应的session，从而判断用户是否登录。

优缺点

  • 优点
    1. 服务端可以控制session的有效期，可以在session过期后，强制用户重新登录。
    2. 服务端可以在session中存储用户的信息，比如用户的权限信息，从而减少服务端的查询压力。
  • 缺点
    脱离浏览器无法使用，比如原生应用

Token认证

为什么需要Token

​ 负载均衡多服务器的情况，不好确认当前用户是否登录，因为多服务器不共享 Session。这个问题也可以将 Session 存在一个服务器中来解决，但是就不能完全达到负载均衡的效果。
​ Token 和 Session-Cookie 认证方式中的 Session ID 不同，并非只是一个标识符。Token 一般会包含用户的相关信息，通过验证 Token 不仅可以完成身份校验，还可以获取预设的信息。
​ 客户端可以将 token 存放于 localStroage 等容器中。客户端每次访问都传递 token，服务端解密 token，服务端就不需要存储 Session 占用存储空间，就很好的解决负载均衡多服务器的问题了。

JWT(目前最常用的token认证方法)

​ 参见链接：https://cheyennee.cn/2021/09/10/JWT/

单点登录

​ 单点登录（Single Sign On，简称 SSO）是目前比较流行的企业业务整合的解决方案之一，它的主要思想是用户只需要登录一次，就可以访问所有相互信任的应用系统。

点击劫持

是什么

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

防御

  • X-FRAME-OPTIONS
    X-FRAME-OPTIONS 是一个 HTTP 响应头，在现代浏览器有一个很好的支持。这个 HTTP 响应头 就是为了防御用 iframe 嵌套的点击劫持攻击。
    X-FRAME-OPTIONS 有三个值可选，分别是 DENY、SAMEORIGIN、ALLOW-FROM。DENY 表示页面不允许通过 iframe 的方式展示，即便是在相同域名的页面中嵌套也不允许。SAMEORIGIN 表示页面可以在相同域名下通过 iframe 的方式展示。ALLOW-FROM 表示页面可以在指定来源的 iframe 中展示。

    1
    2
    3
    X-FRAME-OPTIONS: DENY
    X-FRAME-OPTIONS: SAMEORIGIN
    X-FRAME-OPTIONS: ALLOW-FROM https://example.com/

Cookie的Samesite Cookie属性

是什么

​ Samesite Cookie属性是为了防止CSRF攻击和用户追踪而作出的改进。Samesite Cookie属性可以让Cookie在跨站请求时不会被发送，从而可以阻止跨站请求伪造攻击（CSRF）。

三个值

  • Strict
    Strict模式下，浏览器完全禁止第三方Cookie，跨站点时，任何情况下都不会发送Cookie。这将完全阻止CSRF攻击带来的风险，但是会影响到用户的体验（比如让用户在跨站点时无法正常使用单点登录）。
  • Lax
    Lax模式是默认值，Lax模式会阻止第三方站点的Cookie发送，但是用户从外部链接导航到网站时（比如从搜索引擎结果链接访问网站）除外。这种方式可以防止CSRF攻击，同时可以保证用户的单点登录体验。
  • None
    Cookie将在所有上下文中发送，即允许跨域发送。