**Java Web** **64\. jsp 和 servlet 有什么區別？** 1. jsp經編譯后就變成了Servlet.（JSP的本質就是Servlet，JVM只能識別java的類，不能識別JSP的代碼，Web容器將JSP的代碼編譯成JVM能夠識別的java類） 2. jsp更擅長表現于頁面顯示，servlet更擅長于邏輯控制。 3. Servlet中沒有內置對象，Jsp中的內置對象都是必須通過HttpServletRequest對象，HttpServletResponse對象以及HttpServlet對象得到。 4. Jsp是Servlet的一種簡化，使用Jsp只需要完成程序員需要輸出到客戶端的內容，Jsp中的Java腳本如何鑲嵌到一個類中，由Jsp容器完成。而Servlet則是個完整的Java類，這個類的Service方法用于生成對客戶端的響應。 **65\. jsp 有哪些內置對象？作用分別是什么？** JSP有9個內置對象： * request：封裝客戶端的請求，其中包含來自GET或POST請求的參數； * response：封裝服務器對客戶端的響應； * pageContext：通過該對象可以獲取其他對象； * session：封裝用戶會話的對象； * application：封裝服務器運行環境的對象； * out：輸出服務器響應的輸出流對象； * config：Web應用的配置對象； * page：JSP頁面本身（相當于Java程序中的this）； * exception：封裝頁面拋出異常的對象。 **66\. 說一下 jsp 的 4 種作用域？** JSP中的四種作用域包括page、request、session和application，具體來說： * **page**代表與一個頁面相關的對象和屬性。 * **request**代表與Web客戶機發出的一個請求相關的對象和屬性。一個請求可能跨越多個頁面，涉及多個Web組件；需要在頁面顯示的臨時數據可以置于此作用域。 * **session**代表與某個用戶與服務器建立的一次會話相關的對象和屬性。跟某個用戶相關的數據應該放在用戶自己的session中。 * **application**代表與整個Web應用程序相關的對象和屬性，它實質上是跨越整個Web應用程序，包括多個頁面、請求和會話的一個全局作用域。 **67\. session 和 cookie 有什么區別？** * 由于HTTP協議是無狀態的協議，所以服務端需要記錄用戶的狀態時，就需要用某種機制來識具體的用戶，這個機制就是Session.典型的場景比如購物車，當你點擊下單按鈕時，由于HTTP協議無狀態，所以并不知道是哪個用戶操作的，所以服務端要為特定的用戶創建了特定的Session，用用于標識這個用戶，并且跟蹤用戶，這樣才知道購物車里面有幾本書。這個Session是保存在服務端的，有一個唯一標識。在服務端保存Session的方法很多，內存、數據庫、文件都有。集群的時候也要考慮Session的轉移，在大型的網站，一般會有專門的Session服務器集群，用來保存用戶會話，這個時候 Session 信息都是放在內存的，使用一些緩存服務比如Memcached之類的來放 Session。 * 思考一下服務端如何識別特定的客戶？這個時候Cookie就登場了。每次HTTP請求的時候，客戶端都會發送相應的Cookie信息到服務端。實際上大多數的應用都是用 Cookie 來實現Session跟蹤的，第一次創建Session的時候，服務端會在HTTP協議中告訴客戶端，需要在 Cookie 里面記錄一個Session ID，以后每次請求把這個會話ID發送到服務器，我就知道你是誰了。有人問，如果客戶端的瀏覽器禁用了 Cookie 怎么辦？一般這種情況下，會使用一種叫做URL重寫的技術來進行會話跟蹤，即每次HTTP交互，URL后面都會被附加上一個諸如 sid=xxxxx 這樣的參數，服務端據此來識別用戶。 * Cookie其實還可以用在一些方便用戶的場景下，設想你某次登陸過一個網站，下次登錄的時候不想再次輸入賬號了，怎么辦？這個信息可以寫到Cookie里面，訪問網站的時候，網站頁面的腳本可以讀取這個信息，就自動幫你把用戶名給填了，能夠方便一下用戶。這也是Cookie名稱的由來，給用戶的一點甜頭。所以，總結一下：Session是在服務端保存的一個數據結構，用來跟蹤用戶的狀態，這個數據可以保存在集群、數據庫、文件中；Cookie是客戶端保存用戶信息的一種機制，用來記錄用戶的一些信息，也是實現Session的一種方式。 **68\. 說一下 session 的工作原理？** 其實session是一個存在服務器上的類似于一個散列表格的文件。里面存有我們需要的信息，在我們需要用的時候可以從里面取出來。類似于一個大號的map吧，里面的鍵存儲的是用戶的sessionid，用戶向服務器發送請求的時候會帶上這個sessionid。這時就可以從中取出對應的值了。 **69\. 如果客戶端禁止 cookie 能實現 session 還能用嗎？** Cookie與 Session，一般認為是兩個獨立的東西，Session采用的是在服務器端保持狀態的方案，而Cookie采用的是在客戶端保持狀態的方案。但為什么禁用Cookie就不能得到Session呢？因為Session是用Session ID來確定當前對話所對應的服務器Session，而Session ID是通過Cookie來傳遞的，禁用Cookie相當于失去了Session ID，也就得不到Session了。 假定用戶關閉Cookie的情況下使用Session，其實現途徑有以下幾種： 1. 設置php.ini配置文件中的“session.use\_trans\_sid = 1”，或者編譯時打開打開了“--enable-trans-sid”選項，讓PHP自動跨頁傳遞Session ID。 2. 手動通過URL傳值、隱藏表單傳遞Session ID。 3. 用文件、數據庫等形式保存Session ID，在跨頁過程中手動調用。 **70\. spring mvc 和 struts 的區別是什么？** * ### 攔截機制的不同 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大。 ### * ### 底層框架的不同 Struts2采用Filter（StrutsPrepareAndExecuteFilter）實現，SpringMVC（DispatcherServlet）則采用Servlet實現。Filter在容器啟動之后即初始化；服務停止以后墜毀，晚于Servlet。Servlet在是在調用時初始化，先于Filter調用，服務停止后銷毀。 * ### 性能方面 Struts2是類級別的攔截，每次請求對應實例一個新的Action，需要加載所有的屬性值注入，SpringMVC實現了零配置，由于SpringMVC基于方法的攔截，有加載一次單例模式bean注入。所以，SpringMVC開發效率和性能高于Struts2。 * ### 配置方面 spring MVC和Spring是無縫的。從這個項目的管理和安全上也比Struts2高。 **71\. 如何避免 sql 注入？** 1. PreparedStatement（簡單又有效的方法） 2. 使用正則表達式過濾傳入的參數 3. 字符串過濾 4. JSP中調用該函數檢查是否包函非法字符 5. JSP頁面判斷代碼 **72\. 什么是 XSS 攻擊，如何避免？** XSS攻擊又稱CSS,全稱Cross Site Script? （跨站腳本攻擊），其原理是攻擊者向有XSS漏洞的網站中輸入惡意的 HTML 代碼，當用戶瀏覽該網站時，這段 HTML 代碼會自動執行，從而達到攻擊的目的。XSS 攻擊類似于 SQL 注入攻擊，SQL注入攻擊中以SQL語句作為用戶輸入，從而達到查詢/修改/刪除數據的目的，而在xss攻擊中，通過插入惡意腳本，實現對用戶游覽器的控制，獲取用戶的一些信息。 XSS是 Web 程序中常見的漏洞，XSS 屬于被動式且用于客戶端的攻擊方式。 XSS防范的總體思路是：對輸入(和URL參數)進行過濾，對輸出進行編碼。 **73\. 什么是 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 的最后加上 ，這樣就把token以參數的形式加入請求了。 ### ### 4\. 在HTTP 頭中自定義屬性并驗證 > 這種方法也是使用 token 并進行驗證，和上一種方法不同的是，這里并不是把 token 以參數的形式置于 HTTP 請求之中，而是把它放到 HTTP 頭中自定義的屬性里。通過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，并把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，通過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄，也不用擔心 token 會透過 Referer 泄露到其他網站中去。