一句占、什么是HTTP協(xié)議沪摄？

是什么？

HTTP協(xié)議：即超文本傳輸協(xié)議。

做什么杨拐？

主要用于：用于服務(wù)器跟客戶端進(jìn)行一個(gè)通訊的協(xié)議祈餐。

怎么做？

工作機(jī)制：在客戶端跟服務(wù)器之間以request-response Protocol（請求-回復(fù)協(xié)議）工作哄陶。

二帆阳、HTTP協(xié)議傳輸請求方法：

標(biāo)準(zhǔn)Http協(xié)議支持八種請求方法,即:

1.get

是什么？

GET是HTTP傳輸?shù)某Ｓ梅椒?/p>

做什么屋吨？

從指定服務(wù)器中獲取數(shù)據(jù)蜒谤。

怎么做？

使用GET方法時(shí)至扰，查詢字符串（鍵值對）被附加在URL地址后面一起發(fā)送到服務(wù)器

DEMO：/test/demo_form.jsp?name1=value1&name2=value2

其中name1對應(yīng)的值就是value1鳍徽，name2對應(yīng)的值就是value2，中間用&分割

特點(diǎn)：

~GET請求能夠被緩存

~GET請求會(huì)保存在瀏覽器的瀏覽記錄中

~以GET請求的URL可以保存為瀏覽器書簽

~GET請求有長度限制敢课，大小為2K旬盯。其實(shí)此長度限制，是由于瀏覽器對URL有一個(gè)長度限制翎猛。此文有講述。

~GET請求主要用于獲取數(shù)據(jù)

2.post

是什么接剩？

HTTP常用的方法切厘。

做什么？

提交數(shù)據(jù)給指定服務(wù)器處理懊缺。

怎么做疫稿？

使用POST請求，查詢字符串在POST中單獨(dú)存在鹃两，和HTTP請求一起發(fā)送到服務(wù)器遗座。

DEMO：

POST /test/demo_form.jsp HTTP/1.1

Host: w3schools.com

name1:value1

name2:value2

特點(diǎn)：

~POST請求不能被緩存下來

~POST請求不會(huì)保存在瀏覽器瀏覽記錄中

~以POST請求的URL無法保存為瀏覽器書簽

~POST請求沒有長度限制

3.head

與GET請求類似，不同在與服務(wù)器只返回HTTP頭部信息俊扳，沒有頁面內(nèi)容

4.delete

顧名思義途蒋，Delete方法就是通過http請求刪除指定的URL上的資源啦

HTTP提供了一個(gè)與PUT方法對應(yīng)的DELETE方法。一個(gè)DELETE請求將需要從Web服務(wù)器刪除的內(nèi)容指定為請求行中的資源部分馋记。

DELETE方法唯一有趣的地方在于當(dāng)你接收了一個(gè)標(biāo)識為200 OK的響應(yīng)的時(shí)候号坡，那并不意味著指定的資源已經(jīng)被刪除了。那僅僅說明服務(wù)器接收到了刪除資源的命令梯醒。這一例外允許了出于安全考慮的人為的干預(yù)，Delete請求一般會(huì)返回3種狀態(tài)碼：

200 (OK) - 刪除成功茸习，同時(shí)返回已經(jīng)刪除的資源

202 (Accepted) - 刪除請求已經(jīng)接受畜隶，但沒有被立即執(zhí)行（資源也許已經(jīng)被轉(zhuǎn)移到了待刪除區(qū)域）

204 (No Content) - 刪除請求已經(jīng)被執(zhí)行，但是沒有返回資源（也許是請求刪除不存在的資源造成的）

5.put

上傳指定URL的描述

put方法跟Post相似籽慢，但不常用浸遗。

根本區(qū)別：

POST請求后极景，URL后續(xù)處理與請求前再無聯(lián)系盼樟，可以重定向指定資源氢卡。

PUT請求后译秦，會(huì)反饋狀態(tài)碼，且不會(huì)重定向指定資源击碗。

6.options

返回服務(wù)器支持的HTTP方法筑悴。

OPTIONS請求方法的主要用途有兩個(gè)：

