前端安全系列之登录那些事

一、Cookie与Session

HTTP是无状态协议，它不对之前发生过的请求和响应的状态进行保存。因为无法管理用户状态，对于要登录的页面，每次跳转新页面时都需要再次登录。

于是引入了Cookie来管理用户状态：

① 首先客户端发起不带Cookie信息的登录请求

② 服务端接收到请求，验证用户数据正确后，添加响应头Set-Cookie

③ 客户端收到响应报文后，检查到响应头Set-Cookie，在本地保存Cookie

④ 之后每次向该域发起请求时，自动添加请求头Cookie，发送给服务端

⑤ 服务端获取请求头Cookie，根据Cookie的值，就可以判断出用户是否登录

但是Cookie极容易被篡改和伪造，于是产生了Session，Session将用户信息保存在服务端，那么Session是如何管理用户状态的呢？

① 首先客户端发起不带Cookie信息的登录请求

② 服务端接收到请求，检查到没有携带口令，验证用户密码正确后生成Session，将用户信息保存在Session，设置响应头Set-Cookie，通常是将Session ID作为口令值

③ 客户端检查到Set-Cookie响应头，在本地保存Cookie信息

④ 之后每次发起请求时，自动在请求头Cookie中携带口令，发送给服务端

⑤ 服务端获取Cookie携带的口令值，找到对应的Session，就可以判断用户状态

二、如何让Session口令值更安全

虽然口令值由服务端生成，用户不容易伪造，But nothing is impossible；而且口令值存在客户端，就有可能被盗用。一旦口令值被伪造或盗用，攻击者就可以伪装成用户访问服务端的数据。

那么如何让Session口令值更安全呢？

① 将客户端的某些独有信息+口令值作为原值，对其进行签名

② 将口令值拼接签名返回给客户端，将Cookie设置为HttpOnly（禁止用户通过脚本来获取和更改Cookie）

③ 服务端再次收到请求，取客户端信息与口令值签名，与客户端携带的签名对比，不相等，说明请求不合法

这样的话：

① 即使攻击者知道了口令值，由于不知道密钥，无法伪造签名

② 即使攻击者通过某种方式得到了真实的口令值和签名，但是由于攻击者的客户端信息不一样，发送到服务端后，会得到不一样的签名，签名校验不能通过

三、多系统的复杂性

web系统由早期的单系统发展成多系统组成的应用群，面对如此众多的系统，用户难道要一个个登录、再一个个注销吗？

系统复杂性应该由系统内部承担，而不是用户。无论web系统内部多么复杂，对用户而言，都是一个统一的整体，也就是说，用户访问web系统的整个应用群与访问单个系统一样，只要登录/注销一次就够了。

因为Cookie不允许跨域，早期多系统登录采用将Cookie种在顶级域名下的方式，来实现Cookie共享。这种方式的局限在于：

① 应用群各系统的域名得统一

② 应用群各系统的web服务端使用的技术要相同，比如Session口令值以及它的签名

方式要相同，要不Session口令值不同，无法维持会话

因此，我们需要一种全新的登录方式来实现多系统应用群的登录，这就是单点登录。

四、单点登录

单点登录全称Single Sign On（简称SSO），是指在多系统应用群中登录一个系统，便可在其它所有系统中得到授权而无需再次登录。包括单点登录与单点注销两部分：

1、单点登录

相比于单系统登录，SSO需要一个独立的认证中心，只有认证中心能接受用户的用 户名密码等安全信息，其它系统不提供登录入口，只接受认证中心的间接授权。

通常SSO认证中心验证用户数据没问题后，会创建授权Token，分发给各个子系统。子系统拿到Token，即得到了授权，可以借此创建局部会话，局部会话登录方式与单系统的登录方式相同。这个过程，也就是单点登录的原理。

