Web安全基礎

時間 2019-12-12

標籤 web 安全基礎欄目 HTML 简体版

原文原文鏈接

Web安全基礎

基礎問題回答

1.SQL注入攻擊原理，如何防護？javascript

SQL注入攻擊指的是經過構建特殊的輸入做爲參數傳入Web應用程序，而這些輸入大都是SQL語法裏的一些組合，經過執行SQL語句進而執行攻擊者所要的操做，其主要緣由是程序沒有細緻地過濾用戶輸入的數據，導致非法數據侵入系統。html

防護措施：java

　　1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，能夠經過正則表達式，或限制長度；對單引號和雙"-"進行轉換等。

　　2.永遠不要使用動態拼裝sql，可使用參數化的sql或者直接使用存儲過程進行數據查詢存取。

　　3.永遠不要使用管理員權限的數據庫鏈接，爲每一個應用使用單獨的權限有限的數據庫鏈接。

　　4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。

　　5.應用的異常信息應該給出儘量少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝

　　6.sql注入的檢測方法通常採起輔助軟件或網站平臺來檢測，軟件通常採用sql注入檢測工具jsky，網站平臺就有億思網站安全平臺檢測工具。MDCSOFT SCAN等。採用MDCSOFT-IPS能夠有效的防護

　　SQL注入，XSS攻擊等。

2.XSS攻擊的原理，如何防護？git

XSS是一種常常出如今web應用中的計算機安全漏洞，它容許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中。好比這些代碼包括HTML代碼和客戶端腳本。github

防護措施：web

　　1.基於特徵的防護正則表達式

　　對「javascript」這個關鍵字進行檢索，一旦發現提交信息中包含「javascript」，就認定爲XSS攻擊，但這種方法除了會有大量的漏報外，還存在大量的誤報可能。sql

　　2.基於代碼修改的防護　　shell

　　步驟一、對全部用戶提交內容進行可靠的輸入驗證，包括對URL、查詢關鍵字、HTTP頭、POST數據等，僅接受指定長度範圍內、採用適當格式、採用所預期的字符的內容提交，對其餘的一概過濾。

　　步驟二、實現Session標記(session tokens)、CAPTCHA系統或者HTTP引用頭檢查，以防功能被第三方網站所執行。

　　步驟三、確認接收的的內容被妥善的規範化，僅包含最小的、安全的Tag(沒有javascript)，去掉任何對遠程內容的引用(尤爲是樣式表和javascript)，使用HTTP only的cookie。

3.CSRF攻擊原理，如何防護？數據庫

CSRF（Cross-site request forgery）跨站請求僞造，也被稱爲「One Click Attack」或者Session Riding，一般縮寫爲CSRF或者XSRF，是一種對網站的惡意利用。儘管聽起來像跨站腳本（XSS），但它與XSS很是不一樣，XSS利用站點內的信任用戶，而CSRF則經過假裝來自受信任用戶的請求來利用受信任的網站。

防護措施：

　　對於web站點，將持久化的受權方法（例如cookie或者HTTP受權）切換爲瞬時的受權方法（在每一個form中提供隱藏field），這將幫助網站防止這些攻擊。一種相似的方式是在form中包含祕密信息、用戶

　　指定的代號做爲cookie以外的驗證。

　　另外一個可選的方法是「雙提交」cookie。此方法只工做於Ajax請求，但它可以做爲無需改變大量form的全局修正方法。若是某個受權的cookie在form post以前正被JavaScript代碼讀取，那麼限制跨域規則將

　　被應用。若是服務器須要在Post請求體或者URL中包含受權cookie的請求，那麼這個請求必須來自於受信任的域，由於其它域是不能從信任域讀取cookie的。

　　與一般的信任想法相反，使用Post代替Get方法並不能提供卓有成效的保護。由於JavaScript能使用僞造的POST請求。儘管如此，那些致使對安全產生「反作用」的請求應該總使用Post方式發送。Post方

　　式不會在web服務器和代理服務器日誌中留下數據尾巴，然而Get方式卻會留下數據尾巴。

　　儘管CSRF是web應用的基本問題，而不是用戶的問題，但用戶可以在缺少安全設計的網站上保護他們的賬戶：經過在瀏覽其它站點前登出站點或者在瀏覽器會話結束後清理瀏覽器的cookie。

實驗過程

WebGoat環境

