當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

Burp Scanner Report

發布時間：2024/3/7 编程问答 42 豆豆

生活随笔收集整理的這篇文章主要介紹了 Burp Scanner Report 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

1、使用application web 漏洞平臺，除此之外還有一款類似的工具叫做mulidata,其實mulidata功能更好一點。

2、配置之前的問題處理

??????? 安裝之前要確認自己之前是否安裝過 Apache或者PHP解釋器或者MySQL ，如果之前安裝了單個版本的軟件，需要卸載，或者檢查是否運行，關閉也可以。

?這里我做滲透測試使用的burp沒使用如何破解

? 首先啟動burploadkey,點擊RUN之后，會啟動 burpsuite，下面使用的版本比較低了，最新的版本到2以上了，可以在我的微云上下載?? 地址https://share.weiyun.com/5DQdMcP

? 之后將生成的license復制到打開的burp里面，點擊next ，

?? 之后選擇手動激活，? manualactivation ，將request 粘貼到? active request ，會自動生成response 再將生成的粘貼到下面的response中，點擊下一步。

在之后的使用的時候不需要在想這樣激活，但是必須第一步加載burpsuite loadkey

3、使用brupsuite

?? 手動掃描疑點目錄，首先對存在問題的目錄url發送到 intruder，對要替換的URl worlds進行標準。自己可以取消自動標注，自己設置要模糊替換的單詞。然后對其設置掃描類型，天際字典進行掃描。

4、report

Burp Scanner Report

Summary

The table below shows the numbers of issues identified in different categories. Issues are classified according to severity as High, Medium, Low or Information. This reflects the likely impact of each issue for a typical organization. Issues are also classified according to confidence as Certain, Firm or Tentative. This reflects the inherent reliability of the technique that was used to identify the issue.

?	?	Confidence
?	?	Certain	Firm	Tentative	Total
Severity	High	2	0	0	2
	Medium	0	0	0	0
	Low	3	1	0	4
	Information	2	4	8	14

The chart below shows the aggregated numbers of issues identified in each category. Solid colored bars represent issues with a confidence level of Certain, and the bars fade as the confidence level falls.

Number of issues

Severity

High

Medium

Low

1.?Cleartext submission of password

1.1.?http://www.angeldg.com/Rece/UserLogin.asp

1.2.?http://www.angeldg.com/Rece/UserRegister.asp

2.?Password field with autocomplete enabled

2.1.?http://www.angeldg.com/Rece/UserLogin.asp

2.2.?http://www.angeldg.com/Rece/UserRegister.asp

3.?Content type incorrectly stated

4.?Unencrypted communications

5.?Path-relative style sheet import

5.1.?http://www.angeldg.com/Rece/UserLogin.asp

5.2.?http://www.angeldg.com/Rece/UserRegister.asp

5.3.?http://www.angeldg.com/rece/CProductMain.asp

5.4.?http://www.angeldg.com/rece/index.asp

6.?Cross-domain Referer leakage

7.?Frameable response (potential Clickjacking)

7.1.?http://www.angeldg.com/Rece/UserLogin.asp

7.2.?http://www.angeldg.com/Rece/UserRegister.asp

7.3.?http://www.angeldg.com/rece/CProductMain.asp

7.4.?http://www.angeldg.com/rece/index.asp

8.?HTML does not specify charset

9.?HTML uses unrecognized charset

9.1.?http://www.angeldg.com/Rece/UserLogin.asp

9.2.?http://www.angeldg.com/Rece/UserRegister.asp

9.3.?http://www.angeldg.com/rece/CProductMain.asp

9.4.?http://www.angeldg.com/rece/index.asp

1.?Cleartext submission of password
Next?

There are 2 instances of this issue:

/Rece/UserLogin.asp
/Rece/UserRegister.asp

Issue background

Some applications transmit passwords over unencrypted connections, making them vulnerable to interception. To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.

Vulnerabilities that result in the disclosure of users' passwords can result in compromises that are extremely difficult to investigate due to obscured audit trails. Even if the application itself only handles non-sensitive information, exposing passwords puts users who have re-used their password elsewhere at risk.

Issue remediation

Applications should use transport-level encryption (SSL or TLS) to protect all sensitive communications passing between the client and the server. Communications that should be protected include the login mechanism and related functionality, and any functions where sensitive data can be accessed or privileged actions can be performed. These areas should employ their own session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications. If HTTP cookies are used for transmitting session tokens, then the secure flag should be set to prevent transmission over clear-text HTTP.

