《圖解http》筆記

第一章 網(wǎng)絡基礎

計算機與網(wǎng)絡設備要相互通信盾似,雙方就必須基于相同的方法。比如雪标,如何探測到通信目標零院、由哪一邊先發(fā)起通信、使用哪種語言進行通信村刨、怎樣結束通信等規(guī)則都需要事先確定告抄。不同的硬件、操作系統(tǒng)之間的通信嵌牺,所有的這一切都需要一種規(guī)則打洼。而我們就把這種規(guī)則稱為協(xié)議(protocol)龄糊。

協(xié)議中存在各式各樣的內(nèi)容。從電纜的規(guī)格到IP地址的選定方法募疮、尋找異地用戶的方法炫惩、雙方建立通信的順序,以及Web頁面顯示需要處理的步驟阿浓,等等他嚷。像這樣把與互聯(lián)網(wǎng)相關聯(lián)的協(xié)議集合起來總稱為TCP/IP。

TCP/IP協(xié)議族里重要的一點就是分層芭毙。TCP/IP協(xié)議族按層次分別分為以下4層:應用層筋蓖、傳輸層、網(wǎng)絡層和數(shù)據(jù)鏈路層稿蹲。分層的好處在于修改一個地方不至于牽一發(fā)動全身扭勉,各層接口可以靈活設計和替換。

應用層

應用層決定了向用戶提供應用服務時通信的活動苛聘。TCP/IP協(xié)議族內(nèi)預存了各類通用的應用服務。比如忠聚,F(xiàn)TP(File?Transfer?Protocol设哗,文件傳輸協(xié)議)和DNS(Domain?Name?System,域名系統(tǒng))服務就是其中兩類两蟀。HTTP協(xié)議也處于該層网梢。

傳輸層

傳輸層對上層應用層,提供處于網(wǎng)絡連接中的兩臺計算機之間的數(shù)據(jù)傳輸赂毯。在傳輸層有兩個性質不同的協(xié)議:TCP(Transmission?Control?Protocol战虏,傳輸控制協(xié)議)和UDP(User?Data?Protocol,用戶數(shù)據(jù)報協(xié)議)党涕。

網(wǎng)絡層(又名網(wǎng)絡互連層)

網(wǎng)絡層用來處理在網(wǎng)絡上流動的數(shù)據(jù)包烦感。數(shù)據(jù)包是網(wǎng)絡傳輸?shù)淖钚?shù)據(jù)單位。該層規(guī)定了通過怎樣的路徑(所謂的傳輸路線)到達對方計算機膛堤,并把數(shù)據(jù)包傳送給對方手趣。與對方計算機之間通過多臺計算機或網(wǎng)絡設備進行傳輸時,網(wǎng)絡層所起的作用就是在眾多的選項內(nèi)選擇一條傳輸路線肥荔。

鏈路層(又名數(shù)據(jù)鏈路層绿渣,網(wǎng)絡接口層)

用來處理連接網(wǎng)絡的硬件部分。包括控制操作系統(tǒng)燕耿、硬件的設備驅動中符、NIC(Network?Interface?Card,網(wǎng)絡適配器誉帅,即網(wǎng)卡)淀散,及光纖等物理可見部分(還包括連接器等一切傳輸媒介)

IP地址對應網(wǎng)絡層IP協(xié)議右莱,而MAC地址,則是數(shù)據(jù)鏈路層上的地址吧凉。

MAC地址:

介質訪問控制(Media?Access?Control)地址一般位于網(wǎng)卡中隧出,用于標識網(wǎng)絡設備,控制對網(wǎng)絡介質的訪問阀捅。例如胀瞪,網(wǎng)絡設備要訪問傳輸電纜(網(wǎng)線,位于物理層)饲鄙,必須具備一個MAC地址凄诞,發(fā)送的數(shù)據(jù)要到達目的地,必須知道目的地的MAC地址忍级。因為一個網(wǎng)卡具有唯一的MAC地址帆谍,所以又叫做物理地址。

發(fā)送端在層與層之間傳輸數(shù)據(jù)時轴咱,每經(jīng)過一層時必定會被打上一個該層所屬的首部信息汛蝙。反之,接收端在層與層傳輸數(shù)據(jù)時朴肺,每經(jīng)過一層時會把對應的首部消去窖剑。這種把數(shù)據(jù)信息包裝起來的做法稱為封裝(encapsulate)。

IP協(xié)議的作用是把各種數(shù)據(jù)包傳送給對方戈稿。而要保證確實傳送到對方那里西土,則需要滿足各類條件。其中兩個重要的條件是IP地址和MAC地址(Media?Access?Control?Address)鞍盗。

