?? 前言：Web是互聯(lián)網(wǎng)上最為典型的應(yīng)用模式，幾乎涉及人們生活的各個(gè)方面，因此其安全問(wèn)題備受關(guān)注。本章我們首先聚焦Web應(yīng)用本身的安全問(wèn)題，包括：Web應(yīng)用體系的脆弱性分析，典型Web應(yīng)用安全漏洞攻擊（SQL注入、XSS、Cookie欺騙、CSRF、目錄遍歷、操作系統(tǒng)命令注入、HTTP消息頭注入等）及其防范措施，然后簡(jiǎn)要介紹安全的HTTP協(xié)議HTTPS。

?? 1. Web應(yīng)用體系結(jié)構(gòu)脆弱性分析

Web應(yīng)用體系結(jié)構(gòu)潛在弱點(diǎn)：

• Web客戶端
  • 活動(dòng)內(nèi)容執(zhí)行，客戶端軟件漏洞的利用，交互站點(diǎn)腳本的錯(cuò)誤
• 傳輸
  • 偷聽(tīng)客戶-服務(wù)器通信，SSL重定向
• Web服務(wù)器
  • Web服務(wù)器軟件漏洞；
• Web應(yīng)用程序
  • 攻擊授權(quán)、認(rèn)證、站點(diǎn)結(jié)構(gòu)、輸入驗(yàn)證，以及應(yīng)用程序邏輯
• 數(shù)據(jù)庫(kù)
  • 通過(guò)數(shù)據(jù)庫(kù)查詢運(yùn)行優(yōu)先權(quán)命令，查詢操縱返回額外的數(shù)據(jù)集。

?? 1.1 Web應(yīng)用安全

Web應(yīng)用程序功能與安全隱患的對(duì)應(yīng)關(guān)系

?? 1.2 HTTP協(xié)議安全問(wèn)題

HTTP協(xié)議是一種簡(jiǎn)單的、無(wú)狀態(tài)的應(yīng)用層協(xié)議（RFC1945、RFC2616）

• 無(wú)狀態(tài)使攻擊變得容易
• 基于ASCII碼，無(wú)需弄清復(fù)雜的二進(jìn)制編碼機(jī)制，攻擊者就可了解協(xié)議中的明文信息
• 互聯(lián)網(wǎng)中存在的大量中間盒子，HTTP標(biāo)準(zhǔn)(RFC 2616和RFC 7320)的理解如果不一致，就有可能導(dǎo)致一些新的攻擊發(fā)生

常見(jiàn)安全問(wèn)題：

• HTTP會(huì)話經(jīng)常被劫持
  

• HTTP會(huì)話頭泄露隱私信息
  

• 中間盒子帶來(lái)的HTTP安全問(wèn)題

?? 端到端通信中危險(xiǎn)的中間盒子：祝福還是詛咒？

?? 1.3 Cookie的安全問(wèn)題

為什么需要Cookie？

• 解決無(wú)狀態(tài)問(wèn)題：保存客戶服務(wù)器之間的一些狀態(tài)信息
• Cookie是指網(wǎng)站為了辨別用戶身份、進(jìn)行會(huì)話跟蹤而儲(chǔ)存在用戶本地終端上的一些數(shù)據(jù)（通常經(jīng)過(guò)編碼），最早由網(wǎng)景公司的Lou Montulli在1993年3月發(fā)明的，后被采納為RFC標(biāo)準(zhǔn)（RFC2109、RFC2965）

Cookie的生成與維護(hù)：

• 由服務(wù)器端生成，發(fā)送給客戶端（一般是瀏覽器），瀏覽器會(huì)將Cookie的值保存到某個(gè)目錄下的文本文件內(nèi)，下次請(qǐng)求同一網(wǎng)站時(shí)就發(fā)送該Cookie給服務(wù)器（前提是瀏覽器設(shè)置為啟用Cookie）
• 服務(wù)器可以利用Cookie存儲(chǔ)信息并經(jīng)常性地維護(hù)這些信息，從而判斷在HTTP傳輸中的狀態(tài)
• Cookie在生成時(shí)就會(huì)被指定一個(gè)Expire值，這就是Cookie的生存周期。到期自動(dòng)清除
• 如果一臺(tái)計(jì)算機(jī)上安裝了多個(gè)瀏覽器，每個(gè)瀏覽器都會(huì)在各自獨(dú)立的空間存放Cookie
• Cookie中的內(nèi)容大多數(shù)經(jīng)過(guò)了編碼處理

Cookie的一般格式如下：
NAME= VALUE; expires= DATE; path= PATH;
domain= DOMAIN_NAME; secure

示例
autolog = bWlrzTpteXMxy3IzdA%3D%3D;
expires=Sat, 01-Jan-2018 00:00:00 GMT; path=/;
domain=victim.com

Cookie中包含了一些敏感信息，如用戶名、計(jì)算機(jī)名、使用的瀏覽器和曾經(jīng)訪問(wèn)的網(wǎng)站等，攻擊者可以利用它來(lái)進(jìn)行竊密和欺騙攻擊

?? 2. 常見(jiàn)Web應(yīng)用攻擊及防范

OWASP（開(kāi)放式Web應(yīng)用程序安全項(xiàng)目）是一個(gè)開(kāi)放的社區(qū)，由非營(yíng)利組織 OWASP基金會(huì)支持的項(xiàng)目。對(duì)所有致力于改進(jìn)應(yīng)用程序安全的人士開(kāi)放，旨在提高對(duì)應(yīng)用程序安全性的認(rèn)識(shí)。
其最具權(quán)威的就是“10項(xiàng)最嚴(yán)重的Web 應(yīng)用程序安全風(fēng)險(xiǎn)列表” ，總結(jié)并更新Web應(yīng)用程序中最可能、最常見(jiàn)、最危險(xiǎn)的十大漏洞，是開(kāi)發(fā)、測(cè)試、服務(wù)、咨詢?nèi)藛T應(yīng)知應(yīng)會(huì)的知識(shí)。

?? 2.1 SQL注入攻擊及防范

定義：注入漏洞，特別是SQL注入，在Web應(yīng)用程序中很常見(jiàn)。注入發(fā)生在用戶提供的數(shù)據(jù)作為命令或查詢的一部分發(fā)送到解釋器時(shí)。攻擊者的惡意數(shù)據(jù)欺騙解釋器執(zhí)行意外的命令或更改數(shù)據(jù)。

最普遍的注入漏洞包括：

