整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
本文中，我將向您介紹HTTP的基礎知識。
為什么我應該閱讀有關您可能會問自己的HTTP？
那么，如果你是一個軟件開發者，你就會明白如何通過學習他們如何溝通來編寫更好的應用程序。如果您是系統架構師或網絡管理員，您將會對設計復雜的網絡架構有更深入的了解。
當今非常重要的架構風格REST完全依賴于HTTP功能，因此使HTTP更加重要。如果你想制作很好的RESTful應用程序，你必須先了解HTTP。
我不應該認為REST不僅僅依賴于HTTP。它可以使用其他協議來實現，但HTTP似乎遠勝于此，并且很難找到使用其他協議的REST實現。
那么你是否愿意傳遞機會去理解和學習萬維網和網絡通信的基本概念？
本文將重點介紹HTTP中最重要的部分，并試圖盡可能簡單地解釋它們。這個想法是在一個地方組織所有有關HTTP的有用信息，為您節省閱讀書籍和RFC的時間以找到您需要的信息。
毫不遲疑，讓我們潛入。
HTTP的創始人是Tim Berners-Lee （該人也被認為是萬維網的發明人）。其他對HTTP開發很重要的名字還有Roy Fielding，他也是REST架構風格的創始人。
超文本傳輸協議是應用程序用來相互通信的協議。本質上，HTTP負責委托客戶端和服務器之間的所有互聯網媒體文件。這包括HTML，圖像，文本文件，電影和其中的一切。它可以快速可靠地完成這項工作。
HTTP是 應用程序協議而不是傳輸協議，因為它用于應用程序層的通信。在這里慢跑你的記憶是網絡堆棧的樣子。
從這張圖片中，您可以清楚地看到HTTP是應用程序協議，并且TCP在傳輸層上工作。
互聯網上的所有內容都是資源，HTTP與資源一起工作。這包括文件，流，服務和其他一切。一個HTML頁面是一個資源，一個YouTube視頻是一個資源，一個Web應用程序的日常任務的電子表格是一個資源...你明白了。
你如何區分一種資源與另一種資源？
通過給他們URL（統一資源定位器）。
URL指向可以找到資源的唯一位置。
在WEB客戶端和WEB服務器之間如何交換消息
每一個內容，每個資源都存在于某個Web服務器（HTTP服務器）上。這些服務器正在等待這些資源的HTTP請求。
但是，您如何從Web服務器請求資源？
當然你需要一個HTTP客戶端
您現在正在使用HTTP客戶端來閱讀本文。Web瀏覽器是HTTP客戶端。他們與HTTP服務器通信以將資源提取到您的計算機。一些最受歡迎的客戶是Google的Chrome，Mozilla的Firefox，Opera，Apple的Safari，不幸的是仍然是臭名昭著的Internet Explorer。
消息和一些消息示例
那么HTTP消息是什么樣的？
不用太多地談論它，下面是一些HTTP消息的例子：
GET請求
GET/repos/CodeMazeBlog/ConsumeRestfulApisExamples HTTP/1.1
Host:api.github.com
Content-Type:application/json
Authorization:Basic dGhhbmtzIEhhcmFsZCBSb21iYXV0LCBtdWNoIGFwcHJlY2lhdGVk
Cache-Control:no-cache
POST請求
POST/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks?access_token=5643f4128a9cf974517346b2158d04c8aa7ad45fHTTP/1.1
Host:api.github.com
Content-Type:application/json
Cache-Control:no-cache
{
"url":"http://www.example.com/example",
"events":[
"push"
],
"name":"web",
"active":true,
"config":{
"url":"http://www.example.com/example",
"content_type":"json"
}
}
以下是一個GET和一個POST請求的示例。讓我們快速瀏覽這些請求的不同部分。
該請求的第一行是為請求行保留的。它由 請求方法名稱，請求URI和 HTTP版本組成。
接下來的幾行代表請求頭。請求標頭為請求提供了額外的信息，例如請求期望響應的內容類型，授權信息等，
對于GET請求，故事就此結束。一個POST請求也可以有一個主體并且以主體消息的形式攜帶額外的信息。在這種情況下，它是一個JSON消息，其中包含有關如何為URI中指定的repo創建GitHub webhook的其他信息。該消息是webhook創建所必需的，因此我們使用POST請求將該信息提供給GitHub API。
請求行和請求頭必須后跟（回車和換行符\ r \ n），并且消息頭和消息正文之間僅包含一條僅包含CRLF的空行。
HTTP請求參考：https： //www.w3.org/Protocols/rfc2616/rfc2616-sec5.html
作為對這些要求的回應，我們得到了什么？
HTTP/1.1200OK
Server:GitHub.com
Date:Sun,18Jun201713:10:41GMT
Content-Type:application/json;charset=utf-8
Transfer-Encoding:chunked
Status:200OK
X-RateLimit-Limit:5000
X-RateLimit-Remaining:4996
X-RateLimit-Reset:1497792723
Cache-Control:private,max-age=60,s-maxage=60
[
{
"type":"Repository",
"id":14437404,
"name":"web",
"active":true,
"events":[
"push"
],
"config":{
"content_type":"json",
"insecure_ssl":"0",
"url":"http://www.example.com/example"
},
"updated_at":"2017-06-18T12:17:15Z",
"created_at":"2017-06-18T12:03:15Z",
"url":"https://api.github.com/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks/14437404",
"test_url":"https://api.github.com/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks/14437404/test",
"ping_url":"https://api.github.com/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks/14437404/pings",
"last_response":{
"code":422,
"status":"misconfigured",
"message":"Invalid HTTP Response: 404"
}
},
]
響應消息的結構與請求相同，只是第一行稱為 狀態行，它令人驚訝，其中包含有關響應狀態的信息。
狀態行后面跟著響應頭和響應主體。
HTTP響應參考：https： //www.w3.org/Protocols/rfc2616/rfc2616-sec6.html
MIME類型被用作標準化的方式來描述互聯網上的文件類型。您的瀏覽器具有MIME類型列表，Web服務器也是如此。這樣，無論操作系統如何，文件都可以以相同的方式傳輸。
有趣的是，MIME代表多用途Internet郵件擴展，因為它們最初是為多媒體電子郵件而開發的。自那以后，它們被改編用于HTTP和其他一些協議。
每種MIME類型都由以下格式的類型，子類型 和可選參數 列表組成 ： type / subtype; 可選參數。
這里有一些例子：
Content-Type:application/json
Content-Type:text/xml;charset=utf-8
Accept:image/gif
您可以在HTTP參考中找到常用MIME類型和子類型的列表 。
HTTP請求方法（也稱為“動詞”）定義將在資源上執行的操作。HTTP定義了幾種請求方法。最常用的/使用的是GET和POST方法。
請求方法可以是冪等的或不是冪等的。這僅僅是解釋該方法在同一資源上被多次調用的安全/不安全的一個奇特術語。換句話說，這意味著只有檢索信息的GET方法默認應該是冪等的。一次又一次調用同一資源上的GET應該不會導致不同的響應。另一方面，POST方法不是一個冪等方法。
在HTTP / 1.1之前，只有三種方法：GET，POST和HEAD，并且HTTP / 1.1的規范帶來了更多的方法： OPTIONS，PUT，DELETE，TRACE和CONNECT。
在HTTP參考中查找更多這些方法的工作原理 。
標題字段是可以在請求或響應消息的第一行之后找到的以冒號分隔的名稱值字段。它們為HTTP消息提供了更多的上下文，并確保客戶端和服務器得到適當的關于請求或響應性質的信息。
有五種類型的標題：
常規標題： 這些標題對服務器和客戶端都有用。日期標題字段就是一個很好的例子，它提供了有關創建消息的時間的信息。
請求標頭： 特定于請求消息。他們向服務器提供更多信息。例如， Accept：* / *標頭字段通知服務器客戶端愿意接收任何媒體類型。
響應標頭： 特定于響應消息。他們向客戶提供附加信息。例如， 允許：GET，HEAD，PUT標題字段通知客戶端哪些方法被允許用于請求的資源。
實體標頭： 這些標頭處理實體主體。例如， Content-Type：text / html 頭讓應用程序知道數據是HTML文檔。
擴展頭文件： 這些是由應用程序開發人員構建的非標準頭文件。它們不是HTTP的一部分，但需要被容忍。
您可以在HTTP參考中找到常用請求和響應頭的列表 。
狀態代碼就是一個表示請求的結果的三位數。緊接著是人類可讀的狀態碼解釋的原因短語。
一些例子包括：
200 OK
404未找到
500內部服務器錯誤
狀態代碼按五個不同組別的范圍進行分類。
狀態碼分類和狀態碼的完整列表及其含義可以在HTTP參考中找到 。
唷，那是很多的信息。
通過學習HTTP獲得的知識不是可以幫助您直接解決某些問題的那種知識。但是它讓你了解互聯網通信的基本原理，你可以將它應用于比HTTP更高層次的幾乎所有其他問題。無論是REST，API，Web應用程序開發還是網絡，您現在都可以在解決這些問題時至少更有信心。
當然，HTTP是一個相當大的話題，而且它的基本概念還有很多。
在HTTP系列的第2部分中了解HTTP的體系結構方面。
這篇文章對你有幫助嗎？請留下評論，并讓我知道。
例
帶有兩個源文件的音頻播放器。瀏覽器需要選擇它所支持的源文件（如果都支持則任選一個）：
<audiocontrols><sourcesrc="horse.ogg"type="audio/ogg"><sourcesrc="horse.mp3"type="audio/mpeg"> 您的瀏覽器不支持 audio 元素。</audio>
瀏覽器支持
IE 9+、Firefox、Opera、Chrome 和 Safari 都支持 <source> 標簽。
注釋：IE 8 或更早版本的 IE 瀏覽器都不支持 <source> 標簽。
標簽定義及使用說明
<source> 標簽為媒體元素（比如 <video> 和 <audio>）定義媒體資源。
<source> 標簽允許您規定兩個視頻/音頻文件共瀏覽器根據它對媒體類型或者編解碼器的支持進行選擇。
HTML 4.01 與 HTML5之間的差異
<source> 標簽是 HTML5 中的新標簽。
屬性
New：HTML5 中的新屬性。
| 屬性 | 值 | 描述 |
|---|---|---|
| mediaNew | media_query | 規定媒體資源的類型，供瀏覽器決定是否下載。 |
| srcNew | URL | 規定媒體文件的 URL。 |
| typeNew | MIME_type | 規定媒體資源的 MIME 類型。 |
全局屬性
<source> 標簽支持 HTML 的全局屬性。
事件屬性
<source> 標簽支持 HTML 的事件屬性。
如您還有不明白的可以在下面與我留言或是與我探討QQ群308855039，我們一起飛！
錄-常見web安全問題
文件上傳漏洞是指由于程序員未對上傳的文件進行嚴格的驗證和過濾，而導致的用戶可以越過其本身權限向服務器上上傳可執行的動態腳本文件。這里上傳的文件可以是木馬，病毒，惡意腳本或者WebShell等。這種攻擊方式是最為直接和有效的，“文件上傳”本身沒有問題，有問題的是文件上傳后，服務器怎么處理、解釋文件。如果服務器的處理邏輯做的不夠安全，則會導致嚴重的后果。
在了解文件上傳漏洞之前先了解什么是Web容器、IIS、文件解析。
什么是web容器？
web容器是一種服務程序，在服務器一個端口就有一個提供相應服務的程序，而這個程序就是處理從客戶端發出的請求，如tomcat、apache、nginx等等。（可以理解為給編程語言提供環境）
中間件：提供系統軟件和應用軟件之間連接的軟件，以便于軟件各部件之間的溝通。中間件處在操作系統和更高一級應用程序之間。
容器：給處于其中的應用程序組件（ASP,JSP,PHP）提供一個環境。使處于其中的應用程序組件之間跟容器中的環境變量接口交互，不必關注其他系統問題。
服務器：www服務器或http服務器。提供web信息游覽服務。它只需支持http協議、html文檔格式以及url，向瀏覽器提供服務的程序。
什么是IIS?
IIS全稱是互聯網信息服務，包括FTP/FTPS、NNTP、HTTP/HTTPS、SMTP等服務。
.net Framework是基礎類庫，是程序運行的底層框架。
IIS是架設Web服務器用來提供網頁游覽服務的，屬于系統環境。
一般用ASP.NET開發軟件，然后靠IIS對公網提供服務。
什么是文件解析？
當服務器接收到一個HTTP請求的時候，IIS首先需要決定如何去處理這個請求（服務器處理.aspx和.html肯定是不一樣的），根據的是文件的后綴名。
服務器獲取所請求的頁面（也可以是文件）的后綴名后接下來會在服務器端尋找可以處理這類后綴名的應用程序，如果IIS找不到可以處理此類文件的應用程序，那么IIS將直接把這個文件返還給客戶端。
攻擊者在利用上傳漏洞時，通常會與Web容器的解析漏洞配合在一起。所以我們首先來了解一下解析漏洞，這樣才能更深入地了解上傳漏洞，并加以防范。
常見的Web容器有ⅡS、Apache、Nginx、Tomcat等，下面主要講IIS、Apache容器。
IIS解析漏洞
IIS 6.0在解析文件時存在以下兩個解析漏洞。
Apache解析漏洞
Apache是從右到左開始判斷解析，如果為不可識別解析，就再往左判斷，如xxx.php.owf.rar ，”.owf”和”.rar”這兩種后綴是apache解析不了的，apache就會把xxx.php.owf.rar解析成php。
怎么去判斷是不是合法的后綴就是這個漏洞利用關鍵，測試時把常見的后綴都寫上，去測試是不是合法，任意不識別的后綴，逐級向上識別。
有些程序開發人員在上傳文件時，判斷文件名是否是PHP、ASP、ASPX、ASA、CER、ASPX等腳本擴展名，如果是，則不允許上傳，這時攻擊者就有可能上傳1.php.rar等擴展名來繞過程序檢測，并配合解析漏洞，獲取到WebShell。
繞過上傳漏洞分以下兩種。
客戶端檢測：客戶端使用JavaScript檢測，在文件未上傳時，就對文件進行驗證；
服務器端檢測：服務端腳本一般會檢測文件的MIME類型，檢測文件擴展名是否合法，
甚至有些程序員檢測文件中是否嵌入惡意代碼。
在研究上傳漏洞之前，首先來看兩個小工具：中國菜刀和一句話圖片木馬。
“中國菜刀”這款軟件是用來管理網站文件的，非常小巧靈活，它僅僅需要一段簡短的代碼
就可以方便地管理網站。中國菜刀現在已經成為安全研究者手中必備的利器，其官方網站為：http://www.maicaidao.com。
該軟件提供的服務器端文件僅有一行代碼。目前支持的服務器端腳本包括：PHP、ASP、ASP.NET、JSP等，并且支持HTTPS安全連接的網站。常見的代碼如下：
Asp一句話：<%eval request(“xxx”)%>
Php 一句話：<%php @eval($_POST[xxx]);?>
Aspx一句話：<%@ Page Languag=”xxx”%><%eval(Request.Item[“xxx”])%>
正因為代碼短小精悍，所以被黑客稱為一句話木馬（一句話后門）。
將<？php @eval（S_POST['xxx']);?>保存為shell.php，上傳至PHP主機空間中，配置菜刀進行連接，如圖所示。
“圖片一句話”則是將一句話木馬插入在圖片文件中，而且并不損壞圖片文件，這一方法可以躲過少許的防火墻檢測。制作圖片一句話木馬的方法非常多，目前已經有安全研究人員設計出了專業的制作軟件：Edjpgcom。Edjpgcom的使用方法非常簡單：把一張正常的圖片拖到Edjpgcom.exe程序中，填寫相應的一句話代碼，就可以制作圖片一句話木馬。
在插入一句話木馬之后，以文本的方式打開圖片，就可以看到一句話木馬代碼就在里面，而且不影響圖片正常預覽。
還有將一句話木馬與正常圖片通過CMD命令結合起來。
注：如果直接以文本的方式打開圖片插入一句話，可能會造成文件損壞。
知道了程序員是如何防護上傳漏洞及一句話圖片木馬后，下面深入研究攻擊者是如何繞過程序員的防護思維來上傳一句話木馬文件的。
客戶端檢測
使用FileBug瀏覽器插件
FireBug是一款開源的瀏覽器插件，它支持Firefox、Chrome等瀏覽器。它可以讓Web開發者輕松地調試HTML、JavaScript、AJAX、CSS等前端腳本代碼，屬于Web開發人員的必備武器。正由于FireBug功能強大，所以也被黑客認為是必備利器。
中間人攻擊
中間人攻擊這種方式與FireBug完全不同，FireBug是刪除客戶端的JavaScript驗證，而使用Burp Suite則是按照正常的流程通過JavaScript驗證，然后在傳輸中的HTTP層做手腳。
首先把木馬文件擴展名改為一張正常圖片的擴展名，比如JPG擴展名，在上傳時使用Burp Suite攔截上傳數據，再將其中的擴展名JPG修改為PHP，就可以繞過客戶端驗。
服務器端檢測
白名單與黑名單驗證
（1)黑名單過濾方式
黑名單過濾是一種不安全的方式，黑名單定義了一系列不安全的擴展名，服務器端在接收文件后，與黑名單擴展名對比，如果發現文件擴展名與黑名單里的擴展名匹配，則認為文件不合法。
（2）白名單過濾方式
白名單的過濾方式與黑名單恰恰相反，黑名單是定義不允許上傳的文件擴展名，而白名單則是定義允許上傳的擴展名，白名單擁有比黑名單更好的防御機制。如：$WhiteList=
array(rar’,jpg’,png,bmpy,gif,jpg；doc)；在獲取到文件擴展名后對 WhiteList數組里的擴展名迭代判斷，如果文件擴展名被命中，程序將認為文件是合法的，否則不允許上傳。
MIME驗證
MIME類型用來設定某種擴展名文件的打開方式，當具有該擴展名的文件被訪問時，瀏覽器會自動使用指定的應用程序來打開。如GIF圖片MIME為image/gif，CSS文件MIME類型為text/ess。
目錄驗證
在文件上傳時，程序通常允許用戶將文件放到指定的目錄中，然而有些Web開發人員為了讓代碼更“健壯”，通常會做一個操作，如果指定的目錄存在，就將文件寫入目錄中，不存在則先建立目錄，然后寫入。
截斷上傳攻擊
文件名后綴有一個%00字節，可以截斷某些函數對文件名的判斷。在許多語言函 數中，處理字符串的函數中0x00被認為是終止符
例如: 網站上傳函數處理xxx.asp%00.jpg時，首先后綴名是合法的jpg格式，可以 上傳，在保存文件時，遇到%00字符丟棄后面的 .jpg，文件后綴最終保存的后綴 名為xxx.asp
首先，上傳的文件能夠被Web容器解釋執行。所以文件上傳后所在的目錄要是Web容器所覆蓋到的路徑。 其次，用戶能夠從Web上訪問這個文件。如果文件上傳了，但用戶無法通過Web訪問，或者無法得到Web容器解釋這個腳本，那么也不能稱之為漏洞。 最后，用戶上傳的文件若被安全檢查、格式化、圖片壓縮等功能改變了內容，則也可能導致攻擊不成功。
防范文件上傳漏洞常見的幾種方法：
1.文件上傳的目錄設置為不可執行
只要web容器無法解析該目錄下面的文件，即使攻擊者上傳了腳本文件，服務器本身也不會受到影響，因此這一點至關重要。
2.判斷文件類型
在判斷文件類型時，可以結合使用MIME Type、后綴檢查等方式。在文件類型檢查中，強烈推薦白名單方式，黑名單的方式已經無數次被證明是不可靠的。此外，對于圖片的處理，可以使用壓縮函數或者resize函數，在處理圖片的同時破壞圖片中可能包含的HTML代碼。
3.使用隨機數改寫文件名和文件路徑
文件上傳如果要執行代碼，則需要用戶能夠訪問到這個文件。在某些環境中，用戶能上傳，但不能訪問。如果應用了隨機數改寫了文件名和路徑，將極大地增加攻擊的成本。再來就是像shell.php.rar.rar和crossdomain.xml這種文件，都將因為重命名而無法攻擊。
4.單獨設置文件服務器的域名
由于瀏覽器同源策略的關系，一系列客戶端攻擊將失效，比如上傳crossdomain.xml、上傳包含Javascript的XSS利用等問題將得到解決。
5.限制上傳文件大小
限制上傳文件的大小，防止由于內存、磁盤耗盡造成的拒絕服務。
可以配置web server允許的最大Post大小。
可以在代碼層面獲取上傳文件的大小，根據文件類型的不同進行進一步的過濾。
6.確保上傳文件被訪問正確返回
1.將文件上傳目錄設置為靜態資源目錄，防止被解析為腳本執行。
2.使用代理頁面隱藏文件真實路徑。
3.使用上述方法時，確保Content-Type與實際文件類型一致。
4.如果文件不允許在頁面展示，僅允許下載，請設置Content-disposition：attachment。
備注:
這篇文章摘抄來自網絡。我打算總結一些列架構師需要的優秀文章，由于自己寫會花太多時間，我決定做一個搬運工，為大家篩選優秀的文章，最后我會做成索引方便大家查找。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