IP地址指明了節(jié)點被分配到的地址需了,MAC地址是指網(wǎng)卡所屬的固定地址。IP地址可以和MAC地址進行配對般甲。IP地址可變換肋乍,但MAC地址基本上不會更改。

使用ARP協(xié)議憑借MAC地址進行通信

IP間的通信依賴MAC地址欣除。在網(wǎng)絡上住拭,通信的雙方在同一局域網(wǎng)(LAN)內(nèi)的情況是很少的,通常是經(jīng)過多臺計算機和網(wǎng)絡設備中轉才能連接到對方历帚。而在進行中轉時滔岳,會利用下一站中轉設備的MAC地址來搜索下一個中轉目標。這時挽牢,會采用ARP協(xié)議(Address?Resolution?Protocol)谱煤。ARP是一種用以解析地址的協(xié)議,根據(jù)通信方的IP地址就可以反查出對應的MAC地址禽拔。

確保數(shù)據(jù)能到達目標

為了準確無誤地將數(shù)據(jù)送達目標處刘离,TCP協(xié)議采用了三次握手(three-way?handshaking)策略室叉。用TCP協(xié)議把數(shù)據(jù)包送出去后,TCP不會對傳送后的情況置之不理硫惕,它一定會向對方確認是否成功送達茧痕。握手過程中使用了TCP的標志(flag)——SYN(synchronize)和ACK(acknowledgement)。

發(fā)送端首先發(fā)送一個帶SYN標志的數(shù)據(jù)包給對方恼除。接收端收到后踪旷,回傳一個帶有SYN/ACK標志的數(shù)據(jù)包以示傳達確認信息。最后豁辉,發(fā)送端再回傳一個帶ACK標志的數(shù)據(jù)包令野,代表“握手”結束。若在握手過程中某個階段莫名中斷徽级,TCP協(xié)議會再次以相同的順序發(fā)送相同的數(shù)據(jù)包气破。

DNS根據(jù)域名解析IP地址或通過IP地址反查域名。人類更傾向于字母加數(shù)字記憶餐抢,而計算機更加傾向于單純的數(shù)字記憶现使,因此為了解決二者的沖突,通過使用DNS作為第三方來進行轉換旷痕!

通過這張圖來了解下IP協(xié)議朴下、TCP協(xié)議和DNS服務在使用HTTP協(xié)議的通信過程中各自發(fā)揮了哪些作用。

絕對URI的格式:

第二章 http協(xié)議

HEAD:獲得報文首部

HEAD方法和GET方法一樣苦蒿,只是不返回報文主體部分。用于確認URI的有效性及資源更新的日期時間等渗稍。

TRACE:追蹤路徑

TRACE方法是讓Web服務器端將之前的請求通信環(huán)回給客戶端的方法佩迟。

發(fā)送請求時,在Max-Forwards首部字段中填入數(shù)值竿屹,每經(jīng)過一個服務器端就將該數(shù)字減1报强,當數(shù)值剛好減到0時,就停止繼續(xù)傳輸拱燃,最后接收到請求的服務器端則返回狀態(tài)碼200?OK的響應秉溉。客戶端通過TRACE方法可以查詢發(fā)送出去的請求是怎樣被加工修改/篡改的碗誉。這是因為召嘶,請求想要連接到源目標服務器可能會通過代理中轉,TRACE方法就是用來確認連接過程中發(fā)生的一系列操作哮缺。但是弄跌,TRACE方法本來就不怎么常用,再加上它容易引發(fā)XST(Cross-Site?Tracing尝苇,跨站追蹤)攻擊铛只,通常就更不會用到了埠胖。

管線化

持久連接使得多數(shù)請求以管線化(pipelining)方式發(fā)送成為可能。從前發(fā)送請求后需等待并收到響應淳玩,才能發(fā)送下一個請求直撤。管線化技術出現(xiàn)后,不用等待響應亦可直接發(fā)送下一個請求蜕着。這樣就能夠做到同時并行發(fā)送多個請求谋竖,而不需要一個接一個地等待響應了。

第三章 http報文內(nèi)的http信息

在傳輸大容量數(shù)據(jù)時侮东,通過把數(shù)據(jù)分割成多塊圈盔,能夠讓瀏覽器逐步顯示頁面。這種把實體主體分塊的功能稱為分塊傳輸編碼(Chunked?Transfer?Coding)悄雅。分塊傳輸編碼會將實體主體分成多個部分(塊)驱敲。每一塊都會用十六進制來標記塊的大小,而實體主體的最后一塊會使用“0(CR+LF)”來標記宽闲。

HTTP協(xié)議中也采納了多部分對象集合众眨,發(fā)送的一份報文主體內(nèi)可含有多類型實體。通常是在圖片或文本文件等上傳時使用容诬。

多部分對象集合包含的對象如下娩梨。

●?multipart/form-data