• SQL注入：通過(guò)SQL語(yǔ)句惡意地調(diào)用后臺(tái)數(shù)據(jù)庫(kù)
• 系統(tǒng)調(diào)用
• 通過(guò)shell命令調(diào)用外部程序

?? 2.1.1 SQL注入原理

例子：

• 通過(guò)用戶提供的參數(shù)來(lái)查詢表中的數(shù)據(jù)
• "SELECT * FROM USERS WHERE SSN=‘" + ssn + "’“

SSN參數(shù)來(lái)自于用戶的輸入：

• 參數(shù)未經(jīng)驗(yàn)證或編碼
• 黑客輸入： 1234’ OR ‘1’=‘1

應(yīng)用程序構(gòu)造查詢語(yǔ)句：

• SELECT * FROM USERS WHERE SSN=‘1234’ OR ‘1’=‘1’ （永真邏輯）
• 結(jié)果返回?cái)?shù)據(jù)庫(kù)中的每一個(gè)用戶

?? 2.1.2 SQL注入攻擊流程

1. Web程序提供了用戶輸入的表單；
2. 攻擊者通過(guò)填寫(xiě)表單數(shù)據(jù)發(fā)起攻擊；
3. Web程序通過(guò)SQL語(yǔ)句的形式將攻擊遞交給數(shù)據(jù)庫(kù)；
4. 數(shù)據(jù)庫(kù)執(zhí)行SQL語(yǔ)句，將執(zhí)行結(jié)果加密后返回給應(yīng)用程序；
5. 應(yīng)用程序解密數(shù)據(jù)，將結(jié)果發(fā)送給用戶（攻擊者）。

說(shuō)明：SSL、防火墻等安全措施對(duì)于此類(lèi)攻擊完全沒(méi)用。

實(shí)戰(zhàn)：?? IBM所提供的Web安全漏洞演示網(wǎng)站

1. Web應(yīng)用有一個(gè)登錄頁(yè)面，這個(gè)登錄頁(yè)面控制著用戶是否有權(quán)訪問(wèn)應(yīng)用，它要求用戶輸入一個(gè)名稱和密碼，登錄頁(yè)面中輸入的內(nèi)容將直接用來(lái)構(gòu)造動(dòng)態(tài)的SQL命令 或者直接用作存儲(chǔ)過(guò)程的參數(shù)

System.Text.StringBuilder.query = new System.Text.String.Builder（“SELECT * from Users WHERE login =“).Append（txtLogin Text).Append（“'AND password=“').Append（txtPassword.Text).Append（“”）

2. 攻擊者在用戶名字和密碼輸入框中輸入 'or'1'='1 的內(nèi)容
3. 服務(wù)器運(yùn)行上面的ASP NET代碼構(gòu)造出查詢用戶的SQL命令，最后得到的SQL命令變成

SELECT * from Users WHERE login = ‘or '1'='1'  AND  password ‘or '1'='1'

?? 2.1.3 SQL注入檢測(cè)

?? DVWA靶場(chǎng)——下載與安裝

?? sqlmap詳細(xì)使用教程

防御注入漏洞：

• 使用特定語(yǔ)言的庫(kù)函數(shù)來(lái)代替shell命令和系統(tǒng)調(diào)用；
• 對(duì)用戶輸入的信息進(jìn)行嚴(yán)格檢查和過(guò)濾：
  • 數(shù)據(jù)類(lèi)型（字符串、整數(shù)等）正確嗎？
  • 使用的是允許的字符集嗎？
  • 輸入滿足格式要求嗎？
  • ……
• 使用“最小權(quán)限”限制數(shù)據(jù)庫(kù)用戶的權(quán)限

?? 如何判斷是字符型注入還是數(shù)字型注入

?? 2.1.4 實(shí)驗(yàn)：SQL注入

使用合天網(wǎng)安實(shí)驗(yàn)室進(jìn)入WEB滲透測(cè)試實(shí)驗(yàn)平臺(tái)，并進(jìn)入SQL注入進(jìn)階實(shí)驗(yàn)

實(shí)例1、熱身運(yùn)動(dòng)，不設(shè)防
關(guān)鍵代碼：

$sql = "SELECT * FROM users where name='";
$sql .= $_GET ["name"]."'";
$result = mysql_query ($sgl);

實(shí)例1是字符串型注入

判斷該網(wǎng)絡(luò)后臺(tái)數(shù)據(jù)庫(kù)users表格的列數(shù)：為5列

判斷該網(wǎng)絡(luò)后臺(tái)數(shù)據(jù)庫(kù)users表格的每一列的數(shù)據(jù)類(lèi)型

獲取該網(wǎng)絡(luò)后臺(tái)數(shù)據(jù)庫(kù)的數(shù)據(jù)庫(kù)名

實(shí)例2、節(jié)約是種美德，少用空格
關(guān)鍵代碼：

if (preg_match ( '/ /', $_GET ["name"])){
	die("ERROR NO SPACE");
}
$sql = "SELECT * FROM users where name='";
$sql .= $_GET ["name"]."'";
$result = mysql_query ($sql);

上述步驟與實(shí)例1基本相同，提示：URL中%20表示空格，可替代成%a0，%a0在Mysql中為換行符。注釋指令可用#并用%23編碼進(jìn)行替代。

?? 2.2 跨站腳本（XSS）攻擊及防范

定義：跨站腳本(XSS)漏洞發(fā)生在應(yīng)用使用用戶提供的數(shù)據(jù)并發(fā)送給web瀏覽器而未經(jīng)第一次驗(yàn)證或編碼的時(shí)候。XSS允許攻擊者在受害者的瀏覽器中執(zhí)行腳本，這可以劫持用戶會(huì)話、篡改網(wǎng)站、可能引入蠕蟲(chóng)等。

?? 2.2.1 工作原理

原理：輸入插入包含有JavaScript或其它惡意腳本的HTML標(biāo)簽代碼。

<script>alert(XSS)</script>

問(wèn)題根源：不當(dāng)?shù)姆?wù)器端輸入檢查，從而允許用戶輸入可被客戶端瀏覽器解釋的腳本命令。

XSS是最普遍的Web程序安全問(wèn)題。

DOM，文件對(duì)象模型，Document Object Model.是給HTML和xml文件使用的一組API，是建立網(wǎng)頁(yè)與Script語(yǔ)言溝通的橋梁，比如table對(duì)象代表HTML中的表格，可以由JavaScript腳本取用

?? 2.2.2 反射式XSS

