168、什么是XSS攻擊？什么是SQL注入攻擊？什么是CSRF攻擊？

答：

- XSS（Cross Site Script，跨站腳本攻擊）是向網(wǎng)頁中注入惡意腳本在用戶瀏覽網(wǎng)頁時(shí)在用戶瀏覽器中執(zhí)行惡意腳本的攻擊方式?？缯灸_本攻擊分有兩種形式：反射型攻擊（誘使用戶點(diǎn)擊一個(gè)嵌入惡意腳本的鏈接以達(dá)到攻擊的目標(biāo)，目前有很多攻擊者利用論壇、微博發(fā)布含有惡意腳本的URL就屬于這種方式）和持久型攻擊（將惡意腳本提交到被攻擊網(wǎng)站的數(shù)據(jù)庫中，用戶瀏覽網(wǎng)頁時(shí)，惡意腳本從數(shù)據(jù)庫中被加載到頁面執(zhí)行，QQ郵箱的早期版本就曾經(jīng)被利用作為持久型跨站腳本攻擊的平臺(tái)）。XSS雖然不是什么新鮮玩意，但是攻擊的手法卻不斷翻新，防范XSS主要有兩方面：消毒（對(duì)危險(xiǎn)字符進(jìn)行轉(zhuǎn)義）和HttpOnly（防范XSS攻擊者竊取Cookie數(shù)據(jù)）。

- SQL注入攻擊是注入攻擊最常見的形式（此外還有OS注入攻擊（Struts 2的高危漏洞就是通過OGNL實(shí)施OS注入攻擊導(dǎo)致的）），當(dāng)服務(wù)器使用請(qǐng)求參數(shù)構(gòu)造SQL語句時(shí)，惡意的SQL被嵌入到SQL中交給數(shù)據(jù)庫執(zhí)行。SQL注入攻擊需要攻擊者對(duì)數(shù)據(jù)庫結(jié)構(gòu)有所了解才能進(jìn)行，攻擊者想要獲得表結(jié)構(gòu)有多種方式：（1）如果使用開源系統(tǒng)搭建網(wǎng)站，數(shù)據(jù)庫結(jié)構(gòu)也是公開的（目前有很多現(xiàn)成的系統(tǒng)可以直接搭建論壇，電商網(wǎng)站，雖然方便快捷但是風(fēng)險(xiǎn)是必須要認(rèn)真評(píng)估的）；（2）錯(cuò)誤回顯（如果將服務(wù)器的錯(cuò)誤信息直接顯示在頁面上，攻擊者可以通過非法參數(shù)引發(fā)頁面錯(cuò)誤從而通過錯(cuò)誤信息了解數(shù)據(jù)庫結(jié)構(gòu)，Web應(yīng)用應(yīng)當(dāng)設(shè)置友好的錯(cuò)誤頁，一方面符合最小驚訝原則，一方面屏蔽掉可能給系統(tǒng)帶來危險(xiǎn)的錯(cuò)誤回顯信息）；（3）盲注。防范SQL注入攻擊也可以采用消毒的方式，通過正則表達(dá)式對(duì)請(qǐng)求參數(shù)進(jìn)行驗(yàn)證，此外，參數(shù)綁定也是很好的手段，這樣惡意的SQL會(huì)被當(dāng)做SQL的參數(shù)而不是命令被執(zhí)行，JDBC中的PreparedStatement就是支持參數(shù)綁定的語句對(duì)象，從性能和安全性上都明顯優(yōu)于Statement。