在Web表單文件上傳時使用。

●?multipart/byteranges

狀態(tài)碼206(Partial?Content览徒,部分內(nèi)容)響應報文包含了多個范圍的內(nèi)容時使用狈定。

以前,用戶不能使用現(xiàn)在這種高速的帶寬訪問互聯(lián)網(wǎng)习蓬,當時纽什,下載一個尺寸稍大的圖片或文件就已經(jīng)很吃力了。如果下載過程中遇到網(wǎng)絡中斷的情況躲叼,那就必須重頭開始芦缰。為了解決上述問題,需要一種可恢復的機制枫慷。所謂恢復是指能從之前下載中斷處恢復下載让蕾。

要實現(xiàn)該功能需要指定下載的實體范圍。像這樣或听,指定范圍發(fā)送的請求叫做范圍請求(Range?Request)探孝。對一份10000字節(jié)大小的資源,如果使用范圍請求神帅,可以只請求5001~10000字節(jié)內(nèi)的資源再姑。

執(zhí)行范圍請求時,會用到首部字段Range來指定資源的byte范圍找御。byte范圍的指定形式如下元镀。

Range:?bytes=5001-10000

第四章?http狀態(tài)碼

表4-1:狀態(tài)碼的類別

2xx:200?OK绍填,204?no?contentt?請求成功但沒有資源返回,206?partial?content(只返回部分資源)斷點續(xù)傳和分段下載用到了這個栖疑。類似于?FlashGet?或者迅雷這類的?HTTP下載工具都是使用此類響應實現(xiàn)斷點續(xù)傳或者將一個大文檔分解為多個下載段同時下載讨永。

3xx:客戶端需要做一些操作 ,301永久重定向遇革,302卿闹、303和307功能差不多,用于臨時重定向萝快,304與重定向沒什么關系锻霎,不符合條件不返回響應主體(服務器資源未改變,可使用客戶端沒過期的緩存)

301永久性重定向揪漩。該狀態(tài)碼表示請求的資源已被分配了新的URI旋恼,以后應使用資源現(xiàn)在所指的URI。也就是說奄容,如果已經(jīng)把資源對應的URI保存為書簽了冰更,這時應該按Location首部字段提示的URI重新保存。

302已移動的資源對應的URI將來還有可能發(fā)生改變昂勒。比如蜀细,用戶把URI保存成書簽,但不會像301狀態(tài)碼出現(xiàn)時那樣去更新書簽戈盈,而是仍舊保留返回302狀態(tài)碼的頁面對應的URI奠衔。

303:狀態(tài)碼和302?Found狀態(tài)碼有著相同的功能,但303狀態(tài)碼明確表示客戶端應當采用GET方法獲取資源塘娶,這點與302狀態(tài)碼有區(qū)別涣觉。

304:該狀態(tài)碼表示客戶端發(fā)送附帶條件的請求時,服務器端允許請求訪問資源血柳,但因發(fā)生請求未滿足條件的情況后,直接返回304?Not?Modified(服務器端資源未改變生兆,可直接使用客戶端未過期的緩存)难捌。304狀態(tài)碼返回時,不包含任何響應的主體部分鸦难。304雖然被劃分在3XX類別中根吁,但是和重定向沒有關系。(附帶的條件請求是指if-match等首部字段合蔽,304跟重定向沒有任何關系击敌,雖然劃分在3類型中)

4xx:服務端無法處理,400bad?request請求路徑有問題?401unauthorized?需要http認證?403?forbidden?對請求的資源拒絕訪問?404?no?found找不到資源

5xx:500?(internal?server?error)服務器執(zhí)行請求發(fā)生錯誤拴事,503error(service?unavailale)因過載或停機無法執(zhí)行請求

狀態(tài)碼和狀況的不一致

不少返回的狀態(tài)碼響應都是錯誤的沃斤,但是用戶可能察覺不到這點圣蝎。比如Web應用程序內(nèi)部發(fā)生錯誤,狀態(tài)碼依然返回200?OK衡瓶,這種情況也經(jīng)常遇到徘公。

第五章?與http協(xié)作的web服務器

(同一臺服務器托管多個域名,域名解析出來的IP地址都是相同的哮针。)在互聯(lián)網(wǎng)上关面,域名通過DNS服務映射到IP地址(域名解析)之后訪問目標網(wǎng)站∈幔可見等太,當請求發(fā)送到服務器時,已經(jīng)是以IP地址形式訪問了蛮放。所以缩抡,如果一臺服務器內(nèi)托管了www.tricorder.jp和www.hackr.jp這兩個域名,當收到請求時就需要弄清楚究竟要訪問哪個域名筛武。