• 也稱為非持久性跨站腳本攻擊，是一種最常見(jiàn)的跨站腳本攻擊類(lèi)型。
• 與本地腳本漏洞不同的是Web客戶端使用Server端腳本生成頁(yè)面為用戶提供數(shù)據(jù)時(shí)，如果未經(jīng)驗(yàn)證的用戶數(shù)據(jù)被包含在頁(yè)面中而未經(jīng)HTML實(shí)體編碼，客戶端代碼便能夠注入到動(dòng)態(tài)頁(yè)面中。
• 在這種攻擊模式下，Web程序不會(huì)存儲(chǔ)惡意腳本，它會(huì)將未經(jīng)驗(yàn)證的數(shù)據(jù)通過(guò)請(qǐng)求發(fā)送給客戶端，攻擊者就可以構(gòu)造惡意的URL鏈接或表單并誘騙用戶訪問(wèn)，最終達(dá)到利用受害者身份執(zhí)行惡意代碼的目的。

例子：
(1) Alice經(jīng)常瀏覽Bob建立的網(wǎng)站。Bob的站點(diǎn)運(yùn)行Alice使用用戶名/密碼進(jìn)行登錄，并存儲(chǔ)敏感信息(比如銀行帳戶信息)；
(2) Charly發(fā)現(xiàn)Bob的站點(diǎn)包含反射性的XSS漏洞；
(3) Charly編寫(xiě)一個(gè)利用漏洞的URL，并將其冒充為來(lái)自Bob的郵件發(fā)送給Alice；
(4) Alice在登錄到Bob的站點(diǎn)后，瀏覽Charly提供的URL；
(5) 嵌入到URL中的惡意腳本在Alice的瀏覽器中執(zhí)行，就像它直接來(lái)自Bob的服務(wù)器一樣。此腳本盜竊敏感信息(授權(quán)、信用卡、帳號(hào)信息等)，然后在Alice完全不知情的情況下將這些信息發(fā)送到Charly的Web站點(diǎn)。

?? 2.2.3 儲(chǔ)存式XSS

儲(chǔ)存式跨站腳本攻擊，也稱為持久性跨站腳本攻擊。如果Web程序允許存儲(chǔ)用戶數(shù)據(jù)，并且存儲(chǔ)的輸入數(shù)據(jù)沒(méi)有經(jīng)過(guò)正確的過(guò)濾，就有可能發(fā)生這類(lèi)攻擊。

在這種攻擊模式下，攻擊者并不需要利用一個(gè)惡意鏈接，只要用戶訪問(wèn)了儲(chǔ)存式跨站腳本網(wǎng)頁(yè)，那么惡意數(shù)據(jù)就將顯示為網(wǎng)站的一部分并以受害者身份執(zhí)行。

?? 2.2.4 DOM式XSS

DOM式XSS 攻擊并不是按照“數(shù)據(jù)是否保存在服務(wù)端”劃分的，它是反射式XSS 的一種特例，只是由于DOM式XSS的形成原因比較特殊，因此把它單獨(dú)作為一個(gè)分類(lèi)。

DOM式XSS 攻擊是通過(guò)修改頁(yè)面DOM節(jié)點(diǎn)數(shù)據(jù)信息而形成的?？聪旅娴拇a。

<script
  function test(){
   var str = document.getElementById("input").value;
   document.getElementById("output").innerHTML="<a href="+str+"">test</a>";
   }
</script>
<div id="output"></div>
<input type="text" id="input" size=50 value=""/>
<input type="button" value="提交" onclick="test()"/>

如果構(gòu)造數(shù)據(jù)“‘ onclick=’javascript:alert(/xss/)”，那么最后添加的html代碼就變成了“<a href=’ ‘ onclick=’javascript:alert(/xss/)’>test</a>”，插入一個(gè)onclick事件，點(diǎn)擊提交按鍵，那么就會(huì)發(fā)生一次DOM式xss攻擊。

?? 2.2.5 防御XSS

對(duì)Web應(yīng)用程序的所有輸入進(jìn)行過(guò)濾，對(duì)危險(xiǎn)的HTML字符進(jìn)行編碼：

• ‘<’ , ‘>’ → ‘&lt;’ , ‘&gt;’
• ‘(‘ , ‘)’ → ‘(’ , ‘)’
• ‘#‘ , ‘&’ → ‘#’ , ‘&‘

對(duì)用戶，謹(jǐn)防不明鏈接；
防止訪問(wèn)已知的惡意網(wǎng)站；
執(zhí)行手工或自動(dòng)化代碼掃描，確定并消除潛在的XSS漏洞。

?? 2.2.6 實(shí)驗(yàn)：XSS攻擊

嘗試構(gòu)造語(yǔ)句使瀏覽器執(zhí)行彈出對(duì)話框的腳本。

實(shí)例一、熱身運(yùn)動(dòng)，不設(shè)防

關(guān)鍵代碼：

<?php
	echo $_GET["name"];
?>

實(shí)例二、小寫(xiě)不行，就大寫(xiě)吧

關(guān)鍵代碼：

	$name = $_GET["name"];
	$name = preg_replace("/<script>/", ""，$name);
	$name = preg_replace("/<\/script>/",""，$name);
echo $name;

實(shí)例三、大寫(xiě)小寫(xiě)都不行，看你怎么辦？

關(guān)鍵代碼：

	$name = $_GET[ "name"];
	$name = preg_replace( " /<script>/i",""，$name);
	$name = preg_replace( " /<\/script>/i",""，$name);
echo $name;

實(shí)例四、換一個(gè)角度，陽(yáng)光依舊

關(guān)鍵代碼：

if (preg_match('/script/i'，$_GET["name"])) {
	die("error");
}

實(shí)例五、限制了我的左手，我還有右手

關(guān)鍵代碼：

if (preg_match('/alert/i'，$_GET["name"])) {
	die("error");
}

實(shí)例六、大膽去思考，小心去求證

關(guān)鍵代碼：

<script>
	var $a= "<?php echo $_GET["name"]; ?>";
</script>

?? 2.3 Cookie欺騙及防范

?? 2.3.1 偽造Cookie信息

偽造Cookie信息，繞過(guò)網(wǎng)站的驗(yàn)證過(guò)程，不需要輸入密碼，就可以登錄網(wǎng)站，甚至進(jìn)入網(wǎng)站管理后臺(tái)

網(wǎng)站登錄驗(yàn)證代碼：

<%
if request.Cookies("lunjilyb")("username")=""then response.redirect "login.asp"	/* 如果用戶名為空，就
跳轉(zhuǎn)到登錄界面*/
endif
if request.Cookies("lunjilyb")("password")=""then response.redirect "login.asp"   /* 如果口令為空，就跳轉(zhuǎn)到登錄界面*/
endif
if request.Cookies("lunjilyb")("randomid")<>12 then response.redirect "login.asp"   /* 如果randomid值不等于12，就跳轉(zhuǎn)到登錄界面*/
endif
%>

