jsp 和 servlet 有什麼不同？中上建立「建議學習：java常見的面試題#)
jsp經編譯後就變成了Servlet.java常見的面試題
)##jsp經典，本質上變成了Servlet.（JjavaSP的Servlet.辨識JSP的程式碼，Web容器將JSP的程式碼編譯成JVM能夠辨識的java類別）
jsp更擅長表現於頁面顯示，servlet更擅長於邏輯控制。
Servlet中沒有內建對象，Jsp中的內建物件都是必須透過HttpServletRequest對象，HttpServletResponse物件以及HttpServlet物件得到。
Jsp是Servlet的一種簡化，使用Jsp只需要完成程式設計師需要輸出到客戶端的內容，Jsp中的Java腳本如何鑲嵌到一個類別中，由Jsp容器完成。而Servlet則是個完整的Java類，這個類別的Service方法用來產生對客戶端的回應。
jsp 有哪些內建物件？作用分別是什麼？JSP有9個內建物件：
request：封裝客戶端的請求，其中包含來自GET或POST請求的參數；
response：封裝伺服器對客戶端的回應；
pageContext：透過該物件可以取得其他物件；
session：封裝使用者會話的物件；
application：封裝伺服器運行環境的物件；
out：輸出伺服器回應的輸出流物件；
config：Web應用的設定物件；
page：JSP頁面本身（相當於Java程式中的this）；
exception：封裝頁面拋出例外的物件。
說一下 jsp 的 4 種作用域？JSP中的四個作用域包括page、request、session和application，具體來說：
page代表與一個頁面相關的物件和屬性。
request代表與Web客戶機發出的一個請求相關的物件和屬性。一個請求可能跨越多個頁面，涉及多個Web元件；需要在頁面顯示的臨時資料可以置於此作用域。
session代表與某個使用者與伺服器建立的一次會話相關的物件和屬性。跟某個使用者相關的資料應該放在使用者自己的session中。
application代表與整個Web應用程式相關的物件和屬性，它實質上是跨越整個Web應用程序，包括多個頁面、請求和會話的一個全域作用域。
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的一種方式。
說一下 session 的工作原理？
其實session是一個存在伺服器上的類似一個散列表格的檔案。裡面存有我們需要的訊息，在我們需要用的時候可以從裡面取出。
類似一個大號的map吧，裡面的鍵存儲的是用戶的sessionid，用戶向伺服器發送請求的時候會帶上這個sessionid。這時就可以從中取出對應的數值了。
如果客戶端禁止 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 的差別是什麼？
攔截機制的不同
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高。
如何避免 sql 注入？
PreparedStatement（簡單又有效的方法）
使用正規表示式過濾傳入的參數
字串過濾
JSP中調用函數檢查是否包函非法字元
JSP頁面判斷程式碼
什麼是XSS 攻擊，如何避免？
XSS攻擊又稱CSS,全名為Cross Site Script （跨站腳本攻擊），其原理是攻擊者向有XSS漏洞的網站中輸入惡意的HTML 程式碼，當使用者瀏覽網站時，這段HTML 程式碼會自動執行，達到攻擊的目的。
XSS 攻擊類似於SQL 注入攻擊，SQL注入攻擊中以SQL語句作為用戶輸入，達到查詢/修改/刪除資料的目的，而在xss攻擊中，透過插入惡意腳本，實現對用戶遊覽器的控制，取得使用者的一些資訊。 XSS是 Web 程式中常見的漏洞，XSS 屬於被動式且用於客戶端的攻擊方式。
XSS防範的整體思路是：對輸入(和URL參數)進行過濾，對輸出進行編碼。
什麼是 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 洩漏到其他網站中去。
以上是Java Web常見面試題的詳細內容。更多資訊請關注PHP中文網其他相關文章！