在相同的IP地址下缝其,由于虛擬主機可以寄存多個不同主機名和域名的Web網(wǎng)站,因此在發(fā)送HTTP請求時徘六,必須在Host首部內(nèi)完整指定主機名或域名的URI内边。

通信數(shù)據(jù)轉發(fā)程序:代理、網(wǎng)關待锈、隧道

HTTP通信時漠其,除客戶端和服務器以外,還有一些用于通信數(shù)據(jù)轉發(fā)的應用程序竿音,例如代理和屎、網(wǎng)關和隧道。它們可以配合服務器工作春瞬。

這些應用程序和服務器可以將請求轉發(fā)給通信線路上的下一站服務器柴信,并且能接收從那臺服務器發(fā)送的響應再轉發(fā)給客戶端。

代理

代理是一種有轉發(fā)功能的應用程序宽气,它扮演了位于服務器和客戶端“中間人”的角色随常,接收由客戶端發(fā)送的請求并轉發(fā)給服務器,同時也接收服務器返回的響應并轉發(fā)給客戶端萄涯。

代理服務器的基本行為就是接收客戶端發(fā)送的請求后轉發(fā)給其他服務器绪氛。代理不改變請求URI,會直接發(fā)送給前方持有資源的目標服務器涝影。持有資源實體的服務器被稱為源服務器枣察。從源服務器返回的響應經(jīng)過代理服務器后再傳給客戶端。每次通過代理服務器轉發(fā)請求或響應時,會追加寫入Via首部信息

使用代理服務器的理由有:利用緩存技術減少網(wǎng)絡帶寬的流量序目,組織內(nèi)部針對特定網(wǎng)站的訪問控制挺份,以獲取訪問日志為主要目的润努,等等勾邦。

網(wǎng)關

網(wǎng)關是轉發(fā)其他服務器通信數(shù)據(jù)的服務器蒋腮,接收從客戶端發(fā)送來的請求時,它就像自己擁有資源的源服務器一樣對請求進行處理嘿辟。有時客戶端可能都不會察覺舆瘪,自己的通信目標是一個網(wǎng)關。

網(wǎng)關的工作機制和代理十分相似红伦。而網(wǎng)關能使通信線路上的服務器提供非HTTP協(xié)議服務英古。

利用網(wǎng)關能提高通信的安全性,因為可以在客戶端與網(wǎng)關之間的通信線路上加密以確保連接的安全昙读。比如召调,網(wǎng)關可以連接數(shù)據(jù)庫,使用SQL語句查詢數(shù)據(jù)蛮浑。另外唠叛,在Web購物網(wǎng)站上進行信用卡結算時,網(wǎng)關可以和信用卡結算系統(tǒng)聯(lián)動沮稚。

隧道

隧道是在相隔甚遠的客戶端和服務器兩者之間進行中轉艺沼,并保持雙方通信連接的應用程序。

隧道可按要求建立起一條與其他服務器的通信線路蕴掏,屆時使用SSL等加密手段進行通信障般。隧道的目的是確保客戶端能與服務器進行安全的通信盛杰。通過隧道的傳輸挽荡,可以和遠距離的服務器安全通信。隧道本身是透明的即供,客戶端不用在意隧道的存在

除了本地磁盤可以做緩存定拟,代理服務器也可以做緩存。還有本地瀏覽器緩存逗嫡。瀏覽器緩存如果有效办素,就不必再向服務器請求相同的資源了,可以直接從本地磁盤內(nèi)讀取祸穷。

第六章?http首部

HTTP請求報文

在請求中,HTTP報文由方法勺三、URI雷滚、HTTP版本、HTTP首部字段等部分構成吗坚。

HTTP響應報文

在響應中祈远,HTTP報文由HTTP版本呆万、狀態(tài)碼(數(shù)字和原因短語)、HTTP首部字段3部分構成车份。

使用首部字段是為了給瀏覽器和服務器提供報文主體大小谋减、所使用的語言、認證信息等內(nèi)容扫沼。

通用首部字段是指出爹,請求報文和響應報文雙方都會使用的首部。

Cache-Control

通過指定首部字段Cache-Control的指令缎除,就能操作緩存的工作機制严就。

Cache-Control:?no-cache

使用no-cache指令的目的是為了防止從緩存中返回過期的資源。

Cache-Control:?max-age=604800(單位:秒)

當客戶端發(fā)送的請求中包含max-age指令時器罐,如果判定緩存資源的緩存時間數(shù)值比指定時間的數(shù)值更小梢为,那么客戶端就接收緩存的資源。另外轰坊,當指定max-age值為0铸董,那么緩存服務器通常需要將請求轉發(fā)給源服務器。

當服務器返回的響應中包含max-age指令時肴沫,緩存服務器將不對資源的有效性再作確認粟害,而max-age數(shù)值代表資源保存為緩存的最長時間。

Connection:?close