利用request.Cookies語(yǔ)句分別獲取Cookies中的用戶名、口令和randomid的值。如果用戶名或口令為空或randomid值不等于12就跳轉(zhuǎn)到登錄界面。也就是說(shuō)，程序是通過(guò)驗(yàn)證用戶的Cookie信息來(lái)確認(rèn)用戶是否已登錄。然而，Cookie信息是可以在本地修改的，只要改后的Cookie信息符合驗(yàn)證條件（用戶名和口令不空且randomid值等于12），就可進(jìn)入管理后臺(tái)界面。

判斷是否有刪帖權(quán)限的代碼：

if Request.Cookies("power")="" then
  response.write"<SCRIPT 1anguage=JavaScript>alert(‘你還未登錄論壇! ');</SCRIPT>"
  response.end
else
 if Request.Cookies("power')<500 then
   response.write"<SCRIPT 1anguage=JavaScript>alert('你的管理級(jí)別不夠! );</SCRIPT>"
   response.redirect"http://cnc.cookun.com"
   response.end
 endif
endif

只要Cookie中的power值不小于500，任意用戶都可以刪除任意帖子。同樣可以利用上面介紹的方法進(jìn)行Cookie欺騙攻擊面

上面介紹的兩個(gè)攻擊例子之所以成功，是因?yàn)?strong>在Cookie中保存了用戶名、口令以及權(quán)限信息而留下了安全隱患。

• 安全原則：一般情況下，網(wǎng)站會(huì)話管理機(jī)制僅將會(huì)話ID保存至Cookie，而將數(shù)據(jù)本身保存在Web服務(wù)器的內(nèi)存或文件、數(shù)據(jù)庫(kù)中

?? 2.3.2 監(jiān)聽(tīng)Cookie來(lái)實(shí)現(xiàn)會(huì)話劫持

如果Cookie中沒(méi)有設(shè)置安全屬性secure”，則Cookie內(nèi)容在網(wǎng)絡(luò)中用明文傳輸，攻擊者監(jiān)聽(tīng)到Cookie內(nèi)容后可以輕松實(shí)現(xiàn)會(huì)話劫持

Q：為什么會(huì)不設(shè)置安全屬性？
A：不設(shè)置Cookie安全屬性的原因主要有兩種：一種是Web應(yīng)用開(kāi)發(fā)者不知道安全屬性或不愿意使用安全屬性；第二種是設(shè)置安全屬性后應(yīng)用無(wú)法運(yùn)行。

?? 2.4 CSRF攻擊及防范

定義：CSRF（跨站請(qǐng)求偽造）攻擊迫使已登錄的受害者瀏覽器向易受攻擊的Web應(yīng)用程序發(fā)送預(yù)先驗(yàn)證的請(qǐng)求，然后強(qiáng)制受害者瀏覽器執(zhí)行對(duì)攻擊者有利的惡意操作。

現(xiàn)有銀行的網(wǎng)銀交易流程要比例子復(fù)雜得多，同時(shí)還需要USB key、驗(yàn)證碼、登錄密碼和支付密碼等一系列安全信息，一般并不存在CSRF安全漏洞，安全是有保障的。

重大的差別：

• CSRF利用的是Web服務(wù)器端的漏洞
• XSS利用的是Web客戶端的漏洞

XSS攻擊是實(shí)施CSRF攻擊前的一個(gè)重要步驟：

• 攻擊者通過(guò)XSS攻擊獲取有用的攻擊信息，比如通過(guò)XSS偽造一個(gè)提示用戶輸入身份信息的表單。

防御CSRF攻擊：

• 設(shè)定短暫的可信用戶會(huì)話時(shí)間，完成任務(wù)后記得退出可信會(huì)話，刪除所有cookie；
• 每次提出一個(gè)可信行為時(shí)，對(duì)發(fā)出請(qǐng)求的用戶進(jìn)行驗(yàn)證；
• 讓網(wǎng)站記住登錄用戶名和密碼時(shí)要小心。留在客戶端的登錄信息可能會(huì)攻擊者加以利用；
• 在URL和表單中增加的每個(gè)請(qǐng)求，必須提供基本會(huì)話令牌以外的每個(gè)請(qǐng)求用戶驗(yàn)證；
• 從Web應(yīng)用程序中刪除所有XSS漏洞。

?? 2.5 目錄遍歷及其防范

許多Web應(yīng)用支持外界以參數(shù)的形式來(lái)指定服務(wù)器上的文件名，如果服務(wù)器在處理用戶請(qǐng)求時(shí)不對(duì)文件名進(jìn)行充分校驗(yàn)，就可能出問(wèn)題，如：

• 文件被非法獲取，導(dǎo)致重要信息被泄露；
• 文件被篡改，如篡改網(wǎng)頁(yè)內(nèi)容以發(fā)布不實(shí)消息，設(shè)置圈套將用戶誘導(dǎo)至惡意網(wǎng)站，篡改腳本文件從而在服務(wù)器上執(zhí)行任意腳本等；
• 文件被刪除，如刪除腳本文件或配置文件導(dǎo)致服務(wù)器宕機(jī)等

一般來(lái)說(shuō)，如果Web應(yīng)用滿足以下3個(gè)條件時(shí)，就有可能產(chǎn)生目錄遍歷漏洞

• 外界能夠指定文件名
• 能夠使用絕對(duì)路徑或相對(duì)路徑等形式來(lái)指定其它目錄的文件名
• 沒(méi)有對(duì)拼接后的文件名進(jìn)行校驗(yàn)就允許訪問(wèn)該文件

