web安全（8）-- 程式缺陷
1.1 漏洞描述
● 軟體缺陷（Defect），常常又被叫做Bug。所謂軟體缺陷，即為計算機軟體或程式中存在的某種破壞正常執行能力的問題、錯誤，或者隱藏的功能缺陷。缺陷的存在會導致軟體產品在某種程度上不能滿足使用者的需要。IEEE729-1983對缺陷有一個標準的定義：從產品內部看，缺陷是軟體產品開發或維護過程中存在的錯誤、毛病等各種問題；從產品外部看，缺陷是系統所需要實現的某種功能的失效或違背。在軟體開發生命週期的後期，修復檢測到的軟體錯誤的成本較高。
1.2 漏洞危害
● 程式缺陷的危害可大可小，大的缺陷可能導致系統癱瘓，小的缺陷的可能就是導致操作不方便而已。
● 根據程式缺陷的大小可以將程式缺陷分成以下幾個錯誤嚴重程度：
1.Critical：不能執行正常工作功能或重要功能。或者危及人身安全。
2.Major：嚴重地影響系統要求或基本功能的實現，且沒有辦法更正。（重新安裝或重新啟動該軟體不屬於更正辦法）
3.Minor：嚴重地影響系統要求或基本功能的實現，但存在合理的更正辦法。（重新安裝或重新啟動該軟體不屬於更正辦法）
4.Cosmetic：使操作者不方便或遇到麻煩，但它不影響執行工作功能或重要功能。
5.Other：其它錯誤。
● 同時，根據程式缺陷的嚴重程度，我們給出幾種處理優先順序：
1.Resolve Immediately：缺陷必須被立即解決。
2.Normal Queue：缺陷需要正常排隊等待修復或列入軟體釋出清單。
3.Not Urgent：缺陷可以在方便時被糾正。
1.3 漏洞演示
● 常見問題一：
● 統一性
不要在軟體中使用中英文混合的提示，比如對於使用者的操作提示，不要一會用“error”一會用“錯誤”；一會用“succeed”另一會用“成功”總之要統一。某局長使用心得：刪除的時候提示Error，幸虧我英語水平好，可是你換成中文不行嗎？
比如在我們開發過的系統出現過：
1：operation is succeed，具體看一下我們公司jira中哪個系統出現的問題。
2：另外，專案初期階段，日期控制元件有的採用中文，有的採用英文形式。
● 常見問題二：
● 容錯性
對於儲存提交的資料輸入資訊，在輸入長度方面要麼就限制使用者的輸入，要麼就在客戶端給出使用者的醒目的提示、判斷。不要出現系統崩潰，儲存緩慢系統等無法響應等現象。
做好容錯處理，異常要及時捕獲，別輸出到日誌檔案中，不要將異常丟擲到前臺介面，這樣也會造成資訊洩露的漏洞。
● 常見問題三：
● 互動性
在要求使用者大量輸入資訊後，點選“儲存”或者“提交”按鈕，僅僅是因為使用者的某個地方輸入或者選中不正確，點選“確定”後發現所有輸入的內容全部都被清空了，花費很長時間的輸入，僅僅是因為某個地方的輸入不正確，而把該使用者的所有其他的輸入地方的輸入都清空了，假如你是這個軟體的使用者，你肯定會感覺到很惱火的。（儲存不成功也可以理解，但是不能把使用者所有的輸入資訊全部清空吧，就算你清空你也至少告訴使用者是什麼輸入錯誤，讓使用者知道怎麼重新輸入，才能儲存成功）。
另外，在需要使用者輸入資訊的時候，特別是填寫個人資訊的資料的時候，必填項後面，一律要用*等醒目的提示。讓使用者知道這個地方是必填寫的。
還有，下拉框不選值的時候，應該有個預設值，並且要多檢查程式中多處下拉框，因為很多情況下下拉框取不到值。我們的有些系統，有些地方，現在的下拉框取不到任何值。
● 常見問題四：
● 使用者體驗
頁面上的提示資訊要讓使用者明白，比如不要對使用者使用“記錄”、“欄位”、“ID”等一些很專業的術語。
舉例：比如電商專案中，使用者下單失敗，你給使用者一個提示，要求使用者根據訂單號去進行對應的重新下單操作。訂單號是開發人員為方便資料庫操作設定的一個唯一鍵約束，是給開發人員用的，那麼長一串數字，你要求使用者記住，這是多不合理的體驗。
另外，對於編輯功能，點選“編輯”後，所有的值都要預設保持編輯前的初始值。比如某員工的籍貫是“上海市”，點選“編輯”按鈕後，在籍貫這個地方預設的仍然是“上海市”。
其他欄位資訊也是如此。
● 常見問題五：
● 相容性
現在遇到的情況是程式人員的瀏覽器的版本都比較高（比如IE10，IE11），在他們的開發機器上確實沒有問題，但是在使用者的環境中(比如使用者環境中Winxp機器上的IE8.0瀏覽器下)就有問題。
同時相容性還要考慮移動平臺的相容，比如手機和平板，還要考慮不同的手機系統，以及不同的手機解析度、不同的網路型別（WIFI、3G、4G）下的情況。
另外一些常用軟體的相容也需要考慮，比如匯出操作，匯出的EXCEL等OFFICE檔案要考慮版本之間的相容性。
● 常見問題五：
● 互動性
對於所有的刪除資訊在刪除之前都要給出是否刪除確認的提示或者放棄的提示。
擴充套件下：不僅僅是刪除，包括危險操作之前、或者改變資料狀態等。
另外，新增/修改資訊儲存提交後，系統應該給出“儲存/提交/修改成功”提示資訊，並自動更新顯示。
● 常見問題六：
● 易用性
對於要求使用者大量錄入資訊的頁面，要支援Tab鍵的輸入，Tab鍵的走向要一般要遵循從做左到右，從上到下的的原則。
● 常見問題七：
● 錯別字
另外，要對程式中的錯別字進行檢查，比如把“登入”寫成“登陸”；把“我同意”改成“我統一”。
目前：很多外面的系統都把“登入”寫成“登陸”，其實這樣是不正確的。
舉例：如果系統中首頁中的錯別字，屬於優先順序比較高的問題。
● 常見問題八：
● 開發人員紕漏
開發人員經常會在程式除錯中加入一些彈框輸出操作，但是後來又忘記刪除這些除錯資訊，這些除錯資訊給使用者造成誤解，認為該除錯資訊是系統嚴重的Bug。
程式提交測試之前，程式設計師必須要仔細檢查，刪除該型別的除錯資訊。
● 常見問題九：
● 介面UI
介面佈局缺陷：比如“刪除”按鈕和“儲存”按鈕捱得很近（這樣很容易造成使用者的誤操作）。（注意關閉、刪除、退出按鈕與儲存、下一步等按鈕的距離。類似的按鈕應按此規則排列分佈。另外，注意按鈕的大小是合理一致。
介面上刪除按鈕和儲存按鈕捱得很近。結果有些操作不熟練的業務人員，很容易誤按，因此注意關閉、刪除、退出按鈕與儲存、下一步等按鈕的距離。類似的按鈕應按此規則排列分佈。
● 常見問題九：
● 資源釋放
對於有資源連線的地方（比如資料庫、檔案、索引等），使用完畢後要及時關閉。否則會造成系統資源記憶體洩漏。
這樣的問題，要在編碼階段就需要避免，否則到最後上線，使用者量激增後，使用者體驗會很差，甚至造成系統崩潰。
● 常見問題九：
● 效能體驗
對於經常大資料量的查詢，對於查詢的關鍵欄位是不是要考慮使用到索引等或者其它方法提高查詢的效率，2-5-8原則。
對提高查詢效率，1)可以考慮對查詢關鍵字建立索引、2)可以考慮新增快取、3)可以考慮新增檔案索引(lucene等)
PS:2-5-8原則
就是當用戶能夠在2秒以內得到響應時，會感覺系統的響應很快；
當用戶在2-5秒之間得到響應時，會感覺系統的響應速度還可以；
當用戶在5-8秒以內得到響應時，會感覺系統的響應速度很慢，但是還可以接受；
而當用戶在超過8秒後仍然無法得到響應時，會感覺系統糟透了，或者認為系統已經失去響應，而選擇離開這個Web站點，或者發起第二次請求。
● 常見問題十：
● 介面
程式在介面方面容易出錯。1)內部藉口：事先協商好藉口規範，入參是多少，出參是多少；2)外部藉口：做好容錯處理，如果對方藉口不通，要做好應答。
● 常見問題十一：
● 安全性
● SQL注入
SQL語言對於特殊字元的處理，尤其是查詢語句的單引號的處理，
SQL注入本質有2個關鍵條件：
第一個是使用者能夠控制輸入。
第二個是原本程式要執行的程式碼，拼接了使用者輸入的資料。
比如在文字框中輸入‘ or ’1‘=’1，看是否構成：
Select * FROM member Where username='magci'and password='' or '1'='1'
‘1’=‘1’是永真的，這條SQL語句是能通過驗證的。
● XSS
任一輸入文字域輸入：<script>alert(“xss”);</script>，提交儲存，下次再次訪問時，直接把使用者的輸入直接反射給瀏覽器，如下圖：
● 將sessionId拼接在param裡
現在網站開發已經注意到：登入網站進入其內部網頁後，直接拷貝網址，然後貼上到另一瀏覽器，如果GET請求的param引數裡面拼接了sessionId，則直接可以繞過登入。
● 給session會話設定合理的失效時間
對於需要登入的系統，在使用者不操作的一定時間內，出於安全性考慮，最好要讓使用者重新登入才能重新使用該系統。
● 關閉視窗或者視窗tab頁應該讓session失效
現在很多網站沒有做這個設計，當我關閉瀏覽器或者關閉網站對應的tab頁，應該讓網站的session失效。沒有這個設計，如果使用者在一些公共場合，忘記關電腦的話，別人就可以通過瀏覽器歷史直接進入網站後臺，而不用登入。
● 配置檔案中儘量不要出現使用者名稱密碼
有些檔案在ini等配置檔案中寫出了管理員口令密碼等資訊，而且是明文的!這是一個安全隱患。如果萬不得已要寫到配置檔案中，也儘量加密處理。
● 合理處理彈框
安全缺陷還可能存在於彈出的子視窗。有些設計不嚴格的軟體，在主頁面關閉的時候子頁面還可以執行，這是一個缺陷。
1.4 修復方案
1、首先提高開發人員的安全意識，對一些常見的安全隱患應該有自己敏感的嗅覺，在平時的開發中儘量避免出現這些錯誤
2、配合測試人員，找出對應的缺陷，制定對應的修復方案，然後修復升版。
1.5 相關參考
http://blog.csdn.net/jcy58/article/details/51931652