首先把webgoat的jar包下下來，能夠去官方的github上下，不過我用校網幾乎下不動，我是最後去楊正輝提供的網盤裏下的。

cd到jar包的路徑下，輸入

java -jar webgoat-container-x.x.x-war-exec.jar

而後等到提示

說明webgoat服務已經開啓了，打開瀏覽器訪問http://localhost:8080/WebGoat，出現以下頁面

Injection Flaws

Log Spoofing

General Goal(s):
* The grey area below represents what is going to be logged in the web server's log file.
* Your goal is to make it like a username "admin" has succeeded into logging in.
* Elevate your attack by adding a script to the log file.

有一個登陸界面，提交會在日誌中出現下中的記錄，目標是欺騙管理員"admin"用戶成功登入。輸入文本框沒有任何內容限制。

能夠經過加入換行符來欺騙人的肉眼，輸入user name爲Smith%0d%0aLogin Succeeded for username: admin，%0d%0a是/r/n換行符，這樣就經過一次登陸在日誌中假裝成了兩次登陸。結果以下

String SQL Injection

General Goal(s):
　　The form below allows a user to view their credit card numbers. Try to inject an SQL string that results in all the credit card numbers being displayed. Try the user name of 'Smith'.

先作一次測試，輸入Smith查看結果是什麼樣的。

這時候能夠觀察一下題目給出來的數據庫的SQL語句

SELECT * FROM user_data WHERE last_name = 'Your Name'

只要WHERE後爲真就知足題目要求了，因而就能夠把它構形成SELECT * FROM user_data WHERE last_name = 'Your Name' or '1'='1',結果以下：

Command Injection

General Goal(s):

The user should be able to execute any command on the hosting OS.

這道題須要用到burpsuite作proxy代理服務器，修改抓到的數據包。

首先配置burpsuite，若是沒有burpsuite，能夠直接apt-get install burpsuite，而後terminal輸入burpsuite就能打開。

burpsuite有不少功能，咱們這裏只用它的proxy，首先新建項目的配置所有按照默認就能夠，而後配置本地代理服務器，監聽8000端口，默認是8080，但和webgoat衝突了。burpsuite裏配置好後打開火狐，preferences->advanced->network裏面配置代理服務器

注意把NO Proxy for裏的內容刪掉，有可能默認有localhost和127.0.0.1不用代理。

配置結束後開始作題。依然第一次正常輸入看返回結果

注意到這裏出現了sh -c，說明執行了後面那段代碼，

能夠看到這裏應該是把複選框中的內容拼接到了這個文件夾下而且cat查看，天然地咱們想到cat以後繼續讓他執行咱們想執行的命令，但由於這裏是複選框，咱們只好在burpsuite中來修改。打開burpsuite的intercept，而後再次點擊view提交，查看數據包以下。

顯然此時的HelpFile的參數就是咱們上面看到的拼接到shell命令中的參數，因而咱們想辦法給他改改，好比改爲

HelpFile=BasicAuthentication.help";ifconfig"&SUBMIT=View

點擊forward，獲得下面結果：

說明ifconifg成功執行，成功讓命令執行。

Numeric SQL Injection

General Goal(s):

The form below allows employees to see all their personal data including their salaries. Your account is Mike/test123. Your goal is to try to see other employees data as well.

先用各的用戶名密碼Mike/test123登陸，而後能夠經過複選框獲得對應數據，以下圖所示：

題目已經給出了sql語句，接下來的就很是簡單了，利用burpsuite改一下station的值，把它從101改成101 or 1=1，而後forward，獲得下面結果，攻擊成功。

Cross-Site Scripting (XSS)

Phishing with XSS

General Goal(s):
The user should be able to add a form asking for username and password. On submit the input should be sent to http://localhost/WebGoat/catcher?PROPERTY=yes &user=catchedUserName&password=catchedPasswordName

目標是搜索後生成一個含有用戶名和密碼錶單，提交後把輸入發送到http://localhost/WebGoat/catcher?PROPERTY=yes &user=catchedUserName&password=catchedPasswordName，能夠先輸入個簡單的表單測試一下，好比把實驗8中的表單提交上去結果以下：

以後就只須要把onsubmit的js函數修改便可，改成發送數據到對應路徑。

Stored XSS Attacks

General Goal(s):
The user should be able to add message content that cause another user to load an undesireable page or content.

用戶能夠提交title和message到服務器，且其餘用戶能夠點擊title查看message，目標是經過xss在message中植入本身的js腳本或者html頁面。

