web代碼安全問題總結
一， 資料庫安全性
1， MSSQL資料庫安全性
l web中不允許使用sa級的使用者串連資料庫
解決方案：
- 刪除sa使用者，建立一個許可權為sa的使用者，使用者名稱和密碼一樣要複雜。以防暴力破解。
- 建立一個web串連使用者，去掉所有伺服器角色，在使用者映射中加入此使用者要操作的資料庫和db_public身份。
- 如果需要其它操作要另加許可權（如只加insert/delete/select/update）。
- 每個人都沒法保證自己寫的代碼沒有漏洞。只要在資料庫層做下處理以防入侵。如果有SQL注入db_public身份一樣能對資料庫添加/修改/刪除許可權，所以一定不能存在SQL注入漏洞。
- 如果能防SQL注入和許可權限制就很難發生暴庫/跨庫現像。
2， Access資料庫安全性
解決方案：
- 防暴庫：在資料庫連接時加入錯誤處理代碼，如果資料庫連接失敗就提示錯誤資訊或轉向。不能由系統本身提示錯誤資訊，
- 防下載。
u 第一步：建立一個表。
u 第二步：在表中建一個欄位，名稱隨意，類型是OLE對象，然後用ASP代碼向欄位中添加一條記錄寫入單位元組的"<%" 代碼為：Insert into tablename(fieldname) value (chrB(asc("<")) & chrB(asc("%")))。
u 第三步：將資料庫改名為*.ASP
二， web代碼安全性
1， 備份檔案時的小漏洞。
有些ASP編輯器會自動備份asp檔案，並且改名為*.bak，這樣就存在了會被下載的漏洞,在給asp檔案改名時，不要修改為*.txt/.bak/等等，一定要儲存副檔名不變（*.asp），在上傳到網站時請不要上傳備份檔案。
2， 防SQL注入。
SQL注入主要是單引號沒有過濾，讓人利用，重建一個具有威脅性的SQL語句。
如：http://www.livexy.com/view.asp?id=100 如果存在SQL注入我們就可以這麼寫：http://www.livexy.com/view.asp?id=100 ;delete * from tablename;後台運行時為select * from aaa where;delete * from tablename
在這裡要提醒大家，不要認為.net的安全性高就沒有SQL注入了。錯，只要和資料庫操作有關的都存在SQL注入漏洞。無論是軟體還是網站，都存在。
解決方案：
- 在頁面的開始位置過濾接收到的非法字元，如exec /delete /insert into/update/’ 等等，這裡過濾不是指將非法字元過濾為空白串，而是過濾為相近的字元。或者如果存在非法字元則轉向到錯誤處理頁面。這裡說個例子如果將exec過濾為空白串時會出來什麼後果，如果字串中存在exexecec 請問過濾後是什麼，還是exec。這裡不多說了，大家都明白了哈。
- 如果接收參數為數值型時，必需要先判斷資料類型，以防出現其它錯誤。往往駭客資訊的來源就是頁面出錯的資訊。
- 如果參數為字元型時，必需要過濾字串中的單引號為雙引號或其它字元。
這裡寫個例子：往往我們的代碼都是這麼寫的select * from aaa where bbb=’” + sVal +”’” 表面上看是沒有問題的，是正確的，不過此句存在SQL注入。為什麼呢，請看：sVal的值是外部提交的資料，如果sVal的值為aaa’;delect * from bbb;-- 寫在一起就是：select * from aaa where bbb=’ aaa’;delect * from bbb;--‘其中-- ‘為注釋。
- 使用DbParameter比拼接SQL來的完全的多。
3， 登入漏洞。
解決方案：
- 過濾非法字串
- SQL寫法 select password from user where username=’” + sqlstr(sUser) + “’” 其中sqlstr()為過濾非法字串函數，sUser為使用者名稱文字框中輸入的字元。然後在判斷資料庫中的密碼和輸入的密碼是否一致。
- 原理：由使用者名稱在資料庫中找到此使用者的記錄，然後在用密碼比較。千萬不要用“select * from user where username=’” + sqlstr(sUser) + “’ and password=’” + sqlstr(sPass) + “’” 然後在判斷是否為空白。”這種方法。
4， 防另存新檔
解決方案：
- <NOSCRIPT><IFRAME SRC="*.html"></IFRAME></NOSCRIPT>
防止別人下載網站的HTML代碼，當然不是很完美，不過也夠嗆。
5， 防被內嵌
解決方案：
- <script>if (self != top) { top.location = self.location; }</script>
防止別人內嵌我們的網站，然後做些手角。如鍵盤記錄呀，監視我們輸入的資料呀等等。
6， 防本地提交資料
解決方案：
- 在儲存資料時第一步判斷來源，如果不是從指定的來源提交資料，出示錯誤資訊。
- 第二步對提交資料進行非法字元過濾。
- 第三步儲存到資料庫，儲存時一定要進行錯誤處理。
7， 防無限重新整理
解決方案：
- 這個比較難做，當然也有很多種方法。
- 1，在伺服器上做手角
- 2，在代碼中加入訪問日誌資訊，通過分析日誌資訊來判斷同一人訪問頻率。
- 3，用js操作cookies來記錄訪問日誌資訊，判斷訪問頻率。這種方法不會佔用伺服器的資源。
8， 防無限提交資料/防ajax自動認可資料
解決方案：
9， 防js代碼
解決方案：
- 要想過濾所有js代碼這點很難辦法，js攻擊漏洞佔大多數。Js的寫法也千奇白怪。這裡發上一些具有攻擊性的html代碼。這些都是常見到的，並且每一種都不同的寫法。單引號和雙引號不同/大小寫不同/先後循序不同/tab和空格不同/Html標籤不同/事件不同/樣式不同等等。
- <P style="BACKGROUND:url(JAVA SCRIPT:alert('11111'))">test</P>
- <body>
- <img src="http://www.challenger.se/images/note_yellow.gif"/>
- <img src="JAVASCRIPT:alert('888888')" />
- <STYLE>div{behavior: url("htc.js");};<style>
- <STYLE>body{oMouseOut: eXpreSsIon(onclick = function(){alert('33333');})} <style>
- <STYLE>body{background:url(JAVASCRIPT:alert('22222'));} <style>
- <STYLE>@import "JAVASCRIPT:alert('444444')"; <style>
- <link href="JAVASCRIPT:alert('777777')" rel="stylesheet" />
- <script src= hk.js></script>
- <P style="BACKGROUND:url(JAVASCRIPT:document.write('<script src=hk.js></script>'))">test</P>
- <iframe src='hk1.html'></iframe>
10，防Cookie假冒
解決方案：
- 密碼資訊不要存放在Cookie中
- 在用到Cookie中的資料時，一定要從資料庫中重新讀取。然後比較。以防Cookie篡改。
- Cookie資料需要加密
11，緩衝區溢位
解決方案：
- 伺服器中不要開啟無用軟體。
- 在服務端啟動並執行代碼中，用到一個對像一定要釋放。
- 在用戶端啟動並執行js/vbs/activex/flash代碼中，用到的dom對像在結束時一定要釋放。
12，其它
- 防瀏覽器外掛程式
- 修改IE的安全選項把“動態指令碼處理”和ActiveX的回合設定為禁用或提示。
- 或在IE安全設定裡將安全層級設為高。隱私選項也設為高。
三， 伺服器安全性
- 關閉無用連接埠
- 下載補丁/更新作業系統
- 安裝殺毒軟體
- 安裝防火牆
- 如果伺服器上有多個網站，為每一個站台指派許可權，每個網站都不能操作其它檔案和目錄，也不能影響到其它網站。
注意：其實以上內容大家都知道，哪麼為什麼還會出現這麼多漏洞呢。有時候我和其它的同伴常說一些費話，我常常會說單引號過濾了嗎，回答是都過濾了，我又說請再看一遍回答我，回答的還是都過濾了，當我看時依然是沒有完全過濾。這能反應一個什麼問題大家都明白了吧。因為大家在寫代碼時寫法都是select * from aaa where bbb=’” + sVal +”’”已成習慣。其實我也常犯這個錯誤，所以特別在這裡提出。這就是重重之重。
以上都是廢話，希望對看到此文章的朋友有所協助。如果寫的不足，請給添加部份email給我，共同學習。(完)
2006-12-15 至 2006-12-17
email:cexo255@163.com
MSN:cexo255@hotmail.com
