核心防禦機制

1.為什麼說應用程式處理使用者通路的機制是所有機制中最薄弱的機制？

典型的應用程式使用三重機制（身份驗證、會話管理和通路控制）來處理通路。

這些元件之間高度互相依賴，其中任何一個元件存在缺陷都會降低整個通路控制機制的效率。

例如，攻擊者可以利用身份驗證機制中的漏洞以任何使用者身份登入，并是以獲得未授權通路權限。

如果能夠預測令牌，攻擊者就可以假冒成任何已登入使用者并通路他們的資料。

如果通路控制不完善，則任何使用者都可以直接使用應該受到保護的功能。

2.會話與會話令牌有何不同？

會話是伺服器上儲存的一組資料結構，用于追蹤使用者與應用程式互動的狀态。

會話令牌是應用程式為會話配置設定的一個特殊字元串，使用者需要在連接配接提出請求的過程中送出該字元串，以重新确認自己的身份。

3.為何不可能始終使用基于白名單的方法進行輸入确認？

許多時候，應用程式可能會被迫接受與已知為“良性”輸入的清單或模式不比對的待處理資料。

例如，許多使用者的姓名包含可用在各種攻擊中的字元。

如果應用程式希望允許使用者以真實姓名注冊，就需要接受可能的惡意輸入，并確定安全處理這些輸入。

4. 攻擊者正在攻擊一個執行管理功能的應用程式，并且不具有使用這項功能的任何有效證書。為何他仍然應當密切關注這項功能呢？

攻擊者可以利用任何通路控制核心機制中的缺陷未授權通路管理功能。

此外，攻擊者以低權限使用者身份送出的資料最終将向管理使用者顯示，是以，攻擊者可以送出一些惡意資料，

用于在管理使用者檢視這些資料時攻破他們的會話，進而對管理使用者實施攻擊。

5.  旨在阻止跨站點腳本攻擊的輸入确認機制按以下順序處理一個輸入：

(1) 删除任何出現的<script>表達式；

(2) 将輸入截短為50個字元；

(3) 删除輸入中的引号；

(4) 對輸入進行URL解碼；

(5) 如果任何輸入項被删除，傳回步驟(1)。

是否能夠避開上述确認機制，讓以下資料通過确認？

“><script>alert(“foo”)</script>

是。如果沒有第4步，此機制将是可靠的，能夠過濾其旨在阻止的特定項目。

但是，由于輸入在執行過濾步驟後被解碼，

攻擊者隻需要對有效載荷中的標明字元進行URL編碼，就可以避開這種過濾：

%22>%3cscript>alert(%22foo%22)</script>

如果首先執行第4步，或根本不執行該步驟，攻擊者将難以避開上述過濾。