Vulnerability classifications

CWE-319: Cleartext Transmission of Sensitive Information

1.1.?http://www.angeldg.com/Rece/UserLogin.asp
Next?

Summary

?	Severity:??	High
	Confidence:??	Certain
	Host:??	http://www.angeldg.com
	Path:??	/Rece/UserLogin.asp

Issue detail

The page contains a form with the following action URL, which is submitted over clear-text HTTP:

http://www.angeldg.com/Rece/UserLoginFinish.asp

The form contains the following password field:

PassWord

Request

GET /Rece/UserLogin.asp HTTP/1.1
Host: www.angeldg.com
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://www.angeldg.com/rece/index.asp
Accept-Language: zh-CN,zh;q=0.9
Cookie: ASPSESSIONIDACTATSQC=IDNFEHIBDCCHKMMNFOCJCLOC; UM_distinctid=167cbbc80e43e8-054679a27bccff-5d1f3b1c-100200-167cbbc80e53e9; CNZZDATA5927622=cnzz_eid%3D928603540-1545311388-null%26ntime%3D1545311388
Connection: close

Response

HTTP/1.1 200 OK
Connection: close
Date: Thu, 20 Dec 2018 13:11:19 GMT
Server: WWW Server/1.1
X-Powered-By: ASP.NET
Content-Length: 16583
Content-Type: text/html
Cache-control: private
X-Safe-Firewall: zhuji.360.cn 1.0.9.47 F1W1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script src="/Inc/jquery.js"></script>
<html xmlns="http://www.w3.org/1999
...[SNIP]...
<table width="250" border="0" cellspacing="0" cellpadding="0" align="center" >
<form action="UserLoginFinish.asp" method="post" name="UserLoginForm">
<tr>
...[SNIP]...
<td><input name="PassWord" type="password" id="PassWord" size="30" maxlength="20" class="InputTextD"/></td>
...[SNIP]...

1.2.?http://www.angeldg.com/Rece/UserRegister.asp
Previous??Next?

Summary

?	Severity:??	High
	Confidence:??	Certain
	Host:??	http://www.angeldg.com
	Path:??	/Rece/UserRegister.asp

Issue detail

The page contains a form with the following action URL, which is submitted over clear-text HTTP:

http://www.angeldg.com/Rece/UserRegisterfinish.asp

The form contains the following password fields:

PassWord
confirmPassWord

Request

GET /Rece/UserRegister.asp HTTP/1.1
Host: www.angeldg.com
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://www.angeldg.com/rece/index.asp
Accept-Language: zh-CN,zh;q=0.9
Cookie: ASPSESSIONIDACTATSQC=IDNFEHIBDCCHKMMNFOCJCLOC; UM_distinctid=167cbbc80e43e8-054679a27bccff-5d1f3b1c-100200-167cbbc80e53e9; CNZZDATA5927622=cnzz_eid%3D928603540-1545311388-null%26ntime%3D1545311388
Connection: close

Response

HTTP/1.1 200 OK
Connection: close
Date: Thu, 20 Dec 2018 13:19:24 GMT
Server: WWW Server/1.1
X-Powered-By: ASP.NET
Content-Length: 36275
Content-Type: text/html
Cache-control: private
X-Safe-Firewall: zhuji.360.cn 1.0.9.47 F1W1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script src="/Inc/jquery.js"></script>
<html xmlns="http://www.w3.org/1999
...[SNIP]...
<table width="350" border="0" cellspacing="0" cellpadding="0" align="center">
???<form action="UserRegisterfinish.asp" name="form" method="post" οnsubmit="return checkdata()">
<tr>
...[SNIP]...
<td height="50"><input name="PassWord" type="password" class="InputTextZ" id="PassWord" οnblur="chkpwd(this)" size="30" maxlength="20" autocomplete="off"/><br />
...[SNIP]...
<td height="50"><input name="confirmPassWord" type="password" class="InputTextZ" id="confirmPassWord" size="30" maxlength="20"/></td>
...[SNIP]...

2.?Password field with autocomplete enabled
Previous??Next?

There are 2 instances of this issue:

/Rece/UserLogin.asp
/Rece/UserRegister.asp

Issue background