HTTP/1.1版本的默認連接都是持久連接樊零。為此我磁,客戶端會在持久連接上連續(xù)發(fā)送請求。當服務器端想明確斷開連接時驻襟,則指定Connection首部字段的值為Close夺艰。

Connection:?Keep-Alive

HTTP/1.1之前的HTTP版本的默認連接都是非持久連接。為此沉衣,如果想在舊版本的HTTP協(xié)議上維持持續(xù)連接郁副,則需要指定Connection首部字段的值為Keep-Alive。

Upgrade

首部字段Upgrade用于檢測HTTP協(xié)議及其他協(xié)議是否可使用更高的版本進行通信豌习,其參數(shù)值可以用來指定一個完全不同的通信協(xié)議存谎。

Upgrade首部字段產(chǎn)生作用的Upgrade對象僅限于客戶端和鄰接服務器之間。因此肥隆,使用首部字段Upgrade時既荚,還需要額外指定Connection:Upgrade。

Via

使用首部字段Via是為了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑栋艳。

Host:?www.hackr.jp

首部字段Host會告知服務器恰聘,請求的資源所處的互聯(lián)網(wǎng)主機名和端口號。Host首部字段在HTTP/1.1規(guī)范內(nèi)是唯一一個必須被包含在請求內(nèi)的首部字段。首部字段Host和以單臺服務器分配多個域名的虛擬主機的工作機制有很密切的關聯(lián)晴叨,這是首部字段Host必須存在的意義凿宾。

請求被發(fā)送至服務器時,請求中的主機名會用IP地址直接替換解決兼蕊。但如果這時初厚,相同的IP地址下部署運行著多個域名,那么服務器就會無法理解究竟是哪個域名對應的請求孙技。因此产禾,就需要使用首部字段Host來明確指出請求的主機名。若服務器未設定主機名绪杏,那直接發(fā)送一個空值即可下愈。

If-Match:附帶條件請求

形如If-xxx這種樣式的請求首部字段,都可稱為條件請求蕾久。服務器接收到附帶條件的請求后势似,只有判斷指定條件為真時,才會執(zhí)行請求僧著。

If-Modified-Since:?Thu,?15?Apr?2004?00:00:00

if-modified-since用來確認資源的有效性履因,資源是在該時間之后更新過的,服務器會返回更新的資源盹愚。

User-Agent:?Mozilla/5.0?(Windows?NT?6.1;?WOW64;?rv:13.0)?Gecko/=>

20100101?Firefox/13.0.1

首部字段User-Agent會將創(chuàng)建請求的瀏覽器和用戶代理名稱等信息傳達給服務器栅迄。

Server:?Apache/2.2.17?(Unix)

首部字段Server告知客戶端當前服務器上安裝的HTTP服務器應用程序的信息。不單單會標出服務器上的軟件應用名稱皆怕,還有可能包括版本號和安裝時啟用的可選項毅舆。

Expires:?Wed,?04?Jul?2012?08:26:05?GMT

首部字段Expires會將資源失效的日期告知客戶端。

Set-Cookie:?status=enable;?expires=Tue,?05?Jul?2011?07:26:31?GMT;?=>

path=/;?domain=.hackr.jp;

當省略expires屬性時愈腾,其有效期僅限于維持瀏覽器會話(Session)時間段內(nèi)憋活。這通常限于瀏覽器應用程序被關閉之前。

Cookie的secure屬性用于限制Web頁面僅在HTTPS安全連接時虱黄,才可以發(fā)送Cookie悦即。

Cookie的HttpOnly屬性是Cookie的擴展功能,它使JavaScript腳本無法獲得Cookie橱乱。其主要目的為防止跨站腳本攻擊(Cross-site?scripting,XSS)對Cookie的信息竊取辜梳。

第七章?確保安全的https

HTTP主要有這些不足,例舉如下泳叠。

●通信使用明文(不加密)作瞄,內(nèi)容可能會被竊聽

●不驗證通信方的身份,因此有可能遭遇偽裝

●無法證明報文的完整性危纫,所以有可能已遭篡改

互聯(lián)網(wǎng)上的任何角落都存在通信內(nèi)容被竊聽的風險

竊聽相同段上的通信并非難事宗挥。只需要收集在互聯(lián)網(wǎng)上流動的數(shù)據(jù)包(幀)就行了节预。對于收集來的數(shù)據(jù)包的解析工作,可交給那些抓包(Packet?Capture)或嗅探器(Sniffer)工具属韧。

通信的加密

一種方式就是將通信加密。HTTP協(xié)議中沒有加密機制蛤吓,但可以通過和SSL(Secure?Socket?Layer宵喂,安全套接層)或TLS(Transport?Layer?Security,安全傳輸層協(xié)議)的組合使用会傲,加密HTTP的通信內(nèi)容锅棕。

