jsp 和 servlet 有什么區(qū)別？

jsp經(jīng)編譯后就變成了Servlet.（JSP的本質(zhì)就是Servlet，JVM只能識(shí)別java的類，不能識(shí)別JSP的代碼，Web容器將JSP的代碼編譯成JVM能夠識(shí)別的java類）

jsp更擅長(zhǎng)表現(xiàn)于頁(yè)面顯示，servlet更擅長(zhǎng)于邏輯控制。

Servlet中沒(méi)有內(nèi)置對(duì)象，Jsp中的內(nèi)置對(duì)象都是必須通過(guò)HttpServletRequest對(duì)象，HttpServletResponse對(duì)象以及HttpServlet對(duì)象得到。

Jsp是Servlet的一種簡(jiǎn)化，使用Jsp只需要完成程序員需要輸出到客戶端的內(nèi)容，Jsp中的Java腳本如何鑲嵌到一個(gè)類中，由Jsp容器完成。而Servlet則是個(gè)完整的Java類，這個(gè)類的Service方法用于生成對(duì)客戶端的響應(yīng)。

jsp 有哪些內(nèi)置對(duì)象？作用分別是什么？

JSP有9個(gè)內(nèi)置對(duì)象：

request：封裝客戶端的請(qǐng)求，其中包含來(lái)自GET或POST請(qǐng)求的參數(shù)；

response：封裝服務(wù)器對(duì)客戶端的響應(yīng)；

pageContext：通過(guò)該對(duì)象可以獲取其他對(duì)象；

session：封裝用戶會(huì)話的對(duì)象；

application：封裝服務(wù)器運(yùn)行環(huán)境的對(duì)象；

out：輸出服務(wù)器響應(yīng)的輸出流對(duì)象；

config：Web應(yīng)用的配置對(duì)象；

page：JSP頁(yè)面本身（相當(dāng)于Java程序中的this）；

exception：封裝頁(yè)面拋出異常的對(duì)象。

說(shuō)一下 jsp 的 4 種作用域？

JSP中的四種作用域包括page、request、session和application，具體來(lái)說(shuō)：

page代表與一個(gè)頁(yè)面相關(guān)的對(duì)象和屬性。

request代表與Web客戶機(jī)發(fā)出的一個(gè)請(qǐng)求相關(guān)的對(duì)象和屬性。一個(gè)請(qǐng)求可能跨越多個(gè)頁(yè)面，涉及多個(gè)Web組件；需要在頁(yè)面顯示的臨時(shí)數(shù)據(jù)可以置于此作用域。

session代表與某個(gè)用戶與服務(wù)器建立的一次會(huì)話相關(guān)的對(duì)象和屬性。跟某個(gè)用戶相關(guān)的數(shù)據(jù)應(yīng)該放在用戶自己的session中。

application代表與整個(gè)Web應(yīng)用程序相關(guān)的對(duì)象和屬性，它實(shí)質(zhì)上是跨越整個(gè)Web應(yīng)用程序，包括多個(gè)頁(yè)面、請(qǐng)求和會(huì)話的一個(gè)全局作用域。

session 和 cookie 有什么區(qū)別？

由于HTTP協(xié)議是無(wú)狀態(tài)的協(xié)議，所以服務(wù)端需要記錄用戶的狀態(tài)時(shí)，就需要用某種機(jī)制來(lái)識(shí)具體的用戶，這個(gè)機(jī)制就是Session.典型的場(chǎng)景比如購(gòu)物車，當(dāng)你點(diǎn)擊下單按鈕時(shí)，由于HTTP協(xié)議無(wú)狀態(tài)，所以并不知道是哪個(gè)用戶操作的，所以服務(wù)端要為特定的用戶創(chuàng)建了特定的Session，用用于標(biāo)識(shí)這個(gè)用戶，并且跟蹤用戶，這樣才知道購(gòu)物車?yán)锩嬗袔妆緯?shū)。

這個(gè)Session是保存在服務(wù)端的，有一個(gè)唯一標(biāo)識(shí)。在服務(wù)端保存Session的方法很多，內(nèi)存、數(shù)據(jù)庫(kù)、文件都有。

集群的時(shí)候也要考慮Session的轉(zhuǎn)移，在大型的網(wǎng)站，一般會(huì)有專門(mén)的Session服務(wù)器集群，用來(lái)保存用戶會(huì)話，這個(gè)時(shí)候 Session 信息都是放在內(nèi)存的，使用一些緩存服務(wù)比如Memcached之類的來(lái)放 Session。