Most browsers have a facility to remember user credentials that are entered into HTML forms. This function can be configured by the user and also by applications that employ user credentials. If the function is enabled, then credentials entered by the user are stored on their local computer and retrieved by the browser on future visits to the same application.

The stored credentials can be captured by an attacker who gains control over the user's computer. Further, an attacker who finds a separate application vulnerability such as cross-site scripting may be able to exploit this to retrieve a user's browser-stored credentials.

Issue remediation

To prevent browsers from storing credentials entered into HTML forms, include the attribute?autocomplete="off"?within the FORM tag (to protect all form fields) or within the relevant INPUT tags (to protect specific individual fields).

Please note that modern web browsers may ignore this directive. In spite of this there is a chance that not disabling autocomplete may cause problems obtaining PCI compliance.

Vulnerability classifications

CWE-200: Information Exposure

2.1.?http://www.angeldg.com/Rece/UserLogin.asp
Previous??Next?

Summary

?	Severity:??	Low
	Confidence:??	Certain
	Host:??	http://www.angeldg.com
	Path:??	/Rece/UserLogin.asp

Issue detail

The page contains a form with the following action URL:

http://www.angeldg.com/Rece/UserLoginFinish.asp

The form contains the following password field with autocomplete enabled:

PassWord

Request

Response

2.2.?http://www.angeldg.com/Rece/UserRegister.asp
Previous??Next?

Summary

?	Severity:??	Low
	Confidence:??	Certain
	Host:??	http://www.angeldg.com
	Path:??	/Rece/UserRegister.asp

Issue detail

The page contains a form with the following action URL:

http://www.angeldg.com/Rece/UserRegisterfinish.asp

The form contains the following password field with autocomplete enabled:

confirmPassWord

Request

Response

HTTP/1.1 200 OK
Connection: close
Date: Thu, 20 Dec 2018 13:19:24 GMT
Server: WWW Server/1.1
X-Powered-By: ASP.NET
Content-Length: 36275
Content-Type: text/html
Cache-control: private
X-Safe-Firewall: zhuji.360.cn 1.0.9.47 F1W1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script src="/Inc/jquery.js"></script>
<html xmlns="http://www.w3.org/1999
...[SNIP]...
<table width="350" border="0" cellspacing="0" cellpadding="0" align="center">
???<form action="UserRegisterfinish.asp" name="form" method="post" οnsubmit="return checkdata()">
<tr>
...[SNIP]...
<td height="50"><input name="confirmPassWord" type="password" class="InputTextZ" id="confirmPassWord" size="30" maxlength="20"/></td>
...[SNIP]...

3.?Content type incorrectly stated
Previous??Next?

Summary

?	Severity:??	Low
	Confidence:??	Firm
	Host:??	http://www.angeldg.com
	Path:??	/Rece/UserLoginFinish.asp

Issue detail

The response states that the content type is?text/html. However, it actually appears to contain?unrecognized content.

All browsers may interpret the response as HTML.

Issue background

If a response specifies an incorrect content type then browsers may process the response in unexpected ways. If the content type is specified to be a renderable text-based format, then the browser will usually attempt to interpret the response as being in that format, regardless of the actual contents of the response. Additionally, some other specified content types might sometimes be interpreted as HTML due to quirks in particular browsers. This behavior might lead to otherwise "safe" content such as images being rendered as HTML, enabling cross-site scripting attacks in certain conditions.

The presence of an incorrect content type statement typically only constitutes a security flaw when the affected resource is dynamically generated, uploaded by a user, or otherwise contains user input. You should review the contents of affected responses, and the context in which they appear, to determine whether any vulnerability exists.

Issue remediation

For every response containing a message body, the application should include a single Content-type header that correctly and unambiguously states the MIME type of the content in the response body.

Additionally, the response header "X-content-type-options: nosniff" should be returned in all responses to reduce the likelihood that browsers will interpret content in a way that disregards the Content-type header.

Vulnerability classifications

CWE-16: Configuration
CWE-436: Interpretation Conflict

Request

