一, 資料庫安全性
1, MS SQL Server資料庫安全性
Web中不允許使用sa級的使用者串連資料庫
解決方案:
刪除sa使用者,建立一個許可權為sa的使用者,使用者名稱和密碼一樣要複雜。以防暴力破解。
建立一個web串連使用者,去掉所有伺服器角色,在使用者映射中加入此使用者要操作的資料庫和db_public身份。
如果需要其它操作要另加許可權如只加insert/delete/select/update)。
每個人都沒法保證自己寫的代碼沒有漏洞。只要在資料庫層做下處理以防入侵。如果有SQL注入db_public身份一樣能對資料庫添加/修改/刪除許可權,所以一定不能存在SQL注入漏洞。
如果能防SQL注入和許可權限制就很難發生暴庫/跨庫現像。
2, Access資料庫安全性
解決方案:
防暴庫:在資料庫連接時加入錯誤處理代碼,如果資料庫連接失敗就提示錯誤資訊或轉向。不能由系統本身提示錯誤資訊,
防下載。
第一步:建立一個表。
第二步:在表中建一個欄位,名稱隨意,類型是OLE對象,然後用ASP代碼向欄位中添加一條記錄寫入單位元組的"<%" 代碼為:Insert into tablename(fieldname) value (chrB(asc("<")) & chrB(asc("%")))。
第三步:將資料庫改名為*.ASP
最安全的方法是用使用ODBC資料來源串連
二, 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 +”’”已成習慣。其實我也常犯這個錯誤,所以特別在這裡提出。這就是重重之重。
原文標題:web安全問題匯總
連結:http://www.cnblogs.com/livexy/archive/2010/07/07/1773199.html