例如：

 用户访问系统1，系统1发现用户未登录，跳转至SSO认证中心，并将自己的地址作为参数

 SSO认证中心发现用户未登录，将用户引导至登录页面

 用户输入用户名密码提交登录申请

 SSO认证中心校验用户信息，创建用户与SSO认证中心之间的会话，称为全局会话，同时创建授权Token

 SSO认证中心带着Token跳转回最初的请求地址（系统1）

 系统1拿到Token，去SSO认证中心校验Token是否有效

 SSO认证中心校验Token，返回有效，注册系统1

 系统1使用该Token创建与用户的会话，称为局部会话，返回受保护资源

 用户访问系统2的受保护资源

 系统2发现用户未登录，跳转至SSO认证中心，并将自己的地址作为参数

 SSO认证中心发现用户已登录，跳转回系统2的地址，并附上令牌

 系统2拿到令牌，去SSO认证中心校验令牌是否有效

 SSO认证中心校验令牌，返回有效，注册系统2

 系统2使用该令牌创建与用户的局部会话，返回受保护资源

用户登录成功之后，会与SSO认证中心及各个子系统建立会话，用户与SSO认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过SSO认证中心，全局会话与局部会话有如下约束关系：

① 局部会话存在，全局会话一定存在

② 全局会话存在，局部会话不一定存在

③ 全局会话销毁，局部会话必须销毁

2、单点注销

单点登录自然也要单点注销，在一个子系统中注销，所有子系统的会话都将被销毁。

 用户向系统1发起注销请求

 系统1根据用户与系统1建立的会话拿到Token，向SSO认证中心发起注销请求

 SSO认证中心校验Token有效，销毁全局会话，同时取出所有用此Token注册的系统地址

 SSO认证中心向所有注册系统发起注销请求

 各注册系统接收SSO认证中心的注销请求，销毁局部会话

 SSO认证中心引导用户至登录页面

五、登录安全防范

1、CSRF攻击

CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的登录凭证，绕过后台的用户验证，达到冒充用户对被攻击网站执行某项操作的目的。

一个典型的CSRF攻击有着如下的流程：

① 受害者登录网站a，并保留了登录凭证Cookie

② 攻击者引诱受害者访问网站b，它向网站a的服务器发送了一个跨站请求，该请求会默认携带网站a的Cookie

③ 网站a的服务器接收到请求后，对请求进行验证，确认是受害者的凭证，误以为是受害者自己发送的请求，以受害者的名义执行某个操作

④ 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让网站a执行了攻击者自己定义的操作

CSRF通常发生在第三方域名，由于浏览器同源策略的限制，攻击者不能获取到受害者的Cookie信息，只是冒用。针对这2点，我们可以制定相应的防护策略：

1）同源检测

服务器通过解析Origin 或Referer这两个请求头，确定请求的来源域，如果请求来自外域，直接阻止。

缺点：在部分情况下，攻击者可以隐藏甚至修改自己请求的Referer；会误伤一些正常请求，比如通过搜索结果跳转的页面请求。

2）Samesite Cookie

为了从源头上解决CSRF攻击，Google起草了一份草案来改进HTTP协议，即为响应头Set-Cookie新增Samesite属性：

Strict：任何情况下都不可能作为第三方Cookie，其它网站发起的任意请求都不会携带上该Cookie，包括搜索页面。

Lax：用户在不同网站之间通过链接跳转不受影响；但假如这个请求是从其它网站发起的请求，或者页面跳转是通过表单POST提交触发的，则Cookie也不会携带发送。

缺点：目前还并不成熟，其应用场景有待观望。

3）双重Cookie

① 在用户访问网站页面时，向请求域名注入两个Cookie，一个是原本要注入的Cookie，一个比如随机字符串

② 前端向后端发起请求时，取出随机字符串，添加到URL参数或请求头中

③ 后端验证携带的随机数与Cookie中的随机数是否一致，不一致则拒绝请求

缺点：难以做到子域名隔离，认证Cookie必须被种在顶级域名下，每个子域才可以访问；如果某个子域存在XSS漏洞，攻击者将这个认证Cookie修改为自己配置的Cookie；攻击者直接使用自己配置的Cookie发起CSRF攻击。

4）CSRF Token

CSRF攻击者无法直接窃取到用户的Cookie，仅仅是冒用；而CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户的请求。

① 服务器生成登录Cookie时，同时生成Token和Token签名的2个Cookie

② 前端向后端发起请求时，将Token添加到URL参数或请求头中

③ 后端收到请求，首先验证参数与Token相不相同，不相同则中止请求；然后校验签名，不相同则中止请求。因为攻击者不知道密钥，使用Token签名可以防止Cookie被篡改和伪造。

缺点：每个请求都需要携带Token，且需要服务端对每个请求进行校验。所以一般只对包含敏感数据的请求做此处理。