若是提交任意message結果以下：

而後依然是把實驗8的表單拿過來試試，結果好像能夠，以下圖：

像title作過處理就不能進行xss攻擊

Reflected XSS Attacks

General Goal(s):
For this exercise, your mission is to come up with some input containing a script. You have to try to get this page to reflect that input back to your browser, which will execute the script and do something bad.

Reflected XSS，首先有反彈，在下圖中的表單中找到有可能返回給瀏覽器的參數，按理只有three digit access code服務器纔有可能從新發回給瀏覽器，因而把js腳本寫在這，提交一下，發現alert出現了，說明結果正確。

Cross Site Request Forgery (CSRF)

Goal

Your goal is to send an email to a newsgroup. The email contains an image whose URL is pointing to a malicious request. In this lesson the URL should point to the "attack" servlet with the lesson's "Screen" and "menu" parameters and an extra parameter "transferFunds" having an arbitrary numeric value such as 5000. You can construct the link by finding the "Screen" and "menu" values in the Parameters inset on the right. Recipients of CSRF emails that happen to be authenticated at that time will have their funds transferred. When this lesson's attack succeeds, a green checkmark appears beside the lesson name in the menu on the left.

這道題原理是經過發送郵件給受害者，郵件中包含了指向銀行轉帳的連接，這個連接參數都設好了，但轉帳可否成功執行須要受害人瀏覽器中的cookie能成功被銀行網站認證，這樣雖然用戶只是打開了這個連接，瀏覽器會自動去訪問這個圖片路徑，並且此時cookie又是受害者的cookie，致使轉帳能夠成功進行。

輸入以下代碼，而後點擊連接

<img src="http://localhost:8080/WebGoat/attack?Screen=280&menu=900&transferFunds=5000" width="1" height="1" />

結果以下：

CSRF Prompt By-Pass

General Goal(s):
Similar to the CSRF Lesson, your goal is to send an email to a newsgroup that contains multiple malicious requests: the first to transfer funds, and the second a request to confirm the prompt that the first request triggered. The URLs should point to the attack servlet with this CSRF-prompt-by-pass lesson's Screen, menu parameters and with an extra parameter "transferFunds" having a numeric value such as "5000" to initiate a transfer and a string value "CONFIRM" to complete it. You can copy the lesson's parameters from the inset on the right to create the URLs of the format "attack?Screen=XXX&menu=YYY&transferFunds=ZZZ". Whoever receives this email and happens to be authenticated at that time will have his funds transferred. When you think the attack is successful, refresh the page and you will find the green check on the left hand side menu.

鍵入如下代碼

<form accept-charset='UNKNOWN' method='POST' action='attack?Screen=XXX&menu=YYY' enctype='application/x-www-form-urlencoded'>
    <input name='transferFunds' type='submit' value='CONFIRM'>
    <input name='transferFunds' type='submit' value='CANCEL'>
</form>

結果以下：

CSRF Token By-Pass

General Goal(s):
Similar to the CSRF Lesson, your goal is to send an email to a newsgroup that contains a malicious request to transfer funds. To successfully complete you need to obtain a valid request token. The page that presents the transfer funds form contains a valid request token. The URL for the transfer funds page is the "attack" servlet with the "Screen" and "menu" query parameters of this lesson and an extra parameter "transferFunds=main". Load this page, read the token and append the token in a forged request to transferFunds. When you think the attack is successful, refresh the page and you will find the green check on the left hand side menu.

title隨便輸入一個，message中鍵入如下代碼

<script>
    var tokensuffix;
     
    function readFrame1()
    {
        var frameDoc = document.getElementById("frame1").contentDocument;
        var form = frameDoc.getElementsByTagName("form")[0];
        tokensuffix = '&CSRFToken=' + form.CSRFToken.value;
     
        loadFrame2();
    }
     
    function loadFrame2()
    {
        var testFrame = document.getElementById("frame2");
        testFrame.src="attack?Screen=273&menu=900&transferFunds=5000" + tokensuffix;
    }
</script>
 
<iframe src="attack?Screen=273&menu=900&transferFunds=main"
    onload="readFrame1();"
    id="frame1" frameborder="1" marginwidth="0"
    marginheight="0" width="800" scrolling=yes height="300"></iframe>
 
<iframe id="frame2" frameborder="1" marginwidth="0"
    marginheight="0" width="800" scrolling=yes height="300"></iframe>