读目录

• OAuth2 的概念
• OAuth2授权模式
• 授权码模式（Authorization Code Grant）
• 隐式授权模式（Implicit Grant）
• 密码模式（Resource Owner Password Credentials Grant）
• 客户端模式（Client Credentials Grant）
• OAuth2授权模式的选型
• 后记

OAuth2 的概念

OAuth是一个关于授权的开放网络标准，OAuth2是其2.0版本。

它规定了四种操作流程（授权模式）来确保安全

应用场景有第三方应用的接入、微服务鉴权互信、接入第三方平台、第一方密码登录等

Java王国中Spring Security也对OAuth2标准进行了实现。

OAuth2授权模式

OAuth2定义了四种授权模式（授权流程）来对资源的访问进行控制

• 授权码模式（Authorization Code Grant）
• 隐式授权模式（Implicit Grant）
• 用户名密码模式（Resource Owner Password Credentials Grant）
• 客户端模式（Client Credentials Grant）

无论哪个模式（流程）都拥有三个必要角色：客户端、授权服务器、资源服务器，有的还有用户（资源拥有者），下面简单介绍下授权流程

授权码模式（Authorization Code Grant）

授权码模式是OAuth2目前最安全最复杂的授权流程，先放一张图，稍做解释

如上图，我们可以看到此流程可大致分为三大部分

• Client Side：用户+客户端与授权服务器的交互
• Server Side：客户端与授权服务器之间的交互
• Check Access Token：客户端与资源服务器之间的交互 + 资源服务器与授权服务器之间的交互

整体上来说，可以用一句话概括授权码模式授权流程

客户端换取授权码，客户端使用授权码换token，客户端使用token访问资源

接下来对这三部分进行一些说明 ：

前提条件：

• 第三方客户端需要提前与资源拥有方（同时也是授权所有方）协商客户端id（client_id），客户端密钥（client_secret）
• 文中暂时未将scope、state等依赖具体框架的内容写进来，这里可以参考Spring Security OAuth2的实现

Client Side

客户端换取授权码

这个客户端可以是浏览器，

1. 客户端将client_id + client_secret + 授权模式标识(grant_type) + 回调地址(redirect_uri)拼成url访问授权服务器授权端点
2. 授权服务器返回登录界面，要求用户登录（此时用户提交的密码等直接发到授权服务器，进行校验）
3. 授权服务器返回授权审批界面，用户授权完成
4. 授权服务器返回授权码到回调地址

Server Side

客户端使用授权码换token

1. 客户端接收到授权码，并使用授权码 + client_id + client_secret访问授权服务器颁发token端点
2. 授权服务器校验通过，颁发token返回给客户端
3. 客户端保存token到存储器（推荐cookie）

Check Access Token

客户端使用token访问资源

1. 客户端在请求头中添加token，访问资源服务器
2. 资源服务器收到请求，先调用校验token的方法（可以是远程调用授权服务器校验端点，也可以直接访问授权存储器手动校对）
3. 资源服务器校验成功，返回资源

这里的说明省去了一些参数，如scope(请求token的作用域)、state(用于保证请求不被CSRF)、redirect_uri(授权服务器回调uri)，先理解概念，实现的时候再去要求

隐式授权模式（Implicit Grant）

隐式授权模式大致可分为两部分：

• Client Side：用户+客户端与授权服务器的交互
• Check Access Token：客户端与资源服务器之间的交互 + 资源服务器与授权服务器之间的交互

用一句话概括隐式授权模式授权流程

客户端让用户登录授权服务器换token，客户端使用token访问资源

Client Side

客户端让用户登录授权服务器换token

1. 客户端（浏览器或单页应用）将client_id + 授权模式标识(grant_type)+ 回调地址(redirect_uri)拼成url访问授权服务器授权端点
2. 授权服务器跳转用户登录界面，用户登录
3. 用户授权
4. 授权服务器访问回调地址返回token给客户端

Check Access Token

客户端使用token访问资源

1. 客户端在请求头中添加token，访问资源服务器
2. 资源服务器收到请求，先调用校验token的方法（可以是远程调用授权服务器校验端点，也可以直接访问授权存储器手动校对）
3. 资源服务器校验成功，返回资源

密码模式（Resource Owner Password Credentials Grant）

密码模式大体上也分为两部分：

• Client Side: 用户与客户端交互，客户端与授权服务器交互
• Check Access Token:客户端与资源服务器之间的交互 + 资源服务器与授权服务器之间的交互

一句话概括用户名密码模式流程：

用户在客户端提交账号密码换token，客户端使用token访问资源