用SSL建立安全通信線路之后,就可以在這條線路上進行HTTP通信了淌山。與SSL組合使用的HTTP被稱為HTTPS(HTTP?Secure裸燎,超文本傳輸安全協(xié)議)或HTTP?over?SSL。

中間人攻擊:

比如泼疑,從某個Web網(wǎng)站上下載內(nèi)容德绿,是無法確定客戶端下載的文件和服務器上存放的文件是否前后一致的。文件內(nèi)容在傳輸途中可能已經(jīng)被篡改為其他的內(nèi)容退渗。即使內(nèi)容真的已改變移稳,作為接收方的客戶端也是覺察不到的。像這樣会油,請求或響應在傳輸途中个粱,遭攻擊者攔截并篡改內(nèi)容的攻擊稱為中間人攻擊(Man-in-the-Middle?attack,MITM)

HTTP+加密+認證+完整性保護=HTTPS

對稱密鑰加密:加密、解密一把鑰匙翻翩,為解決共享密鑰的問題都许,提出非對稱密鑰加密:加密用公鑰,解密用私鑰嫂冻。共享密鑰加密也稱為對稱密鑰加密胶征。公開密鑰加密也稱為非對稱密鑰加密。

混合加密方式:https是對通信內(nèi)容做對稱加密(速度快)絮吵,然后對對稱加密的密鑰做非對稱加密(安全)弧烤,充分利用兩者的優(yōu)勢

證明公開密鑰正確性的證書

使用由數(shù)字證書認證機構(CA,Certificate?Authority)和其相關機關頒發(fā)的公開密鑰證書。

用以確認客戶端的客戶端證書

銀行的網(wǎng)上銀行就采用了客戶端證書蹬敲。在登錄網(wǎng)銀時不僅要求用戶確認輸入ID和密碼暇昂,還會要求用戶的客戶端證書,以確認用戶是否從特定的終端訪問網(wǎng)銀伴嗡。

由自認證機構頒發(fā)的證書稱為自簽名證書

如果使用OpenSSL這套開源程序急波,每個人都可以構建一套屬于自己的認證機構,從而自己給自己頒發(fā)服務器證書瘪校。但該服務器證書在互聯(lián)網(wǎng)上不可作為證書使用澄暮,似乎沒什么幫助名段。獨立構建的認證機構叫做自認證機構,由自認證機構頒發(fā)的“無用”證書也被戲稱為自簽名證書泣懊。瀏覽器訪問該服務器時伸辟,會顯示“無法確認連接安全性”或“該網(wǎng)站的安全證書存在問題”等警告消息。

HTTPS的安全通信機制:

1.選擇加密算法和相應組件

2.傳輸加密公鑰

3.建立SSL通道

4.傳輸HTTP報文

為什么不一直使用HTTPS

既然HTTPS那么安全可靠馍刮,那為何所有的Web網(wǎng)站不一直使用HTTPS信夫?其中一個原因是,因為與純文本通信相比卡啰,加密通信會消耗更多的CPU及內(nèi)存資源静稻。如果每次通信都加密,會消耗相當多的資源匈辱,平攤到一臺計算機上時振湾,能夠處理的請求數(shù)量必定也會隨之減少。

因此亡脸,如果是非敏感信息則使用HTTP通信押搪,只有在包含個人信息等敏感數(shù)據(jù)時,才利用HTTPS加密通信梗掰。特別是每當那些訪問量較多的Web網(wǎng)站在進行加密處理時嵌言,它們所承擔著的負載不容小覷。在進行加密處理時及穗,并非對所有內(nèi)容都進行加密處理摧茴,而是僅在那些需要信息隱藏時才會加密,以節(jié)約資源埂陆。

第11章?針對web的攻擊技術

在HTTP請求報文內(nèi)加載攻擊代碼苛白,就能發(fā)起對Web應用的攻擊。通過URL查詢字段或表單焚虱、HTTP首部购裙、Cookie等途徑把攻擊代碼傳入,若這時Web應用存在安全漏洞鹃栽,那內(nèi)部信息就會遭到竊取躏率,或被攻擊者拿到管理權限。

對Web應用的攻擊模式有以下兩種

●主動攻擊

●被動攻擊

主動攻擊模式里具有代表性的攻擊是SQL注入攻擊和OS命令注入攻擊民鼓。

被動攻擊(passive?attack)是指利用圈套策略執(zhí)行攻擊代碼的攻擊模式薇芝。

被動攻擊模式中具有代表性的攻擊是跨站腳本攻擊和跨站點請求偽造。

實施Web應用的安全對策可大致分為以下兩部分

●客戶端的驗證

●Web應用端(服務器端)的驗證

○?輸入值驗證

