标签：iba   ocs   vcl   position   domain   exe   otf   rri   osi   

1、使用application web 漏洞平台，除此之外还有一款类似的工具 叫做mulidata

2、配置之前的问题处理

        安装之前要确认 自己之前是否安装过 Apache或者PHP解释器或者MySQL ，如果之前安群众了

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.

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
		0	1	2	3	4
Severity	High
	Medium
	Low

Contents

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

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

Response

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

Summary

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

Response

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

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

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

3. Content type incorrectly stated
Previous  Next 

Summary

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

Response

4. Unencrypted communications
Previous  Next 

Summary

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:

1. 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").
2. 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.
3. 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.
4. 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.
5. 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

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

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

Summary

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

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

Summary

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

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

Summary

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

6. Cross-domain Referer leakage
Previous  Next 

Summary

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

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

Request

Response

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

Summary

Request

Response

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

Summary

Request

Response

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

Summary

Request

Response

8. HTML does not specify charset
Previous  Next 

Summary

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

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

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

Summary

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.2. http://www.angeldg.com/Rece/UserRegister.asp
Previous  Next 

Summary

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

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.4. http://www.angeldg.com/rece/index.asp
Previous 

Summary

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

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

Burp Scanner Report

标签：iba   ocs   vcl   position   domain   exe   otf   rri   osi   

原文地址：https://www.cnblogs.com/xinxianquan/p/10140568.html