POST /Rece/UserLoginFinish.asp HTTP/1.1
Host: www.angeldg.com
Content-Length: 112
Cache-Control: max-age=0
Origin: http://www.angeldg.com
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://www.angeldg.com/Rece/UserLogin.asp
Accept-Language: zh-CN,zh;q=0.9
Cookie: ASPSESSIONIDACTATSQC=IDNFEHIBDCCHKMMNFOCJCLOC; UM_distinctid=167cbbc80e43e8-054679a27bccff-5d1f3b1c-100200-167cbbc80e53e9; CNZZDATA5927622=cnzz_eid%3D928603540-1545311388-null%26ntime%3D1545311388
Connection: close

DUserName=1214tian%40sina.com&PassWord=admin%27+or+%271%27%3D%271&Loginnum=7332&Submit.x=126&Submit.y=15&ComUrl=

Response

HTTP/1.1 200 OK
Connection: close
Date: Thu, 20 Dec 2018 13:19:23 GMT
Server: WWW Server/1.1
X-Powered-By: ASP.NET
pragma: no-cache
Content-Length: 147
Content-Type: text/html
Expires: Thu, 20 Dec 2018 13:18:23 GMT
Cache-control: no-cache
X-Safe-Firewall: zhuji.360.cn 1.0.9.47 F1W1

<script src="/Inc/jquery.js"></script>
???<script language="javascript">
??? ???alert('..........................');
??? ???history.back();
???</script>
???

4.?Unencrypted communications
Previous??Next?

Summary

?	Severity:??	Low
	Confidence:??	Certain
	Host:??	http://www.angeldg.com
	Path:??	/

Issue description

The application allows users to connect to it over unencrypted connections. An attacker suitably positioned to view a legitimate user's network traffic could record and monitor their interactions with the application and obtain any information the user supplies. Furthermore, an attacker able to modify traffic could use the application as a platform for attacks against its users and third-party websites. Unencrypted connections have been exploited by ISPs and governments to track users, and to inject adverts and malicious JavaScript. Due to these concerns, web browser vendors are planning to visually flag unencrypted connections as hazardous.

To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.

Please note that using a mixture of encrypted and unencrypted communications is an ineffective defense against active attackers, because they can easily remove references to encrypted resources when these references are transmitted over an unencrypted connection.

Issue remediation

Applications should use transport-level encryption (SSL/TLS) to protect all communications passing between the client and the server. The Strict-Transport-Security HTTP header should be used to ensure that clients refuse to access the server over an insecure connection.

References

Marking HTTP as non-secure
Configuring Server-Side SSL/TLS
HTTP Strict Transport Security

Vulnerability classifications

CWE-326: Inadequate Encryption Strength

5.?Path-relative style sheet import
Previous??Next?

There are 4 instances of this issue:

/Rece/UserLogin.asp
/Rece/UserRegister.asp
/rece/CProductMain.asp
/rece/index.asp

Issue background

Path-relative style sheet import vulnerabilities arise when the following conditions hold:

A response contains a style sheet import that uses a path-relative URL (for example, the page at "/original-path/file.php" might import "styles/main.css").

When handling requests, the application or platform tolerates superfluous path-like data following the original filename in the URL (for example, "/original-path/file.php/extra-junk/"). When superfluous data is added to the original URL, the application's response still contains a path-relative stylesheet import.

The response in condition 2 can be made to render in a browser's quirks mode, either because it has a missing or old doctype directive, or because it allows itself to be framed by a page under an attacker's control.

When a browser requests the style sheet that is imported in the response from the modified URL (using the URL "/original-path/file.php/extra-junk/styles/main.css"), the application returns something other than the CSS response that was supposed to be imported. Given the behavior described in condition 2, this will typically be the same response that was originally returned in condition 1.

An attacker has a means of manipulating some text within the response in condition 4, for example because the application stores and displays some past input, or echoes some text within the current URL.

Given the above conditions, an attacker can execute CSS injection within the browser of the target user. The attacker can construct a URL that causes the victim's browser to import as CSS a different URL than normal, containing text that the attacker can manipulate.

Being able to inject arbitrary CSS into the victim's browser may enable various attacks, including:

Executing arbitrary JavaScript using IE's expression() function.
Using CSS selectors to read parts of the HTML source, which may include sensitive data such as anti-CSRF tokens.
Capturing any sensitive data within the URL query string by making a further style sheet import to a URL on the attacker's domain, and monitoring the incoming Referer header.

Issue remediation

The root cause of the vulnerability can be resolved by not using path-relative URLs in style sheet imports. Aside from this, attacks can also be prevented by implementing all of the following defensive measures:

