会话与认证介绍以及相关漏洞案例分析

很开心能在这边跟大家分享有关于会话跟认证相关的内容以及跟认证相关的漏洞案例分析，在这个过程中过大家有什么疑惑或者有什么我讲得不对的地方，欢迎大家及时提出，我们一起交流探讨，共同学习！ 

今天的主要内容：

一.介绍什么是认证

二.介绍什么是会话

三.跟认证相关的一些安全漏洞案例分享

 

一.什么是认证？为什么需要认证？后端服务器是怎么认证的？(不会直接讲概念，而是通过案例图片跟说明，让大家体会什么是认证)

1.首先，如果是一些可以公开访问的页面，那么此时是不需要认证的，比如我请求访问淘宝网首页，进去之后，可以随意浏览商品信息同时不需要登录(登录就是认证的一种具体方式)

 

 

 

因为访问公开资源不会涉及网站安全问题跟用户安全问题，因此不需要认证机制就能访问。

 

2.这时候，当我去点击页面里的【购物车】按钮要去访问购物车信息时，就会弹出登录页面，要求我们进行认证。因为如果此时不进行认证的话，服务器并不知道此时操作的"我"是哪个用户(网站平台有很多个用户)，它就不知道要返回哪个用户的购物车信息给我。这就是为什么需要认证的原因，当然进行认证的话，也是为了网站的安全跟保证用户的安全(包括隐私安全)。

 

 

 

3.通过以上信息的了解，我们也容易知道，其实平常我们进行:输入账号和密码进行登录的这类操作，就是一种网站的认证机制。由于HTTP协议的无状态特性，所以通过认证，服务器才能知道我们是谁。

 

 

二.什么是会话？为什么需要会话？

1.前置知识：浏览器跟远程服务器的交互，是通过HTTP协议进行的。(某个计网协议就是规定两台计算机的进程之间进行"通信交流"的具体方式)

并且HTTP协议是【无状态】的：所谓无状态，就是在每次浏览器跟服务器的交互中，它只是纯粹地负责接收请求并响应请求，服务器不会在意本次请求是从"哪个浏览器"发给它的，更不会去记忆同一个浏览器跟它进行多次交互中产生的额外的数据信息。正是因为HTTP协议的无状态性，它割舍了很多的功能特性，只保留了最原生的接收请求并响应请求功能，因此通过这个协议，可以使得两台计算之间的通信都会变得快速高效。

 

 

2.假设我们重新回到上面的那个购物车场景：我们访问了淘宝网首页，点击购物车后，页面提示我们进行登录认证，这时候我们输入了账号密码并登录成功。

 

 

这时候可以看到，正是通过认证之后，服务器才知道我们"是谁"，是哪个用户，所以可以把当前我这个用户的各种信息读取出来，比如购物车有84个商品。

现在问题来了，HTTP协议是无状态的，假设我们现在网站只有认证这个机制存在，那么当我们点击【立即购买】或者【加入购物车】按钮后，会发生什么呢？(大家稍微思考一下......)

 

 

 

.......(若干秒后.....)

 

 

 

 

--又会出现之前的老毛病，服务器很健忘，它马上忘记了此时的用户是谁，因此不管是加入购物车还是立即购买，它不知道到底是谁要把商品加入购物车，不知道此时要立即购买的是哪个用户，如果不知道是哪个用户，那么就不知道要往哪个用户的购物车塞东西或者扣他的钱下单购买商品。

 

这时候，我们该怎么办呢？再次进行认证就可以了。但是这样的话，会非常麻烦，每次我点一下按钮，点一下功能，就得认证一次，这是无法忍受的。

因此我们需要一种机制，能够帮助服务器"记忆"此次登录的用户是谁，这样就能避免上面的重复认证问题了。这就是会话机制的由来：通过额外的一些数据存储手段，来帮助服务器"记忆"到它的请求，是否是属于之前某个已经有认证过的浏览器。

 

具体做法：比如Cookie技术，Session技术，JWT等，大家可以自行了解。

然后我们可以大概可以看一下JWT的做法，有个大概的印象即可：

 

 

  

三.跟认证相关的一些安全漏洞案例分享

通过这些攻防案例的分享，让我们初步对认证相关的漏洞有比较形象具体的了解跟认识。

1.认证机制 - 验证码相关 - 验证码识别率 - 漏洞案例攻防分析

背景介绍：

1)在登录认证中，我们除了有账号跟密码外，还会使用验证码。使用验证码的目的是为了【阻止】攻击者使用一些自行开发的【自动登录工具】连续尝试登录，从而降低被暴力破解的可能。如果没有验证码，那么攻击者可能通过不断暴力破解的方式去登录我们的网站。

2)有了验证码之后，可以一定程度上解决上面的问题。但是道高一尺，魔高一丈。我们有了验证码机制，黑客们又会想办法来攻克我们的验证码，

比如如果是图片验证码的话，那么攻击者也可以开发出验证码识别工具，因此为了安全，我们必须保证我们的验证码识别率足够低，才能防止被工具破解。