Client Side

用户在客户端提交账号密码换token

1. 客户端要求用户登录
2. 用户输入密码，客户端将表单中添加客户端的client_id + client_secret发送给授权服务器颁发token端点
3. 授权服务器校验用户名、用户密码、client_id、client_secret，均通过返回token到客户端
4. 客户端保存token

Check Access Token

客户端使用token访问资源

1. 客户端在请求头中添加token，访问资源服务器
2. 资源服务器收到请求，先调用校验token的方法（可以是远程调用授权服务器校验端点，也可以直接访问授权存储器手动校对）
3. 资源服务器校验成功，返回资源

客户端模式（Client Credentials Grant）

客户端模式大体上分为两部分：

• Server Side: 客户端与授权服务器之间的交互
• Check Access Token: 客户端与资源服务器，资源服务器与授权服务器之间的交互

一句话概括客户端模式授权流程：

客户端使用自己的标识换token，客户端使用token访问资源

Server Side

客户端使用自己的标识换token

1. 客户端使用client_id + client_secret + 授权模式标识访问授权服务器的颁发token端点
2. 授权服务器校验通过返回token给客户端
3. 客户端保存token

Check Access Token

客户端使用token访问资源

1. 客户端在请求头中添加token，访问资源服务器
2. 资源服务器收到请求，先调用校验token的方法（可以是远程调用授权服务器校验端点，也可以直接访问授权存储器手动校对）
3. 资源服务器校验成功，返回资源

OAuth2授权模式的选型

考虑到授权场景的多样性，可以参考以下两种选型方式

1.按授权需要的多端情况

2.按客户端类型与所有者

后记

学习OAuth2有一段时间了，把学到的知识分享出来，行文中难免有错误，如果发现还请留言指正，谢谢！

Java知音，专注于Java实用文章推送，不容错过！

来源：cnblogs.com/hellxz/p/oauth2_process.html

icrosoft Outlook 可变成 C2 信标来远程执行代码，网络安全公司 TrustedSec 本周发布的全新红队后利用框架“Specula”就证明了这一点。

该 C2 框架通过利用 CVE-2017-11774（2017 年 10 月修补的 Outlook 安全功能绕过漏洞）使用 WebView 创建自定义 Outlook 主页。

微软表示：“在文件共享攻击场景中，攻击者可以提供专门为利用该漏洞而设计的文档文件，然后诱使用户打开该文档文件并与文档进行交互。”

然而，即使微软修补了该漏洞并删除了显示 Outlook 主页的用户界面，攻击者仍然可以使用 Windows 注册表值创建恶意主页，即使在安装了最新 Office 365 版本的系统上也是如此。

正如 Trusted 所解释的那样，Specula 纯粹在 Outlook 环境中运行，其工作原理是通过调用交互式 Python Web 服务器的注册表项设置自定义 Outlook 主页。

为此，非特权威胁者可以在 HKEY_CURRENT_USER\Software\Microsoft\Office.0\Outlook\WebView\ 下的 Outlook WebView 注册表项中将 URL 目标设置为他们控制的外部网站。

Outlook Specula 注册表值

攻击者控制的 Outlook 主页旨在提供自定义 VBscript 文件，攻击者可使用该文件在受感染的 Windows 系统上执行任意命令。

TrustedSec 表示：“尽管目前已有相关知识和预防措施，但 TrustedSec 仍能够利用这一特定渠道对数百个客户端进行初始访问。当通过 Microsoft 在其解决方法中列出的任何注册表项设置自定义主页时，Outlook 将在选择相关选项卡时下载并显示该 HTML 页面，而不是显示正常的邮箱元素（收件箱、日历、已发送等）。

从下载的 HTML 页面，可以在特权上下文中运行 vbscript 或 jscript，或多或少可以完全访问本地系统，就像运行 cscript / wscript.exe 一样。

虽然首先需要入侵设备才能配置 Outlook 注册表项，但一旦配置完成，攻击者就可以使用此技术实现持久性并横向传播到其他系统。

由于 outlook.exe 是一个受信任的进程，因此攻击者在执行命令时可以更轻松地逃避现有软件。

正如美国网络司令部（US CyberCom）五年前警告的那样，CVE-2017-11774 Outlook 漏洞也被用来攻击美国政府机构。

Chronicle、FireEye 和 Palo Alto Networks 的安全研究人员后来将这些攻击与伊朗支持的 APT33 网络间谍组织联系起来。