Setting the HTTP response header "X-Frame-Options: deny" in all responses. One method that an attacker can use to make a page render in quirks mode is to frame it within their own page that is rendered in quirks mode. Setting this header prevents the page from being framed.
Setting a modern doctype (e.g. "<!doctype html>") in all HTML responses. This prevents the page from being rendered in quirks mode (unless it is being framed, as described above).
Setting the HTTP response header "X-Content-Type-Options: no sniff" in all responses. This prevents the browser from processing a non-CSS response as CSS, even if another page loads the response via a style sheet import.

References

Detecting and exploiting path-relative stylesheet import (PRSSI) vulnerabilities

Vulnerability classifications

CWE-16: Configuration

5.1.?http://www.angeldg.com/Rece/UserLogin.asp
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Tentative
	Host:??	http://www.angeldg.com
	Path:??	/Rece/UserLogin.asp

Issue detail

The application may be vulnerable to path-relative style sheet import (PRSSI) attacks. The response contains a path-relative style sheet import, and so condition 1 for an exploitable vulnerability is present (see issue background). The response can also be made to render in a browser's quirks mode. Although the page contains a modern doctype directive, the response does not prevent itself from being framed. An attacker can frame the response within a page that they control, to force it to be rendered in quirks mode. (Note that this technique is IE-specific and due to P3P restrictions might sometimes limit the impact of a successful attack.) This means that condition 3 for an exploitable vulnerability is probably present if condition 2 is present.

Burp was not able to confirm that the other conditions hold, and you should manually investigate this issue to confirm whether they do hold.

Request

Response

HTTP/1.1 200 OK
Connection: close
Date: Thu, 20 Dec 2018 13:11:19 GMT
Server: WWW Server/1.1
X-Powered-By: ASP.NET
Content-Length: 16583
Content-Type: text/html
Cache-control: private
X-Safe-Firewall: zhuji.360.cn 1.0.9.47 F1W1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script src="/Inc/jquery.js"></script>
<html xmlns="http://www.w3.org/1999
...[SNIP]...
</title>
<link href="../Images/Css.css" rel="stylesheet" type="text/css">
</head>
...[SNIP]...

5.2.?http://www.angeldg.com/Rece/UserRegister.asp
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Tentative
	Host:??	http://www.angeldg.com
	Path:??	/Rece/UserRegister.asp

Issue detail

Request

Response

HTTP/1.1 200 OK
Connection: close
Date: Thu, 20 Dec 2018 13:19:24 GMT
Server: WWW Server/1.1
X-Powered-By: ASP.NET
Content-Length: 36275
Content-Type: text/html
Cache-control: private
X-Safe-Firewall: zhuji.360.cn 1.0.9.47 F1W1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script src="/Inc/jquery.js"></script>
<html xmlns="http://www.w3.org/1999
...[SNIP]...
</script>
<link href="../webtime/mobiscroll_002.css" rel="stylesheet" type="text/css">
<script src="../webtime/mobiscroll.js" type="text/javascript"></script>
<link href="../webtime/mobiscroll_003.css" rel="stylesheet" type="text/css">


<link href="../Images/Css.css" rel="stylesheet" type="text/css">
</head>
...[SNIP]...

5.3.?http://www.angeldg.com/rece/CProductMain.asp
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Tentative
	Host:??	http://www.angeldg.com
	Path:??	/rece/CProductMain.asp

Issue detail

Request

GET /rece/CProductMain.asp?MainType=1&BClass=56 HTTP/1.1
Host: www.angeldg.com
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://www.angeldg.com/rece/index.asp
Accept-Language: zh-CN,zh;q=0.9
Cookie: ad_play_index=70; ASPSESSIONIDACTATSQC=IDNFEHIBDCCHKMMNFOCJCLOC; UM_distinctid=167cbbc80e43e8-054679a27bccff-5d1f3b1c-100200-167cbbc80e53e9; CNZZDATA5927622=cnzz_eid%3D928603540-1545311388-null%26ntime%3D1545311388
Connection: close

Response

HTTP/1.1 200 OK
Connection: close
Date: Thu, 20 Dec 2018 13:11:05 GMT
Server: WWW Server/1.1
X-Powered-By: ASP.NET
Content-Length: 26677
Content-Type: text/html
Cache-control: private
X-Safe-Firewall: zhuji.360.cn 1.0.9.47 F1W1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script src="/Inc/jquery.js"></script>
<html xmlns="http://www.w3.org/1999
...[SNIP]...
</script>
<link href="../Images/Css.css" rel="stylesheet" type="text/css">
</head>
...[SNIP]...

