A1 失效的访问控制

概述

访问控制：访问控制实施策略以防止用户超出其指定权限范围进行操作。

失效的访问控制，也叫越权，攻击者通过各种手段提升自己的权限，越过访问控制，使访问控制失效，这样攻击者就可以冒充用户、管理员或拥有特权的用户，或者创建、访问、更新或删除任何记录。（也就是说由于访问漏洞，未经身份验证或不受欢迎的用户可能会访问机密数据和进程以及用户权限设置）

常见的访问漏洞包括：

1.通过修改 URL、内部应用程序状态或 HTML 页面，或仅使用自定义 API （接口）攻击工具来绕过访问控制检查。

2.允许将主键更改为其他用户的记录，允许查看或编辑其他人的帐户。

3.特权提升，在未登录的情况下充当用户或以用户身份登录时充当管理员。

4.元数据操作，例如重放或篡改 JSON Web 令牌 (JWT) 访问控制令牌，或用于提升权限或滥用 JWT 失效的 cookie 或隐藏字段。

5.CORS （跨域资源共享）错误配置允许未经授权的 API 访问。

6.强制以未经身份验证的用户身份浏览经过身份验证的页面或以标准用户身份浏览特权页面。访问 API 时缺少对 POST、PUT 和 DELETE 的访问控制。

分类

垂直提权：普通用户有了更高一级用户的权限（测试思路：主要通过看看能否通过A用户操作影响到B用户）

水平提权：普通用户a有了普通用户b的权限（测试思路：看看低权限用户是否能越权使用高权限用户的功能，比如普通用户可以使用管理员的功能。）

防御

访问控制仅在受信任的服务器端代码或无服务器 API 中有效，攻击者无法修改访问控制检查或元数据。

1.除公共资源外，默认拒绝。

2.实施一次访问控制机制并在整个应用程序中重复使用它们，包括最大限度地减少 CORS 的使用。

3.模型访问控制应该强制记录所有权，而不是接受用户可以创建、读取、更新或删除任何记录。

4.独特的应用程序业务限制要求应由领域模型强制执行。

5.禁用 Web 服务器目录列表并确保文件元数据（例如 .git）和备份文件不在 Web 根目录中。

6.记录访问控制失败，在适当时提醒管理员（例如，重复失败）。

7.速率限制 API 和控制器访问，以最大限度地减少自动攻击工具的危害。

8.注销后，JWT 令牌应在服务器上失效。

攻击方式

        没有检查身份，直接导致攻击者绕过权限直接访问

漏洞原因

        在未对通过身份验证的用户，实施恰当的访问控制。攻击者可以利用这一漏洞，访问未经授权的功能或数据。

特有名词解释

元数据

被定义为描述数据及其环境的数据，主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能，简而言之就是数据的数据，并且以二进制形式存在

cors(跨域资源共享):

是一种基于 HTTP 头的机制，该机制通过允许服务器标示除了它自己以外的其他源（域、协议或端口），使得浏览器允许这些源访问加载自己的资源。跨源资源共享还通过一种机制来检查服务器是否会允许要发送的真实请求，该机制通过浏览器发起一个到服务器托管的跨源资源的“预检”请求。在预检中，浏览器发送的头中标示有 HTTP 方法和真实请求中会用到的头。(简言之:就是a网站的一些信息可以被b网站访问，但是b网站需要用到js代码（XMLHttpRequest）来描述它想访问到a网站)

分为两种请求：简单请求和非简单请求

1. 简单请求：
   1. 一、请求方法为一下三种中的一种：

　　 １.HEAD

　　 2. POST

　　 3.GET

• 1. 二、HTTP头信息不超过以下几种字段：

　　 1.Accept

　　 2.Accept-Language

　　 3.Content-Language

　　 4.Last-Event-ID

　　 5.Content-Type只限于这三个：application/x-www-form-urlencoded、multipart/form-data、text/plain

• 1. 例题：比如说，假如站点 https://foo.example 的网页应用想要访问 https://bar.other 的资源。foo.example 的网页中可能包含类似于下面的 JavaScript 代码：

const xhr = new XMLHttpRequest();

const url = 'https://bar.other/resources/public-data/';

xhr.open('GET', url);

xhr.onreadystatechange = someHandler;

xhr.send();

浏览器发送给服务器的请求报文：

GET /resources/public-data/ HTTP/1.1

Host: bar.other

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Connection: keep-alive

Origin: https://foo.example

本例中，服务端返回的 Access-Control-Allow-Origin 标头的 Access-Control-Allow-Origin: * 值表明，该资源可以被任意外源访问。

1. 非简单请求：非简单请求是指一些特殊的请求，比如PUT，DELETE这种，浏览器检测到此次请求为非简单请求，则会先发送一次“预检”请求，类型为OPTIONS，向服务器查询是否支持此次请求的源，以及支持哪些方式和头信息字段
   1. 预检："预检"请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。

