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