2、短信防刷

短信轰炸是指攻击者利用从各个网站上找到的发送动态短信的URL和前端输入的被攻击者的手机号码，发送HTTP请求，每次请求给用户发送一个动态短信。

危害：增加公司的运营成本，因为短信是需要计费的；被攻击者大量被动接收非自身请求的短信，造成无法正常使用移动运营商业务；给公司形象造成极大影响，因为一般短信会带公司签名。

常见防范手段：

 短信发送间隔设置

 发送量限制

 图文验证码

 触发流程限制

六、全球部署问题

Session存在内存里随着用户的增多会导致内存溢出，且不能跨进程、跨机器共享，且重启进程后会导致Session丢失，所以Session通常会存在第三方缓存，比如Redis里。

Redis全球部署带来的问题在于，已登录的用户再次请求时，如果请求定位到不同集群的Redis，会导致登录状态失效。

解决方案：

 不同集群Redis数据同步

 保证相同集群的Web服务请求同一集群的Redis学习网络安全技术的方法无非三种:

第一种是报网络安全专业，现在叫网络空间安全专业，主要专业课程:程序设计、计算机组成原理原理、数据结构、操作系统原理、数据库系统、 计算机网络、人工智能、自然语言处理、社会计算、网络安全法律法规、网络安全、内容安全、数字取证、机器学习，多媒体技术，信息检索、舆情分析等。

第二种是自学，就是在网上找资源、找教程，或者是想办法认识一-些大佬，抱紧大腿，不过这种方法很耗时间，而且学习没有规划，可能很长一段时间感觉自己没有进步，容易劝退。

如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！

第三种就是去找培训。

接下来，我会教你零基础入门快速入门上手网络安全。

网络安全入门到底是先学编程还是先学计算机基础？这是一个争议比较大的问题，有的人会建议先学编程，而有的人会建议先学计算机基础，其实这都是要学的。而且这些对学习网络安全来说非常重要。但是对于完全零基础的人来说又或者急于转行的人来说，学习编程或者计算机基础对他们来说都有一定的难度，并且花费时间太长。

第一阶段：基础准备 4周~6周

这个阶段是所有准备进入安全行业必学的部分，俗话说：基础不劳，地动山摇

第二阶段：web渗透

学习基础 时间：1周 ~ 2周：

① 了解基本概念：（SQL注入、XSS、上传、CSRF、一句话木马、等）为之后的WEB渗透测试打下基础。
② 查看一些论坛的一些Web渗透，学一学案例的思路，每一个站点都不一样，所以思路是主要的。
③ 学会提问的艺术，如果遇到不懂得要善于提问。

配置渗透环境 时间：3周 ~ 4周：

① 了解渗透测试常用的工具，例如（AWVS、SQLMAP、NMAP、BURP、中国菜刀等）。
② 下载这些工具无后门版本并且安装到计算机上。
③ 了解这些工具的使用场景，懂得基本的使用，推荐在Google上查找。

渗透实战操作 时间：约6周：

① 在网上搜索渗透实战案例，深入了解SQL注入、文件上传、解析漏洞等在实战中的使用。
② 自己搭建漏洞环境测试，推荐DWVA，SQLi-labs，Upload-labs，bWAPP。
③ 懂得渗透测试的阶段，每一个阶段需要做那些动作：例如PTES渗透测试执行标准。
④ 深入研究手工SQL注入，寻找绕过waf的方法，制作自己的脚本。
⑤ 研究文件上传的原理，如何进行截断、双重后缀欺骗(IIS、PHP)、解析漏洞利用（IIS、Nignix、Apache）等，参照：上传攻击框架。
⑥ 了解XSS形成原理和种类，在DWVA中进行实践，使用一个含有XSS漏洞的cms，安装安全狗等进行测试。
⑦ 了解一句话木马，并尝试编写过狗一句话。
⑧ 研究在Windows和Linux下的提升权限，Google关键词：提权

以上就是入门阶段

第三阶段：进阶

已经入门并且找到工作之后又该怎么进阶？详情看下图

给新手小白的入门建议：
新手入门学习最好还是从视频入手进行学习，视频的浅显易懂相比起晦涩的文字而言更容易吸收，这里我给大家准备了一套网络安全从入门到精通的视频学习资料包免费领取哦！

如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！