除了Origin字段，"预检"请求的头信息包括两个特殊字段。

（1）Access-Control-Request-Method

该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法，上例是PUT。

（2）Access-Control-Request-Headers

该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，上例是axios-header,content-type

• 1. 下图请求代码

const xhr = new XMLHttpRequest(); xhr.open('POST', 'https://bar.other/resources/post-here/'); xhr.setRequestHeader('X-PINGOTHER', 'pingpong'); xhr.setRequestHeader('Content-Type', 'application/xml'); xhr.onreadystatechange = handler; xhr.send('<person><name>Arun</name></person>');

如果 https://bar.other 的资源持有者想限制他的资源只能通过 https://foo.example 来访问（也就是说，非 https://foo.example 域无法通过跨源访问访问到该资源）,就有了下图的Access-Control-Allow-Origin: https://foo.example

浏览器和服务器首次交互：

OPTIONS /doc HTTP/1.1

Host: bar.other

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Connection: keep-alive

Origin: https://foo.example

Access-Control-Request-Method: POST //比简单请求多出来的 部分

Access-Control-Request-Headers: X-PINGOTHER, Content-Type //比简单请求多出来的 部分

HTTP/1.1 204 No Content

Date: Mon, 01 Dec 2008 01:15:39 GMT

Server: Apache/2

Access-Control-Allow-Origin: https://foo.example

Access-Control-Allow-Methods: POST, GET, OPTIONS

Access-Control-Allow-Headers: X-PINGOTHER, Content-Type

Access-Control-Max-Age: 86400

Vary: Accept-Encoding, Origin

Keep-Alive: timeout=2, max=100

Connection: Keep-Alive

• 1. 对比简单请求和非简单请求就是：先判断浏览器请求方式，如果是前者那么Access-Control-Allow-Origin可以是任意值（*），如果是后者则要先利用options预检，并且Access-Control-Allow-Origin只能是a网站持有者指定的网站来访问
• 参考链接：跨源资源共享（CORS） - HTTP | MDN；跨域资源共享CORS详解 - 简书

JWT令牌

1. 什么是JWT：JWT简称JSON、Web、Token，也就是通过JSON形式作为web与应用中的令牌，用于在各方之间安全地将信息作为JSON对象传输。在数据传输过程中还可以完成数据加密、签名等相关处理。
2. JWT的作用：
   1. 授权： 用户的授权，一旦用户登录后获得了token，后续一些需要用户权限的请求就不会拒绝请求
   2. 信息交互： JSON Web Token是在各方之间安全传输信息的好方法。因为可以对JWT进行签名（例如：使用公钥/私钥对），所以可以确保发送方信息，由于签名是使用标头和有效负载计算的，因此可以验证内容是否遭到篡改。保证信息的完整性。
3. JWT和传统session的比较
   1. 传统session
      1. http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，下一次请求时，用户还要再一次进行用户认证才行。在第一次请求后服务器会创建一个会话即session，为了下一次能够识别到是哪个用户发出的请求，只能在服务器存储一份用户登录信息，这份登录信息会在响应时传给浏览器，即为一个sessionid存储在cookie中，这就是传统的基于session认证。
      2. 流程：

• • 1. 问题：

每个用户认证一次就要记录一个sessionid，都保存在内存中，服务器的开销很大，且断电就丢失。

session只存储在本服务器的内存中，在分布式应用场景中是非常不方便的，分布式通常是几个服务之间的调用，使用session认证就相应的限制了负载均衡的能力。

因为是基于cookie来进行用户的识别，cookie如果被截获，服务器就很容易受到跨站请求伪造的攻击。

前后端分离系统中更加的痛苦，sessionid1还只是一个特征值，表达的信息不够丰富。在后端应用是多节点部署场景中，就要实现session的共享机制，不太方便。也不方便集群应用

• 1. JWT
     1. 用户进行认证，向服务器发送请求，服务器响应请求并进行认证，认证通过后生成JWT即token，响应给前端；后面的每次请求都携带JWT，服务器拦截请求验证token的有效性，正确的token执行业务逻辑响应数据，错误的token返回错误信息给前端，前端展示相应的的信息
     2. 流程：

• • 1. 优点：

简洁： 数据量小，传输熟读快。

自包含： 负载中包含了所有用户所需要的信息，避免多次查询数据库。

Token是以JSON加密形式保存在客户端的，所以Jwt是跨语言的。

特别适用于分布式微服务

1. 总结：session更加繁琐，占用空间断电即丢失，每次的session都都需要认证，而且容易CRSF攻击（利用被截获的cookie）；而JWT相对简单，认证通过后给一个JWT令牌，每次请求都要带上JWT，然后对其token进行正误判断即可
2. 参考链接：JWT令牌_Qiumin~的博客-CSDN博客