1、獲取服務(wù)器支持的HTTP請求方法稍途；也是黑客經(jīng)常使用的方法阁吝。

2、用來檢查服務(wù)器的性能械拍。例如：AJAX進(jìn)行跨域請求時(shí)的預(yù)檢突勇，需要向另外一個(gè)域名的資源發(fā)送一個(gè)HTTP OPTIONS請求頭，用以判斷實(shí)際發(fā)送的請求是否安全坷虑。

7.trace

支持該方式的服務(wù)器存在跨站腳本漏洞甲馋，通常在描述各種瀏覽器缺陷的時(shí)候，把"Cross-Site-Tracing"簡稱為XST迄损。

攻擊者可以利用此漏洞欺騙合法用戶并得到他們的私人信息定躏。

URL: XXX

漏洞等級: 提示

威脅類型: TRACE Method Enabled

可能導(dǎo)致: 啟用TRACE方法存在如下風(fēng)險(xiǎn)：

1、惡意攻擊者可以通過TRACE方法返回的信息了解到網(wǎng)站前端的某些信息芹敌，如果緩存服務(wù)器等共屈，從而為進(jìn)一步的攻擊提供便利；

2党窜、惡意攻擊者可以通過TRACE方法進(jìn)行XSS攻擊拗引，盜取會(huì)話cookie、獲取賬戶幌衣、模擬其他用戶身份矾削，甚至可以修改網(wǎng)頁呈現(xiàn)給其他用戶的內(nèi)容壤玫，從而給用戶帶來損失；

3哼凯、即使網(wǎng)站對關(guān)鍵頁面啟用了HttpOnly頭標(biāo)記欲间，禁止腳本讀取cookie信息時(shí)，通過使用Trace方法断部，惡意攻擊者可以繞過這個(gè)限制猎贴，讀取cookie信息。

描述: 目標(biāo)WEB服務(wù)器啟用了TRACE方法蝴光。

TRACE方法是HTTP（超文本傳輸）協(xié)議定義的一種協(xié)議調(diào)試方法她渴，該方法使得服務(wù)器原樣返回任何客戶端請求的內(nèi)容（可能會(huì)附加路由中間的代理服務(wù)器的信息），由于該方法原樣返回客戶端提交的任意數(shù)據(jù)蔑祟，因此趁耗，可用來進(jìn)行跨站腳本（XSS）攻擊，這種攻擊方式又稱為跨站跟蹤攻擊（XST）疆虚。

建議: 如非必要苛败，請禁用TRACE方法。

解決方案：

1）2.0.55以上版本的Apache服務(wù)器径簿，可以在httpd.conf的尾部添加：

TraceEnable off

2）如果你使用的是Apache：

-? 確認(rèn)rewrite模塊激活（httpd.conf罢屈，下面一行前面沒有#）：

LoadModule rewrite_module modules/mod_rewrite.so

- 在各虛擬主機(jī)的配置文件里添加如下語句：

RewriteEngine On

RewriteCond %{REQUEST_METHOD} ^TRACE

RewriteRule .* – [F]

注：可以在httpd.conf里搜索VirtualHost確定虛擬主機(jī)的配置文件。

trace的攻擊方法篇亭，在網(wǎng)上沒有找到多少缠捌。找到了trace 方法

traceroute

Version 1.4a12+Darwin

Usage: traceroute [-adDeFInrSvx] [-A as_server] [-f first_ttl] [-g gateway] [-i iface]

[-M first_ttl] [-m max_ttl] [-p port] [-P proto] [-q nqueries] [-s src_addr]

[-t tos] [-w waittime] [-z pausemsecs] host [packetlen]

詳情請看traceroute使用

8.connect

轉(zhuǎn)換為透明TCP/IP隧道的連接請求。

CONNECT與GET等的不同之處就在于代理服務(wù)器對CONNECT連接處理為建立一個(gè)到目標(biāo)服務(wù)器的連接而不把CONNECT請求發(fā)送出去暗赶，建立連接以后代理服務(wù)器不會(huì)對連接數(shù)據(jù)作任何修改，只是轉(zhuǎn)發(fā)

