通用Web平台安全最佳實踐

通用Web平台安全最佳實踐

    下面列出的建議适用于所有Web平台，無論它是現成的還是自定制的。

執行嚴格的雙向網絡通路控制

    我們認為在網際網路的現今階段，就不用再強調對Web伺服器的入站通信進行嚴格防火牆過濾的必要性了。TCP端口80（如果你實作了SSL/TLS，還有443端口）應該是一般通路者在入站時唯一可以通路的端口（顯然，特定的使用者通信，比如内容管理，伺服器管理等，可能需要通路其他特殊的端口）。

    雖然入站的過濾被廣泛應用，但我們經常看到的一個錯誤是忽略了對出站的通路控制。一旦攻擊者獲得了在Web伺服器上運作任意指令的權限，他首先要做的事情是得到一個出站Shell，或者建立出站的連接配接來上傳更多的檔案到受害機上。在Web伺服器前端防火牆上，進行正确的出站過濾，可以阻止這些請求，進而從根本上阻止攻擊者。最簡單的規則是保留已經建立的連接配接，拒絕所有其他的出站連接配接，這可以通過保留有TCP SYN标志的包而阻止其他包來實作。這樣不會阻止對合法請求的響應，伺服器仍然可以被外部通路到（你的入站過濾器也是很嚴格的，對吧？）

請注意很重要的一點是，老練的攻擊者可能會劫持合法的出站連接配接，來繞過出站過濾。但是，依據我們的經驗，在實際中是很難做到的。嚴格的出站通路控制，是你可以為Web伺服器建立的重要防範層。

及時更新安全更新檔

    保持Web平台強健和安全的最有效方法，是随時保持系統更新最新的安全更新檔。你必須不斷地為你的平台和應用程式打上更新檔，沒有什麼捷徑可言。雖然這裡還有很多其他的步驟可以用來加強你的系統以避免攻擊，但是就像宣傳的那樣，及時更新系統的安全設定是你能做的最重要的事情。我們建議使用自動更新工具，比如微軟更新服務，來幫助你保證擷取最新的更新檔。對于Apache來說，隻需訂閱Apache公告清單，就可以在新版本釋出的時候得到通知，進而進行更新（其連結請檢視本章末尾的“參考和進一步閱讀”一節）。

不要在源代碼中放置私密資訊

    如果教導你的開發團隊不犯此類錯誤，你就不用太擔心最新、最嚴重的源代碼洩漏會傳遍黑客圈。這一類常見的錯誤包括：

    在ASP腳本中用明文SQL連接配接字元串  使用SQL內建安全或一個二進制的COM對象來代替。

    在應用配置檔案中使用明文密碼  在諸如global.asa或web.config應用程式配置檔案中，永遠不要使用明文密碼。

    使用以.inc為擴充名的包含檔案  把它們改名為.asp，并在其他腳本中改變對應的内部引用（或者像本章前面描述的那樣，把.inc映射到ASP擴充）。

    在腳本中的注釋中包含諸如E-mail位址、目錄結構資訊和密碼等私密資訊  不要把你自己放到如此高危的環境中，确認删除了會對自己不利的Web平台資訊和應用程式資訊。

定期為易受到攻擊的伺服器進行網絡掃描

    防範攻擊的最佳機制是定期進行漏洞掃描。這裡有很多非常有效的檢測Web應用程式的産品，比如SPI Dynamics的WebInspect，Watchfire的AppScan。對于識别Web平台漏洞和應用層漏洞，它們都非常棒。

！提示  關于自動化Web安全評估工具的評測，請檢視第13章。

能判斷自己是否受到了攻擊

    應急響應措施就像防範措施一樣重要，對于易受攻擊的Web伺服器來說更是如此。為了确認你的伺服器是否已經成為了目錄周遊攻擊的受害者，我們推薦如下指定的調查行動，這包括了如下的經典技術。

    在受到攻擊的Web伺服器上使用Netstat程式，是确認任何連到Web伺服器高端口的陌生入站連接配接的好辦法。就像我們已經看到的那樣，在漏洞被利用之後，可能随後有連接配接到流氓Shell執行個體。但是，要把出站連接配接和Web用戶端的合法連接配接區分開有點困難。

！提示  在WindowsXP之後（包括XP）的版本，netstat指令做了修改，可以用-o選項顯示使用TCP/IP端口的程式。

    另一個不錯的調查切入點是檔案系統。大量現成的攻擊代碼在網際網路上流傳。那裡有很多與攻擊相關的檔案，它們最初是由很嚴肅的安全研究人員釋出的，卻常常被腳本小子完全重用。舉個例子來說，在IIS上，諸如Sensepost.exe，Upload.asp，Upload.inc和Cmdasp.asp等檔案都是常見的系統後門。雖然隻是簡單地重命名，但至少可以防範腳本小子的攻擊。特别要注意諸如IIS的/script這類可寫/可執行檔案夾下的檔案。另一種常見的情況是，IIS攻擊代碼常常帶有root.exe（重命名後的指令行shell），e.asp，dl.exe，reggina.exe，regit.exe，restsec.exe，makeini.exe，newgina.dll，firedaemon.exe，mmtask.exe，sud.exe和sud.bak等檔案。一定要留心它們！

    最後，也可能是最顯眼的，首先顯示未授權行為的地方常常是Web伺服器日志（在本章的前面，我們已經讨論過日志繞過技術）。下面，我們舉一個簡單的例子，說明如何發現Code Red和Nimda蠕蟲對伺服器的通路。2001年末到2002年，Code Red和Nimda蠕蟲在Internet上橫行，它們感染帶有緩沖區溢出漏洞的伺服器，植入代碼，然後繼續感染其他的伺服器。在Code Red感染的伺服器上，Web伺服器日志包含了像下面這樣的項：

GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

NNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090

%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff

%u0078%u0000%u00=a

    Code Red和Nimda也會在受攻擊的系統上留下很多檔案。出現%systemdrive%\notworm目錄是伺服器已經被Code Red攻擊的明顯标記。如果存在已被重命名的叫做root.exe的Windows指令行shell，那也是Nimda曾通路過機器的标記。

    我們明白，即使在一個規模不大的Web伺服器上定期監視日志和檔案系統，都需要很大的精力。但是，我們希望一旦發現伺服器已經受到攻擊，這些提示可以幫助你。

本文節選自電子工業出版社2008年6月出版的《黑客大曝光——Web應用安全機密與解決方案（第2版）》。

到當當網購買

到卓越網購買

到china-pub購買

浏覽更多精彩文章>>

訂閱軟體安全電子期刊>>