思考一下服務(wù)端如何識(shí)別特定的客戶？

這個(gè)時(shí)候Cookie就登場(chǎng)了。每次HTTP請(qǐng)求的時(shí)候，客戶端都會(huì)發(fā)送相應(yīng)的Cookie信息到服務(wù)端。實(shí)際上大多數(shù)的應(yīng)用都是用 Cookie 來(lái)實(shí)現(xiàn)Session跟蹤的，第一次創(chuàng)建Session的時(shí)候，服務(wù)端會(huì)在HTTP協(xié)議中告訴客戶端，需要在 Cookie 里面記錄一個(gè)Session ID，以后每次請(qǐng)求把這個(gè)會(huì)話ID發(fā)送到服務(wù)器，我就知道你是誰(shuí)了。

有人問(wèn)，如果客戶端的瀏覽器禁用了 Cookie 怎么辦？

一般這種情況下，會(huì)使用一種叫做URL重寫(xiě)的技術(shù)來(lái)進(jìn)行會(huì)話跟蹤，即每次HTTP交互，URL后面都會(huì)被附加上一個(gè)諸如 sid=xxxxx 這樣的參數(shù)，服務(wù)端據(jù)此來(lái)識(shí)別用戶。

Cookie其實(shí)還可以用在一些方便用戶的場(chǎng)景下，設(shè)想你某次登陸過(guò)一個(gè)網(wǎng)站，下次登錄的時(shí)候不想再次輸入賬號(hào)了，怎么辦？

這個(gè)信息可以寫(xiě)到Cookie里面，訪問(wèn)網(wǎng)站的時(shí)候，網(wǎng)站頁(yè)面的腳本可以讀取這個(gè)信息，就自動(dòng)幫你把用戶名給填了，能夠方便一下用戶。這也是Cookie名稱的由來(lái)，給用戶的一點(diǎn)甜頭。

所以，總結(jié)一下：

Session是在服務(wù)端保存的一個(gè)數(shù)據(jù)結(jié)構(gòu)，用來(lái)跟蹤用戶的狀態(tài)，這個(gè)數(shù)據(jù)可以保存在集群、數(shù)據(jù)庫(kù)、文件中；

Cookie是客戶端保存用戶信息的一種機(jī)制，用來(lái)記錄用戶的一些信息，也是實(shí)現(xiàn)Session的一種方式。

說(shuō)一下 session 的工作原理？

其實(shí)session是一個(gè)存在服務(wù)器上的類似于一個(gè)散列表格的文件。里面存有我們需要的信息，在我們需要用的時(shí)候可以從里面取出來(lái)。

類似于一個(gè)大號(hào)的map吧，里面的鍵存儲(chǔ)的是用戶的sessionid，用戶向服務(wù)器發(fā)送請(qǐng)求的時(shí)候會(huì)帶上這個(gè)sessionid。這時(shí)就可以從中取出對(duì)應(yīng)的值了。

如果客戶端禁止 cookie 能實(shí)現(xiàn) session 還能用嗎？

Cookie與 Session，一般認(rèn)為是兩個(gè)獨(dú)立的東西，Session采用的是在服務(wù)器端保持狀態(tài)的方案，而Cookie采用的是在客戶端保持狀態(tài)的方案。

但為什么禁用Cookie就不能得到Session呢？

因?yàn)镾ession是用Session ID來(lái)確定當(dāng)前對(duì)話所對(duì)應(yīng)的服務(wù)器Session，而Session ID是通過(guò)Cookie來(lái)傳遞的，禁用Cookie相當(dāng)于失去了Session ID，也就得不到Session了。

假定用戶關(guān)閉Cookie的情況下使用Session，其實(shí)現(xiàn)途徑有以下幾種：

設(shè)置php.ini配置文件中的“session.use_trans_sid = 1”，或者編譯時(shí)打開(kāi)打開(kāi)了“--enable-trans-sid”選項(xiàng)，讓PHP自動(dòng)跨頁(yè)傳遞Session ID。

手動(dòng)通過(guò)URL傳值、隱藏表單傳遞Session ID。

用文件、數(shù)據(jù)庫(kù)等形式保存Session ID，在跨頁(yè)過(guò)程中手動(dòng)調(diào)用。

spring mvc 和 struts 的區(qū)別是什么？

攔截機(jī)制的不同

