Web項(xiàng)目比較常見的安全問題和解決方法

Web項(xiàng)目比較常見的安全問題

1.XSS(CrossSite Script)跨站腳本
XSS(CrossSite Script)跨站腳本。它指的是惡意往Web 頁面里插入惡意html代碼，當(dāng)用戶瀏覽該頁之時(shí)，嵌入其中Web 里面的html 代碼會(huì)被執(zhí)行，從而達(dá)到惡意用戶的特殊目的。

測試方法：在數(shù)據(jù)輸入界面，添加記錄輸入：，添加成功如果彈出對(duì)話框，表明此處存在一個(gè)XSS 漏洞。或把url請(qǐng)求中參數(shù)改為，如果頁面彈出對(duì)話框，表明此處存在一個(gè)XSS 漏洞

修改建議：過濾掉用戶輸入中的危險(xiǎn)字符。對(duì)輸入數(shù)據(jù)進(jìn)行客戶端和程序級(jí)的校驗(yàn)（如通過正則表達(dá)式等）。Eg:對(duì)用戶輸入的地方和變量有沒有做長度和對(duì)”<”,”>”,”;”,”’”等字符是否做過濾

2.CSRF與跨站腳本(XSS)
CSRF與跨站腳本(XSS)，是指請(qǐng)求迫使某個(gè)登錄的瀏覽器向易受的Web應(yīng)用發(fā)送一個(gè)請(qǐng)求，然后以受害者的名義，為者的利益進(jìn)行所選擇的行動(dòng)。

測試方法：同個(gè)瀏覽器打開兩個(gè)頁面，一個(gè)頁面權(quán)限失效后，另一個(gè)頁面是否可操作成功，使用工具發(fā)送請(qǐng)求，在http請(qǐng)求頭中不加入referer字段，檢驗(yàn)返回消息的應(yīng)答，應(yīng)該重新定位到錯(cuò)誤界面或者登陸界面。

修改建議：在不同的會(huì)話中兩次發(fā)送同一請(qǐng)求并且收到相同的響應(yīng)。這顯示沒有任何參數(shù)是動(dòng)態(tài)的（會(huì)話標(biāo)識(shí)僅在cookie 中發(fā)送），因此應(yīng)用程序易受到此問題。因此解決的方法為：

（1） Cookie Hashing(所有表單都包含同一個(gè)偽隨機(jī)值)：

（2） 驗(yàn)證碼

（3） One‐Time Tokens(不同的表單包含一個(gè)不同的偽隨機(jī)值)客戶端保護(hù)措施，應(yīng)用防止CSRF的工具或插件。

3.注入測試
SQL注入是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請(qǐng)求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。

測試方法：在需要進(jìn)行查詢的頁面，輸入正確查詢條件 and 1=1等簡單sql語句，查看應(yīng)答結(jié)果，如與輸入正確查詢條件返回結(jié)果一致，表明應(yīng)用程序?qū)τ脩糨斎胛催M(jìn)行過濾，可以初步判斷此處存在SQL注入漏洞

修改建議：對(duì)用戶的輸入進(jìn)行校驗(yàn)，可以通過正則表達(dá)式，或限制長度；對(duì)以下關(guān)鍵字進(jìn)行轉(zhuǎn)換等;

|alert|and|exec|execute|insert|select|delete|update|count|drop|chr|mid|master|truncate|declare|sitename|netuser|xp_cmdshell|or|+|,|like’|and|exec|execute|insert|create|drop|table|from|grant|group_concat|column_name|information_schema.columns|table_schema|union|where|select|delete|update|order|by|count|chr|mid|master|truncate|declare|or|–|+|,|like|//

不要使用動(dòng)態(tài)拼裝sql，可以使用參數(shù)化的sql或者直接使用存儲(chǔ)過程進(jìn)行數(shù)據(jù)查詢存取;

不要使用管理員權(quán)限的數(shù)據(jù)庫連接，為每個(gè)應(yīng)用使用單獨(dú)的權(quán)限有限的數(shù)據(jù)庫連接;

應(yīng)用的異常信息應(yīng)該給出盡可能少的提示，最好使用自定義的錯(cuò)誤信息對(duì)原始錯(cuò)誤信息進(jìn)行包裝。

4.登錄認(rèn)證測試
4.1暴力破解
暴力破解是目前最直接有效的方式，特別對(duì)于金融業(yè)務(wù)來說，很多情況下口令都為6位純數(shù)字，很容易被。本測試項(xiàng)在于檢查認(rèn)證系統(tǒng)對(duì)破解的防護(hù)性。

測試方法：
啟動(dòng)抓包工具，同時(shí)打開瀏覽器輸入用戶登錄頁面，輸入用戶名、密碼以及驗(yàn)證碼，進(jìn)行登錄，如果在抓包中存在明文的用戶名和密碼，說明存在弱點(diǎn)。

