登陆认证&amp；权限控制（1）——从session到token认证的变迁 &amp； session的问题分析 + CSRF攻击的认识_window

最新推荐文章于 2024-07-23 17:29:37 发布

2401_84141219

最新推荐文章于 2024-07-23 17:29:37 发布

阅读量923

点赞数 26

分类专栏：程序员文章标签： csrf 前端

本文链接：https://blog.csdn.net/2401_84141219/article/details/138464195

版权

程序员专栏收录该内容

191 篇文章 1 订阅

订阅专栏

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

在这里插入图片描述

基于session认证所显露的问题

Session：每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。
应用场景：只适合于单体架构,集群/分布式架构的不合适
- Session要进行同步，比较困难（网络抖动、延迟等）；
- Cookie: 不支持跨域，无法在前后端分离项目中应用；
- 移动端(很少使用cookie)，比如微信小程序不支持cookie；
扩展性：用户认证之后，服务端做认证记录，如果认证的记录被保存在内存的话，这意味着用户下次请求还必须要请求在这台服务器上，这样才能拿到授权的资源，这样在分布式的应用上，响应的限制了负载均衡器的能力，也意味着限制了应用的扩展性。

在这里插入图片描述

认识跨站请求伪造（CSRF，Cross-site request forgery）

CSRF基本原理、GET和POST型CSRF

跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。

CSRF原理

在这里插入图片描述

A并不知道(4)中的请求是C发出的还是B发出的，由于浏览器会自动带上用户C的Cookie，所以A会根据用户的权限处理(4)的请求，这样B就达到了模拟用户操作的目的

从上图能够看出，要完毕一次CSRF攻击，受害者必须依次完毕两个步骤：

登录受信任站点A，并在本地生成Cookie。
在不登出A的情况下，訪问危急站点B。

其他的攻击

跨站脚本攻击（Cross-site scripting，XSS）：攻击者通过在目标网站上注入恶意脚本代码，使得用户在浏览器中执行这些恶意脚本。这种攻击可以用来窃取用户的敏感信息、劫持用户会话、篡改网页内容等。
SQL注入攻击（SQL injection）：攻击者通过在用户输入的数据中注入恶意的SQL代码，从而绕过应用程序的输入验证，执行未经授权的数据库操作。这种攻击可以导致数据库信息泄露、数据损坏或者应用程序的完全控制权被攻击者获取。
会话劫持（Session hijacking）：攻击者通过窃取用户的会话标识（如Cookie），冒充合法用户的身份进行操作。这种攻击可以导致攻击者获取用户的敏感信息、执行未经授权的操作等。
点击劫持（Clickjacking）：攻击者通过在一个网页上覆盖一个透明的、欺骗性的图层，诱使用户在不知情的情况下点击了隐藏的恶意链接或按钮。这种攻击可以用来执行未经授权的操作、下载恶意软件等。
XML外部实体攻击（XML External Entity，XXE）：攻击者通过在XML解析过程中利用外部实体引用，读取敏感文件、执行远程请求等。这种攻击可以导致信息泄露、拒绝服务等问题。

GET类型的CSRF

仅仅须要一个HTTP请求。就能够构造一次简单的CSRF。

案例：

<!-- 银行站点A：它以GET请求来完毕银行转账的操作，如：-->
http://www.mybank.com/Transfer.php?toBankId=11&money=1000
<!-- 危急站点B：它里面有一段HTML的代码例如以下：-->
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先。你登录了银行站点A，然后訪问危急站点B，这时你会发现你的银行账户少了1000块

为什么会这样呢？原因是银行站点A违反了HTTP规范，使用GET请求更新资源。

在访问危急站点B的之前。你已经登录了银行站点A，而B中的一个合法的请求，但这里被不法分子利用了）。所以你的浏览器会带上你的银行站点A的Cookie发出Get请求，去获取资源以GET的方式请求第三方资源（这里的第三方就是指银行站点了，原本这是http://www.mybank.com/Transfer.php?toBankId=11&money=1000 ，结果银行站点服务器收到请求后，觉得这是一个更新资源操作（转账操作），所以就立马进行转账操作。

POST类型的CSRF

这种类型的CSRF危害没有GET型的大，利用起来通常使用的是一个自动提交的表单

案例：

<form action=http://www.mybank.com/Transfer.php method=POST>
    <input type="text" name="toBankId" value="11" />
    <input type="text" name="money" value="1000" />
</form>
<script> document.forms[0].submit(); </script>

访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。

目前主流的做法是使用Token抵御CSRF攻击。

基于token的鉴权机制

基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或会话信息。这也就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登陆了，这就为应用的扩展提供了便利。

流程

用户使用用户名密码请求服务器
服务器进行验证用户信息
服务器通过验证发送给用户一个token
客户端存储token，并在每次请求时附加这个token值
服务器验证token，并返回数据

这个token必须要在每次请求时发送给服务器，它应该保存在请求头中，另外服务器要支持CORS（跨来源资源共享）策略，一般我们在服务端这么做就可以了： Access-Control-Allow-Origin：*

（Access-Control-Allow-Origin是HTML5中定义的一种解决资源跨域的策略。他是通过服务器端返回带有Access-Control-Allow-Origin标识的Response header，用来解决资源的跨域权限问题。）

Jwt，Json web token

Jwt（Json web token）——从Http协议到session+cookie到Token & Jwt介绍 & Jwt的应用：登陆验证的流程

在这里插入图片描述

JSON Web Token（令牌）

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact压缩的 and self-contained自包含的 way for securely transmitting information安全传输 between parties as a JSON object。

This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

基于JSON格式用于网络传输的令牌。
紧凑的Claims声明格式。
Claim有索赔、声称、要求或者权利要求的含义。

在这里插入图片描述

token的颁发流程

官网：https://jwt.io/

一般用于身份验证和数据信息交换

Json web token（JWT）是为了在网络应用环境间传递声明而执行的一种基于JSON的开发标准（RFC 7519），该token（令牌）被设计为紧凑且安全的，特别适用于分布式站点的单点登陆（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

注意：secret是保存在服务器端的，jwt的签发也是在服务端的，secret就是用来进行jwt的签发和jwt的验证，所以它就是你服务端的私钥，在任何场景都不应该流露出去，一旦客户端得知这个secret，那就意味着客户端可以自我签发jwt了

流程

一种做法是放在HTTP请求的头信息字段里面，格式如下：

Token: xxxx.xxxx.xxx

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！**

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

2401_84141219

关注

26
点赞
踩
17

收藏

觉得还不错? 一键收藏
0
评论
登陆认证&amp；权限控制（1）——从session到token认证的变迁 &amp； session的问题分析 + CSRF攻击的认识_window

你已经登录了银行站点A，而B中的一个合法的请求，但这里被不法分子利用了）。扩展性：用户认证之后，服务端做认证记录，如果认证的记录被保存在内存的话，这意味着用户下次请求还必须要请求在这台服务器上，这样才能拿到授权的资源，这样在分布式的应用上，响应的限制了负载均衡器的能力，也意味着限制了应用的扩展性。Session：每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。
复制链接

扫一扫