Ⅰ Web安全測試的作品目錄
序 1
前言 3
第1章 緒論 13
1.1 什麼是安全測試 13
1.2 什麼是Web應用 17
1.3 Web應用基礎 21
1.4 Web應用安全測試 25
1.5 方法才是重點 26
第2章 安裝免費工具 29
2.1 安裝Firefox 29
2.2 安裝Firefox擴展 30
2.3 安裝Firebug 31
2.4 安裝OWASP的WebScarab 32
2.5 在Windows上安裝Perl及其軟體包 33
2.6 在Linux, Unix或OS X上安裝Perl和使用CPAN 34
2.7 安裝CAL9000 35
2.8 安裝ViewState Decoder 36
2.9 安裝cURL 36
2.10 安裝Pornzilla 37
2.11 安裝Cygwin 38
2.12 安裝Nikto 2 39
2.13 安裝Burp Suite 40
2.14 安裝Apache HTTP Server 41
第3章 基本觀察 43
3.1 查看網頁的HTML源代碼 44
3.2 查看源代碼，高級功能 45
3.3 使用Firebug觀察實時的請求頭 48
3.4 使用WebScarab觀察實時的POST數據 52
3.5 查看隱藏表單域 55
3.6 使用TamperData觀察實時的響應頭 56
3.7 高亮顯示JavaScript和注釋 59
3.8 檢測JavaScript事件 60
3.9 修改特定的元素屬性 61
3.10 動態跟蹤元素屬性 63
3.11 結論 65
第4章 面向Web的數據編碼 66
4.1 辨別二進制數據表示 67
4.2 使用Base-64 69
4.3 在網頁中轉換Base-36數字 71
4.4 在Perl中使用Base-36 71
4.5 使用以URL方式編碼的數據 72
4.6 使用HTML實體數據 74
4.7 計算散列值 76
4.8 辨別時間格式 78
4.9 以編程方式對時間值進行編碼 80
4.11 解碼多重編碼 83
第5章 篡改輸入 85
5.1 截獲和修改POST請求 86
5.2 繞過輸入限制 89
5.3 篡改URL 90
5.4 自動篡改URL 93
5.5 測試對URL長度的處理 94
5.6 編輯Cookie 96
5.7 偽造瀏覽器頭信息 99
5.8 上傳帶有惡意文件名的文件 101
5.9 上傳大文件 104
5.10 上傳惡意XML實體文件 105
5.11 上傳惡意XML結構 107
5.12 上傳惡意ZIP文件 109
5.13 上傳樣例病毒文件 110
5.14 繞過用戶界面的限制 111
第6章 自動化批量掃描 114
6.1 使用WebScarab爬行網站 115
6.2 將爬行結果轉換為清單 117
6.3 減少要測試的URL 120
6.4 使用電子表格程序來精簡列表 120
6.5 使用LWP對網站做鏡像 121
6.6 使用wget對網站做鏡像 123
6.7 使用wget對特定的清單做鏡像 124
6.8 使用Nikto掃描網站 125
6.9 理解Nikto的輸出結果 127
6.10 使用Nikto掃描HTTPS站點 128
6.11 使用帶身份驗證的Nikto 129
6.12 在特定起始點啟動Nikto 130
6.13 在Nikto中使用特定的會話Cookie 131
6.14 使用WSFuzzer測試Web服務 132
6.15 理解WSFuzzer的輸出結果 134
第7章 使用cURL實現特定任務的自動化 137
7.1 使用cURL獲取頁面 138
7.2 獲取URL的許多變體 139
7.3 自動跟蹤重定向 140
7.4 使用cURL檢查跨站式腳本 141
7.5 使用cURL檢查目錄遍歷 144
7.6 冒充特定類型的網頁瀏覽器或設備 147
7.7 以交互方式冒充另一種設備 149
7.8 使用cURL模仿搜索引擎 151
7.9 通過假造Referer頭信息來偽造工作流程 152
7.10 僅獲取HTTP頭 153
7.11 使用cURL發送POST請求 154
7.12 保持會話狀態 156
7.13 操縱Cookie 157
7.14 使用cURL上傳文件 158
7.15 建立多級測試用例 159
7.16 結論 164
第8章 使用LibWWWPerl實現自動化 166
8.1 編寫簡單的Perl腳本來獲取頁面 167
8.2 以編程方式更改參數 169
8.3 使用POST模仿表單輸入 170
8.4 捕獲和保存Cookie 172
8.5 檢查會話過期 173
8.6 測試會話固定 175
8.7 發送惡意Cookie值 177
8.8 上傳惡意文件內容 179
8.9 上傳帶有惡意名稱的文件 181
8.10 上傳病毒到應用 182
8.11 使用Perl解析接收到的值 184
8.12 以編程方式來編輯頁面 186
8.13 使用線程化提高性能 189
第9章 查找設計缺陷 191
9.1 繞過必需的導航 192
9.2 嘗試特權操作 194
9.3 濫用密碼恢復 195
9.4 濫用可預測的標識符 197
9.5 預測憑證 199
9.6 找出應用中的隨機數 200
9.7 測試隨機數 202
9.8 濫用可重復性 204
9.9 濫用高負載操作 206
9.10 濫用限制性的功能 208
9.11 濫用競爭條件 209
第10章 攻擊AJAX 211
10.1 觀察實時的AJAX請求 213
10.2 識別應用中的JavaScript 214
10.3 從AJAX活動回溯到源代碼 215
10.4 截獲和修改AJAX請求 216
10.5 截獲和修改伺服器響應 218
10.6 使用注入數據破壞AJAX 220
10.7 使用注入XML破壞AJAX 222
10.8 使用注入JSON破壞AJAX 223
10.9 破壞客戶端狀態 224
10.10 檢查跨域訪問 226
10.11 通過JSON劫持來讀取私有數據 227
第11章 操縱會話 229
11.1 在Cookie中查找會話標識符 230
11.2 在請求中查找會話標識符 232
11.3 查找Authentication頭 233
11.4 分析會話ID過期 235
11.5 使用Burp分析會話標識符 239
11.6 使用WebScarab分析會話隨機性 240
11.7 更改會話以逃避限制 245
11.8 假扮其他用戶 247
11.9 固定會話 248
11.10 測試跨站請求偽造 249
第12章 多層面的測試 251
12.1 使用XSS竊取Cookie 251
12.2 使用XSS創建覆蓋 253
12.3 使用XSS產生HTTP請求 255
12.4 以交互方式嘗試基於DOM的XSS 256
12.5 繞過欄位長度限制（XSS） 258
12.6 以交互方式嘗試跨站式跟蹤 259
12.7 修改Host頭 261
12.8 暴力猜測用戶名和密碼 263
12.9 以交互方式嘗試PHP包含文件注入 265
12.10 製作解壓縮炸彈 266
12.11 以交互方式嘗試命令注入 268
12.12 系統地嘗試命令注入 270
12.13 以交互方式嘗試XPath注入 273
12.14 以交互方式嘗試伺服器端包含（SSI）注入 275
12.15 系統地嘗試伺服器端包含（SSI）注入 276
12.16 以交互方式嘗試LDAP注入 278
12.17 以交互方式嘗試日誌注入 280
Ⅱ 在使用伺服器端的會話管理時，通過什麼方法標識會話
會話跟蹤常用的方法:a) URL重寫:URL(統一資源定位符)是Web上特定頁面的地址，URL重寫的技術就是在URL結尾添加一個附加數據以標識該會話,把會話ID通過URL的信息傳遞過去，以便在伺服器端進行識別不同的用戶 b) 隱藏表單域:將會話ID添加到HTML表單...
Ⅲ 簡述cookies和session的區別
1、cookie 和session的區別是：cookie數據保存在客戶端，session數據保存在伺服器端。
2、兩個都可以用來存私密的東西，同樣也都有有效期的說法,區別在於session是放在伺服器上的，過期與否取決於服務期的設定，cookie是存在客戶端的，過去與否可以在cookie生成的時候設置進去。
(1)、cookie數據存放在客戶的瀏覽器上，session數據放在伺服器上 ；
(2)、cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙,如果主要考慮到安全應當使用session ；
(3)、session會在一定時間內保存在伺服器上。當訪問增多，會比較佔用你伺服器的性能，如果主要考慮到減輕伺服器性能方面，應當使用COOKIE ；
(4)、單個cookie在客戶端的限制是3K，就是說一個站點在客戶端存放的COOKIE不能3K；
(5)、所以將登陸信息等重要信息存放為SESSION;其他信息如果需要保留，可以放在COOKIE中。
3、cookie和session的共同之處在於：cookie和session都是用來跟蹤瀏覽器用戶身份的會話方式。
4、cookie 是一種發送到客戶瀏覽器的文本串句柄，並保存在客戶機硬碟上，可以用來在某個WEB站點會話間持久的保持數據。
Ⅳ 什麼是會話ID和如何使用會話ID
什麼是會話ID
會話ID是一種唯一標識當前訪問伺服器的客戶的只讀值。在經典的ASP環境下，會話ID是按照順序方式被分配的，也就是說，會話ID 706616433之後跟著會話 ID 706616434等等。傳統的ASP會話ID以加密的、非持久存在的cookie形式保存在客戶機上。例如，會話ID 706616434就可能作為cookie ASPSESSIONIDGQQGQGCS=JHMBOBKCBINEHLPKJHOPABBE保存在客戶機上。
ASP.NET下的會話ID有所變化。在使用 ASP.NET 時，會話ID是由URL合法ASCII字元組成的一個120位字元串。根據微軟文檔的說明，產生會話 ID 值採用了保證其唯一性的演算法，從而避免出現兩個客戶試圖採用同一ID時出現的會話沖突。另外，會話ID的隨機性使得確定現有會話的ID變得非常困難從而帶來了額外的安全性。同傳統ASP一樣，ASP.NET的會話ID通常也作為非持久保存的cookie存儲在客戶機上。這種cookie的格式同傳統ASP相比稍有變化，例如，asp.net_sessionid=jhmbobkcbinehlpkjhopabbe。
除了維持狀態的傳統型的、非持久保存的cookie的方法之外，ASP.NET還支持一種不採用cookie的會話狀態維持模式。在啟用無cookie模式的情況下，ASP.NET在發送回客戶機的URL中嵌入會話ID。這樣就為使用不支持cookie或禁用cookie瀏覽器的客戶提供了會話狀態堅持。考慮到利用cookie跟蹤客戶信息的舉動，我們有理由對無Cookie模式保持高度的關注。
如何使用會話ID
客戶每發出一個請求，包含加密會話ID的cookie在存在的情況下即被發送給伺服器。伺服器隨後確定cookie所關聯的會話ID並恢復關聯該客戶的所有會話變數。如果cookie不存在就會生成一個新的會話ID，同時加密的會話ID cookie則被發送給客戶機。這樣就能讓ASP跟蹤訪問網站的單個客戶了。同時，以上機制還促使ASP建立伺服器方會話變數同單一會話的關聯關系。
Ⅳ jsp的Session 和Servlet的Session有什麼區別
jsp的Session和Servlet的Session本質上是一致的，區別是：jsp中session是作為隱式對象存在的，可以直接使用；Servlet中的session需要手動提取後才能使用.
HttpSession是Java平台對session機制的實現規范，因為它僅僅是個介面，具體到每個web應用伺服器的提供商，除了對規范支持之外，仍然會有一些規范里沒有規定的細微差異。
1、session機制
http是無狀態的協議，客戶每次讀取web頁面時，伺服器都打開新的會話，而且伺服器也不會自動維護客戶的上下文信息，session就是一種保存上下文信息的機制，它是針對每一個用戶的，變數的值保存在伺服器端，通過SessionID來區分不同的客戶,session是以cookie或URL重寫為基礎的，默認使用cookie來實現，系統會創造一個名為JSESSIONID的輸出返回給客戶端Cookie保存。
2、jsp和Servlet的關系
jsp是servlet的一種簡化，jsp是Servlet技術的擴展，本質上就是Servlet的簡易方式。JSP編譯後是「類servlet」。Servlet和JSP最主要的不同點在於，Servlet的應用邏輯是在Java文件中，並且完全從表示層中的HTML里分離開來。而JSP的情況是Java和HTML可以組合成一個擴展名為.jsp的文件。JSP側重於視圖，Servlet主要用於控制邏輯
Ⅵ java中會話在WEB的作用
session:會話。舉個例子吧，編寫一個論壇，就可以用session。用戶登錄之後，打開了多個頁面，但是用戶名是不變的，這就是session起的作用。關閉瀏覽器，session就銷毀了。
Ⅶ session錯誤
我們可以使用 Session 對象存儲特定的用戶會話所需的信息。當用戶在應用程序的頁之間跳轉時，存儲在 Session 對象中的變數不會清除，而用戶在應用程序中訪問頁面時，這些變數始終存在。當用戶請求來自應用程序的 Web 頁時，如果該用戶還沒有會話，則 Web 伺服器將自動創建一個 Session 對象。當會話過期或被放棄後，伺服器將終止該會話。 通過向客戶程序發送唯一的 Cookie 可以管理伺服器上的 Session 對象。當用戶第一次請求 ASP 應用程序中的某個頁面時，ASP 要檢查 HTTP 頭信息，查看是否有在報文中有名為 ASPSESSIONID 的 Cookie 發送過來，如果有，則伺服器會啟動新的會話，並為該會話生成一個全局唯一的值，在把這個值作為新 ASPSESSIONID Cookie 的值發送給客戶端，正是使用這種 Cookie，可以訪問存儲在伺服器上的屬於客戶程序的信息。Session 對象最常見的作用就是存儲用戶的首選項。例如，如果用戶指明不喜歡查看圖形，就可以將該信息存儲在 Session 對象中。另外其還經常被用在鑒別客戶身份的程序中。要注意的是，會話狀態僅在支持 cookie 的瀏覽器中保留，如果客戶關閉了 Cookie 選項，Session 也就不能發揮作用了。 一、屬性 1、SessionID SessionID 屬性返回用戶的會話標識。在創建會話時，伺服器會為每一個會話生成一個單獨的標識。會話標識以長整形數據類型返回。在很多情況下 SessionID 可以用於 WEB 頁面注冊統計。 2、TimeOut Timeout 屬性以分鍾為單位為該應用程序的 Session 對象指定超時時限。如果用戶在該超時時限之內不刷新或請求網頁，則該會話將終止。 二、方法 Session 對象僅有一個方法，就是 Abandon，Abandon 方法刪除所有存儲在 Session 對象中的對象並釋放這些對象的源。如果您未明確地調用 Abandon 方法，一旦會話超時，伺服器將刪除這些對象。當伺服器處理完當前頁時，下面示例將釋放會話狀態。 < % Session.Abandon %> 三、事件 Session 對象有兩個事件可用於在 Session 對象啟動和釋放是運行過程。 1、Session_OnStart 事件在伺服器創建新會話時發生。伺服器在執行請求的頁之前先處理該腳本。Session_OnStart 事件是設置會話期變數的最佳時機，因為在訪問任何頁之前都會先設置它們。 盡管在 Session_OnStart 事件包含 Redirect 或 End 方法調用的情況下 Session 對象仍會保持，然而伺服器將停止處理 Global.asa 文件並觸發 Session_OnStart 事件的文件中的腳本。 為了確保用戶在打開某個特定的 Web 頁時始終啟動一個會話，就可以在 Session_OnStart 事件中調用 Redirect 方法。當用戶進入應用程序時，伺服器將為用戶創建一個會話並處理 Session_OnStart 事件腳本。您可以將腳本包含在該事件中以便檢查用戶打開的頁是不是啟動頁，如果不是，就指示用戶調用 Response.Redirect 方法啟動網頁。程序如下 : < SCRIPT RUNAT=Server Language=VBScript> Sub Session_OnStart startPage = "/MyApp/StartHere.asp" currentPage = Request.ServerVariables("SCRIPT_NAME") if strcomp(currentPage,startPage,1) then Response.Redirect(startPage) end if End Sub < /SCRIPT> 上述程序只能在支持 cookie 的瀏覽器中運行。因為不支持 cookie 的瀏覽器不能返回 SessionID cookie，所以，每當用戶請求 Web 頁時，伺服器都會創建一個新會話。這樣，對於每個請求伺服器都將處理 Session_OnStart 腳本並將用戶重定向到啟動頁中。 2、Session_OnEnd 事件在會話被放棄或超時發生。 關於使用 Session 對象需要注意的事項 Application 對象相近，請參照前文。 會話可以通過以下三種方式啟動 : 1、一個新用戶請求訪問一個 URL，該 URL 標識了某個應用程序中的 .asp 文件，並且該應用程序的 Global.asa 文件包含 Session_OnStart 過程。 2、用戶在 Session 對象中存儲了一個值。 3、用戶請求了一個應用程序的 .asp 文件，並且該應用程序的Global.asa 文件使用 < OBJECT> 標簽創建帶有會話作用域的對象的實例。 如果用戶在指定時間內沒有請求或刷新應用程序中的任何頁，會話將自動結束。這段時間的默認值是 20 分鍾。可以通過在 Internet 服務管理器中設置「應用程序選項」屬性頁中的「會話超時」屬性改變應用程序的默認超時限制設置。應依據您的 Web 應用程序的要求和伺服器的內存空間來設置此值。例如，如果您希望瀏覽您的 Web 應用程序的用戶在每一頁僅停留幾分鍾，就應該縮短會話的默認超時值。過長的會話超時值將導致打開的會話過多而耗盡您的伺服器的內存資源。對於一個特定的會話，如果您想設置一個小於默認超時值的超時值，可以設置 Session 對象的 Timeout 屬性。例如，下面這段腳本將超時值設置為 5 分鍾。 < % Session.Timeout = 5 %> 當然你也可以設置一個大於默認設置的超時值，Session.Timeout 屬性決定超時值。你還可以通過 Session 對象的 Abandon 方法顯式結束一個會話。例如，在表格中提供一個「退出」按鈕，將按鈕的 ACTION 參數設置為包含下列命令的 .asp 文件的 URL。 < % Session.Abandon %>
Ⅷ WEB應用中的SESSION知多少
目 錄
一、Session
二、Cookies
三、Cookies機制
四、Session機制
五、Cookies機制與Session機制的區別和聯系
六、常見問題
七、Session的用法
Session是WEB上有效的信息交互手段，因其使用方便、穩定、安全、可靠而被眾多WEB開發者所認知。尤其在互聯網身份驗證、網上電子購物等方面的應用更為廣泛。下面就著重來介紹下Session。
一、Session
Session，在漢語中表示通話、會話、對話(期)、話路［對談時間］的意思，其本來的含義一個終端用戶與交互系統進行通信的時間(間隔),通常是指從注冊(進入系統)到注銷(退出系統)之間所經過的時間。比如打電話時從拿起電話撥號到掛斷電話這中間的一系列過程可以稱之為一個Session。有時候我們可以看到這樣的話「在一個瀏覽器會話期間，…」，這里的會話一詞用的就是這個意思，是指從一個瀏覽器窗口打開到關閉這個期間。Session在我們的網路應用中就是一種客戶端與伺服器端保持狀態的解決方案，有時候Session也用來指這種解決方案的存儲結構，
Session對象，就是客戶端瀏覽器與伺服器之間建立的互動信息狀態。每一個不同的用戶連接將得到不同的Session，也就是說Session與用戶之間是一種一對一的關系。Session在用戶進入網站時由伺服器自動產生，並在用戶正常離開站點時釋放。使用Session的好處就在於，可以將很多與用戶相關的信息，例如用戶的帳號、昵稱等保存到Session中；利用Session，可以跟蹤用戶在網站上的活動。例如：當你上網進入一個網站時，如果你沒有登陸，無論你訪問哪幾個頁面都會跳轉回登陸頁。還有就是你在購物時，不可能把你的東西放到別人的購物車里去，這就得用一個信息變數來判斷！
如果能夠提供一些按需生成的動態信息會使web變得更加有用，就像給有線電視加上點播功能一樣。這種需求一方面迫使HTML逐步添加了表單、腳本、DOM 等客戶端行為，另一方面在伺服器端則出現了CGI規范以響應客戶端的動態請求，作為傳輸載體的HTTP協議也添加了文件上載、cookie這些特性。其中 cookie的作用就是為了解決HTTP協議無狀態的缺陷所作出的努力。至於後來出現的Session機制則是又一種在客戶端與伺服器之間保持狀態的解決方案。
二、Cookies
Cookie是WEB上最常用的跟蹤用戶會話方式，當 Cookie被禁止後，一般都用URL重寫來跟蹤會話。Cookie是一種由伺服器發送給客戶的片段信息，存儲在客戶環境中，並在客戶所有的對伺服器的請求中都要發回它。就好比我們在用IE登陸某個電子購物商城時，IE在得到商品列表頁面的 同時還收到Set-Cookie應答頭信息，我們打開一個Cookie文件，我們所看到的格式一般都是：
Cookie：NAME=VALUE；Comment=COMMENT；Domain=DOMAINNMAM；Max-age=SECONDS；Path=PATH；secure；Version=1*DIGIT
其中NAME值對（值對間用分號分隔）是必須的，其餘都是可選的。最重要的信息當然也在所必須的值對里了，VALUE是NAME的值，也是這個 Cookie的標識，Max-age定義了Cookie的最長生存時間。當我們選購了某種商品，向伺服器發送選購清單時，會自動在你的請求信息頭里加上NAME值對,如果Cookie被禁止，則用 URL重寫方式在URL請求地址上附加NAME值對。當Web伺服器收到這個請求後，會檢查該Cookie是否存在，然後相應的跟蹤會話。從以上分析不難理解，其實Web伺服器跟蹤會話就靠Set-Cookie頭信息，跟蹤NAME值對進行身份驗證。假如我們用非Web終端接收Web伺服器的響應信息，從中解析出Cookie頭信息，當再次向Web伺服器發送請求時附加上解析出的Cookie信息，Web伺服器據此不就可以進行身份認證了嗎？
Cookies中文是餅乾的意思，對於為何引用Cookies，從網上查找了一些資料：
在瀏覽器與WEB伺服器之間是使用HTTP協議進行通信的，當某個用戶發出頁面請求時，WEB伺服器只是簡單的進行響應，然後就關閉與該用戶的連接。因此當一個請求發送到WEB伺服器時，無論其是否是第一次來訪，伺服器都會把它當作第一次來對待，這樣的不好之處可想而知。為了彌補這個缺陷，Netscape開發出了cookie這個有效的工具來保存某個用戶的識別信息，因此人們昵稱為「小甜餅」。cookies是一種WEB伺服器通過瀏覽器在訪問者的硬碟上存儲信息的手段：Netscape Navigator使用一個名為cookies.txt本地文件保存從所有站點接收的Cookie信息；而IE瀏覽器把Cookie信息保存在類似於 c:\Internet 臨時文件\的目錄下。當用戶再次訪問某個站點時，服務端將要求瀏覽器查找並返回先前發送的Cookie信息，來識別這個用戶。Cookies給網站和用戶帶來的好處：
(1)、Cookie能使站點跟蹤特定訪問者的訪問次數、最後訪問時間和訪問者進入站點的路徑
(2)、Cookie能告訴在線廣告商廣告被點擊的次數，從而可以更精確的投放廣告
(3)、Cookie有效期限未到時，Cookie能使用戶在不鍵入密碼和用戶名的情況下進入曾經瀏覽過的一些站點
(4)、Cookie能幫助站點統計用戶個人資料以實現各種各樣的個性化服務，其實，cookie的作用就是為了解決HTTP協議無狀態的缺陷所作的努力.
三．Cookie機制
Cookie機制採用的是在客戶端保持狀態的方案。
Cookie機制，就是當伺服器對訪問它的用戶生成了一個Session的同時伺服器通過在HTTP的響應頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應的cookie，保存在客戶端，裡面記錄著用戶當前的信息，當用戶再次訪問伺服器時，瀏覽器檢查所有存儲的cookie，如果某個cookie所聲明的作用范圍大於等於將要請求的資源所在的位置也就是對應的Cookie文件。 若存在，則把該cookie附在請求資源的HTTP請求頭上發送給伺服器，例如：當我們登陸了一個網站，並且填寫了有關資料，以本站會員的名義登陸上了有關網頁，這時你把瀏覽器關閉，再重啟進入該網站的某一個頁面時是以你登陸過的會員進去的，當然，不是所有網站都是這樣，我們知道，cookie的保存有臨時性的和持久性的，大多都是臨時性的，也就是cookie只保存在客戶端的內存中，而沒有保存在硬碟上，當關閉瀏覽器，cookie也就銷毀。以下是有關 cookie機制的一些具體說明：
cookie的內容主要包括：名字，值，過期時間，路徑和域。
其中域可以指定某一個域比如.，相當於總店招牌，比如寶潔公司，也可以指定一個域下的具體某台機器可以用飄柔來做比。
路徑就是跟在域名後面的URL路徑，比如/或者/foo等等，可以用某飄柔專櫃做比。路徑與域合在一起就構成了cookie的作用范圍。
如果不設置過期時間，則表示這個cookie的生命期為瀏覽器會話期間，只要關閉瀏覽器窗口，cookie就消失了。這種生命期為瀏覽器會話期的 cookie被稱為會話cookie。會話cookie一般不存儲在硬碟上而是保存在內存里，當然這種行為並不是規范規定的。如果設置了過期時間，瀏覽器就會把cookie保存到硬碟上，關閉後再次打開瀏覽器，這些cookie仍然有效直到超過設定的過期時間。
存儲在硬碟上的cookie可以在不同的瀏覽器進程間共享，比如兩個IE窗口。而對於保存在內存里的cookie，不同的瀏覽器有不同的處理方式。對於微軟的IE瀏覽器，在一個打開的窗口上按Ctrl-N（或者從文件菜單）打開的窗口可以與原窗口共享，而使用其他方式新開的IE進程則不能共享已經打開的窗口的內存cookie；對於火狐狸firefox瀏覽器，所有的進程和標簽頁都可以共享同樣的cookie。一般來說是用javascript的 window.open打開的窗口會與原窗口共享內存cookie。瀏覽器對於會話cookie的這種只認cookie不認人的處理方式經常給採用 Session機制的web應用程序開發者造成很大的困擾。
Ⅸ Servlet中如何理解會話
servlet中session的使用
還是由於HTTP協議連接的無狀態性，才使得session的不得已而產生。既然Web應用並不了解有關同一用戶以前請求的信息，那麼解決這個問題的一個辦法是使用Servlet/JSP容器提供的會話跟蹤功能，Servlet API規范定義了一個簡單的HttpSession介面，通過它我們可以方便地實現會話跟蹤。
HttpSession介面提供了存儲和返回標准會話屬性的方法。標准會話屬性如會話標識符、應用數據等，都以「名字-值」對的形式保存在伺服器端。也就是說，HttpSession介面提供了一種把對象保存到內存、在同一用戶的後繼請求中提取這些對象的標准辦法。在會話中保存數據的方法是setAttribute(String s, Object o)，從會話提取原來所保存對象的方法是getAttribute(String s)。
在伺服器端，每當新用戶請求一個使用了HttpSession對象的JSP頁面，Servlet/JSP容器除了發回應答頁面之外，它還要以cookie的形式向瀏覽器發送一個特殊的數字。這個特殊的數字稱為「會話標識符」，它是一個唯一的用戶標識符。此後，HttpSession對象就駐留在內存之中(這當然是在伺服器端)，瀏覽器再請求session時,伺服器會先得到它的sessionid,再作處理。
在客戶端，瀏覽器保存會話標識符，並在每一個後繼請求中把這個會話標識符發送給伺服器。會話標識符告訴JSP容器當前請求不是用戶發出的第一個請求，伺服器以前已經為該用戶創建了HttpSession對象。此時，JSP容器不再為用戶創建新的HttpSession對象，而是尋找具有相同會話標識符的HttpSession對象，然後建立該HttpSession對象和當前請求的關聯。
會話標識符以Cookie的形式在伺服器和瀏覽器之間傳送，標准會話屬性在伺服器端也是以會話的形式存在的，並且這個Cookie的生命周期只是臨時的，即會話結束後就自動消失，沒有為它指定固定的生命周期，因此有人說session是基於Cookie的技術。另外，如果客戶端不支持Cookie，運用url重寫機制來保證會話標識符傳回伺服器。
還有一點，session不像Cookie那樣擁有路徑訪問的問題。session對應的是窗口，只要是同一個客戶端或者是存在父子關系的多個客戶端，同一個application下的servlet/JSP可以共享同一個session。當然，session和窗口的對應關系也是受時間限制的，至於多長時間，可以在伺服器的conf/web.xml中配置<session-config><session- timeout>30</session-timeout></session-config>
Ⅹ 如何配置http服務標識，使其不泄露web伺服器以及操作系統的版本
網站伺服器運行段間down掉原能造種現象：比tomcat堆非堆內存設置足程序沒能釋放內存空間造內存溢或者某些進程直運行沒能釋放造cup資源量消耗除程序本身原能客服端訪問造（客戶端包含蜘蛛軟體等搜索引擎）伺服器客戶端建立鏈接(用netstat -a命令查看網路訪問信息)需要http響應connection做定設置
http1.1requestreponse header都能現connection欄位header含義clientserver通信於鏈接何進行處理http1.1clientserver都默認支持鏈接 client使用http1.1協議希望使用鏈接則需要header指明connection值close；server想支持鏈接則response需要明確說明connection值close
論requestresponseheader包含值closeconnection都表明前使用tcp鏈接請求處理完畢斷掉client再進行新請求必須創建新tcp鏈接
HTTP Connectionclose設置允許客戶端或伺服器任何關閉底層連接雙都要求處理請求關閉TCP連接
何程序設置：濾器加入：response.setHeader(connection, close);
內容自: HTTP Keep-Alive詳解
HTTP Keep Alive
HTTP Keep-Alive 程序誤解面介紹HTTP/1.0HTTP/1.1版本何工作及其JAVA運行原理
HTTP請求響應模式典型範例即客戶端向伺服器發送請求信息伺服器響應信息HTTP版本每請求都創建新客戶端->伺服器連接連接發送請求接收請求模式優點簡單容易理解編程實現；缺點效率低Keep-Alive提用解決效率低問題
HTTP/1.0
HTTP/1.0版本並沒官標准規定Keep-Alive何工作實際附加HTTP/1.0協議客戶端瀏覽器支持Keep-AliveHTTP請求添加欄位 Connection: Keep-Alive伺服器收附帶Connection: Keep-Alive請求響應添加同欄位使用Keep-Alive客戶端伺服器間HTTP連接保持斷（超Keep-Alive規定間意外斷電等情況除外）客戶端發送另外請求使用條已經建立連接
HTTP/1.1
HTTP/1.1版本官規定Keep-Alive使用標准HTTP/1.0版本些同默認情況所HTTP1.1所連接都保持除非請求或響應指明要關閉：Connection: Close Connection: Keep-Alive欄位再沒意義原另外添加新欄位Keep-Alive:欄位並沒詳細描述用做忽略
Not reliable（靠）
HTTP狀態協議意味著每請求都獨立Keep-Alive沒能改變結另外Keep-Alive能保證客戶端伺服器間連接定躍HTTP1.1版本唯能保證連接關閉能通知所應該讓程序依賴於Keep-Alive保持連接特性否則意想
Keep-AlivePOST
HTTP1.1細則規定POST消息體面能任何字元指於某特定瀏覽器能並遵循標准（比POST消息體面放置CRLF符）據我所知部瀏覽器POST消息體都自跟CRLF符再發送何解決問題呢根據面說明POST請求禁止使用Keep-Alive或者由伺服器自忽略CRLF部伺服器都自忽略未經測試前能知道伺服器否做
內容自:
HTTP狀態協議Connection:Keep-Alive容易犯誤區
名詞解釋：
HTTP狀態：狀態指協議於事務處理沒記憶能力伺服器知道客戶端狀態另面講打伺服器網頁前打伺服器網頁間沒任何聯系
要實現購物車需要藉助於Cookie或Session或伺服器端API（NSAPI and ISAPI）記錄些信息請求伺服器結算頁面同些信息提交伺服器
登錄網站登錄狀態由Cookie或Session記憶伺服器並知道否登錄
優點：伺服器用每客戶端連接配內存記憶量狀態用客戶端失連接清理內存更高效處理WEB業務
缺點：客戶端每請求都需要攜帶相應參數伺服器需要處理些參數
Keep-Alive：參考另外篇文章HTTP Keep-Alive 詳解
容易犯誤區：
1、HTTP狀態面向連接協議狀態代表HTTP能保持TCP連接更能代表HTTP使用UDP協議（連接）
2、HTTP/1.1起默認都啟Keep-Alive保持連接特性簡單說網頁打完客戶端伺服器間用於傳輸HTTP數據TCP連接關閉客戶端再訪問伺服器網頁繼續使用條已經建立連接
3、Keep-Alive永久保持連接保持間同伺服器軟體（Apache）設定間
內容自:
Keep-Alive簡介及Tomcat配置
Keep-Alive功能使客戶端伺服器端連接持續效現伺服器繼請求Keep-Alive功能避免建立或者重新建立連接市場 部Web伺服器包括iPlanet、IISApache都支持HTTP Keep-Alive於提供靜態內容網站說功能通用於負擔較重網站說存另外問題：雖客戶保留打連 接定處同影響性能處理暫停期間本釋放資源仍舊佔用Web伺服器應用伺服器同台機器運行Keep-Alive功能資源利用影響尤其突 功能HTTP 1.1預設功能HTTP 1.0加Keep-Alive header提供HTTP持續作用功能
Keep-Alive: timeout=5, max=100
timeout：期間5秒（應httpd.conf參數：KeepAliveTimeout）max百請求強制斷掉連接
timeout間內新連接同max自減1直0強制斷掉
Tomcat相關設置,server.xml Connector 元素
keepAliveTimeout：
間連接close單位milliseconds
maxKeepAliveRequests：
連接數（1表示禁用-1表示限制數默認100般設置100~200間）.
maxKeepAliveRequests=1″避免tomcat產量TIME_WAIT連接定程度避免tomcat假死
<Connector executor=tomcatThreadPool
port=80″ protocol=HTTP/1.1″
connectionTimeout=60000″
keepAliveTimeout=15000″
maxKeepAliveRequests=1″
redirectPort=443″
maxHttpHeaderSize=8192″ URIEncoding=UTF-8″ enableLookups=false acceptCount=100″ disableUploadTimeout=true/>?網站伺服器運行段間down掉原能造種現象：比tomcat堆非堆內存設置足程序沒能釋放內存空間造內存溢或者某些進程直運行沒能釋放造cup資源量消耗除程序本身原能客服端訪問造（客戶端包含蜘蛛軟體等搜索引擎）伺服器客戶端建立鏈接(用netstat -a命令查看網路訪問信息)需要http響應connection做定設置
http1.1requestreponse header都能現connection欄位header含義clientserver通信於鏈接何進行處理http1.1clientserver都默認支持鏈接 client使用http1.1協議希望使用鏈接則需要header指明connection值close；server想支持鏈接則response需要明確說明connection值close
論requestresponseheader包含值closeconnection都表明前使用tcp鏈接請求處理完畢斷掉client再進行新請求必須創建新tcp鏈接
HTTP Connectionclose設置允許客戶端或伺服器任何關閉底層連接雙都要求處理請求關閉TCP連接
何程序設置：濾器加入：response.setHeader(connection, close);
內容自: HTTP Keep-Alive詳解
HTTP Keep Alive
HTTP Keep-Alive 程序誤解面介紹HTTP/1.0HTTP/1.1版本何工作及其JAVA運行原理
HTTP請求響應模式典型範例即客戶端向伺服器發送請求信息伺服器響應信息HTTP版本每請求都創建新客戶端->伺服器連接連接發送請求接收請求模式優點簡單容易理解編程實現；缺點效率低Keep-Alive提用解決效率低問題
HTTP/1.0
HTTP/1.0版本並沒官標准規定Keep-Alive何工作實際附加HTTP/1.0協議客戶端瀏覽器支持Keep-AliveHTTP請求添加欄位 Connection: Keep-Alive伺服器收附帶Connection: Keep-Alive請求響應添加同欄位使用Keep-Alive客戶端伺服器間HTTP連接保持斷（超Keep-Alive規定間意外斷電等情況除外）客戶端發送另外請求使用條已經建立連接
HTTP/1.1
HTTP/1.1版本官規定Keep-Alive使用標准HTTP/1.0版本些同默認情況所HTTP1.1所連接都保持除非請求或響應指明要關閉：Connection: Close Connection: Keep-Alive欄位再沒意義原另外添加新欄位Keep-Alive:欄位並沒詳細描述用做忽略
Not reliable（靠）
HTTP狀態協議意味著每請求都獨立Keep-Alive沒能改變結另外Keep-Alive能保證客戶端伺服器間連接定躍HTTP1.1版本唯能保證連接關閉能通知所應該讓程序依賴於Keep-Alive保持連接特性否則意想
Keep-AlivePOST
HTTP1.1細則規定POST消息體面能任何字元指於某特定瀏覽器能並遵循標准（比POST消息體面放置CRLF符）據我所知部瀏覽器POST消息體都自跟CRLF符再發送何解決問題呢根據面說明POST請求禁止使用Keep-Alive或者由伺服器自忽略CRLF部伺服器都自忽略未經測試前能知道伺服器否做
內容自:
HTTP狀態協議Connection:Keep-Alive容易犯誤區
名詞解釋：
HTTP狀態：狀態指協議於事務處理沒記憶能力伺服器知道客戶端狀態另面講打伺服器網頁前打伺服器網頁間沒任何聯系
要實現購物車需要藉助於Cookie或Session或伺服器端API（NSAPI and ISAPI）記錄些信息請求伺服器結算頁面同些信息提交伺服器
登錄網站登錄狀態由Cookie或Session記憶伺服器並知道否登錄
優點：伺服器用每客戶端連接配內存記憶量狀態用客戶端失連接清理內存更高效處理WEB業務
缺點：客戶端每請求都需要攜帶相應參數伺服器需要處理些參數
Keep-Alive：參考另外篇文章HTTP Keep-Alive 詳解
容易犯誤區：
1、HTTP狀態面向連接協議狀態代表HTTP能保持TCP連接更能代表HTTP使用UDP協議（連接）
2、HTTP/1.1起默認都啟Keep-Alive保持連接特性簡單說網頁打完客戶端伺服器間用於傳輸HTTP數據TCP連接關閉客戶端再訪問伺服器網頁繼續使用條已經建立連接
3、Keep-Alive永久保持連接保持間同伺服器軟體（Apache）設定間
內容自:
Keep-Alive簡介及Tomcat配置
Keep-Alive功能使客戶端伺服器端連接持續效現伺服器繼請求Keep-Alive功能避免建立或者重新建立連接市場 部Web伺服器包括iPlanet、IISApache都支持HTTP Keep-Alive於提供靜態內容網站說功能通用於負擔較重網站說存另外問題：雖客戶保留打連 接定處同影響性能處理暫停期間本釋放資源仍舊佔用Web伺服器應用伺服器同台機器運行Keep-Alive功能資源利用影響尤其突 功能HTTP 1.1預設功能HTTP 1.0加Keep-Alive header提供HTTP持續作用功能
Keep-Alive: timeout=5, max=100
timeout：期間5秒（應httpd.conf參數：KeepAliveTimeout）max百請求強制斷掉連接
timeout間內新連接同max自減1直0強制斷掉
Tomcat相關設置,server.xml Connector 元素
keepAliveTimeout：
間連接close單位milliseconds
maxKeepAliveRequests：
連接數（1表示禁用-1表示限制數默認100般設置100~200間）.
maxKeepAliveRequests=1″避免tomcat產量TIME_WAIT連接定程度避免tomcat假死
<Connector executor=tomcatThreadPool
port=80″ protocol=HTTP/1.1″
connectionTimeout=60000″
keepAliveTimeout=15000″
maxKeepAliveRequests=1″
redirectPort=443″
maxHttpHeaderSize=8192″ URIEncoding=UTF-8″ enableLookups=false acceptCount=100″ disableUploadTimeout=true/>