修改建議：將請(qǐng)求方式從HTTP方式修改為HTTPS方式或者對(duì)輸入的用戶名和密碼進(jìn)行加密，在服務(wù)端對(duì)密碼進(jìn)行驗(yàn)證

4.2代碼注釋
開發(fā)版本的Web程序所帶有的注釋在發(fā)布版本中沒有被去掉，而導(dǎo)致一些敏感信息的泄漏。我們要查看客戶端能看到的頁面源代碼并發(fā)現(xiàn)此類安全隱患。

測試方法：打開登陸頁面(或者待測試頁面)，點(diǎn)擊瀏覽器郵件，查看源代碼，檢查源代碼注釋部分是否有敏感信息泄露，敏感信息包括以下內(nèi)容：字段文字描述、內(nèi)網(wǎng) IP 地址、SQL 語句以及物理路徑等等。

修改建議：請(qǐng)勿在HTML 注釋中遺留任何重要信息（如文件名或文件路徑）。

從生產(chǎn)站點(diǎn)注釋中除去以前（或未來）站點(diǎn)鏈接的跟蹤信息。避免在HTML 注釋中放置敏感信息。確保HTML 注釋不包括源代碼片段。

4.3 用戶名破解

為了進(jìn)行暴力破解，者需要知道已存在的用戶名，再對(duì)該用戶名進(jìn)行。

測試方法：在登錄界面輸入不存在的用戶名和任意的口令，如果提示用戶名不存在，則說明存在漏洞；使用正確的用戶名和錯(cuò)誤的口令進(jìn)行登錄，如果提示口令或密碼錯(cuò)誤，則說明存在漏洞。

修改建議：服務(wù)器對(duì)所有的登陸錯(cuò)誤原因進(jìn)行統(tǒng)一的應(yīng)答，不會(huì)提示準(zhǔn)確的錯(cuò)誤提示信息。

4.4默認(rèn)賬戶名稱設(shè)置
一般系統(tǒng)均設(shè)有默認(rèn)登錄用戶，以及超級(jí)管理員賬號(hào)，如登錄賬號(hào)過于簡單將易被破解，造成超級(jí)權(quán)限泄露。

修改建議：上線系統(tǒng)清除超級(jí)管理員權(quán)限用戶，或增加超級(jí)管理員登錄名復(fù)雜度，不要設(shè)置成易猜測的admin、superadmin等名稱。

4.5 錯(cuò)誤的頁面信息
404、500等錯(cuò)誤或警告消息，可能會(huì)泄露敏感信息。

修改建議：捕獲異常跳轉(zhuǎn)至統(tǒng)一錯(cuò)誤頁面，避免對(duì)外泄漏詳細(xì)錯(cuò)誤信息。

5.會(huì)話管理測試未更新

5.1會(huì)話標(biāo)識(shí)測試

查看登錄成功后會(huì)話標(biāo)識(shí)是否變更。如果未變更，那么者就可以通過一些手段（如構(gòu)造URL）為受害著確定一個(gè)會(huì)話標(biāo)識(shí)，當(dāng)受害者登錄成功后，者也可以利用這個(gè)會(huì)話標(biāo)識(shí)冒充受害者訪問系統(tǒng)。

測試方法：啟動(dòng)抓包工具或?yàn)g覽器自帶開發(fā)者模式打開登錄頁面，輸入正確的用戶名、口令以及驗(yàn)證碼，進(jìn)行登錄，登錄后，進(jìn)行任意一項(xiàng)業(yè)務(wù)操作。如果登錄的SessionId和進(jìn)行業(yè)務(wù)的SessionId沒有變化，則說明存在漏洞。

修改建議：對(duì)每次請(qǐng)求都從上次請(qǐng)求獲得令牌，服務(wù)端對(duì)每次交互都進(jìn)行驗(yàn)證

查看是否存在瀏覽器窗口閑置超時(shí)后需重新登錄的機(jī)制

5.2會(huì)話清除測試
用戶注銷后會(huì)話信息需要清除，否則會(huì)導(dǎo)致用戶在點(diǎn)擊注銷按鈕之后還能繼續(xù)訪問注銷之前才能訪問的頁面。

測試方法：進(jìn)入登錄頁面，輸入正確的用戶名和密碼，登錄成功后，進(jìn)行一些業(yè)務(wù)操作，點(diǎn)擊注銷按鈕，在瀏覽器輸入地址，輸入上面進(jìn)行業(yè)務(wù)操作的地址，如果能夠正常返回業(yè)務(wù)頁面，則說明存在漏洞。

修改建議：在用戶注銷后，必須將用戶的Session信息以及緩存信息全部清空。