- CSRF攻擊（Cross Site Request Forgery，跨站請(qǐng)求偽造）是攻擊者通過跨站請(qǐng)求，以合法的用戶身份進(jìn)行非法操作（如轉(zhuǎn)賬或發(fā)帖等）。CSRF的原理是利用瀏覽器的Cookie或服務(wù)器的Session，盜取用戶身份，其原理如下圖所示。防范CSRF的主要手段是識(shí)別請(qǐng)求者的身份，主要有以下幾種方式：（1）在表單中添加令牌（token）；（2）驗(yàn)證碼；（3）檢查請(qǐng)求頭中的Referer（前面提到防圖片盜鏈接也是用的這種方式）。令牌和驗(yàn)證都具有一次消費(fèi)性的特征，因此在原理上一致的，但是驗(yàn)證碼是一種糟糕的用戶體驗(yàn)，不是必要的情況下不要輕易使用驗(yàn)證碼，目前很多網(wǎng)站的做法是如果在短時(shí)間內(nèi)多次提交一個(gè)表單未獲得成功后才要求提供驗(yàn)證碼，這樣會(huì)獲得較好的用戶體驗(yàn)。

補(bǔ)充：防火墻的架設(shè)是Web安全的重要保障，ModSecurity是開源的Web防火墻中的佼佼者。企業(yè)級(jí)防火墻的架設(shè)應(yīng)當(dāng)有兩級(jí)防火墻，Web服務(wù)器和部分應(yīng)用服務(wù)器可以架設(shè)在兩級(jí)防火墻之間的DMZ，而數(shù)據(jù)和資源服務(wù)器應(yīng)當(dāng)架設(shè)在第二級(jí)防火墻之后。

169. 什么是領(lǐng)域模型(domain model)？貧血模型(anaemic domain model)和充血模型(rich domain model)有什么區(qū)別？

答：領(lǐng)域模型是領(lǐng)域內(nèi)的概念類或現(xiàn)實(shí)世界中對(duì)象的可視化表示，又稱為概念模型或分析對(duì)象模型，它專注于分析問題領(lǐng)域本身，發(fā)掘重要的業(yè)務(wù)領(lǐng)域概念，并建立業(yè)務(wù)領(lǐng)域概念之間的關(guān)系。貧血模型是指使用的領(lǐng)域?qū)ο笾兄挥衧etter和getter方法（POJO），所有的業(yè)務(wù)邏輯都不包含在領(lǐng)域?qū)ο笾卸欠旁跇I(yè)務(wù)邏輯層。有人將我們這里說的貧血模型進(jìn)一步劃分成失血模型（領(lǐng)域?qū)ο笸耆珱]有業(yè)務(wù)邏輯）和貧血模型（領(lǐng)域?qū)ο笥猩倭康臉I(yè)務(wù)邏輯），我們這里就不對(duì)此加以區(qū)分了。充血模型將大多數(shù)業(yè)務(wù)邏輯和持久化放在領(lǐng)域?qū)ο笾?，業(yè)務(wù)邏輯（業(yè)務(wù)門面）只是完成對(duì)業(yè)務(wù)邏輯的封裝、事務(wù)和權(quán)限等的處理。下面兩張圖分別展示了貧血模型和充血模型的分層架構(gòu)。

貧血模型

充血模型

貧血模型下組織領(lǐng)域邏輯通常使用事務(wù)腳本模式，讓每個(gè)過程對(duì)應(yīng)用戶可能要做的一個(gè)動(dòng)作，每個(gè)動(dòng)作由一個(gè)過程來驅(qū)動(dòng)。也就是說在設(shè)計(jì)業(yè)務(wù)邏輯接口的時(shí)候，每個(gè)方法對(duì)應(yīng)著用戶的一個(gè)操作，這種模式有以下幾個(gè)有點(diǎn)：

- 它是一個(gè)大多數(shù)開發(fā)者都能夠理解的簡單過程模型（適合國內(nèi)的絕大多數(shù)開發(fā)者）。

- 它能夠與一個(gè)使用行數(shù)據(jù)入口或表數(shù)據(jù)入口的簡單數(shù)據(jù)訪問層很好的協(xié)作。

- 事務(wù)邊界的顯而易見，一個(gè)事務(wù)開始于腳本的開始，終止于腳本的結(jié)束，很容易通過代理（或切面）實(shí)現(xiàn)聲明式事務(wù)。