<?php
	define('TMPLDIR',‘/var/www/example/tmp1');
	$tmp1 -$_GET( 'template');
?>
<body>
<?php readfile(TMPLDIR, $tmp1,".html'); ?>
</body>

http://example.cn/example/ex.php?template=../../../../etc/hosts%00
將顯示/etc/hosts文件內(nèi)容

防御：

• 避免由外界指定文件名
  • 將文件名固定，保存在會(huì)話變量中，不直接指定文件名，而是使用編號(hào)等方法間接指定
• 文件名中不允許包含目錄名
  • 不同系統(tǒng)中表示目錄的字符有所不同，常見(jiàn)的有：/、\、:等
• 限定文件中僅包含字母或數(shù)字
  • 有些攻擊使用不同的編碼轉(zhuǎn)換進(jìn)行過(guò)濾性的繞過(guò)，如通過(guò)對(duì)參數(shù)進(jìn)行URL編碼來(lái)繞過(guò)檢查
    downfile.jsp?filename= %66%61%6E%2E%70%64%66

?? 2.6 操作系統(tǒng)命令注入及防范

很多Web應(yīng)用編程語(yǔ)言支持應(yīng)用通過(guò)Shell執(zhí)行操作系統(tǒng)（OS）命令。通過(guò)Shell執(zhí)行OS命令，或開(kāi)發(fā)中用到的某個(gè)方法在其內(nèi)部使用了Shell，就有可能出現(xiàn)惡意利用Shell提供的功能來(lái)任意執(zhí)行OS命令的情況，這就是OS命令注入。

// 頁(yè)面功能是發(fā)送電子郵件( sendmai1.htm1)
<body>
<form action ="send.php" method="POST">
請(qǐng)輸入您的郵箱地址<br>
郵箱地址<input type ="text" name ="mail"<br>
郵件內(nèi)容<textarea name ="con" cols = "20" rows = "3"></textarea><br>
<input type = "submit" value ="發(fā)送”>
</form>
</body> // sendmail.html結(jié)束

// 接收頁(yè)面的處理腳本(send.php)
<?php
	$mail = $_POST['mail'];
	// 調(diào)用OS命令sendmail將郵件發(fā)送到表單中填入的郵件地址$mail
	// 郵件信息保存在template.txt中
	system("/usr/sbin/sendmail -I <template.txt $mail");
	// 省略代碼
<body>
	郵件已發(fā)送
<body> //send.php結(jié)束

如果用戶在郵箱地址處輸入的是正常的郵箱地址，該頁(yè)面將給該郵箱發(fā)送一封正常的電子郵件。但是，如果攻擊者在郵箱地址處輸入的是以下內(nèi)容:
list@example.com; cat /etc/passwd
則在頁(yè)面上點(diǎn)擊“發(fā)送”按鈕后，頁(yè)面上將顯示的是系統(tǒng)口令文件/etc/passwd 的內(nèi)容。此處攻擊者只是用cat命令顯示文件內(nèi)容，他也完全可以用Web應(yīng)用的用戶權(quán)限執(zhí)行任何操作系統(tǒng)命令，如刪除文件、下載文件、執(zhí)行下載來(lái)的惡意軟件等。

上述攻擊成功的主要原因是Shell支持連續(xù)執(zhí)行多條命令，如Unix操作系統(tǒng)Shell中使用分號(hào)；或管道|等字符支持連續(xù)執(zhí)行多條命令，Windows操作系統(tǒng)cmd.exe使用&符號(hào)來(lái)連接多條命令。這些符號(hào)一般稱為Shell的元字符，如果OS命令參數(shù)中混入了元字符，就會(huì)使攻擊者添加的操作系統(tǒng)命令被執(zhí)行，這就是OS注入漏洞產(chǎn)生的原因

OS命令注入攻擊的一般流程為：

1. 從外部下載攻擊用軟件；
2. 對(duì)下載來(lái)的軟件授予執(zhí)行權(quán)限；
3. 從內(nèi)部攻擊操作系統(tǒng)漏洞以取得管理員權(quán)限；
4. 攻擊者在Web服務(wù)器上執(zhí)行攻擊操作，如：瀏覽、篡改或刪除Web服務(wù)器內(nèi)的文件，對(duì)外發(fā)送郵件，以此服務(wù)器作跳板攻擊其他服務(wù)器等。

OS命令注入攻擊防御策略：

• 選擇不調(diào)用操作系統(tǒng)命令的實(shí)現(xiàn)方法，即不調(diào)用Shell功能，而用其它方法實(shí)現(xiàn)；
• 避免使用內(nèi)部可能會(huì)調(diào)用Shell的函數(shù)；
• 不將外部輸入的字符串作為命令行參數(shù)；
• 使用安全的函數(shù)對(duì)傳遞給操作系統(tǒng)的參數(shù)進(jìn)行轉(zhuǎn)義，消除Shell元字符帶來(lái)的威脅。由于Shell轉(zhuǎn)義規(guī)則的復(fù)雜性以及其它一些環(huán)境相關(guān)的原因，這一方法有時(shí)很難完全湊效。

?? 2.7 HTTP消息頭注入攻擊及防范

指在重定向或生成Cookie時(shí)，基于外部傳入的參數(shù)生成HTTP響應(yīng)頭：

• HTTP響應(yīng)頭信息一般以文本格式逐行定義消息頭，即消息頭之間互相以換行符隔開(kāi)。攻擊者可以利用這一特點(diǎn)，在指定重定向目標(biāo)URL或Cookie值的參數(shù)中插入換行符且該換行符又被直接作為響應(yīng)輸出，從而在受害者的瀏覽器上任意添加響應(yīng)消息頭或偽造響應(yīng)消息體：生成任意Cookie，重定向到任意URL，更改頁(yè)面顯示內(nèi)容，執(zhí)行任意JavaScript而造成與XSS同樣效果

看下面的例子
http://example.com/web/in.cfg?url=http://example.com/%0D%0ALocation: + http://trap. com /web/attack.php
執(zhí)行之后，瀏覽器會(huì)跳轉(zhuǎn)到惡意網(wǎng)站trap.com/web/attack.php，而不是期望的正常網(wǎng)站http://example.com。造成這一結(jié)果的主要原因是，CGI腳本里使用的查詢字符串url中包含了換行符（%0D%0A）。出兩個(gè)消息頭：
Location: http://example.com
Location: http://trap.com/web/attack.php

采用類(lèi)似方法可以生成任意Cookie，看下面例子
http://example.com/web/in.cfg?url=http://example.com/web/exampple.php%0D%0ASet-Cookie: + SESSID=ac13rkd90
執(zhí)行之后，兩個(gè)消息頭：
Set-Cookie: SESSID=ac13rkd90
Location: http://example.com/web/exampple.php

防御：

• 不將外部傳入?yún)?shù)作為HTTP響應(yīng)消息頭輸出，如不直接使用URL指定重定向目標(biāo)，而是將其固定或通過(guò)編號(hào)等方式來(lái)指定，或使用Web應(yīng)用開(kāi)發(fā)工具中提供的會(huì)話變量來(lái)轉(zhuǎn)交URL；
• 由專(zhuān)門(mén)的API來(lái)進(jìn)行重定向或生成Cookie，并嚴(yán)格檢驗(yàn)生成消息頭的參數(shù)中的換行符

?? 2.8 其他攻擊