5.4.?http://www.angeldg.com/rece/index.asp
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Tentative
	Host:??	http://www.angeldg.com
	Path:??	/rece/index.asp

Issue detail

Request

GET /rece/index.asp HTTP/1.1
Host: www.angeldg.com
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://www.angeldg.com/rece/index.asp
Accept-Language: zh-CN,zh;q=0.9
Cookie: ad_play_index=70; ASPSESSIONIDACTATSQC=IDNFEHIBDCCHKMMNFOCJCLOC; UM_distinctid=167cbbc80e43e8-054679a27bccff-5d1f3b1c-100200-167cbbc80e53e9; CNZZDATA5927622=cnzz_eid%3D928603540-1545311388-null%26ntime%3D1545311388
Connection: close

Response

HTTP/1.1 200 OK
Connection: close
Date: Thu, 20 Dec 2018 13:19:23 GMT
Server: WWW Server/1.1
X-Powered-By: ASP.NET
Content-Length: 42402
Content-Type: text/html
Cache-control: private
X-Safe-Firewall: zhuji.360.cn 1.0.9.47 F1W1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script src="/Inc/jquery.js"></script>
<html xmlns="http://www.w3.org/1999/x
...[SNIP]...
<![endif]-->
<link href="../Images/Css.css" rel="stylesheet" type="text/css">
</head>
...[SNIP]...
</div>

<link href="../images/16sucai_style.css" rel="stylesheet" type="text/css" />
<script type="text/javascript" src="../Inc/16sucai.js">
...[SNIP]...

6.?Cross-domain Referer leakage
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Certain
	Host:??	http://www.angeldg.com
	Path:??	/rece/CProductMain.asp

Issue detail

The page was loaded from a URL containing a query string:

http://www.angeldg.com/rece/CProductMain.asp

The response contains the following links to other domains:

http://www.gsqihang.com/
http://www.miitbeian.gov.cn/

Issue background

When a web browser makes a request for a resource, it typically adds an HTTP header, called the "Referer" header, indicating the URL of the resource from which the request originated. This occurs in numerous situations, for example when a web page loads an image or script, or when a user clicks on a link or submits a form.

If the resource being requested resides on a different domain, then the Referer header is still generally included in the cross-domain request. If the originating URL contains any sensitive information within its query string, such as a session token, then this information will be transmitted to the other domain. If the other domain is not fully trusted by the application, then this may lead to a security compromise.

You should review the contents of the information being transmitted to other domains, and also determine whether those domains are fully trusted by the originating application.

Today's browsers may withhold the Referer header in some situations (for example, when loading a non-HTTPS resource from a page that was loaded over HTTPS, or when a Refresh directive is issued), but this behavior should not be relied upon to protect the originating URL from disclosure.

Note also that if users can author content within the application then an attacker may be able to inject links referring to a domain they control in order to capture data from URLs used within the application.

Issue remediation

Applications should never transmit any sensitive information within the URL query string. In addition to being leaked in the Referer header, such information may be logged in various locations and may be visible on-screen to untrusted parties.

Vulnerability classifications

CWE-200: Information Exposure

Request

Response

HTTP/1.1 200 OK
Connection: close
Date: Thu, 20 Dec 2018 13:11:05 GMT
Server: WWW Server/1.1
X-Powered-By: ASP.NET
Content-Length: 26677
Content-Type: text/html
Cache-control: private
X-Safe-Firewall: zhuji.360.cn 1.0.9.47 F1W1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script src="/Inc/jquery.js"></script>
<html xmlns="http://www.w3.org/1999
...[SNIP]...
<td height="50" class="white">Copyright © 2018 www.angeldg.com  All Rights Reserved  ................................<a href="http://www.miitbeian.gov.cn/" target="_blank">..ICP..14000628..-1</a>............<a href="http://www.gsqihang.com" target="_blank">........</a>
...[SNIP]...

7.?Frameable response (potential Clickjacking)
Previous??Next?

There are 4 instances of this issue:

/Rece/UserLogin.asp
/Rece/UserRegister.asp
/rece/CProductMain.asp
/rece/index.asp