然而，事務(wù)腳本模式的缺點(diǎn)也是很多的，隨著領(lǐng)域邏輯復(fù)雜性的增加，系統(tǒng)的復(fù)雜性將迅速增加，程序結(jié)構(gòu)將變得極度混亂。開源中國社區(qū)上有一篇很好的譯文《貧血領(lǐng)域模型是如何導(dǎo)致糟糕的軟件產(chǎn)生》對(duì)這個(gè)問題做了比較細(xì)致的闡述。

170. 談一談測(cè)試驅(qū)動(dòng)開發(fā)（TDD）的好處以及你的理解。

答：TDD是指在編寫真正的功能實(shí)現(xiàn)代碼之前先寫測(cè)試代碼，然后根據(jù)需要重構(gòu)實(shí)現(xiàn)代碼。在JUnit的作者Kent Beck的大作《測(cè)試驅(qū)動(dòng)開發(fā)：實(shí)戰(zhàn)與模式解析》（Test-Driven Development: by Example）一書中有這么一段內(nèi)容：“消除恐懼和不確定性是編寫測(cè)試驅(qū)動(dòng)代碼的重要原因”。因?yàn)榫帉懘a時(shí)的恐懼會(huì)讓你小心試探，讓你回避溝通，讓你羞于得到反饋，讓你變得焦躁不安，而TDD是消除恐懼、讓Java開發(fā)者更加自信更加樂于溝通的重要手段。TDD會(huì)帶來的好處可能不會(huì)馬上呈現(xiàn)，但是你在某個(gè)時(shí)候一定會(huì)發(fā)現(xiàn)，這些好處包括：

- 更清晰的代碼 — 只寫需要的代碼

- 更好的設(shè)計(jì)

- 更出色的靈活性 — 鼓勵(lì)程序員面向接口編程

- 更快速的反饋 — 不會(huì)到系統(tǒng)上線時(shí)才知道bug的存在

補(bǔ)充：敏捷軟件開發(fā)的概念已經(jīng)有很多年了，而且也部分的改變了軟件開發(fā)這個(gè)行業(yè)，TDD也是敏捷開發(fā)所倡導(dǎo)的。

TDD可以在多個(gè)層級(jí)上應(yīng)用，包括單元測(cè)試（測(cè)試一個(gè)類中的代碼）、集成測(cè)試（測(cè)試類之間的交互）、系統(tǒng)測(cè)試（測(cè)試運(yùn)行的系統(tǒng)）和系統(tǒng)集成測(cè)試（測(cè)試運(yùn)行的系統(tǒng)包括使用的第三方組件）。TDD的實(shí)施步驟是：紅（失敗測(cè)試）- 綠（通過測(cè)試） – 重構(gòu)。關(guān)于實(shí)施TDD的詳細(xì)步驟請(qǐng)參考另一篇文章《測(cè)試驅(qū)動(dòng)開發(fā)之初窺門徑》。

在使用TDD開發(fā)時(shí)，經(jīng)常會(huì)遇到需要被測(cè)對(duì)象需要依賴其他子系統(tǒng)的情況，但是你希望將測(cè)試代碼跟依賴項(xiàng)隔離，以保證測(cè)試代碼僅僅針對(duì)當(dāng)前被測(cè)對(duì)象或方法展開，這時(shí)候你需要的是測(cè)試替身。測(cè)試替身可以分為四類：

- 虛設(shè)替身：只傳遞但是不會(huì)使用到的對(duì)象，一般用于填充方法的參數(shù)列表

- 存根替身：總是返回相同的預(yù)設(shè)響應(yīng)，其中可能包括一些虛設(shè)狀態(tài)

- 偽裝替身：可以取代真實(shí)版本的可用版本（比真實(shí)版本還是會(huì)差很多）

- 模擬替身：可以表示一系列期望值的對(duì)象，并且可以提供預(yù)設(shè)響應(yīng)

Java世界中實(shí)現(xiàn)模擬替身的第三方工具非常多，包括EasyMock、Mockito、jMock等

http://bbs.itheima.com/forum.php?mod=viewthread&tid=383781