这里就有一条白金测试用例，是为了测试验证码的【识别率】的。

测试步骤如下：

1)使用最新版本的"验证码识别"工具来测试我们网站验证码识别的成功率，

2)通过Burp Suite 抓取验证码的URL，

3)至少要进行100次以上的识别

测试结果：验证码识别正确率低于5%才算安全。(验证码自负全部被识别出来算一次成功)

 

注：这边列出操作步骤，大家有时间也都可以去自行尝试验证，这样才会更深刻。现在只是列出步骤，大家可以脑补一下，这样对【会话认证】以及【会话认证相关的漏洞案例】，大家也会有一定的理解吧。

 

2.认证机制 - 验证码相关 - 验证码在一次使用后要求立即失效，新的请求需要重新生成验证码

这个应该也是很好理解的，

具体用例的操作步骤如下：

1)访问带有验证码的登录页面

2)开启 Burp Suite，配置对GET, POST 和 PUT请求进行拦截，并在浏览器中配置代码服务器IP为127.0.0.1, 端口为8080

3)填入错误的用户名和密码，同时填入正确的验证码，提交表单

4)在 Burp Suite 的proxy -> HTTP history 的tab页中选择刚提交的登录报文，放到repeater中

5)将报文中的用户名和密码改为正确的用户名和密码，验证码不变

6)点击"go"按钮，对报文进行重放

 

测试结果：检查响应信息是否包含"验证码错误"(或类似)的提示。

对这里的细节说明(问题根源)：进行验证码校验后，需要立即将会话中的验证码信息清空，而不是等到生成新的验证码再去覆盖旧的验证码，这就防止了验证码多次有效。

 

这是以上两个跟验证码相关的比较容易理解的案例，刚开始用这种比较容易理解的案例，我觉得可以让我们从整体上能理解会话认证以及相关漏洞的一些攻防手段和发现这些漏洞手段的一些基本思路。

 

3.认证机制 - 对敏感信息的访问需要有安全认证机制

说明：比如我们最开头说的那个购物车的例子，购物车信息应该是用户的私有信息，要访问的话至少需要先登录认证。

 

4.认证机制 - 删除认证表单http请求中的【记录用户登录次数】的字段后，可绕过登录限制进行正常登录

一些应用系统在认证的http请求中添加了【记录用户登录次数】的字段，以防止暴力破解，但是该字段如果没有在服务器端维护的话，而是在用户提交的http请求中携带，那么这时候通过拦截工具将该字段删除或者修改成其他数值，那么就有机会绕过登录限制。

 

操作步骤如下：

1)已知该系统的一个账号及密码

2)配置完成web代理工具，然后打开登录界面，输入账号和密码以及验证码，并提交登录

3)使用web代理工具拦截登录消息，这时候我们可以查看报文，如果存在【记录登录次数】的字段，那么将该字段删除之后或者修改成其他数值，之后提交请求

4)观察服务端响应，如果系统没有这个漏洞的话，那么服务端的响应应该是返回类似"系统无法正常登录"的字样，否则我们就成功绕过了登录限制。

 

5.认证绕过 - 通过URL参数进行认证模式绕过测试

操作步骤：

1)使用未知系统账号和密码

2)配置完成web代理工具，登录系统，进入功能页面，并复制相关的URL信息

3)退出系统后，直接提交页面请求

4)通过URL绕过，通过修改URL参数方式绕过鉴权，如 authenticated = no 等

分析：此举，其实就是通过修改URL的参数，探测是否存在一些参数控制，如果刚好命中，就能绕过认证，否则就是安全的。

 

6.认证机制 - DOS攻击【锁定】用户账户

分析：一般我们的应用都会设置这样的一个机制，就是如果在用户登录失败若干次后，就会锁定账户。如果黑客判断该系统存在这样的机制，那么如果他知道一些合法的用户名或者用户账号，那么他就可以编写工具发送大量用户名跟密码去请求登录，然后触发登录失败，通过多次发送，就会导致大量的用户被锁定而一定时间内无法登录。这个应该也是比较好理解的。

建议：用户不能一次被锁定得太久，不然就影响了整体的运转。

 

7.认证绕过 - 绕过授权

背景介绍：对于系统中的用户，为了限定让不同的用户只能访问特定的计算机资源，可以引入权限机制。

这里我们简要介绍下RABC(Role-Based Access Control ）- 基于角色的访问控制，就是给不同的角色分配不同的权限(可以访问哪些URL的哪些操作(增，删，改，查))

 

 

 

操作步骤：

1)用授权用户登录系统，记录一些通过GET方式或者POST方式发送的数据包。比如授权用户的操作后台的URL，并记录下该URL，

同时保存这些敏感操作的数据包(为了让接下去的非授权用户能发起类似的请求)

2)用非授权用户访问，重新发送上面步骤记录的GET或者POST数据包，直接访问上面那个授权用户的URL，检查访问情况。

如果结果是不能访问，那就说明系统在这块是安全的，不会出现越权的情况。