Issue description

If a page fails to set an appropriate X-Frame-Options or Content-Security-Policy HTTP header, it might be possible for a page controlled by an attacker to load it within an iframe. This may enable a clickjacking attack, in which the attacker's page overlays the target application's interface with a different interface provided by the attacker. By inducing victim users to perform actions such as mouse clicks and keystrokes, the attacker can cause them to unwittingly carry out actions within the application that is being targeted. This technique allows the attacker to circumvent defenses against cross-site request forgery, and may result in unauthorized actions.

Note that some applications attempt to prevent these attacks from within the HTML page itself, using "framebusting" code. However, this type of defense is normally ineffective and can usually be circumvented by a skilled attacker.

You should determine whether any functions accessible within frameable pages can be used by application users to perform any sensitive actions within the application.

Issue remediation

To effectively prevent framing attacks, the application should return a response header with the name?X-Frame-Options?and the value?DENY?to prevent framing altogether, or the value?SAMEORIGIN?to allow framing only by pages on the same origin as the response itself. Note that the SAMEORIGIN header can be partially bypassed if the application itself can be made to frame untrusted websites.

References

X-Frame-Options

Vulnerability classifications

CWE-693: Protection Mechanism Failure

7.1.?http://www.angeldg.com/Rece/UserLogin.asp
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Firm
	Host:??	http://www.angeldg.com
	Path:??	/Rece/UserLogin.asp

Request

Response

7.2.?http://www.angeldg.com/Rece/UserRegister.asp
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Firm
	Host:??	http://www.angeldg.com
	Path:??	/Rece/UserRegister.asp

Request

Response

7.3.?http://www.angeldg.com/rece/CProductMain.asp
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Firm
	Host:??	http://www.angeldg.com
	Path:??	/rece/CProductMain.asp

Request

Response

7.4.?http://www.angeldg.com/rece/index.asp
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Firm
	Host:??	http://www.angeldg.com
	Path:??	/rece/index.asp

Request

Response

8.?HTML does not specify charset
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Certain
	Host:??	http://www.angeldg.com
	Path:??	/Rece/UserLoginFinish.asp

Issue description

If a response states that it contains HTML content but does not specify a character set, then the browser may analyze the HTML and attempt to determine which character set it appears to be using. Even if the majority of the HTML actually employs a standard character set such as UTF-8, the presence of non-standard characters anywhere in the response may cause the browser to interpret the content using a different character set. This can have unexpected results, and can lead to cross-site scripting vulnerabilities in which non-standard encodings like UTF-7 can be used to bypass the application's defensive filters.

In most cases, the absence of a charset directive does not constitute a security flaw, particularly if the response contains static content. You should review the contents of affected responses, and the context in which they appear, to determine whether any vulnerability exists.

Issue remediation

For every response containing HTML content, the application should include within the Content-type header a directive specifying a standard recognized character set, for example?charset=ISO-8859-1.

Vulnerability classifications

CWE-16: Configuration
CWE-436: Interpretation Conflict

Request

Response

9.?HTML uses unrecognized charset
Previous?

There are 4 instances of this issue:

/Rece/UserLogin.asp
/Rece/UserRegister.asp
/rece/CProductMain.asp
/rece/index.asp

Issue background

Applications may specify a non-standard character set as a result of typographical errors within the code base, or because of intentional usage of an unusual character set that is not universally recognized by browsers. If the browser does not recognize the character set specified by the application, then the browser may analyze the HTML and attempt to determine which character set it appears to be using. Even if the majority of the HTML actually employs a standard character set such as UTF-8, the presence of non-standard characters anywhere in the response may cause the browser to interpret the content using a different character set. This can have unexpected results, and can lead to cross-site scripting vulnerabilities in which non-standard encodings like UTF-7 can be used to bypass the application's defensive filters.

In most cases, the absence of a valid charset directive does not constitute a security flaw, particularly if the response contains static content. You should review the contents of affected responses, and the context in which they appear, to determine whether any vulnerability exists.

Issue remediation

Vulnerability classifications

CWE-16: Configuration
CWE-436: Interpretation Conflict

9.1.?http://www.angeldg.com/Rece/UserLogin.asp
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Tentative
	Host:??	http://www.angeldg.com
	Path:??	/Rece/UserLogin.asp

Issue detail

