Web攻擊動(dòng)機(jī)：

• 惡作劇；
• 關(guān)閉Web站點(diǎn)，拒絕正常服務(wù)；
• 篡改Web網(wǎng)頁，損害企業(yè)名譽(yù)；
• 免費(fèi)瀏覽收費(fèi)內(nèi)容；
• 盜竊用戶隱私信息，例如Email；
• 以用戶身份登錄執(zhí)行非法操作，從而獲取暴利；
• 以此為跳板攻擊企業(yè)內(nèi)網(wǎng)其他系統(tǒng)；
• 網(wǎng)頁掛木馬，攻擊訪問網(wǎng)頁的特定用戶群；
• 仿冒系統(tǒng)發(fā)布方，誘騙用戶執(zhí)行危險(xiǎn)操作，例如用木馬替換正常下載文件，要求用戶匯款等

1.SQL注入(SQL Injection)

定義

由于程序中對(duì)用戶輸入檢查不嚴(yán)格，用戶可以提交一段數(shù)據(jù)庫查詢代碼，根據(jù)程序返回的結(jié)果，獲得某些他想得知的數(shù)據(jù)，這就是所謂的SQL Injection，即SQL注入。

原因分析

其本質(zhì)是對(duì)于輸入檢查不充分，導(dǎo)致SQL語句將用戶提交的非法數(shù)據(jù)當(dāng)作語句的一部分來執(zhí)行。
由于我們的部分WEB應(yīng)用，采用Jsp+JavaBean或SSH框架，代碼中會(huì)有直接寫SQL（或HQL）語句，而有些SQL是用拼串實(shí)現(xiàn)的。

風(fēng)險(xiǎn)

SQL盲注：如果系統(tǒng)屏蔽了詳細(xì)的錯(cuò)誤信息，那么對(duì)攻擊者而言就是盲注入，可能會(huì)查看、修改或刪除數(shù)據(jù)庫條目和表
使用SQL注入的認(rèn)證旁路：可能會(huì)繞開 Web 應(yīng)用程序的認(rèn)證機(jī)制

例子：

預(yù)防措施

• 嚴(yán)格限定參數(shù)類型，明確參數(shù)檢驗(yàn)的邊界，必須在服務(wù)端執(zhí)行數(shù)據(jù)驗(yàn)證
• 采用參數(shù)化查詢的方法（推薦）
• 內(nèi)置過濾系統(tǒng)（本質(zhì)是黑名單，很常見但是不推薦）
• 數(shù)據(jù)庫加固

2.跨站腳本漏洞(XSS)

定義

它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當(dāng)用戶瀏覽該頁之時(shí)，嵌入其中Web里面的html代碼會(huì)被執(zhí)行，從而達(dá)到惡意用戶的特殊目的。XSS屬于被動(dòng)式的攻擊，因?yàn)槠浔粍?dòng)且不好利用，所以許多人常忽略其危害性。

分類

持久型XSS（Persistent），與非持久型XSS相反，它是指通過提交惡意數(shù)據(jù)到服務(wù)器，通過Web應(yīng)用程序輸出惡意數(shù)據(jù)輸出到頁面，持久型XSS多出現(xiàn)在Web郵箱、BBS、社區(qū)等從數(shù)據(jù)庫讀出數(shù)據(jù)的正常頁面（比如BBS的某篇帖子中可能就含有惡意代碼）
非持久型XSS（Non-persistent），即反射型,它是指那些瀏覽器每次都要在參數(shù)中提交惡意數(shù)據(jù)才能觸發(fā)的跨站腳本漏洞。

例子：

預(yù)防措施

一.過濾：

• 有時(shí)候過濾會(huì)導(dǎo)致意外的結(jié)果，例如alice’s 變成了alices。
• 有時(shí)候需要多次過濾，例如<scrip<script>t>過濾掉<script>后還是<script>。
• 需要注意多個(gè)過濾器的先后次序。當(dāng)多個(gè)過濾器一起生效時(shí)，有可能后進(jìn)行的過濾導(dǎo)致前面的過濾失效。例如過濾器1要過濾ABC，過濾器2要過濾DEF，那么ABDEFC在依次通過1，2過濾器后變成了ABC，這樣相當(dāng)于繞開過濾器1。

