淺析history hack、心血漏洞、CSS欺騙、SQL注入與CSRF攻擊

漏洞產生的緣由主要有系統機制和編碼規範兩方面，因爲網絡協議的開放性，目前以 Web 漏洞居多

---

關於系統機制漏洞的典型有JavaScript/CSS history hack，而編碼規範方面的漏洞典型有心血漏洞（Heart Bleed）。
在對漏洞概念有必定了解後，將搭建一個測試網站，對CSS欺騙、SQL注入與CSRF攻擊進行實驗測試。

JavaScript/CSS history hack 漏洞

漏洞影響：攻擊者可以獲取用戶瀏覽器的某些歷史記錄。

攻擊原理：利用瀏覽器自動查詢歷史記錄，以及CSS對訪問過的和未訪問過超連接樣式的不一樣渲染。好比 百度 這個連接是紫色，由於你最近訪問過百度。而 自建CA證書搭建https服務器 這個連接是黑色，由於你當前沒有訪問過我上一篇博客。若是是紫色，刪除訪問歷史後刷新會變成黑色。

攻擊方法：因爲JavaScript能夠讀取任何元素的CSS信息，因此能分辨瀏覽器應用了哪一種樣式從而判斷用戶是否訪問過該連接。攻擊者能夠搭建本身的網站，在上面定義一些網站的超連接。當其餘用戶訪問該網站時，瀏覽器會自動根據用戶的歷史記錄判斷哪些網址曾經訪問過，從而以不一樣顏色呈現給用戶。

攻擊者的網站後臺能夠將用戶訪問過的網站發回給服務器，達到的效果是可以檢測用戶是否訪問過某個網站，但並非直接獲取用戶訪問的歷史記錄。

該漏洞已被修復，現在雖然可以看到對超連接狀態的不一樣顯示，可是js已沒法獲取到其中的顏色差別。

Heart Bleed漏洞

又稱爲心臟出血漏洞，編號(CVE-2014-0160)

漏洞由來：該漏洞由谷歌白帽子尼爾·梅塔（Neel Mehta）提出，他可從特定服務器上隨機獲取64k的工做日誌，整個過程如同釣魚，攻擊能夠一次次持續進行，大量敏感數據會泄露。

產生緣由：編碼時未能在memcpy()調用用戶輸入的內容前，對長度進行邊界檢查。攻擊者能夠輸入超出範圍的字節，再返回等長的緩存內容。

攻擊方法：
OpenSSL有一個叫 Heartbeat（心跳檢測）的拓展，所謂心跳檢測，就是創建一個 Client Hello 問詢來檢測對方服務器是否是正常在線，服務器發回 Server hello，代表SSL通信正常。就像咱們打電話時會問對方 「喂聽獲得嗎？」同樣。
剛纔測試超連接的博客有關於SSL與https的介紹

每次問詢都會附加一個問詢的字符長度，若是這個字符長度大於實際的長度，服務器還是會返回相同規模的字符信息，因而造成了內存裏信息的越界訪問。

漏洞影響：每發起一個心跳，服務器就能泄露一點點數據（理論上最多泄露 64K），這些數據裏可能包括用戶的登陸帳號密碼、電子郵件甚至是加密密鑰等信息，也可能並無包含這些信息，但攻擊者能夠不斷利用 「心跳」來獲取更多的信息。就這樣，服務器一點一點泄露愈來愈多的信息，就像是心臟慢慢在出血，心臟出血的名字由此而來，漏洞目前已修復，但該漏洞被提出以前是否已被利用就不得而知。

---

以上是兩種類型漏洞的簡單介紹，如下將對CSS欺騙、SQL注入與CSRF攻擊進行實驗

---

CSS欺騙

正如名字同樣，CSS欺騙主要是做爲一種欺騙手段，給瀏覽器用戶呈現出虛假信息。

雖然是很簡單的手段，可是應用卻十分普遍

欺騙原理：經過CSS定位方式和僞類，實現網頁內容覆蓋

html如人的骨骼，css是外表裝飾，js控制頁面的效果相似神經，CSS欺騙主要是利用CSS對頁面的渲染。

定位方式和僞類簡介

CSS對網頁元素的定位方式有如下四種：

• 靜態定位（static）：全部元素的默認定位方式，能夠將元素定位於靜態位置，所謂靜態位置就是各個元素在HTML文檔流中默認的位置。
• 相對定位（relative）：不脫離文檔流，參考自身靜態位置經過 top,bottom,left,right定位，而且能夠經過z-index進行層次分級。
• 絕對定位（absolute）：脫離文檔流，經過 top,bottom,left,right 選取其最近的父級元素定位，當父級 position 爲 static 時，absolute元素將以body座標原點進行定位，能夠經過z-index進行層次分級。
• 固定定位（fixed）：所固定的對象是當前可視窗口（瀏覽器窗口）而並不是是body或是父級元素，頁面滾動也不會移動，可經過z-index進行層次分級。

經常使用定位方式：子絕父相

• 當子元素是絕對定位時，父元素採用相對定位，這樣父容器既能夠在原文檔流中保留位置，子元素也能參照父容器絕對定位。