FireEye 网络安全研究人员表示，FireEye 于 2018 年 6 月首次观察到 APT34 使用 CVE-2017-11774，随后 APT33 从 2018 年 7 月开始采用该漏洞进行范围更广的攻击活动，并持续了至少一年。

、为什么用命令行模式

使用GUI方式启动jmeter，运行线程较多的测试时，会造成内存和CPU的大量消耗，导致客户机卡死；

所以一般采用的方式是在GUI模式下调整测试脚本，再用命令行模式执行；

命令行方式支持在多个环境下使用，windosw的dos环境下，也可以在linux环境上执行。

注意：使用命令执行jmeter脚本必须使用jmeter 3.0及以上版本。

2、怎么用

2.1、执行命令

jmeter -n -t <testplan filename> -l <listener filename>

示例： jmeter -n -t testplan.jmx -l test.jtl

示例含义：表示以命令行模式运行testplan.jmx文件，输出的日志文件为test.jtl

2.2、参数介绍

Jmeter官方手册给的介绍如下：

-h, –help -> prints usage information and exit
-n, –nongui -> run JMeter in nongui mode
-t, –testfile <argument> -> the jmeter test(.jmx) file to run
-l, –logfile <argument> -> the file to log samples to
-r, –runremote -> Start remote servers (as defined in remote_hosts)
-H, –proxyHost <argument> -> Set a proxy server for JMeter to use
-P, –proxyPort <argument> -> Set proxy server port for JMeter to use

中文释义：

-h 帮助 -> 打印出有用的信息并退出

-n 非 GUI 模式 -> 在非 GUI 模式下运行 JMeter

-t 测试文件 -> 要运行的 JMeter 测试脚本文件

-l 日志文件 -> 记录结果的文件

-R 远程执行 -> 远程执行机的IP（ip地址）如果有多个ip时，使用-R 192.168.2.170，192.168.2.171（分布式使用）

-r 远程执行 -> 在Jmter.properties文件中指定的所有远程服务器（分布式使用）

-H 代理主机 -> 设置 JMeter 使用的代理主机

-P 代理端口 -> 设置 JMeter 使用的代理主机的端口号

2.3、执行过程

命令：jmeter -n -t C:\Users\yzs\Desktop\Unione_performance.jmx -l report-result.jtl

不在jmeter安卓目录执行脚本的前提是配置了jmeter的环境变量。

2.4、报告查看

上述的命令有测试结果保存到D:\report中，在GUI模式下查看测试报告：

1、在测试计划下，添加对应的测试报告元件，举例增加了：查看结果树、聚合报告

2、在“所有数据写入一个文件”，选择加载对应的结果文件

3、下面就会有对应的表格展示，具体见下图

2.5、命令行传递变量值

设置线程组的线程数和循环次数。

注意格式：

${__P(threadNum)}

${__P(threadCount)}

其中P前面是两个下划线，()内就是变量名

执行时，在命令行中用-J参数给变量赋值即可：

jmeter -n -t C:\Users\yzs\Desktop\Unione_performance.jmx -J threadNum=10 -J threadCount=2 -l report-result.jtl

此次测试相当于：10个线程，循环2次，共计20个请求。

3、生成HTML报告

生成HTML报告有2种方式，一种是直接在命令行加上-o参数，另一种是已有jtl结果文件，运行命令生成报告

3.1、命令行直接生成报告

jmeter -n -t 【Jmx脚本位置】-l 【中间文件result.jtl位置】-e -o 【报告指定文件夹】

-e：测试结束后，生成测试报告
-o：指定测试报告的存放位置

注意：-o后面跟的文件夹一定是不存在的或者是空文件夹

3.2、已有jtl结果文件，运行命令生成报告

jmeter -g【已经存在的.jtl文件的路径】-o 【用于存放html报告的目录】

注意：经实操，windows系统上，以上2种方法都可以生成HTML测试报告，但是在Linux系统上第1种方法，没有生成报告，只有第二种方法才可以（具体原因后面在慢慢找吧）

3.3、HTML报告注解

用浏览器打开index.html

报告详解

Dashboard：（重点查看）
Test and Report informations：指的是测试和报告信息

• File：测试结果的保存文件名称
• Start Time：测试开始时间
• End Time：测试结束时间
• Filter for display展示过滤器

APDEX(Application Performance Index)：应用程序性能满意度的标准

其中，

• “Apdex”范围在0-1之间，1表示达到所有用户均满意，越接近1满意度越高
• “toleration threshold”：耐受阈值（0.5秒）
• “frustration threshold”：挫败阈值（1.5秒）

Requests Summary：请求的通过率(OK)与失败率(KO)，百分比显示