○?輸出值轉義

從數(shù)據(jù)庫或文件系統(tǒng)丰嘉、HTML夯到、郵件等輸出Web應用處理的數(shù)據(jù)之際,針對輸出做值轉義處理是一項至關重要的安全策略饮亏。當輸出值轉義不完全時耍贾,會因觸發(fā)攻擊者傳入的攻擊代碼阅爽,而給輸出對象帶來損害。

跨站腳本攻擊(Cross-Site?Scripting,XSS)是指通過存在安全漏洞的Web網(wǎng)站注冊用戶的瀏覽器內(nèi)運行非法的HTML標簽或JavaScript進行的一種攻擊荐开。

SQL注入(SQL?Injection)是指針對Web應用使用的數(shù)據(jù)庫付翁,通過運行非法的SQL而產(chǎn)生的攻擊。該安全隱患有可能引發(fā)極大的威脅晃听,有時會直接導致個人信息及機密信息的泄露胆敞。

Web應用通常都會用到數(shù)據(jù)庫,當需要對數(shù)據(jù)庫表內(nèi)的數(shù)據(jù)進行檢索或添加杂伟、刪除等操作時,會使用SQL語句連接數(shù)據(jù)庫進行特定的操作仍翰。如果在調用SQL語句的方式上存在疏漏赫粥,就有可能執(zhí)行被惡意注入(Injection)非法SQL語句。

SQL注入攻擊有可能會造成以下等影響予借。

●非法查看或篡改數(shù)據(jù)庫內(nèi)的數(shù)據(jù)

●規(guī)避認證

●執(zhí)行和數(shù)據(jù)庫服務器業(yè)務關聯(lián)的程序等

OS命令注入攻擊(OS?Command?Injection)是指通過Web應用越平,執(zhí)行非法的操作系統(tǒng)命令達到攻擊的目的。只要在能調用Shell函數(shù)的地方就有存在被攻擊的風險灵迫。

可以從Web應用中通過Shell來調用操作系統(tǒng)命令秦叛。倘若調用Shell時存在疏漏,就可以執(zhí)行插入的非法OS命令瀑粥。

HTTP首部注入攻擊(HTTP?Header?Injection)是指攻擊者通過在響應首部字段內(nèi)插入換行挣跋,添加任意響應首部或主體的一種攻擊。屬于被動攻擊模式狞换。

向首部主體內(nèi)添加內(nèi)容的攻擊稱為HTTP響應截斷攻擊(HTTP?Response?Splitting?Attack)避咆。

HTTP首部注入攻擊有可能會造成以下一些影響。

●設置任何Cookie信息

●重定向至任意URL

●顯示任意的主體(HTTP響應截斷攻擊)

HTTP響應截斷攻擊是用在HTTP首部注入的一種攻擊修噪。攻擊順序相同查库,但是要將兩個%0D%0A%0D%0A并排插入字符串后發(fā)送。利用這兩個連續(xù)的換行就可作出HTTP首部與主體分隔所需的空行了黄琼,這樣就能顯示偽造的主體樊销,達到攻擊目的。這樣的攻擊叫做HTTP響應截斷攻擊脏款。

會話劫持(Session?Hijack)是指攻擊者通過某種手段拿到了用戶的會話ID围苫,并非法使用此會話ID偽裝成用戶,達到攻擊的目的弛矛。

跨站點請求偽造(Cross-Site?Request?Forgeries,CSRF)攻擊是指攻擊者通過設置好的陷阱够吩,強制對已完成認證的用戶進行非預期的個人信息或設定信息等某些狀態(tài)更新,屬于被動攻擊丈氓。

跨站點請求偽造有可能會造成以下等影響周循。

●利用已通過認證的用戶權限更新設定信息等

●利用已通過認證的用戶權限購買商品

●利用已通過認證的用戶權限在留言板上發(fā)表言論

通過網(wǎng)絡進行密碼試錯

對Web應用提供的認證功能强法,通過網(wǎng)絡嘗試候選密碼進行的一種攻擊。主要有以下兩種方式湾笛。

●窮舉法

●字典攻擊

DoS攻擊(Denial?of?Service?attack)是一種讓運行中的服務呈停止狀態(tài)的攻擊饮怯。有時也叫做服務停止攻擊或拒絕服務攻擊。DoS攻擊的對象不僅限于Web網(wǎng)站嚎研,還包括網(wǎng)絡設備及服務器等蓖墅。

主要有以下兩種DoS攻擊方式。

●?集中利用訪問請求造成資源過載临扮,資源用盡的同時论矾,實際上服務也就呈停止狀態(tài)。

●通過攻擊安全漏洞使服務停止杆勇。

