当前位置： 首页 > news >正文

网站设计文稿,网站加入视频,做网站买空间多少钱,WordPress添加进度条附#xff1a;完整笔记目录~ ps#xff1a;本人小白#xff0c;笔记均在个人理解基础上整理#xff0c;若有错误欢迎指正#xff01; 5.2 Https身份鉴权 引子#xff1a;上一篇主要对Http数据包结构、内容做了介绍#xff0c;本篇则聊聊Https、身份鉴权等技术。 …附完整笔记目录~ ps本人小白笔记均在个人理解基础上整理若有错误欢迎指正 5.2 Https身份鉴权 引子上一篇主要对Http数据包结构、内容做了介绍本篇则聊聊Https、身份鉴权等技术。 Https 概述 由于Http报文在通信链路中明文传输因此一旦报文被截获任何人都可查看更改Http报文内容。而这一行为往往会造成许多安全隐患如窃取受害者的登录凭证、使受害者访问恶意网页等。 这也是我们所常说的中间人攻击而Https则为解决该问题而出现通过TLS加密协议确保数据在传输时不会被第三方窃取且能对用户访问服务器身份进行验证。Https数据包 接下来展示通过WireShark嗅探到的Http/Https数据包。 QA Q1既然Https数据包被加密那为什么在浏览器各抓包软件中都可以获取到Https数据包的实际内容呢 A1这其实是基于TLS加密原理。简单来说通过TLS加密的报文内容无论是客户端还是服务端在获取到报文时均需先使用证书进行解密才能得到原报文内容。我们的浏览器实际上已经提前将所需证书安装好了而各抓包软件也同样内置了证书。 Q2那既然抓包软件内置了证书已经可以拦截、解密Https数据包了为什么我们本地也需要额外安装抓包软件的证书 A2是因为Https数据包由抓包软件转发给用户本地而证书不仅有解密TLS的功能也能验证用户访问的服务器是否合法。若本地不安装抓包软件证书则当Https报文由抓包软件转发给本地浏览器时由于证书校验不上浏览器会弹出安全告警且阻止解密。当然你要使用抓包软件自带浏览器则无该问题因为其浏览器已经装好了对应证书。) 身份鉴权 引子Https解决了Http报文在客户端和服务端之间安全传输的问题而客户端自身仍会产生安全问题如越权访问、敏感用户账号密码被爆破、身份被伪造等。因此产生了身份鉴权技术其目的就是为了确认用户/系统在访问某一资源时身份是否合法。下面则对常见的身份鉴权方式做一介绍。 Http基本鉴权 概述组合用户所输入的账户密码并进行base64编码。 鉴权流程 请求一个受限内容。客户端输入账户密码账户密码于前端被组合且进行base64编码。服务端收到后解码并验证账户密码是否正确。 影响 对于用户每一次访问新的受限内容时无论是否跨域都需重新输入账户密码很麻烦。对于安全测试者账户密码就相当于明文传输常规测试手法仍有效如爆破、注入等。 现如今也几乎不存在这种鉴权方式放到这了解一下就行。 Session - Cookie 概述Session - Cookie为解决用户每次访问新受限页面时需重新登录问题。 鉴权流程 请求一个受限内容客户端输入账户密码。服务端收到后基于用户输入生成Session并保存。此时在服务端响应包中响应头会存在一个Set-Cookie字段其内容则为刚刚生成Session的唯一标识Session ID。客户端收到后会将Set-Cookie的值Session ID存储于本地浏览器Cookie中。当客户端对同站不同页面内容进行访问时其请求包请求头会携带Cookie。服务端收到后只需比对保存的Session和来自客户端Cookie中的Session ID就能通过ID判断会话是否存在。若会话存在则证明客户端身份正确无需客户端反复输入账户密码。 补我们常常会发现发送给服务端的Cookie内容往往有很多因为Cookie除了含有登录凭证外还有一些个性化设置或其它要记录的数据等内容。 影响 对于服务端服务端需保存每个用户Session且Session会过期默认关闭浏览器后Session过期当然服务端也可自定义过期时间服务端需定期清理过期的Session影响服务器性能。对于安全测试者一旦用户Cookie被窃取且服务端Session并未过期。那攻击者就可以利用用户Cookie实现 用户登录、伪造用户操作等行为这也是XSS、CSRF攻击的原理。 补基于Session - Cookie实现的攻击思路往往是窃取被保存至客户端本地的Cookie但我们知道能实现身份认证的仅为Cookie中的Session ID那Session ID可不可以被破解伪造呢emmm。。。来自小白的提问 Token 概述工作机制实现功能与Session - Cookie类似不过Token往往会携带完整的用户身份认证信息。鉴权流程 请求受限内容客户端输入账户密码。服务端收到账户密码后依据后端逻辑生成加密后的Token并返回给客户端。客户端收到Token并将其保存至本地浏览器。Token除了被保存到浏览器Cookie外也可以被存储至localStorage、sessionStorage等。当客户端再次对受限内容请求时请求包会默认携带Token。服务端接收并验证Token是否有效实现身份鉴权。 影响 对于服务端由于Token内已经携带用户的完整信息相较于Session - Cookie服务端要存储每一个用户的会话Token则无需存储服务端只需接收并验证即可。节约服务端性能。对于安全测试者Token往往在生成时会设置过期时间一般过期时间较短。相较于Session - Cookie更加安全。 JWT 概述全称JSON Web Token其实从名字就可以看出JWT也是Token鉴权的一种。 鉴权流程同Token。 特征 由于JWT具有很明显的特征因此在这里额外聊一下。 JWT的组成Header . Payload . Signature头部 . 载荷 . 签名 Header 存储JWT的基本信息如Token类型、签名算法等并进行base64编码。给一个JWT的官方示例 // Header经base64编码 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 // 解码后 {alg: HS256,// jwt签名算法typ: JWT// token类型 }Payload存储JWT用户的有效信息如JWT过期时间、用户id、用户名等并进行base64编码。同样是官方示例 // Payload经base64编码 eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ // 解码后 {sub: 1234567890,name: John Doe,iat: 1516239022 } // 我们称sub、name、iat这些字段为声明 // 其中sub、iat为JWT注册声明而每一个注册声明都有其特定含义。这里对JWT注册声明进行列举 字段名含义iss签发者 (Issuer)表示 JWT 的创建者或签发服务的标识。sub主题 (Subject)表示 JWT 的主题一般是用户的唯一标识符。aud受众 (Audience)表示 JWT 的接收者通常是应用程序的标识。exp过期时间 (Expiration Time)表示 Token 的到期时间单位为秒的时间戳。nbf生效时间 (Not Before)表示 Token 的有效开始时间。在该时间之前JWT 无效。iat签发时间 (Issued At)表示 JWT 的签发时间。jtiJWT ID表示 Token 的唯一标识符常用于避免重复使用 Token防止重放攻击。Signature验证JWT完整性Signature计算方式 Header记录的加密算法(base64UrlEncode(header) . base64UrlEncode(payload),secrect// 密钥 ) // 官方示例的Signature SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c将这三部分通过 “.” 组合构成完整的JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c了解其组成后也就可以得出JWT特征eyJxxxxxx.eyJxxxxxx.signature。 影响 对于服务端同Token。对于安全测试者由于JWT前两part仅进行base64编码则一旦JWT算法密钥被获取爆破则可实现伪造JWT。 OAuth 概述OAuth作为一个授权框架允许用户在不暴露其凭证的情况下授权第三方应用访问其在另一个服务提供商上的受保护资源。简单来说使用OAuth用户就可以在不向第三方泄露自己账户密码的情况下使第三方应用实现部分资源访问。 举个栗子使用QQ登录百度执行授权操作后百度在未获取到QQ账户密码的情况下 1. 实现了登录。2. 通过获取到的QQ账户信息创建了百度账户。 授权流程 注由于OAuth2.0标准定义了四种授权方式分别为授权码、隐藏式、密码式和客户端凭证。其中授权码方式是如今被应用最多的因此本文仅介绍使用授权码方式的授权流程如果想了解其余授权方式可参考 https://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html 在OAuth授权中共有三位角色用户所属的客户端用户所访问的第三方应用第三方应用需要请求资源的服务端在该服务端中又分别存在授权服务资源服务。 当客户端访问的第三方应用想要获取服务端的资源时需先向服务端授权服务器备案并获取其给予的client_id client_secrect。 随后客户端需为第三方应用向服务端授权服务器申请授权码申请成功后服务端授权服务器将授权码转发给第三方应用。 # 授权码申请 /oauth/authorize?client_idxxxxresponse_typecodescopereadredirect_urihttp://第三方

其中reponse_type表示授权方式

scope表示授权范围

redirect_uri表示重定向地址一般为第三方应用地址# 授权码申请成功后随redircet_uri返回给第三方应用

http://第三方/callback?codeauthorationcode

其中code值为授权码第三方应用拿到授权码后再向服务端授权服务器申请Token申请成功后服务端将Token返回给第三方应用。由于Token仅在第三方应用与服务端之间传递无法被用户窃取更加安全。 # 第三方向授权服务器申请Token

/oauth/token?client_idxxxxclient_secrectxxxxgrant_typeauthoration_codecodeauthorationcoderedirect_urihttp://第三方/

其中grant_type为授权方式

code为第三方应用获取的授权码# 申请成功后授权服务器将token返回给第三方应用随后第三方应用凭借token向服务端资源服务器获取资源。 影响 对于服务端解决了服务端在访问受限资源时的身份鉴权问题。对于安全测试者针对OAuth框架的安全问题留给后面来讨论吧现在只需对其有基本认知即可。 ps其实是我没见过