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 泄露到其他網站中去。

如果您想了解