2020全新Java面試題－Java Web（二）

一、如果客戶端禁止 cookie 能實現 session 還能用嗎？

Cookie與 Session，一般認為是兩個獨立的東西，Session採用的是在伺服器端保持狀態的方案，而Cookie採用的是在客戶端保持狀態的方案。但為什麼禁用Cookie就不能得到Session呢？因為Session是用Session ID來確定目前對話所對應的伺服器Session，而Session ID是透過Cookie來傳遞的，禁用Cookie相當於失去了Session ID，也就得不到Session了。

假定使用者關閉Cookie的情況下使用Session，其實作途徑有以下幾種：

• 設定php.ini設定檔中的「session.use_trans_sid = 1 ”，或編譯時開啟了“--enable-trans-sid”選項，讓PHP自動跨頁傳遞Session ID。

• 手動透過URL傳值、隱藏表單傳遞Session ID。

• 以檔案、資料庫等形式保存Session ID，在跨頁過程中手動呼叫。

二、spring mvc 和 struts 的差別是什麼？

1、攔截機制的不同

Struts2是類別層級的攔截，每次要求就會建立一個Action，和Spring整合時Struts2的ActionBean注入作用域是原型模式prototype，然後透過setter，getter吧request資料注入到屬性。 Struts2中，一個Action對應一個request，response上下文，在接收參數時，可以透過屬性接收，這說明屬性參數是讓多個方法共享的。 Struts2中Action的一個方法可以對應一個url，而其類別屬性卻被所有方法共享，這也就無法用註解或其他方式標識其所屬方法了，只能設計為多例。

SpringMVC是方法層級的攔截，一個方法對應一個Request上下文，所以方法直接基本上是獨立的，獨享request，response資料。而每個方法同時又何一個url對應，參數的傳遞是直接注入到方法中的，是方法所獨有的。處理結果透過ModeMap傳回給框架。在Spring整合時，SpringMVC的Controller Bean預設單例模式Singleton，所以預設對所有的請求，只會創建一個Controller，有應為沒有共享的屬性，所以是線程安全的，如果要改變預設的作用域，需要添加@Scope註解修改。

Struts2有自己的攔截Interceptor機制，SpringMVC這是用的是獨立的Aop方式，這樣導致Struts2的設定檔量還是比SpringMVC大。

（相關教學推薦：java入門程式）

2、底層框架的不同

Struts2採用Filter（StrutsPrepareAndExecuteFilter）實現，SpringMVC（DispatcherServlet ）則採用Servlet實作。 Filter在容器啟動之後即初始化；服務停止以後墜毀，晚於Servlet。 Servlet在呼叫時初始化，先於Filter調用，服務停止後銷毀。

3、效能方面

Struts2是類別層級的攔截，每次要求對應實例一個新的Action，需要載入所有的屬性值注入，SpringMVC實作了零配置，由於SpringMVC基於方法的攔截，有載入一次單例模式bean注入。所以，SpringMVC開發效率和效能高於Struts2。

4、配置方面

spring MVC和Spring是無縫的。從這個專案的管理和安全上也比Struts2高。

三、如何避免 sql 注入？

• PreparedStatement（簡單又有效的方法）

• 使用正規表示式過濾傳入的參數

• #字串過濾

• JSP中呼叫函數檢查是否包函非法字元

• JSP頁面判斷程式碼

四、什麼是XSS 攻擊，如何避免？

XSS攻擊又稱CSS,全名為Cross Site Script  （跨站腳本攻擊），其原理是攻擊者向有XSS漏洞的網站中輸入惡意的HTML 程式碼，當使用者瀏覽網站時，這段HTML 程式碼會自動執行，達到攻擊的目的。

XSS 攻擊類似於SQL 注入攻擊，SQL注入攻擊中以SQL語句作為用戶輸入，達到查詢/修改/刪除資料的目的，而在xss攻擊中，透過插入惡意腳本，實現對用戶遊覽器的控制，取得使用者的一些資訊。 XSS是 Web 程式中常見的漏洞，XSS 屬於被動式且用於客戶端的攻擊方式。

XSS防範的整體思路是：對輸入(和URL參數)進行過濾，對輸出進行編碼。

（影片教學推薦：java影片教學）

五、什麼是 CSRF 攻擊，如何避免？

CSRF（Cross-site request forgery）也被稱為 one-click attack或 session riding，中文全稱是叫跨站請求偽造。一般來說，攻擊者透過偽造用戶的瀏覽器的請求，向訪問一個用戶自己曾經認證訪問過的網站發送出去，使目標網站接收並誤以為是用戶的真實操作而去執行命令。常用於盜取帳號、轉帳、發送虛假訊息等。攻擊者利用網站對請求的驗證漏洞而實現這樣的攻擊行為，網站能夠確認請求來自使用者的瀏覽器，卻無法驗證請求是否源自於使用者的真實意願下的操作行為。

如何避免：

1、驗證 HTTP Referer 欄位

HTTP頭中的Referer欄位記錄了該 HTTP 請求的來源位址。在通常情況下，訪問一個安全受限頁面的請求來自於同一個網站，而如果駭客要對其實施 CSRF攻擊，他一般只能在他自己的網站建構請求。因此，可以透過驗證Referer值來防禦CSRF 攻擊。

2、使用驗證碼

關鍵操作頁面加上驗證碼，後台收到請求後透過判斷驗證碼可以防禦CSRF。但這種方法對使用者不太友善。

3、在請求位址中加入token並驗證

CSRF 攻擊之所以能夠成功，是因為駭客可以完全偽造使用者的請求，而這個要求中所有的使用者驗證資訊都是存在於cookie中，因此駭客可以在不知道這些驗證資訊的情況下直接利用使用者自己的cookie 來通過安全驗證。

要抵禦 CSRF，關鍵在於在請求中放入駭客所不能偽造的訊息，並且該資訊不存在於 cookie 之中。可以在HTTP 請求中以參數的形式加入一個隨機產生的token，並在伺服器端建立一個攔截器來驗證這個token，如果請求中沒有token或token 內容不正確，則認為可能是CSRF 攻擊而拒絕該請求。

這種方法要比檢查Referer 要安全一些，token 可以在用戶登陸後產生並放於session之中，然後在每次請求時把token 從session 中拿出，與請求中的token進行比對，但這種方法的困難在於如何把token 以參數的形式加入請求。

對於GET 請求，token 會附在請求地址之後，這樣URL 就變成

http://url?csrftoken=tokenvalue

而對於POST 請求來說，要在form 的最後加上

<input type="hidden" name="csrftoken" value="tokenvalue"/>

這樣就把token以參數的形式加入請求了。

4、在HTTP 頭中自訂屬性並驗證

這種方法也是使用token 並進行驗證，和上一個方法不同的是，這裡並不是把token以參數的形式置於HTTP 請求之中，而是把它放到HTTP 頭中自訂的屬性裡。透過 XMLHttpRequest 這個類，可以一次給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，並把 token 值放入其中。

這樣解決了上種方法在請求中加入token 的不便，同時，透過XMLHttpRequest 請求的位址不會被記錄到瀏覽器的位址欄，也不用擔心token 會透過Referer 洩漏到其他網站中去。

如果您想了解更多相關面試題，可以造訪java面試題專欄。

以上是2020全新Java面試題－Java Web（二）的詳細內容。更多資訊請關注PHP中文網其他相關文章！