三肃叶、COOKIE和SESSION

作者：知乎用戶

鏈接：https://www.zhihu.com/question/19786827/answer/28752144

來源：知乎

著作權(quán)歸作者所有蹂随。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處因惭。

1. 由于HTTP協(xié)議是無狀態(tài)的協(xié)議岳锁，所以服務(wù)端需要記錄用戶的狀態(tài)時(shí)，就需要用某種機(jī)制來識具體的用戶蹦魔，這個(gè)機(jī)制就是Session.典型的場景比如購物車激率，當(dāng)你點(diǎn)擊下單按鈕時(shí)，由于HTTP協(xié)議無狀態(tài)勿决，所以并不知道是哪個(gè)用戶操作的乒躺，所以服務(wù)端要為特定的用戶創(chuàng)建了特定的Session，用用于標(biāo)識這個(gè)用戶低缩，并且跟蹤用戶嘉冒，這樣才知道購物車?yán)锩嬗袔妆緯芑酢＿@個(gè)Session是保存在服務(wù)端的，有一個(gè)唯一標(biāo)識讳推。在服務(wù)端保存Session的方法很多顶籽，內(nèi)存、數(shù)據(jù)庫银觅、文件都有礼饱。集群的時(shí)候也要考慮Session的轉(zhuǎn)移，在大型的網(wǎng)站究驴，一般會(huì)有專門的Session服務(wù)器集群镊绪，用來保存用戶會(huì)話，這個(gè)時(shí)候 Session 信息都是放在內(nèi)存的纳胧，使用一些緩存服務(wù)比如Memcached之類的來放 Session镰吆。

2. 思考一下服務(wù)端如何識別特定的客戶？這個(gè)時(shí)候Cookie就登場了跑慕。每次HTTP請求的時(shí)候万皿，客戶端都會(huì)發(fā)送相應(yīng)的Cookie信息到服務(wù)端。實(shí)際上大多數(shù)的應(yīng)用都是用 Cookie 來實(shí)現(xiàn)Session跟蹤的核行，第一次創(chuàng)建Session的時(shí)候牢硅，服務(wù)端會(huì)在HTTP協(xié)議中告訴客戶端，需要在 Cookie 里面記錄一個(gè)Session ID芝雪，以后每次請求把這個(gè)會(huì)話ID發(fā)送到服務(wù)器减余，我就知道你是誰了。有人問惩系，如果客戶端的瀏覽器禁用了 Cookie 怎么辦位岔？一般這種情況下，會(huì)使用一種叫做URL重寫的技術(shù)來進(jìn)行會(huì)話跟蹤堡牡，即每次HTTP交互抒抬，URL后面都會(huì)被附加上一個(gè)諸如 sid=xxxxx 這樣的參數(shù)，服務(wù)端據(jù)此來識別用戶晤柄。

3. Cookie其實(shí)還可以用在一些方便用戶的場景下擦剑，設(shè)想你某次登陸過一個(gè)網(wǎng)站，下次登錄的時(shí)候不想再次輸入賬號了芥颈，怎么辦惠勒？這個(gè)信息可以寫到Cookie里面，訪問網(wǎng)站的時(shí)候爬坑，網(wǎng)站頁面的腳本可以讀取這個(gè)信息纠屋，就自動(dòng)幫你把用戶名給填了，能夠方便一下用戶盾计。這也是Cookie名稱的由來巾遭，給用戶的一點(diǎn)甜頭肉康。

所以，總結(jié)一下：

Session是在服務(wù)端保存的一個(gè)數(shù)據(jù)結(jié)構(gòu)灼舍，用來跟蹤用戶的狀態(tài)吼和，這個(gè)數(shù)據(jù)可以保存在集群、數(shù)據(jù)庫骑素、文件中炫乓；

Cookie是客戶端保存用戶信息的一種機(jī)制，用來記錄用戶的一些信息献丑，也是實(shí)現(xiàn)Session的一種方式末捣。

具體分析，請看知乎的一些觀點(diǎn)创橄。