Struts2是類級(jí)別的攔截，每次請(qǐng)求就會(huì)創(chuàng)建一個(gè)Action，和Spring整合時(shí)Struts2的ActionBean注入作用域是原型模式prototype，然后通過(guò)setter，getter吧request數(shù)據(jù)注入到屬性。

Struts2中，一個(gè)Action對(duì)應(yīng)一個(gè)request，response上下文，在接收參數(shù)時(shí)，可以通過(guò)屬性接收，這說(shuō)明屬性參數(shù)是讓多個(gè)方法共享的。

Struts2中Action的一個(gè)方法可以對(duì)應(yīng)一個(gè)url，而其類屬性卻被所有方法共享，這也就無(wú)法用注解或其他方式標(biāo)識(shí)其所屬方法了，只能設(shè)計(jì)為多例。

SpringMVC是方法級(jí)別的攔截，一個(gè)方法對(duì)應(yīng)一個(gè)Request上下文，所以方法直接基本上是獨(dú)立的，獨(dú)享request，response數(shù)據(jù)。而每個(gè)方法同時(shí)又何一個(gè)url對(duì)應(yīng)，參數(shù)的傳遞是直接注入到方法中的，是方法所獨(dú)有的。處理結(jié)果通過(guò)ModeMap返回給框架。

在Spring整合時(shí)，SpringMVC的Controller Bean默認(rèn)單例模式Singleton，所以默認(rèn)對(duì)所有的請(qǐng)求，只會(huì)創(chuàng)建一個(gè)Controller，有應(yīng)為沒(méi)有共享的屬性，所以是線程安全的，如果要改變默認(rèn)的作用域，需要添加@Scope注解修改。

Struts2有自己的攔截Interceptor機(jī)制，SpringMVC這是用的是獨(dú)立的Aop方式，這樣導(dǎo)致Struts2的配置文件量還是比SpringMVC大。

底層框架的不同

Struts2采用Filter（StrutsPrepareAndExecuteFilter）實(shí)現(xiàn)，SpringMVC（DispatcherServlet）則采用Servlet實(shí)現(xiàn)。Filter在容器啟動(dòng)之后即初始化；服務(wù)停止以后墜毀，晚于Servlet。Servlet在是在調(diào)用時(shí)初始化，先于Filter調(diào)用，服務(wù)停止后銷毀。

性能方面

Struts2是類級(jí)別的攔截，每次請(qǐng)求對(duì)應(yīng)實(shí)例一個(gè)新的Action，需要加載所有的屬性值注入，SpringMVC實(shí)現(xiàn)了零配置，由于SpringMVC基于方法的攔截，有加載一次單例模式bean注入。所以，SpringMVC開(kāi)發(fā)效率和性能高于Struts2。

配置方面

spring MVC和Spring是無(wú)縫的。從這個(gè)項(xiàng)目的管理和安全上也比Struts2高。

如何避免 sql 注入？

PreparedStatement（簡(jiǎn)單又有效的方法）

使用正則表達(dá)式過(guò)濾傳入的參數(shù)

字符串過(guò)濾

JSP中調(diào)用該函數(shù)檢查是否包函非法字符

JSP頁(yè)面判斷代碼

什么是 XSS 攻擊，如何避免？

XSS攻擊又稱CSS,全稱Cross Site Script （跨站腳本攻擊），其原理是攻擊者向有XSS漏洞的網(wǎng)站中輸入惡意的 HTML 代碼，當(dāng)用戶瀏覽該網(wǎng)站時(shí)，這段 HTML 代碼會(huì)自動(dòng)執(zhí)行，從而達(dá)到攻擊的目的。

XSS 攻擊類似于 SQL 注入攻擊，SQL注入攻擊中以SQL語(yǔ)句作為用戶輸入，從而達(dá)到查詢/修改/刪除數(shù)據(jù)的目的，而在xss攻擊中，通過(guò)插入惡意腳本，實(shí)現(xiàn)對(duì)用戶游覽器的控制，獲取用戶的一些信息。 XSS是 Web 程序中常見(jiàn)的漏洞，XSS 屬于被動(dòng)式且用于客戶端的攻擊方式。

XSS防范的總體思路是：對(duì)輸入(和URL參數(shù))進(jìn)行過(guò)濾，對(duì)輸出進(jìn)行編碼。

什么是 CSRF 攻擊，如何避免？

CSRF（Cross-site request forgery）也被稱為 one-click attack或者 session riding，中文全稱是叫跨站請(qǐng)求偽造。一般來(lái)說(shuō)，攻擊者通過(guò)偽造用戶的瀏覽器的請(qǐng)求，向訪問(wèn)一個(gè)用戶自己曾經(jīng)認(rèn)證訪問(wèn)過(guò)的網(wǎng)站發(fā)送出去，使目標(biāo)網(wǎng)站接收并誤以為是用戶的真實(shí)操作而去執(zhí)行命令。

