跳轉到內容

WebObjects/Web 應用/開發/身份驗證和安全

來自 Wikibooks,開放世界中的開放書籍

Wikibooks WebObjects 頁面被認為已過時

[編輯 | 編輯原始碼]

請參閱 http://wiki.objectstyle.org/confluence/display/WO/Web+Applications-Development-Authentication+and+Security

加密密碼

[編輯 | 編輯原始碼]

Kieran Kelleher 在他的部落格上寫了一篇關於透過自定義屬性對 EO 屬性執行加密的優秀文章:http://web.archive.org/20071121050703/homepage.mac.com/kelleherk/iblog/C729512539/E2033071041/index.html

安全注意事項

[編輯 | 編輯原始碼]

只是一些最初由 Anders Björklund 彙編的提示和技巧...

除了“透過 HTTP 的一切都不安全,對敏感資料使用 HTTPS” 的常規操作之外,還有一些 WO 特定的問題。它可以向訪問者洩露很多您的設定...

首先,如果您在 WO 4.5.1 之前使用 Apache Web 伺服器,請將 WebObjectsConnectionPool 設定為零以避免 Session Mixing 錯誤(使用者會獲取彼此的會話)

您可能想要檢查您的系統(最好是從伺服器防火牆外部)是否存在以下問題

  • $HOSTNAME = host.domain.tld (您的 Web 伺服器)
  • $APPNAME = WOApplication 名稱(您的應用程式)

CGI 介面卡應用程式列表

[編輯 | 編輯原始碼]

http://$HOSTNAME/cgi-bin/WebObjects/

為應用程式列表設定使用者名稱和密碼。

Web 伺服器資源列表

[編輯 | 編輯原始碼]

http://$HOSTNAME/WebObjects/

不要允許在您的 Web 伺服器上瀏覽目錄,否則使用者將能夠檢視所有 Web 伺服器資源,並瞭解所有包含 Web 伺服器資源的應用程式和框架的名稱。

wotaskd 配置頁面 (WO >= 4.5)

[編輯 | 編輯原始碼]

http://$HOSTNAME:1085/cgi-bin/WebObjects/wotaskd.woa/wa/woconfig

埠 1085 不應允許透過防火牆。

監控器

[編輯 | 編輯原始碼]

http://$HOSTNAME/cgi-bin/WebObjects/Monitor

監控器應不可用,或者至少受密碼保護。

xyzzy 預設頁面

[編輯 | 編輯原始碼]

http://$HOSTNAME/cgi-bin/WebObjects/xyzzy

xyzzy 頁面的名稱/密碼應更改。

WOStatisticsStore 預設頁面

[編輯 | 編輯原始碼]

http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOStats

統計頁面應受密碼保護(或關閉)。

WOEventDisplay 預設頁面 (WO >= 4.5)

[編輯 | 編輯原始碼]

http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOEventDisplay

事件頁面應受密碼保護(或關閉)。

WOEventSetup 預設頁面

[編輯 | 編輯原始碼]

http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/WOEventSetup

請參閱 http://developer.apple.com/techpubs/webobjects/EOControlRef/Java/Classes/Concepts/EOEventCenterConcepts.html

如果知道 WOComponent 的名稱,您可以直接呼叫它

[編輯 | 編輯原始碼]

http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wo/$COMPONENTNAME.wo

這可用於以其他方式明確不允許的方式導航網站。此外,WebObjects 框架中包含許多具有眾所周知名稱的 WOComponent,因此可在任何 WebObjects 應用程式中訪問它們。

這是一個非常嚴重的安全問題。以這種方式訪問的 WOComponent 基本上未初始化(即,沒有設定繫結)。在某些情況下,以這種方式訪問未初始化的 WOComponent 會使應用程式崩潰。應阻止任何允許任何人透過對應用程式的簡單 URL 呼叫使應用程式崩潰的方式。

如果知道 DirectAction 的名稱,您可以呼叫它

[編輯 | 編輯原始碼]

http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/$DIRECTACTIONNAME http://$HOSTNAME/cgi-bin/WebObjects/$APPNAME.woa/wa/$DIRECTACTIONCLASSNAME/$DIRECTACTIONNAME

如果有人可以訪問您的應用程式,那麼他們可以使用上面的 URL 呼叫任何他們想要的直接操作。如果 DirectAction 名稱存在,它將被呼叫。如果不存在,則會丟擲錯誤(應該被捕獲)。不應該隨機訪問的 DirectAction 應該被保護。如果您的應用程式將使用者輸入的文字顯示到 HTML 流中,那麼他們可能可以插入一個 <WEBOBJECT> 標籤來顯示否則不會顯示的元件。

這很棘手——攻擊者需要知道現有 Web 物件的名稱,即使這樣他們也無法覆蓋繫結 (.wod) 檔案中的引數。

Andrus Adamchik 指出,由於 WebObjects 的 HTML 模板系統的工作方式,您還需要使用使用者輸入的字串顯式呼叫 WOComponent.templateWithName。

以及一些由英國 WebObjects 顧問 GarrickMcFarlane 提供的雜項補充。

  • 如果您保留多個介面卡(例如,在 IIS 上,WebObjects.dll 和 WebObjects.exe),那麼您可以對其中一個應用所有安全措施,同時仍然讓另一個幾乎沒有保護——因為它們使用不同的名稱和機制來確定您的安全設定。因此,如果您使用的是 dll,您應該考慮刪除 .exe。
  • xyzzy 在 4.5.1 及更高版本中被稱為 WOAdaptorInfo。
  • 如果您使用檔案上傳元件,請確保您已將 Web 伺服器配置為禁止超過一定大小的檔案上傳,否則您的 Web/應用程式伺服器/介面卡/應用程式很容易被拒絕服務(動詞?),透過上傳大量資料。
  • 如果您在應用程式級別實現使用者/密碼安全——例如,透過在主頁上新增一個登入面板——考慮覆蓋請求處理的全域性部分(例如 session.appendToResponse),以檢查它是否在每次請求中都設定。否則,透過意外的“後門”偷偷進入您的應用程式就太容易了。
  • 您可以使用 Web 伺服器身份驗證並在 application.handleRequest 中類似的地方檢查每個請求的標頭——這樣任何未經授權的請求都不會被您的應用程式處理。如果您想格外小心,您可以重新編譯介面卡以檢查這些標頭,甚至不會將請求傳遞給應用程式。

不要忘記您在應用程式中可能可用的任何直接操作的安全影響。

您可能還想檢查您的應用程式伺服器和資料庫伺服器的服務埠是否對公共網際網路開放。通常,您只需要 80 和 443 到 Web 伺服器作為唯一的通訊(有一些例外:您可能還想允許 22,用於 SSH 管理,甚至可能允許 21 用於某些頁面的 FTP 訪問等)。

以及所有其他正常的伺服器網際網路連線預防措施... http://www.w3.org/Security/Faq/

華夏公益教科書