?? 2.8.1 惡意文件執(zhí)行

定義：易受遠(yuǎn)程文件包含（RFI）攻擊的代碼允許攻擊者包含惡意代碼和數(shù)據(jù)，從而導(dǎo)致毀滅性的攻擊，如服務(wù)器完全被攻陷。惡意文件執(zhí)行攻擊會(huì)影響 PHP、XML 和任何接受用戶文件名或文件的框架。

• 惡意文件執(zhí)行漏洞也稱為不安全的遠(yuǎn)程文件包含漏洞；
• 需要用戶提供輸入文件名的Web程序容易受到攻擊：如果對(duì)用戶輸入不驗(yàn)證，攻擊者可借此操控Web程序執(zhí)行系統(tǒng)程序或外部URL；
• 允許上傳文件給Web程序帶來(lái)的危害更大
  • 可以將可執(zhí)行代碼放置到Web應(yīng)用中去；
  • 可以替換Session文件、日志文件或認(rèn)證令牌

防御：

• 禁止用戶輸入被用作輸入文件片斷；
• 對(duì)于必須要用戶輸入文件名、URL的地方，執(zhí)行嚴(yán)格的檢查驗(yàn)證輸入合法性；
• 文件上傳的處理要非常小心：
  • 文件只允許上傳到webroot目錄以外的目錄中，這樣能防止文件被執(zhí)行；
  • 限制或隔離Web程序?qū)ξ募脑L問(wèn)權(quán)限。

?? 2.8.2 不安全的直接對(duì)象引用

定義：當(dāng)開(kāi)發(fā)人員將內(nèi)部實(shí)現(xiàn)對(duì)象的引用（例如文件、目錄、數(shù)據(jù)庫(kù)記錄或鍵）暴露為URL或表單參數(shù)時(shí)，就會(huì)發(fā)生直接對(duì)象引用。攻擊者可以操作這些引用，未經(jīng)授權(quán)訪問(wèn)其他對(duì)象。

• 不安全的直接對(duì)象引用漏洞也常稱為目錄遍歷漏洞；
• Web程序常常會(huì)暴露內(nèi)部對(duì)象，包括：
  • 文件或目錄
  • URL
  • 數(shù)據(jù)庫(kù)口令
  • 數(shù)據(jù)庫(kù)的一些對(duì)象名稱，比如表名
• 如果訪問(wèn)控制配置不合理，攻擊者就可以不經(jīng)授權(quán)地操作這些暴露的內(nèi)部對(duì)象。

防御：

• 鎖定Web目錄。使得通過(guò)網(wǎng)絡(luò)訪問(wèn)Web服務(wù)器的用戶都不能訪問(wèn)除專(zhuān)門(mén)用于存放Web內(nèi)容的目錄以外的目錄；
• 對(duì)于每一次對(duì)象引用都要重新驗(yàn)證授權(quán)；
• 禁止通過(guò)參數(shù)暴露內(nèi)部對(duì)象；
• 建議使用間接映射的方法取代簡(jiǎn)單的直接對(duì)象引用，比如：
  http://www.example.com/application?file=1

?? 2.8.3 信息泄露和不當(dāng)?shù)腻e(cuò)誤處理

定義：應(yīng)用程序可能會(huì)無(wú)意間泄露關(guān)于其配置、內(nèi)部工作原理或違反隱私的信息，這可能是由于應(yīng)用程序存在各種問(wèn)題。攻擊者利用這些弱點(diǎn)來(lái)竊取敏感數(shù)據(jù)或進(jìn)行更嚴(yán)重的攻擊。

敏感信息泄露常常細(xì)微難以察覺(jué)

常見(jiàn)的脆弱點(diǎn)：

• 查明堆棧跟蹤：為程序員提供詳盡的信息，說(shuō)明錯(cuò)誤發(fā)生前調(diào)用了哪些程序或函數(shù)。相同的信息還可為計(jì)算機(jī)罪犯提供函數(shù)、對(duì)象名稱，以及其它設(shè)計(jì)針對(duì)報(bào)告錯(cuò)誤的系統(tǒng)的攻擊的相關(guān)情況。
• SQL狀態(tài)信息：揭示數(shù)據(jù)庫(kù)、字段和表名稱——在計(jì)劃實(shí)施SQL注入之類(lèi)的攻擊時(shí)，與數(shù)據(jù)庫(kù)有關(guān)的信息十分重要
• 登錄信息：登錄失敗后，通知用戶是否用戶ID或密碼出錯(cuò)——登錄失敗可能是由于ID或密碼錯(cuò)誤造成的。這為一個(gè)對(duì)關(guān)鍵資產(chǎn)發(fā)動(dòng)暴力攻擊的攻擊者提供重要信息。
• 授權(quán)信息：確認(rèn)某個(gè)文件——如果未獲得授權(quán)的用戶企圖訪問(wèn)某個(gè)文件，返回的錯(cuò)誤消息會(huì)告訴她沒(méi)有取得訪問(wèn)那個(gè)資源的授權(quán)。如果她是一名試圖定位某個(gè)包含敏感信息的文件的攻擊者，錯(cuò)誤消息就為她提供了肯定信息。

示例1：

Microsoft OLE DB Provider for ODBC Drivers error '80004005' 
[Microsoft][ODBC Microsoft Access 97 Driver] Can't open database ‘VDPROD'.

示例2：

java.sql.SQLException: ORA-00600: internal error code,
arguments: [ttcgnd-1], [0], [], [], [],
at oracle.jdbc.dbaccess.DBError.throwSqlException (DBError.java:169) 
at oracle.jdbc.ttc7.TTIoer.processError (TTIoer.java:208)

錯(cuò)誤處理信息對(duì)于Debug非常有用，但是為攻擊者提供了太多潛在可用的攻擊信息！

防御：

• 每個(gè)應(yīng)用程序都應(yīng)包含一個(gè)標(biāo)準(zhǔn)的錯(cuò)誤處理框架來(lái)處理異常：禁止顯示堆棧跟蹤、數(shù)據(jù)庫(kù)訪問(wèn)、協(xié)議等相關(guān)的信息；
• Web程序應(yīng)只提供盡量簡(jiǎn)短、“剛好夠用”的錯(cuò)誤處理信息給用戶；

?? 2.8.4 認(rèn)證和會(huì)話管理不完善

定義：賬戶憑據(jù)和會(huì)話令牌通常沒(méi)有得到適當(dāng)?shù)谋Ｗo(hù)。攻擊者通過(guò)竊取密碼、密鑰或身份驗(yàn)證令牌來(lái)冒充其他用戶的身份。