常用于盜取賬號(hào)、轉(zhuǎn)賬、發(fā)送虛假消息等。攻擊者利用網(wǎng)站對(duì)請(qǐng)求的驗(yàn)證漏洞而實(shí)現(xiàn)這樣的攻擊行為，網(wǎng)站能夠確認(rèn)請(qǐng)求來(lái)源于用戶的瀏覽器，卻不能驗(yàn)證請(qǐng)求是否源于用戶的真實(shí)意愿下的操作行為。

如何避免：

1. 驗(yàn)證 HTTP Referer 字段

HTTP頭中的Referer字段記錄了該 HTTP 請(qǐng)求的來(lái)源地址。在通常情況下，訪問(wèn)一個(gè)安全受限頁(yè)面的請(qǐng)求來(lái)自于同一個(gè)網(wǎng)站，而如果黑客要對(duì)其實(shí)施 CSRF

攻擊，他一般只能在他自己的網(wǎng)站構(gòu)造請(qǐng)求。因此，可以通過(guò)驗(yàn)證Referer值來(lái)防御CSRF 攻擊。

2. 使用驗(yàn)證碼

關(guān)鍵操作頁(yè)面加上驗(yàn)證碼，后臺(tái)收到請(qǐng)求后通過(guò)判斷驗(yàn)證碼可以防御CSRF。但這種方法對(duì)用戶不太友好。

3. 在請(qǐng)求地址中添加token并驗(yàn)證

CSRF 攻擊之所以能夠成功，是因?yàn)楹诳涂梢酝耆珎卧煊脩舻恼?qǐng)求，該請(qǐng)求中所有的用戶驗(yàn)證信息都是存在于cookie中，因此黑客可以在不知道這些驗(yàn)證信息的情況下直接利用用戶自己的cookie 來(lái)通過(guò)安全驗(yàn)證。要抵御 CSRF，關(guān)鍵在于在請(qǐng)求中放入黑客所不能偽造的信息，并且該信息不存在于 cookie 之中。

可以在 HTTP 請(qǐng)求中以參數(shù)的形式加入一個(gè)隨機(jī)產(chǎn)生的 token，并在服務(wù)器端建立一個(gè)攔截器來(lái)驗(yàn)證這個(gè) token，如果請(qǐng)求中沒(méi)有token或者 token 內(nèi)容不正確，則認(rèn)為可能是 CSRF 攻擊而拒絕該請(qǐng)求。

這種方法要比檢查 Referer 要安全一些，token 可以在用戶登陸后產(chǎn)生并放于session之中，然后在每次請(qǐng)求時(shí)把token 從 session 中拿出，與請(qǐng)求中的 token 進(jìn)行比對(duì)，但這種方法的難點(diǎn)在于如何把 token 以參數(shù)的形式加入請(qǐng)求。

對(duì)于 GET 請(qǐng)求，token 將附在請(qǐng)求地址之后，這樣 URL 就變成 http://url?csrftoken=tokenvalue。

而對(duì)于 POST 請(qǐng)求來(lái)說(shuō)，要在 form 的最后加上 <input type='hidden' name='csrftoken' value='tokenvalue'/>，這樣就把token以參數(shù)的形式加入請(qǐng)求了。

4. 在HTTP 頭中自定義屬性并驗(yàn)證

這種方法也是使用 token 并進(jìn)行驗(yàn)證，和上一種方法不同的是，這里并不是把 token 以參數(shù)的形式置于 HTTP 請(qǐng)求之中，而是把它放到 HTTP 頭中自定義的屬性里。

通過(guò) XMLHttpRequest 這個(gè)類，可以一次性給所有該類請(qǐng)求加上 csrftoken 這個(gè) HTTP 頭屬性，并把 token 值放入其中。

這樣解決了上種方法在請(qǐng)求中加入 token 的不便，同時(shí)，通過(guò) XMLHttpRequest 請(qǐng)求的地址不會(huì)被記錄到瀏覽器的地址欄，也不用擔(dān)心 token 會(huì)透過(guò) Referer 泄露到其他網(wǎng)站中去。

以上就是Java Web最近面試題匯總的詳細(xì)內(nèi)容，更多關(guān)于Java Web常見(jiàn)面試題的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！