Statistics：数据分析，基本将Summary Report和Aggrerate Report的结果合并（平均响应时间、TPS在此查看）

Errors：错误情况，依据不同的错误类型，将所有错误结果展示

关于Apdex的补充：

性能指数，Apdex(Application Performance Index)是一个国际通用标准，Apdex 是用户对应用性能满意度的量化值。它提供了一个统一的测量和报告用户体验的方法，把最终用户的体验和应用性能作为一个完整的指标进行统一度量。下图表示为通用用户满意度区域，0代表没有满意用户，1则代表所有用户都满意。实际业务系统开发过程中，1是团队的追求目标。

若所有请求的Apdex值都接近1，说明用户满意度优秀，也从侧面说明了服务器响应速度快。
通常而言，最低要求超过0.5，当然项目组可设定具体需求。

Charts：（辅助分析）

主要有如下特点：
（1）将测试过程中经常使用的数据，用图表的形式展示，让测试结果更加直观
（2）每个图表数据，有两种展示形式
（3）支持请求样例过滤显示
（4）支持导出PNG图片格式

Over Time Charts：

• Response Times Over Time：每秒钟响应时间，X轴表示的是系统运行的时刻，Y轴表示的是响应时间，F(X,Y)表示系统随着时间的推移，系统的响应时间的变化，可以看出响应时间稳定性
• Bytes Throughput Over Time：字节接收与发送的数量，每秒传输字节吞吐量，表明Jmeter在测试时，随着时间推移发送和接收的字节数
• Latencies Over Time：延迟时间

Throughput Charts：

• Hits Per Second： 每秒点击率
• Codes Per Second：每秒状态码数量
• Transactions Per Second：每秒事务量
• Response Time Vs Request：响应时间点请求的成功与失败数
• Latency Vs Request：延迟时间点请求的成功与失败数

Response Times Charts：

• Response Time Percentiles：响应时间百分比
• Active Threads Over Time：激活线程数
• Time Vs Threads：响应时间用户数， X轴表示的是活动线程数，也就是并发访问的用户数，Y轴表示的是响应时间，F(X,Y)表示在某种并发量的情况下，系统的响应时间是多少
• Response Time Distribution：响应时间分布

3.4、HTML报告的自定义配置

JMeter3.0开始在bin目录新增了reportgenerator.properties文件保存了所有关于图形化HTML报告生成模块的默认配置，要变更配置，建议不要直接编辑该文件，而是推荐在user.properties中去配置和覆盖。

3.4.1总体配置

总体配置都是以jmeter.reportgenerator.为前缀，如：jmeter.reportgenerator.overall_granularity=60000

• overall_granularity：定义采样点粒度，默认为60000ms，通常在稳定性以外的测试中，我们可能需要定义更细的粒度，比如1000ms，我们可以在user.properties文件末尾添加如下配置

# Change this parameter if you want to change the granularity of over time graphs.
jmeter.reportgenerator.overall_granularity=6000

• report_title:定义报告的标题，我们可能需要将标题定义为实际测试项名称
• apdex_satisfied_threshold：定义Apdex评估中满意的阈值(单位ms)
• apdex_tolerated_threshold: 定义Apdex评估中可容忍的阈值

Apdext=(Satisfied Count + Tolerating Count / 2) / Total Samples

另外，在jmeter.properties中，有关于集合报告中的三个百分位的默认值：

aggregate_rpt_pct1 : Defaults to 50
aggregate_rpt_pct2 : Defaults to 70
aggregate_rpt_pct3 : Defaults to 99

3.5、HTML报告的定制

JMeter的HTML报告生成时是使用了固定的模板，模板文件路径为./bin/report-template。
进入该目录可以看到报告的每个页面都有一个.fmkr模板文件，包括index.html.fmkr和./content/pages路径下的几个文件。通过查看这些模板文件，就可以知道怎样去进行报告的轻度定制，比如将一些文本修改得更易懂，或者修改为中文等

页面的title
默认为"Apache JMeter Dashboard"
可以由reportgenerator.properties中的jmeter.reportgenerator.report_title来统一定义，这种方式就是所有页面的title都使用同一个。
也可以直接修改对应的.fmkr文件中的title标签中双引号内的值，如<title>${reportTitle!"想要设置的title"}</title>，这中方式可以为每个页面单独定义title
图表的名称
当前版本下，各图表的名称是直接在模板文件中定义，要修改也是直接修改模板文件中对应元素的值即可
如要修改Transactions Per Second图表的名称，可以直接在./content/pages/Throughput.html.fmkr文件中修改，效果如下图