The response specifies that its MIME type is HTML. However, it specifies a charset that is not commonly recognized as standard. The following charset directive was specified:

gb2312

Request

Response

HTTP/1.1 200 OK
Connection: close
Date: Thu, 20 Dec 2018 13:11:19 GMT
Server: WWW Server/1.1
X-Powered-By: ASP.NET
Content-Length: 16583
Content-Type: text/html
Cache-control: private
X-Safe-Firewall: zhuji.360.cn 1.0.9.47 F1W1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script src="/Inc/jquery.js"></script>
<html xmlns="http://www.w3.org/1999
...[SNIP]...
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
<link rel="shortcut icon" href="../Images/favicon.ico">
...[SNIP]...

9.2.?http://www.angeldg.com/Rece/UserRegister.asp
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Tentative
	Host:??	http://www.angeldg.com
	Path:??	/Rece/UserRegister.asp

Issue detail

The response specifies that its MIME type is HTML. However, it specifies a charset that is not commonly recognized as standard. The following charset directive was specified:

gb2312

Request

Response

9.3.?http://www.angeldg.com/rece/CProductMain.asp
Previous??Next?

Summary

?	Severity:??	Information
	Confidence:??	Tentative
	Host:??	http://www.angeldg.com
	Path:??	/rece/CProductMain.asp

Issue detail

The response specifies that its MIME type is HTML. However, it specifies a charset that is not commonly recognized as standard. The following charset directive was specified:

gb2312

Request

Response

HTTP/1.1 200 OK
Connection: close
Date: Thu, 20 Dec 2018 13:11:05 GMT
Server: WWW Server/1.1
X-Powered-By: ASP.NET
Content-Length: 26677
Content-Type: text/html
Cache-control: private
X-Safe-Firewall: zhuji.360.cn 1.0.9.47 F1W1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script src="/Inc/jquery.js"></script>
<html xmlns="http://www.w3.org/1999
...[SNIP]...
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
<link rel="shortcut icon" href="../Images/favicon.ico">
...[SNIP]...

9.4.?http://www.angeldg.com/rece/index.asp
Previous?

Summary

?	Severity:??	Information
	Confidence:??	Tentative
	Host:??	http://www.angeldg.com
	Path:??	/rece/index.asp

Issue detail

The response specifies that its MIME type is HTML. However, it specifies a charset that is not commonly recognized as standard. The following charset directive was specified:

gb2312

Request

Response

HTTP/1.1 200 OK
Connection: close
Date: Thu, 20 Dec 2018 13:19:23 GMT
Server: WWW Server/1.1
X-Powered-By: ASP.NET
Content-Length: 42402
Content-Type: text/html
Cache-control: private
X-Safe-Firewall: zhuji.360.cn 1.0.9.47 F1W1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script src="/Inc/jquery.js"></script>
<html xmlns="http://www.w3.org/1999/x
...[SNIP]...
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
<link rel="shortcut icon" href="../Images/favicon.ico">
...[SNIP]...

Report generated by Burp Suite?web vulnerability scanner?v1.7.26, at Thu Dec 20 23:01:39 CST 2018.

轉載于:https://www.cnblogs.com/xinxianquan/p/10140568.html

總結

以上是生活随笔為你收集整理的Burp Scanner Report的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：光刻机：半导体工业最耀眼的明珠
下一篇： stc15系列c语言pwm编程,STC单

编程问答

Burp Scanner Report

Burp Scanner Report

Summary

Contents

Issue background

Issue remediation

Vulnerability classifications

Summary

Issue detail

Request

Response

Summary

Issue detail

Request

Response

Issue background

Issue remediation

Vulnerability classifications

Summary

Issue detail

Request

Response

Summary

Issue detail

Request

Response

Summary

Issue detail

Issue background

Issue remediation

Vulnerability classifications

Request

Response

Summary

Issue description

Issue remediation

References

Vulnerability classifications

Issue background

Issue remediation

References

Vulnerability classifications

Summary

Issue detail

Request

Response

Summary

Issue detail

Request

Response

Summary

Issue detail

Request

Response

Summary

Issue detail

Request

Response

Summary

Issue detail

Issue background

Issue remediation

Vulnerability classifications

Request

Response

Issue description

Issue remediation

References

Vulnerability classifications

Summary

Request

Response

Summary

Request

Response

Summary

Request

Response

Summary