CSS僞類能夠與 CSS 類配合使用，有anchor僞類、first-child僞類等。

如anchor僞類：

• a:link {color:#FF0000;} /* 未訪問的連接 */
• a:visited {color:#00FF00;} /* 已訪問的連接 */
• a:hover {color:#FF00FF;} /* 鼠標劃過連接 */
• a:active {color:#0000FF;} /* 已選中的連接 */

欺騙案例：早年的淘寶店鋪裝修直接使用css控制頁面顯示效果，有商戶就此製做虛假店鋪信息。

如下是2012年先後的一家店鋪信息

圖中所呈現的信息並不是真實的店鋪信息。

30天銷售量實際值爲0，經過店鋪裝修時設置背景圖，呈現出了580件的字樣。

「購物須知」被背景圖假裝成了 「優質商家 7天無理由退換」。

評價詳情與成交記錄一樣是使用背景圖進行虛假宣傳。

實際並無買家評價，只是添加了背景圖片。

爲何說CSS欺騙雖然簡單可是應用普遍？

就我的網頁瀏覽經歷而言，在4G以前或者4G剛開始那個時候，這種利用圖片作虛假頁面是很常見的。

最近一次是2018年雙十一時候，在某電商平臺申請退款，商家一直不理會，在平臺進行投訴時發現提交投訴的按鈕怎麼點都沒反應。一開始覺得是手機顯示不兼容，後來發現那個頁面下半部分是張圖片，提交按鈕只是圖片的一部分。

不過雙十一也能夠理解，可是就大多數沒什麼計算機基礎的網民而言，CSS欺騙仍是頗有效的。

下面將會先介紹SQL注入，而後再將CSS欺騙與SQL注入結合，在搭建的測試網站上實現利用SQL注入前端代碼進行CSS欺騙。

SQL注入

SQL注入便是指web應用程序對用戶輸入數據的合法性沒有判斷或過濾不嚴，攻擊者能夠在web應用程序中事先定義好的查詢語句的結尾上添加額外的SQL語句，在管理員不知情的狀況下實現非法操做，是目前最多見危險的漏洞之一。

SQL注入不是一個過時的安全問題，偏偏相反，它是一種很是容易被使用的攻擊方式，SQL注入並不須要高深的攻擊手段即可以輕易使敏感的數據庫信息被非法瀏覽或刪除。

通常注入過程：

1. SQL注入點探測。
   經過適當的分析應用程序，判斷什麼地方存在SQL注入點。一般只要帶有輸入提交的動態網頁，而且動態網頁訪問數據庫，就可能存在SQL注入漏洞。
2. 收集後臺數據庫信息。
   不一樣數據庫的注入方法、函數都不盡相同，在注入以前先要判斷一下數據庫的類型。能夠輸入特殊字符如單引號，讓程序返回錯誤信息，根據錯誤信息提示進行判斷；還可使用特定函數來判斷，好比輸入「1 and version（）>0」，程序返回正常說明version（）函數被數據庫識別並執行，而version（）函數是MySQL特有的函數，所以能夠推斷後臺數據庫爲MySQL。
3. 猜解用戶名和密碼。
   數據庫中的表和字段命名通常都是有規律的，經過構造特殊SQL語句在數據庫中依次猜解出表名、字段名、字段數、用戶名和密碼。

網站搭建與SQL注入測試

若是有簡單網站的搭建經驗，只須要理解了SQL注入的原理，就能夠構建本身的測試。
下圖是搭建的測試網站的登錄界面：

先註冊一個userA的帳號並登陸：

網站有三個簡單的頁面，分別是Home、Users、Transfer：

• Home: 顯示用戶的zoobars（當前網站用戶的虛擬貨幣）數量，設置用戶的我的簡介。
  
• Users：能夠搜索其餘用戶並顯示用戶財富和簡介。
  
• Transfer：能夠將本身的zoobars轉給其餘用戶。
  

如下有兩種SQL注入可使得本身的zoobars變多：

1. 經過填寫我的簡介修改本身的zoobars，會改動數據庫zoobars數量
2. 經過填寫我的簡介注入CSS代碼，使得別人搜索本身時zoobars看上去變多，不會改動數據庫zoobars數量

方法一

注入代碼：

userA的我的簡介', Zoobars='20

保存我的簡介後刷新頁面，userA的zoobars變成了20，簡介顯示「userA的我的簡介」：

這種方法直接改動了數據庫數據，後臺更新我的簡介的php代碼以下：

<?php
  if($_POST['profile_submit']) {  // Check for profile submission
    $profile = $_POST['profile_update'];
    $sql = "UPDATE Person SET Profile='$profile' ".
           "WHERE PersonID=$user->id";
    $db->executeQuery($sql);      // Overwrite profile in database
  }
  $sql = "SELECT Profile FROM Person WHERE PersonID=$user->id";
  $rs = $db->executeQuery($sql);
  $rs = mysqli_fetch_array($rs);
  echo $rs["Profile"];
?>

第四、5行的$sql值是數據庫要執行的語句，方法1使得實際執行的sql語句變成了：

UPDATE Person SET Profile='userA的我的簡介', Zoobars='20' WHERE PersonID=userA

方法二

因爲場景不一樣，有時候會使用方法二注入，僅修改網頁的顯示進行CSS欺騙：

userA的zoobars數量是20，經過SQL注入前端代碼，可使得這個網站的用戶在搜索userA時看到的數量爲200，這裏爲了方便觀察，欺騙的字體設置了紅色。

注入代碼：

<span style="color:#000000;position:relative;left:60px;top:-54px;">0</span>

與以前介紹淘寶商家用CSS直接設置背景圖片不一樣，這裏是經過SQL注入在我的簡介裏寫了個相對定位的標籤，當網站用戶搜索userA的我的簡介時，我的簡介裏的html代碼會被瀏覽器解釋渲染成數字0，並顯示在zoobars數量的後面。

下面將介紹與瀏覽器機制相關的另外一種攻擊方式。

CSRF攻擊

CSRF（Cross-site request forgery），即跨站請求僞造。

引誘瀏覽器用戶訪問本身的攻擊網站進行跨站訪問，經過瀏覽器保存用戶原網站cookie的機制，在攻擊網站獲取用戶的身份權限並僞造請求進行攻擊。

瀏覽器機制：

當用戶登陸某一網站後，本地會保存一份cookie用於身份認證，若是cookie沒有過時，就不須要反覆進行登陸操做。

與JavaScript/CSS history hack不一樣的是，CSRF暫時沒法像修改CSS或JS引擎那樣進行漏洞修補，由於目前的瀏覽器須要這種機制。

場景模擬：程序員登陸博客園瀏覽博客，發現一篇不錯的博客後打算分享到朋友圈，但第一次分享時網頁會要求先登陸朋友圈。當登陸分享成功後，沒過多久程序員又發現一篇不錯的博客，打算再次分享，以此往復循環，瀏覽器會怎麼作？

目前瀏覽器的機制是會在第一次登錄後保存用戶的cookie，使得用戶在有效期內沒必要反覆認證身份，因此後續的跨站不須要再登陸。（沒有實際操做過，也可能博客園分享每次都須要登陸，只是舉個例子模擬網頁跨站情景）

瀏覽器保存cookie的機制是須要的，但同時給了攻擊者可乘之機。

web中用戶身份驗證的漏洞：

簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求自己是用戶自願發出的。

也就是說，用戶的瀏覽器發送了一條請求，同時瀏覽器的cookie也能證實用戶身份，可是並不能保證這條請求是用戶主動在原網站上進行的操做。

以搭建的網站爲例進行攻擊演示

攻擊步驟：

1. 搭建一個網頁，用於僞造請求，請求內容是從被攻擊者的帳戶轉1個zoobar到本身帳戶
2. 在攻擊者申請的網站帳戶裏，填寫我的簡介，SQL注入一個本身的網站鏈接
3. 誘導其餘用戶點擊攻擊者帳號我的簡介上的網頁連接進行攻擊

搭建網頁

原網頁與代碼：

Transfer界面點擊Send按鈕會發送一條請求，執行轉帳操做。

攻擊者須要製做一個本身的網站，在網站上編寫攻擊操做。
這裏直接將原網站的界面代碼複製了一份，而後Send的金額寫入默認值1，轉帳對象默認設置成攻擊者的userA帳戶，再經過JS代碼讓網站在加載時自動執行Send按鈕的提交操做。

攻擊網頁與代碼：

雖然看上去同樣，可是經過瀏覽器地址能夠看出這個另外一個網頁，用來模擬進行攻擊的網站。

而後在我的簡介裏注入一個超連接：

<a href="https://localhost/myzoo/send.php">點擊獲取</a>

網址是攻擊者本身的網站

這時其餘用戶搜索userA時，會看到以下簡介：

目前userB的zoobars數量爲9，若是點擊一下這個連接，會跳轉到攻擊者網站並自動給userA轉一個zoobar，以後userA的數量變成21個，userB只剩下8個。


攻擊實際上就是經過用戶瀏覽器保存的cookie認證，僞造出用戶請求。

應對CSRF攻擊的方法有不少，有一種是能夠經過檢查請求的Referer字段判斷請求的來源網站，不過這是一個攻防的過程，攻擊者也有可能進一步攻擊篡改Referer字段。

小結

• JavaScript/CSS history hack
  利用了瀏覽器爲了方便用戶瀏覽而查詢歷史記錄的機制漏洞，已經過完善CSS/JS修補。
• 心血漏洞
  代碼不規範引發的數據泄露漏洞，已被修補。
• CSS欺騙
  經常使用的欺騙技術，須要根據特定場景結合其餘攻擊方式。
• SQL注入
  最多見安全漏洞之一，數據泄露的主要緣由之一，安全風險較高，必定程度上超過緩衝區溢出漏洞，只能儘可能避免。
• 跨站請求僞造 利用瀏覽器的機制漏洞，沒法直接根治，與SQL注入同樣是個攻防的過程。