二.輸入編碼：

• 輸入編碼往往可以有全局的解決方案，從設(shè)計(jì)的角度來看，這是最佳的。
• 一旦數(shù)據(jù)已經(jīng)入庫，就難以用輸出編碼處理。

三.輸出編碼：

• 輸出編碼有助于開發(fā)者細(xì)粒度控制輸出，但也導(dǎo)致了工作量的增加。
• 輸出編碼可以解決輸入編碼無法處理的已入庫數(shù)據(jù)。

四.用戶安全加固：

• 小心點(diǎn)擊來源不明的URL。
• 對(duì)瀏覽器進(jìn)行安全加固，例如禁止ActiveX。
• 永遠(yuǎn)不要點(diǎn)擊自動(dòng)登錄信息！

3.跨站請(qǐng)求偽造（XSRF ）

風(fēng)險(xiǎn)

可能會(huì)竊取或操縱客戶會(huì)話和 cookie，它們可能用于模仿合法用戶，從而使黑客能夠以該用戶身份查看或變更用戶記錄以及執(zhí)行事務(wù)

原因分析

應(yīng)用程序使用的認(rèn)證方法不充分

典型攻擊方式

• 在頁面中加入一個(gè)<img>標(biāo)簽，瀏覽器就會(huì)發(fā)送一個(gè)請(qǐng)求，以獲取其src屬性引用的值。
• 攻擊者將敏感操作的URI作為src
• 繼承Cookie，以瀏覽者的身份作敏感訪問并操作
• 危害：在用戶無意識(shí)情況下進(jìn)行危險(xiǎn)操作

預(yù)防措施

檢查 HTTP 頭部 Refer 信息
Server端在收到請(qǐng)求之后，可以去檢查這個(gè)頭信息，只接受來自本域的請(qǐng)求而忽略外部域的請(qǐng)求
使用一次性令牌
每個(gè)請(qǐng)求都帶上一個(gè)由服務(wù)器生成的隨機(jī)參數(shù)。然后在服務(wù)器端核對(duì)該參數(shù)，如果和下發(fā)的隨機(jī)數(shù)不同，則可以認(rèn)為有人在偽造請(qǐng)求。因?yàn)楣粽邿o法知道他本次攻擊的http請(qǐng)求需要帶什么樣的隨機(jī)數(shù)才是有效的。
使用驗(yàn)證圖片
圖片驗(yàn)證信息很難被惡意程序在客戶端識(shí)別，因此能夠提高更強(qiáng)的保護(hù)
判斷HTTP請(qǐng)求類型
采用request.getMethod()判斷請(qǐng)求的方式是否POST
直接獲取數(shù)據(jù)
對(duì)request再次封裝,直接獲取form的數(shù)據(jù)不接收URL的 ，request.getForm(“user”)

4.文件上傳漏洞

常見的驗(yàn)證錯(cuò)誤

• 允許上傳可執(zhí)行文件
• 使用客戶端JS驗(yàn)證上傳文件類型
• 使用黑名單限制上傳文件類型
• 文件名/存儲(chǔ)目錄名可自定義
• 文件名中特殊字符處理不當(dāng)

預(yù)防措施

• 首先編碼者需要對(duì)上傳頁面代碼嚴(yán)格把關(guān)，特別是在保存文件的時(shí)候，考察可能出現(xiàn)的異常字符，如../，..\，空字符等。
• 其次，對(duì)文件擴(kuò)展名檢查要采取“允許jpg,gif…”這樣的檢查，而不要采取“不允許asp…”這樣的檢查；
• 最好對(duì)上傳文件的目錄設(shè)置不可執(zhí)行，這可以通過web服務(wù)器配置加固實(shí)現(xiàn)。