Threat Class :Content Spoofing
Reason :The test result seems to indicate a vulnerability because the test response contained a link to the file "WF_XSRF.html".
Technical Description :The software constructs all or part of a command, data structure, or record using externally-influenced input, but fails to neutralize elements that could modify how it is parsed or interpreted.
Link Injection is the modifying of the content of a site by embedding in it a URL to an external site, or to a script in the vulnerable site. After embedding the URL in the vulnerable site, an attacker is able to use it as a platform to launch attacks against other sites, as well as against the vulnerable site itself.
Some of these possible attacks require the user to be logged in to the site during the attack. By launching these attacks from the vulnerable site itself, the attacker increases the chances of success, because the user is more likely to be logged in.
The Link Injection vulnerability is a result of insufficient user input sanitization, the input being later returned to the user in the site response. The resulting ability to inject hazardous characters into the response makes it possible for attackers to embed URLs, among other possible content modifications.
Below is an example for a Link Injection (We will assume that site "www.vulnerable.com" has a parameter called "name", which is used to greet users).
The following request:
HTTP://www.vulnerable.com/greet.asp?name=John Smith
Will yield the following response:
However, a malicious user may send the following request:
HTTP://www.vulnerable.com/greet.asp?name=
This will return the following response:
As this example shows, it is possible to cause a user's browser to issue automatic requests to virtually any site the attacker desires. As a result, Link Injection vulnerability can be used to launch several types of attack:
[-] Cross-Site Request Forgery
[-] Cross-Site Scripting
[-] Phishing
Risk :It is possible to persuade a naive user to supply sensitive information such as username, password, credit card number, social security number etc. It may be possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user It is possible to upload, modify or delete web pages, scripts and files on the web server
Mitigation: There are several mitigation techniques:
[1] Strategy: Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to occur, or provides constructs that make it easier to avoid.
Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
[2] Understand the context in which your data will be used, and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
Parts of the same output document may require different encodings, which will vary depending on whether the output is in the:
[-] HTML body
[-] Element attributes (such as src="XYZ")
[-] URIs
[-] JavaScript sections
[-] Cascading Style Sheets and style property
Note that HTML Entity Encoding is only appropriate for the HTML body.
Consult the XSS Prevention Cheat Sheet
for more details on the types of encoding and escaping that are needed.
[3] Strategy: Identify and Reduce Attack Surface
Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
[4] Strategy: Output Encoding
For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing the web page encoding. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.
[5] Strategy: Identify and Reduce Attack Surface
To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
[6] Strategy: Input Validation
Assume all input is malicious. Use an "accept known good" input validation strategy: a whitelist of acceptable inputs that strictly conform to specifications. Reject input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on a blacklist of malicious or malformed inputs. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
When dynamically constructing web pages, use stringent whitelists that limit the character set based on the expected value of the parameter in the request. All input should be validated and cleansed: not only parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so on. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. It is common to see data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.
Note that proper output encoding, escaping, and quoting is the most effective solution for preventing XSS, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent XSS, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, in a chat application, the heart emoticon ("<3") would likely pass the validation step, since it is commonly used. However, it cannot be directly inserted into the web page because it contains the "<" character, which would need to be escaped or otherwise handled. In this case, stripping the "<" might reduce the risk of XSS, but it would produce incorrect behavior because the emoticon would not be recorded. This might seem to be a minor inconvenience, but it would be more important in a mathematical forum that wants to represent inequalities.
Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.
Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.
Threat Class :Content Spoofing Reason :The test result seems to indicate a vulnerability because the test response contained a link to the file "WF_XSRF.html". Technical Description :The software constructs all or part of a command, data structure, or record using externally-influenced input, but fails to neutralize elements that could modify how it is parsed or interpreted. Link Injection is the modifying of the content of a site by embedding in it a URL to an external site, or to a script in the vulnerable site. After embedding the URL in the vulnerable site, an attacker is able to use it as a platform to launch attacks against other sites, as well as against the vulnerable site itself. Some of these possible attacks require the user to be logged in to the site during the attack. By launching these attacks from the vulnerable site itself, the attacker increases the chances of success, because the user is more likely to be logged in. The Link Injection vulnerability is a result of insufficient user input sanitization, the input being later returned to the user in the site response. The resulting ability to inject hazardous characters into the response makes it possible for attackers to embed URLs, among other possible content modifications. Below is an example for a Link Injection (We will assume that site "www.vulnerable.com" has a parameter called "name", which is used to greet users). The following request: HTTP://www.vulnerable.com/greet.asp?name=John Smith Will yield the following response: However, a malicious user may send the following request: HTTP://www.vulnerable.com/greet.asp?name=
This will return the following response:
As this example shows, it is possible to cause a user's browser to issue automatic requests to virtually any site the attacker desires. As a result, Link Injection vulnerability can be used to launch several types of attack:
[-] Cross-Site Request Forgery
[-] Cross-Site Scripting
[-] Phishing
Risk :It is possible to persuade a naive user to supply sensitive information such as username, password, credit card number, social security number etc. It may be possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user It is possible to upload, modify or delete web pages, scripts and files on the web server
Mitigation: There are several mitigation techniques: [1] Strategy: Libraries or Frameworks Use a vetted library or framework that does not allow this weakness to occur, or provides constructs that make it easier to avoid. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket. [2] Understand the context in which your data will be used, and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: [-] HTML body [-] Element attributes (such as src="XYZ") [-] URIs [-] JavaScript sections [-] Cascading Style Sheets and style property Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed. [3] Strategy: Identify and Reduce Attack Surface Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls. [4] Strategy: Output Encoding For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing the web page encoding. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping. [5] Strategy: Identify and Reduce Attack Surface To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set. [6] Strategy: Input Validation Assume all input is malicious. Use an "accept known good" input validation strategy: a whitelist of acceptable inputs that strictly conform to specifications. Reject input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on a blacklist of malicious or malformed inputs. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue." When dynamically constructing web pages, use stringent whitelists that limit the character set based on the expected value of the parameter in the request. All input should be validated and cleansed: not only parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so on. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. It is common to see data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended. Note that proper output encoding, escaping, and quoting is the most effective solution for preventing XSS, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent XSS, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, in a chat application, the heart emoticon ("<3") would likely pass the validation step, since it is commonly used. However, it cannot be directly inserted into the web page because it contains the "<" character, which would need to be escaped or otherwise handled. In this case, stripping the "<" might reduce the risk of XSS, but it would produce incorrect behavior because the emoticon would not be recorded. This might seem to be a minor inconvenience, but it would be more important in a mathematical forum that wants to represent inequalities. Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address. Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.
https://preprod.armorcode.ai/#/findings/3505723