其中贪壳,集中利用訪問請求的DoS攻擊,單純來講就是發(fā)送大量的合法請求蚜退。服務器很難分辨何為正常請求闰靴,何為攻擊請求,因此很難防止DoS攻擊钻注。

多臺計算機發(fā)起的DoS攻擊稱為DDoS攻擊(Distributed?Denial?of?Service?attack)蚂且。DDoS攻擊通常利用那些感染病毒的計算機作為攻擊者的攻擊跳板。

?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末幅恋,一起剝皮案震驚了整個濱河市杏死,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌捆交,老刑警劉巖识埋,帶你破解...
    沈念sama閱讀 219,110評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異零渐,居然都是意外死亡窒舟,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,443評論 3 395
  • 文/潘曉璐 我一進店門诵盼,熙熙樓的掌柜王于貴愁眉苦臉地迎上來惠豺,“玉大人,你說我怎么就攤上這事风宁〗嗲剑” “怎么了?”我有些...
    開封第一講書人閱讀 165,474評論 0 356
  • 文/不壞的土叔 我叫張陵戒财,是天一觀的道長热监。 經(jīng)常有香客問我,道長饮寞,這世上最難降的妖魔是什么孝扛? 我笑而不...
    開封第一講書人閱讀 58,881評論 1 295
  • 正文 為了忘掉前任列吼,我火速辦了婚禮,結果婚禮上苦始,老公的妹妹穿的比我還像新娘寞钥。我一直安慰自己,他們只是感情好陌选,可當我...
    茶點故事閱讀 67,902評論 6 392
  • 文/花漫 我一把揭開白布理郑。 她就那樣靜靜地躺著,像睡著了一般咨油。 火紅的嫁衣襯著肌膚如雪您炉。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,698評論 1 305
  • 那天役电,我揣著相機與錄音邻吭,去河邊找鬼。 笑死宴霸,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的膏蚓。 我是一名探鬼主播瓢谢,決...
    沈念sama閱讀 40,418評論 3 419
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼驮瞧!你這毒婦竟也來了氓扛?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 39,332評論 0 276
  • 序言:老撾萬榮一對情侶失蹤论笔,失蹤者是張志新(化名)和其女友劉穎采郎,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體狂魔,經(jīng)...
    沈念sama閱讀 45,796評論 1 316
  • 正文 獨居荒郊野嶺守林人離奇死亡蒜埋,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,968評論 3 337
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了最楷。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片整份。...
    茶點故事閱讀 40,110評論 1 351
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖籽孙,靈堂內(nèi)的尸體忽然破棺而出烈评,到底是詐尸還是另有隱情,我是刑警寧澤犯建,帶...
    沈念sama閱讀 35,792評論 5 346
  • 正文 年R本政府宣布讲冠,位于F島的核電站,受9級特大地震影響适瓦,放射性物質發(fā)生泄漏竿开。R本人自食惡果不足惜谱仪,卻給世界環(huán)境...
    茶點故事閱讀 41,455評論 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望德迹。 院中可真熱鬧芽卿,春花似錦、人聲如沸胳搞。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,003評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽肌毅。三九已至筷转,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間悬而,已是汗流浹背呜舒。 一陣腳步聲響...
    開封第一講書人閱讀 33,130評論 1 272
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留笨奠,地道東北人袭蝗。 一個月前我還...
    沈念sama閱讀 48,348評論 3 373
  • 正文 我出身青樓,卻偏偏與公主長得像般婆,于是被迫代替她去往敵國和親到腥。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 45,047評論 2 355

推薦閱讀更多精彩內(nèi)容

  • 第一章:Web及網(wǎng)絡基礎 TCP/IP是互聯(lián)網(wǎng)相關的各類協(xié)議族的總稱蔚袍,包含TCP乡范、UDP、HTTP啤咽、FTP晋辆、IP、...
    loneyzhou閱讀 389評論 0 1
  • 請求首部字段 請求首部字段是從客戶端往服務器端發(fā)送請求報文中所使用的字段宇整, 用于補充請求的附加信息瓶佳、客戶端信息、對...
    THINKA閱讀 292評論 0 0
  • 與 HTTP 協(xié)作的 Web 服務器 一臺 Web 服務器可搭建多個獨立域名的 Web 網(wǎng)站鳞青,也可作為通信路徑上的...
    THINKA閱讀 482評論 0 0
  • Web 頁面的實現(xiàn) Web 基于 HTTP 協(xié)議通信 客戶端(Client)的 Web 瀏覽器從 Web 服務器端...
    毛圈閱讀 1,090評論 0 2
  • 從小就喜歡看古裝電視劇涩哟,因為覺得很好看。那些現(xiàn)代偶像劇總覺得看了開頭就知道結局了盼玄,可是古裝劇不一樣贴彼,想象空間大,劇...
    200523c0e810閱讀 98評論 0 0