會(huì)話（Session）管理

• HTTP/HTTPS是“無(wú)狀態(tài)”協(xié)議。意味著每一次用戶請(qǐng)求都需要認(rèn)證
• 會(huì)話管理解決了這樣的問(wèn)題：當(dāng)一個(gè)用戶得到服務(wù)器認(rèn)證后，服務(wù)器如何識(shí)別和處理這個(gè)認(rèn)證用戶接下來(lái)的請(qǐng)求
• Web程序一般會(huì)提供內(nèi)置的會(huì)話跟蹤方法，方便用戶的使用；
• Web開(kāi)發(fā)者常采用自己的策略來(lái)實(shí)現(xiàn)會(huì)話狀態(tài)管理，可能會(huì)犯錯(cuò)誤而導(dǎo)致安全問(wèn)題。

會(huì)話管理：Session ID

• 唯一地標(biāo)識(shí)用戶
• 一個(gè)ID僅用于一次認(rèn)證會(huì)話
• 由服務(wù)器生成
• 以如下的形式發(fā)送給客戶端：
  • 隱式變量
  • HTTP cookie
  • URL查詢串
• 服務(wù)器期待用戶在下一次請(qǐng)求時(shí)發(fā)送同樣的ID（用來(lái)標(biāo)識(shí)用戶已被認(rèn)證）

會(huì)話管理：Session Hijacking

• Session ID可能被泄露和猜解，黑客可以：
  • 獲取用戶的帳號(hào)
  • 做任何受害者能做的事情：一個(gè)使用同樣Session ID的攻擊者將擁有和真正用戶相同的特權(quán)。

認(rèn)證和會(huì)話管理攻擊流程：

防御：

• 使用長(zhǎng)且復(fù)雜的隨機(jī)Session ID，難以猜解；
• 對(duì)Session ID的傳輸、存儲(chǔ)進(jìn)行保護(hù)，防止被泄露和劫持；
• 使用SSL時(shí)，必須保護(hù)認(rèn)證和Session ID兩部分的內(nèi)容；
• URL查詢字符串中不要包含有User/Session任何信息。

?? 2.8.5 不安全的加密存儲(chǔ)

定義：Web程序很少正確使用加密功能來(lái)保護(hù)數(shù)據(jù)和憑據(jù)。攻擊者利用弱保護(hù)的數(shù)據(jù)進(jìn)行身份盜竊和其他犯罪活動(dòng)，例如信用卡欺詐。

常見(jiàn)的問(wèn)題：

• 對(duì)敏感信息沒(méi)有加密；
• 繼續(xù)使用已被證明加密強(qiáng)度不高的算法（ MD5, SHA-1, RC3, RC4, etc.）；
• 加密方法使用不安全，比如對(duì)加密口令的存儲(chǔ)不加保護(hù)；
• 嘗試使用自己發(fā)明的加密方法（實(shí)踐證明這種方法比較糟糕?。?。

示例：

防御：

• 如非必要，不要保存敏感信息；
• 確保所有的敏感信息都被加密，檢查敏感信息的歸檔過(guò)程和政策；
• 只使用經(jīng)過(guò)證明的標(biāo)準(zhǔn)加密算法；
• 小心存儲(chǔ)口令、證書(shū)等信息。

?? 2.8.6 URL訪問(wèn)缺少限制

定義：通常，應(yīng)用程序僅通過(guò)防止向未經(jīng)授權(quán)的用戶顯示鏈接或URL來(lái)保護(hù)敏感功能。攻擊者可以利用此弱點(diǎn)直接訪問(wèn)這些URL并執(zhí)行未經(jīng)授權(quán)的操作。

當(dāng)Web應(yīng)用缺少對(duì)某些URL的訪問(wèn)限制，攻擊者可以直接在瀏覽器中輸入U(xiǎn)RL來(lái)訪問(wèn)。

比如：

• Add_account_form.php 在顯示這個(gè)表單頁(yè)時(shí)要先對(duì)用戶的管理員角色進(jìn)行驗(yàn)證；
• 表單填好后發(fā)送給add_acct.php執(zhí)行添加帳號(hào)的功能；
• 如果不限制add_acct.php的直接訪問(wèn)，攻擊者直接在瀏覽器中訪問(wèn)該頁(yè)面，就繞過(guò)了權(quán)限檢查。

防御：

• 從早期做起！
  • 從需求階段就要制定詳細(xì)的安全策略；
  • 從頁(yè)面到每一個(gè)功能，都只由相應(yīng)的經(jīng)過(guò)認(rèn)證的角色來(lái)訪問(wèn)；
  • 訪問(wèn)控制策略越簡(jiǎn)單越好。
• 徹底地測(cè)試！
  • 進(jìn)行詳盡地測(cè)試保證訪問(wèn)控制沒(méi)有被旁路；
  • 嘗試所有的非法訪問(wèn)；
  • 測(cè)試時(shí)不要跟隨Web應(yīng)用的正常工作流；

?? 3. HTTPS

?? 3.1 提出背景：不安全的通信

定義：當(dāng)需要保護(hù)敏感通信時(shí)，應(yīng)用程序經(jīng)常無(wú)法加密網(wǎng)絡(luò)流量。

存在的問(wèn)題：

• 攻擊者可以從網(wǎng)絡(luò)上任何一個(gè)被攻陷的系統(tǒng)或設(shè)備上嗅探網(wǎng)絡(luò)流量：Web流量往往是不加密的
• 使用SSL也可能遭受“中間人”攻擊

?? 3.2 防御

保證所有用來(lái)認(rèn)證和傳輸敏感信息的連接都使用基于SSL/TLS的HTTPS

超文本傳輸安全協(xié)議（Hypertext Transfer Protocol Secure，HTTPS），是一種將HTTP和SSL（或TLS）結(jié)合來(lái)實(shí)現(xiàn)Web瀏覽器和服務(wù)器之間的安全通信協(xié)議，也稱為HTTP over TLS，HTTP over SSL或HTTP Secure?；赟SL或TLS的HTTP并沒(méi)有本質(zhì)區(qū)別，都被稱為HTTPS

?? 【PPT分享】清華大學(xué)鄭曉峰： 端到端安全協(xié)議的威脅、演進(jìn)和部署

從用戶使用的角度看，HTTP和HTTPS的主要區(qū)別是URL地址開(kāi)始于http://還是https://

• 一個(gè)標(biāo)準(zhǔn)的HTTP服務(wù)使用80端口，而一個(gè)標(biāo)準(zhǔn)的HTTPS服務(wù)則使用443端口

