企業級 JavaBeans 編程規範中說明每一個 bean 的提供者必須遵守一系列編程規範，來確保 bean 在 EJB 容器 [1] 中的可移植性和運作方式一致。

在此案例中，程式違背了以下 EJB 規範：

「企業級 bean 禁止使用 AWT 功能來嘗試將資訊輸出至顯示器，或者從鍵盤輸入資訊。」

制定此規範的理由如下所示：

「大部分的伺服器都不允許應用程式中的程式與伺服器系統上的鍵盤與顯示器進行直接互動。」

企業級 JavaBeans 編程規範中說明每一個 bean 的提供者必須遵守一系列編程規範，來確保 bean 在 EJB 容器 [1] 中的可移植性和運作方式一致。

在此案例中，程式違背了以下 EJB 規範：

「企業級 bean 禁止以下內容：嘗試建立類別載入器、取得目前的類別載入器、設定類別載入器的環境、設定安全管理員、建立新的安全管理員、停止 JVM 或者變更輸入、輸出與錯誤串流。」

制定此規範的理由如下所示：

「這些功能是為 EJB 容器保留的。允許企業級 bean 使用這些功能會造成一些安全上的問題，並且使得容器無法正確管理執行期間環境。」

企業級 JavaBeans 編程規範中說明每一個 bean 的提供者必須遵守一系列編程規範，來確保 bean 在 EJB 容器 [1] 中的可移植性和運作方式一致。

在此案例中，程式違背了以下 EJB 規範：

「企業級 bean 禁止使用 java.io 封包來嘗試直接存取 File System 中的檔案與目錄。」

制定此規範的理由如下所示：

「File System API 並不適合讓商用元件來存取資料。商用元件應使用資源管理員 API (例如 JDBC) 來儲存資料。」

企業級 JavaBeans 編程規範中說明每一個 bean 的提供者必須遵守一系列編程規範，來確保 bean 在 EJB 容器 [1] 中的可移植性和運作方式一致。

在此案例中，程式違背了以下 EJB 規範：

「企業級的 bean 禁止嘗試監聽通訊端、接受通訊端上的連線或使用通訊端來做多點傳送。」

制定此規範的理由如下所示：

「EJB 架構允許企業級的 bean 實例做為網路通訊端用戶端來運作，但是不允許它做為網路伺服器來運作。允許企業級 bean 實例做為網路伺服器會與企業級 bean 的基本功能 (為 EJB 用戶端提供服務) 相抵觸。」

企業級 JavaBeans 編程規範中說明每一個 bean 的提供者必須遵守一系列編程規範，來確保 bean 在 EJB 容器 [1] 中的可移植性和運作方式一致。

在此案例中，程式違背了以下 EJB 規範：

「一個企業級 bean 禁止使用執行緒同步處理來同步執行多個實例。」

制定此規範的理由如下所示：

「這個規則需要確保一致的執行期間語義，因為一些 EJB 容器可能會使用單一 JVM 來執行所有的 bean 實例，其他則可能會跨多個 JVM 來分配實例。」

以下狀況都會導致檔案洩漏：
1. 資料從一個不可信賴的來源進入程式。


2. 此資料將用於動態地建構路徑。

範例 1：以下程式碼採用不可信賴的資料，並使用該資料來開啟檔案，該檔案隨後會回傳給使用者。

from django.http import FileResponse
...
def file_disclosure(request):
    path = request.GET['returnURL']
    return FileResponse(open(path, 'rb'))
...

如果攻擊者所提供 URL 的要求參數符合敏感檔案位置，他們也會能夠檢視該檔案。例如，"http://www.yourcorp.com/webApp/logic?returnURL=settings.py" 可讓他們檢視應用程式的 "settings.py"。

以下狀況都可能導致檔案洩露：
1. 資料從一個不可信賴的來源進入程式。


2. 此資料將用於動態地建構路徑。

範例 1：以下程式碼採用不可信賴的資料，並使用該資料來建立在伺服器端轉送中使用的路徑。

...
String returnURL = request.getParameter("returnURL");
	RequestDispatcher rd = request.getRequestDispatcher(returnURL);
	rd.forward();
...

範例 2：以下程式碼採用不可信賴的資料，並使用該資料來建立在伺服器端轉送中使用的路徑。

...
	<% String returnURL = request.getParameter("returnURL"); %>
	<jsp:include page="<%=returnURL%>" />
	...

如果攻擊者所提供 URL 的要求參數符合敏感檔案位置，他們也會能夠檢視該檔案。例如，"http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml" 會讓他們能夠檢視應用程式的 applicationContext.xml。
攻擊者在擁有 applicationContext.xml 之後，便可找到並下載 applicationContext.xml 中所參照的配置檔案，甚至也可能下載類別或 jar 檔案。這讓攻擊者能夠取得應用程式的相關敏感資訊，並使其成為其他類型攻擊的目標。