當(dāng)使用HTTPS時(shí)，下述通信內(nèi)容被加密：請(qǐng)求的文件的URL，文件的內(nèi)容，瀏覽器表單的內(nèi)容（由瀏覽器使用者填寫(xiě)），從瀏覽器發(fā)送到服務(wù)器或從服務(wù)器發(fā)送給瀏覽器的Cookie，HTTP標(biāo)題的內(nèi)容

連接建立：
作為HTTP用戶的代理程序（也是TLS的用戶）首先向服務(wù)器的指定端口（443）發(fā)起TCP連接請(qǐng)求。成功建立TCP連接后，向服務(wù)器發(fā)送TLS ClientHello，開(kāi)始TLS握手過(guò)程。當(dāng)TLS握手過(guò)程完成后，用戶將發(fā)起第一次HTTP請(qǐng)求。此時(shí)，所有HTTP協(xié)議數(shù)據(jù)都要以TLS應(yīng)用數(shù)據(jù)的形式通過(guò)TLS記錄協(xié)議加密傳輸。在此過(guò)程中，要遵守HTTP協(xié)議規(guī)范，包括保留連接。

Q：HTTP連接的含義？
A：HTTPS連接具體多個(gè)層面的意思。在HTTP層面，一個(gè)HTTP用戶通過(guò)向下一層（TCP或SSL/TLS）發(fā)送一個(gè)連接請(qǐng)求來(lái)向服務(wù)器請(qǐng)求建立一條連接；在TLS層面，一個(gè)會(huì)話建立在一個(gè)TLS用戶和一個(gè)TLS服務(wù)器之間，可以在任何時(shí)間支持一條或多條TLS連接。一條TLS連接請(qǐng)求的開(kāi)始總是伴隨著一條TCP連接的建立。

連接關(guān)閉：
關(guān)閉一條HTTPS連接要求關(guān)閉TLS與其對(duì)應(yīng)的對(duì)端實(shí)體之間的連接，這意味著也要關(guān)閉TLS的下層TCP連接。在TLS層面，關(guān)閉連接的最好方式是兩端都用TLS告警協(xié)議發(fā)出一個(gè)“close_notify”告警。在發(fā)出“close_notify”后，一個(gè)TLS實(shí)體會(huì)立即關(guān)閉該連接，而不會(huì)等待它的對(duì)等實(shí)體發(fā)來(lái)“close_notify”告警，從而可能造成“不完整的關(guān)閉”。

服務(wù)器端的HTTPS部署情況：

HSTS (HTTP Strict Transport Security)

• IETF提出的一種新的Web安全協(xié)議，其目的是強(qiáng)制客戶端（如Web瀏覽器）使用HTTPS與服務(wù)器進(jìn)行通信。使用HSTS協(xié)議的網(wǎng)站將保證瀏覽器始終使用HTTPS連接到服務(wù)器，不需要用戶在瀏覽器的地址欄中手工輸入HTTPS。當(dāng)客戶端通過(guò)HTTPS向服務(wù)器發(fā)出請(qǐng)求時(shí)，服務(wù)器在返回的超文本傳輸協(xié)議響應(yīng)頭中包含Strict-Transport-Security字段。
• HSTS可以用來(lái)抵御SSL剝離攻擊（一種用來(lái)阻止瀏覽器與服務(wù)器之間創(chuàng)建HTTPS連接的中間人攻擊方法，由Moxie Marlinspike在2009年的黑帽大會(huì)上提出），因?yàn)橹灰獮g覽器曾經(jīng)與服務(wù)器創(chuàng)建過(guò)一次安全連接，之后瀏覽器會(huì)強(qiáng)制使用HTTPS，即使URL鏈接中的https被替換成了http

判斷一個(gè)域名是否支持HTTPS：?? Internet.nl

有了HTTPS，即使被中間人攻擊，也能防止攻擊

• 2020.3.26 國(guó)內(nèi)部分地區(qū)網(wǎng)絡(luò)出現(xiàn)中間人攻擊（通過(guò)骨干網(wǎng)絡(luò)進(jìn)行劫持 HTTPS的443端口）：GitHub、京東等被劫持。因證書(shū)不對(duì)，被瀏覽器阻止訪問(wèn)

?? 國(guó)內(nèi)部分地區(qū)網(wǎng)絡(luò)出現(xiàn)中間人攻擊：GitHub、京東等被劫持

?? 域名注冊(cè)商GoDaddy客服被釣魚(yú)攻擊，多家公司域名解析被篡改

?? HTTPS 劫持漫談：代理劫持與透明劫持

簡(jiǎn)答題：小王某次出差住宿，利用酒店提供的Wi-Fi來(lái)上網(wǎng)，當(dāng)他開(kāi)始訪問(wèn)一個(gè)自己經(jīng)常訪問(wèn)的網(wǎng)站時(shí)，瀏覽器卻彈出類(lèi)似“你的連接不是專(zhuān)用連接”，將鼠標(biāo)放在瀏覽器地址欄的證書(shū)風(fēng)險(xiǎn)處，下拉顯示“證書(shū)無(wú)效之類(lèi)的信息”，如下圖所示。瀏覽器提示用戶“繼續(xù)訪問(wèn)”還是“返回”。而自己平時(shí)在辦公室訪問(wèn)該網(wǎng)站卻沒(méi)有出現(xiàn)該提示。請(qǐng)分析可能的原因。

答：最可能的原因是酒店在監(jiān)聽(tīng)用戶的上網(wǎng)，酒店使用自簽名證書(shū)或?yàn)g覽器不信任的CA頒發(fā)的證書(shū)作為中間人分別與瀏覽器與目標(biāo)網(wǎng)站進(jìn)行加密通信，解密、加密用戶瀏覽器與目標(biāo)網(wǎng)站之間的通信。

OK，以上就是本期知識(shí)點(diǎn)“Web應(yīng)用安全”的知識(shí)啦~~ ，感謝友友們的閱讀。后續(xù)還會(huì)繼續(xù)更新，歡迎持續(xù)關(guān)注喲??~
??如果有錯(cuò)誤?，歡迎批評(píng)指正呀??~讓我們一起相互進(jìn)步??
??如果覺(jué)得收獲滿滿，可以點(diǎn)點(diǎn)贊??支持一下喲~

? 轉(zhuǎn)載請(qǐng)注明出處
作者：HinsCoder
博客鏈接：?? 作者博客主頁(yè)文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-771390.html

到了這里，關(guān)于【信息安全原理】——Web應(yīng)用安全（學(xué)習(xí)筆記）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！