Configure Attack Modules

Anonymous Access module checks if access is enabled without providing credentials.

The presence of this vulnerability allows any user to access or post content without providing a user name/password or security token challenge.

Recommendations

Disable Anonymous Authentication in the server configuration.

Details

• ModuleId - C0B05B9C-3343-41B1-80D2-494235FF8F99
• Type - Vulnerability
• Active or Passive - Active

The Apache Struts 2 Framework Checks module checks the application for vulnerabilities that are specific to the Apache Struts 2 framework.

Apache Struts version 2.5.12 and earlier, as well as 2.3.33 and earlier have multiple vulnerabilities.

Recommendations

Upgrade to Apache Struts version 2.5.13 or 2.3.34.

Details

• ModuleId - 59597A25-A950-4D5A-AD20-B74A4DCCABB7
• Type - Vulnerability
• Active or Passive - Active

Attempts to detect use of Apache Struts.

Older versions of Apache Struts have known vulnerabilities. It is not generally possible to detect which version is in use, but servers should be upgraded to the most recent release for maximum security.

Recommendations

Ensure that the version of struts used is not an older version with known vulnerabilities. Use the most recent version, to maximize security.

Details

• ModuleId - 9F6600FB-2E78-40E4-8B15-6790FEFAC10A
• Type - Best Practice
• Active or Passive - Passive

Arbitrary File Upload module checks the application for vulnerabilities that allows to upload file. The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system, forwarding attacks to backend systems, and simple defacement. It depends on what the application does with the uploaded file, including where it is stored.

It has proven possible to use file upload facilities made available by the web application to upload an executable application to the server.

Recommendations

Intercept file upload attempts and ensure that only the intended types are being uploaded before allowing the upload to succeed.

Details

• ModuleId - 929E08F6-0E08-4936-B12C-984ED0F5F47C
• Type - Vulnerability
• Active or Passive - Active

ASP.NET Serialization security module checks for serialized binary objects.

Asp.Net Serialization is the technique used by an ASP.NET Web page to persist changes to the state of a binary object. By default, binary data is encoded using base64 encoding.

Serialized data can potentially be intercepted and read by malicious users. Furthermore, in some cases controls might use serialized data for internal processing, so a malicious code may be processed on the web server

Recommendations

• Controls might use serialized data to store information that no users should have access to. For example, the page might contain a data-bound control that stores item identifiers (data keys) in view state. If those identifiers contain sensitive data, such as social security numbers or customer IDs, you should encrypt the serialized data.
• It is also important that you continually keep your Web server computer up to date with the latest security updates for Microsoft Windows and Internet Information Services (IIS).

Details

• ModuleId - B7CEE386-C7C6-4618-A510-F3F8FED5400B
• Type - Vulnerability
• Active or Passive - Active

Checks autocomplete form input control attribute

HTML forms are a key component to exchanging information between a user and the server. Browser feature of remembering what you entered in previous text form fields with the same name.

So, for example, if the field is named 'name' and you had entered several variants of your name in other fields named name, then autocompletion provides those options in a dropdown.

Recommendations

The password autocomplete should always be disabled, especially in sensitive applications, since an attacker, if able to access the browser cache, could easily obtain the password in cleartext (public computers are a very notable example of this attack).

You can turn it off by setting AUTOCOMPLETE to OFF:

 
1
input autocomplete="off" name="oPassword" type="password"

Details

• ModuleId - 865E5CE0-E514-4D3E-899B-825EC8603969
• Type - Best Practice
• Active or Passive - Passive

Browser Cache directive (web application performance) module checks responses for missing cache directives.

The response does not include cache directives, so an user receives this page from the server every time. That could mean a significant increase in server load, so that every hit to the page will generate a request to the server. The page does not contain any sensitive information, also it is accessible to unautorized users.

By default, a response is cacheable if the requirements of the request method, request header fields, and the response status indicate that it is cacheable. Therefore, the browser has a capability to temporarily store some of the pages browsed. These cached files are stored in a folder. When we ask for these pages again, the browser displays them from its cache.

Recommendations

Put a Cache-Control directive, freshness indicator, on the page, so it is sent with each of the original responses. As a result the browser can pull the files directly from the browser cache on subsequent requests without any need for server validation until the expires time assigned to the object is reached.

A correct cache MUST respond to a request with the most up-to-date response held by the cache that is appropriate to the request.

Do not force the browser to store the page if it contains any sensitive information.

Details

• ModuleId - 13B4C758-BA17-4200-885A-29CBA7346165
• Type - Best Practice
• Active or Passive - Passive

Browser Cache directive module checks for leaking sensitive information in browser cache. The response browser cache headers allow response caching. If the response contains sensitive information then it may be leaked into the browser cache. By default, a response is cacheable if the requirements of the request method, request header fields, and the response status indicate that it is cacheable.

Finally, unless specifically constrained by a cache-control directive, a caching system MAY always store a successful response as a cache entry, MAY return it without validation if it is fresh, and MAY return it after successful validation. If there is neither a cache validator nor an explicit expiration time associated with a response, we do not expect it to be cached, but certain caches MAY violate this expectation (for example, when little or no network connectivity is available).

A client can usually detect that such a response was taken from a cache by comparing the Date header to the current time. Therefore, the browser has a capability to temporarily store some of the pages browsed. These cached files are stored in a folder. When we ask for these pages again, the browser displays them from its cache. Logging out from an application obviously does not clear the browser cache of any sensitive information that might have been stored.

Recommendations

Update Cache-Control http header to include no-store directive. The purpose of this directive is to prevent the inadvertent release or retention of sensitive information.

The suggested HTTP response headers are:

• Cache-Control: no-cache, no-store
• Expires: 0
• Pragma: no-cache

Details

• ModuleId - 865E5CE0-E514-4D3E-899B-825EC8603969
• Type - Best Practice
• Active or Passive - Passive

HTTP Authentication Brute Force module checks the application for vulnerabilities that allows an attacker to retrieve a valid user account and password, by trying to enumerate many (i.e. dictionary attack) or all the possible candidates.

Recommendations

• Enforce a strong password security policy.
• Require that all passwords have a suitable minimum length.
• Require that all passwords have a suitable complexity, using mixed-case alphanumeric content.
• Require that all passwords expire periodically and have suitable rules for re-use of previously expired passwords.

Details

• ModuleId - A8091DB7-769C-49ED-9E84-4B9F19529AC1
• Type - Vulnerability
• Active or Passive - Active

A valid username and password combination was discovered for the application. Default passwords and trivial passwords expose an application to unauthorized access. If a user chooses a very insecure password, then that user's account information can be compromised and the account can be used to attempt to compromise the application.

Recommendations

• Enforce a strong password security policy.
• Require that all passwords have a suitable minimum length.
• Require that all passwords have a suitable complexity, using mixed-case alphanumeric content.
• Require that all passwords expire periodically and have suitable rules for re-use of previously expired passwords.

Details

• ModuleId - 7F61DDD5-22C5-439B-9EAB-4FC17B2F47AA
• Type - Vulnerability
• Active or Passive - Active

What is Blind SQL Injection?

Blind SQL injection techniques analyze the application's response to parameter values that are designed to be interpreted and executed by a database. These requests contain arguments that are not being caught by input validation filters. The application submits the original payload to the database, where the database interprets the payload as a valid SQL query. This implies that arbitrary SQL commands may be executed through this parameter value.

During a Blind SQL attack, multiple differing payloads are sent to the application and the results are compared with each other. These attacks are 'blind', unlike SQL Injection. No attempt is made to directly compare the responses of these attacks with a specific pattern (e.g. database error text). Instead, responses are compared with each other and any unexpected differences found imply that the database query is directly executing the payload.

Why do we need to protect against this type of vulnerability?

Very similarly to SQL injection, data can be taken or modified in the database, compromising the app. If the client is able to inject a SQL query that comes through the app service and run their own commands, the attacker will potentially have the same permissions and can do anything the app service can do, including accessing user entries or passwords. The attacker may be able to run commands on the database server, which could escalate to takeover.

How do we protect against this vulnerability?

The following recommendations are in line with the standard SQL Injection best practices:

• Primary defenses -
  • Verify that user data cannot modify the meaning of commands and queries sent to any site or software package invoked by the application.
  • Check the code that processes input and output parameters or data.
  • Escape all user supplied input.
• Additional defenses -
  • Apply principle of least privilege: To minimize the potential damage of a successful Blind SQL injection attack, you should minimize the privileges assigned to every database account in your environment. Do not assign DBA or admin type access rights to your application accounts. We understand that this is convenient, but it comes with a high level of risk. Start from the ground up to determine what access rights your application accounts require, rather than trying to figure out what access rights you need to take away. Make sure that accounts that only need read access are only granted read access to the tables they need access to. If an account only needs access to portions of a table, consider creating a view that limits access to that portion of the data and assigning the account access to the view instead, rather than the underlying table. Rarely, if ever, grant create or delete access to database accounts.
  • Apply Input Validation.

The Rapid7 attack module attempts to search for SQL vulnerabilities through a number of different attacks. A variety of approaches are used to try to detect unsanitized data being passed to a query. For example, where a parameter has been determined to be a number, a series of logical expressions will be used to establish whether the parser within a SQL engine is executing the expression. Returned results are compared for equality or differences depending on the attack iteration. As several iterations are run, these attacks are typically slower than a normal SQL Injection attack.

Associated severity/classification

The risk associated with this is High.

OWASP 2021: A03

Details

• ModuleId - 22E85EEA-6883-4039-82D8-C298AEBC935A
• Type - Vulnerability
• Active or Passive - Active

What is Blind NoSQL Injection?

Blind NoSQL injection techniques analyze the application's response to parameter values that are designed to be interpreted and executed by a database. These requests contain arguments that are not being caught by input validation filters. The attack technique is similar to that used for Blind SQL except the payloads are targeted against NoSQL databases (e.g. MongoDB). The application submits the original payload to the database, where the database interprets the payload as a valid NoSQL query. This implies that arbitrary NoSQL commands may be executed through this parameter value.

During a Blind NoSQL attack, multiple differing payloads are sent to the application and the results are compared with each other. These attacks are 'blind', unlike NoSQL Injection. No attempt is made to directly compare the responses of these attacks with a specific pattern (e.g. database error text). Instead, responses are compared with each other and any unexpected differences found imply that the database query is directly executing the payload.

Why do we need to protect against this type of vulnerability?

Similarly to NoSQL injection, data can be taken or modified in the NoSQL database, compromising the app. If the client is able to inject a NoSQL query that comes through the app service and run their own commands, an attacker could potentially have the same permissions and the ability to do anything the app service can do, including accessing user entries or passwords. The attacker may be able to run commands on the database server, which could escalate to takeover.

How do we protect against this vulnerability?

The following recommendations are in line with the standard SQL Injection best practices:

• Primary defenses -
  • Verify that user data cannot modify the meaning of commands and queries sent to any site or software package invoked by the application.
  • Check the code that processes input and output parameters or data.
  • Escape all user supplied input.
• Additional defenses -
  • Apply principle of least privilege: To minimize the potential damage of a successful Blind NoSQL injection attack, you should minimize the privileges assigned to every database account in your environment. Do not assign DBA or admin type access rights to your application accounts. We understand that this is convenient, but it comes with a high level of risk. Start from the ground up to determine what access rights your application accounts require, rather than trying to figure out what access rights you need to take away. Make sure that accounts that only need read access are only granted read access to the tables they need access to. If an account only needs access to portions of a table, consider creating a view that limits access to that portion of the data and assigning the account access to the view instead, rather than the underlying table. Rarely, if ever, grant create or delete access to database accounts.
  • Apply Input Validation.

The detection logic within this module attempts to search for NoSQL vulnerabilities through a number of different attacks. Two main approaches are used to try to detect unsanitized data being passed to a query. Logical substitutions are the first approach, for example, where a parameter has been determined to be a number, a series of logical expressions will be used to establish whether the parser within a NoSQL engine is executing the expression. Returned results are compared for equality or differences depending on the attack iteration. The second approach is time-based. Additions are made to the parameter value that would cause the NoSQL DB engine to sleep for varying durations. Time elapsed for responses are compared to determine a vulnerability. As several iterations are run, these attacks are typically slower than a normal NoSQL Injection attack.

Associated severity/classification

The risk associated with this is High.

OWASP 2021: A03

Details

• ModuleId - A00A59F5-3CEF-42AA-9320-B6CF5E78CA26
• Type - Vulnerability
• Active or Passive - Active

The Clients Cross-Domain Policy Files module verifies policy files for Adobe and Silverlight applications. A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. use to access data across different domains. For Silverlight, Microsoft adopted a subset of the Adobe's crossdomain.xml, and additionally created it's own cross-domain policy file: clientaccesspolicy.xml

Whenever a web client detects that a resource has to be requested from other domain, it will first look for a policy file in the target domain to determine if performing cross-domain requests, including headers, and socket-based connections are allowed. Master policy files are located at the domain's root. A client may be instructed to load a different policy file but it will always check the master policy file first to ensure that the master policy file permits the requested policy file.

Recommendations

There are several recommendations prior to deployment of a cross-domain policy file: Carefully evaluate which sites will be allowed to make cross-domain calls. Consider network topology and any authentication mechanisms that will be affected by the configuration or implementation of the cross-domain policy.

Limit the scope of the cross-domain policy to only the desired functionality by creating subdomains or virtual directories containing shared functionality.

Review any XSRF prevention mechanisms to see if they may be affected by allowing cross-domain data loading.

Details

• ModuleId - FD1C7602-70CE-493D-92F5-0C347C79218F
• Type - Best Practice
• Active or Passive - Active

Scans comments for Information Disclosure issues.

HTML comments were discovered in page content. While not necessarily vulnerable, it is too easy to inadvertently leave sensitive information (usernames, passwords, absolute paths, ...) in the page content.

Recommendations

Remove HTML comments from anything that could be pushed to the client as a webpage.

Details

• ModuleId - A41D5AC8-4259-4BF0-86E9-A96DD3353333
• Type - Best Practice
• Active or Passive - Low

Checks cookie for HttpOnly and Secure attributes. The HttpOnly attribute directs browsers to use cookies via the HTTP protocol only. An HttpOnly cookie is not accessible via non-HTTP methods, such as calls via JavaScript (e.g., referencing document.cookie), and therefore cannot be stolen easily via cross-site scripting (a pervasive attack technique). The Secure attribute is meant to keep cookie communication limited to encrypted transmission, directing browsers to use cookies only via secure/encrypted connections.

Recommendations

Whenever a cookie contains sensitive information or is a session token, then it should always be passed using an encrypted tunnel. For example, after logging into an application and a session token is set using a cookie, then verify it is tagged using the ;secure flag. If it is not, then the browser believes it safe to pass via an unencrypted channel such as using HTTP.

Details

• ModuleId - BBFCB667-79ED-4E72-92C0-8F19E9BB45DF
• Type - Best Practice
• Active or Passive - Passive

The Cross Origin Resource Sharing module verifies that the target web application serves resources to permitted origin domains. Cross-origin resource sharing (CORS) is a mechanism that allows JavaScript on a web page to make XMLHttpRequests to another domain, not the domain the JavaScript originated from. Such "cross-domain" requests would otherwise be forbidden by web browsers, per the same origin security policy. CORS defines a way in which the browser and the server can interact to determine whether or not to allow the cross-origin request. It is more useful than only allowing same-origin requests, but it is more secure than simply allowing all such cross-origin requests.

Recommendations

Web sites have various CORS countermeasures available:

1. Validate URLs passed to XMLHttpRequest.open. Current browsers allow these URLs to be cross domain; this behavior can lead to code injection by a remote attacker. Pay extra attention to absolute URLs.
2. Ensure that URLs responding with Access-Control-Allow-Origin: * do not include any sensitive content or information that might aid attacker in further attacks. Use the Access-Control-Allow-Origin header only on chosen URLs that need to be accessed cross-domain. Don't use the header for the whole domain.
3. Allow only selected, trusted domains in the Access-Control-Allow-Origin header. Prefer allowlisting domains over denylisting or allowing any domain (do not use * wildcard nor blindly return the Origin header content without any checks).
4. Keep in mind that CORS does not prevent the requested data from going to an unauthenticated location. It's still important for the server to perform usual CSRF prevention.
5. While the RFC recommends a pre-flight request with the OPTIONS verb, current implementations might not perform this request, so it's important that "ordinary" (GET and POST) requests perform any access control necessary.
6. Discard requests received over plain HTTP with HTTPS origins to prevent mixed content bugs.
7. Don't rely only on the Origin header for Access Control checks. Browser always sends this header in CORS requests, but may be spoofed outside the browser. Application- level protocols should be used to protect sensitive data.

Details

• ModuleId - 2227AE47-A2AA-40A6-B6B1-328AC13A6F0C
• Type - Best Practice
• Active or Passive - Active

Test that credentials are transported over an encrypted channel. Sending credentials over HTTP and with GET method.

Recommendations

Credentials or sensitive data is transmitted without encryption and a malicious user could read users' sensitive data by simply sniffing the net with a tool like Wireshark. HTTPS protocol ensures that data is sent through an encrypted channel and not readable by other people. GET method should never be used in a form that transmits credentials or sensitive data, because it is displayed in clear in the URL and this entails a whole set of security issues. It is strongly suggested to use the POST method instead.

Details

• ModuleId - F8A08145-8459-4965-B0AF-68B4E190F566
• Type - Vulnerability
• Active or Passive - Passive

What is Content Security Policy (CSP) Header?

CSP is a widely used standard in web development. The Content-Security-Policy declares what dynamic resources are allowed to load via a HTTP Header. These are defined as directives as part of the policy. You can find more information about the kinds of directives that might be included here.

Why do we need to protect against this type of vulnerability?

The absence of an appropriate CSP runs the risk of Cross-Site Scripting (XSS), clickjacking, and injection. XSS or code injection would result in an attacker being able to inject code which then gets unintentionally run by the end user. Clickjacking may result in the end user being tricked into clicking on a UI element or link which would direct them to a suspicious site or cause them to download malware.

If the CSP hasn't been declared either through the meta-tag or the header, the browser's trust of the content received from the server can be exploited. Malicious scripts are executed by the victim's browser because the browser trusts the source of the content, even when it's not coming from where it seems to be coming from.

How do we protect against this vulnerability?

The module reports missing Content Security Policy attributes from the http headers or html meta tags. In addition to this, the attack module looks for the use of all related best practices to CSP.

The presence of a CSP header makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those allowlisted domains, ignoring all other script (including inline scripts and event-handling HTML attributes).

Associated severity/classification

The risk associated with this is Low.

OWASP 2021: A03 (injection)

The Cross-Site Checking module tests the application for susceptibility to embedded script attacks. If the application does not filter certain HTML tags and syntax, then a user would be able to embed malicious code that targets other users. Vulnerabilities discovered by this module can result in stolen passwords, stolen Cookie values, and social engineering attacks. Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data. For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request. In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website. Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

This check corresponds to the OWASP Top-10 Vulnerability A4 (Cross-Site Scripting Flaws).

Recommendations

Web sites have various CSRF countermeasures available:

1. Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site cannot put the right token in its submissions
2. Requiring the client to provide authentication data in the same HTTP Request used to perform any operation with security implications (money transfer, etc.)
3. Limiting the lifetime of session cookies
4. Checking the HTTP Referer header
5. Ensuring that there is no clientaccesspolicy.xml file granting unintended access to Silverlight controls
6. Ensuring that there is no crossdomain.xml file granting unintended access to Flash movies
7. Verifying that the request's header contains a X-Requested-With. Used by Ruby on Rails (before v2.0) and Django (before v1.2.5). This protection has been proven unsecure under a combination of browser plugins and redirects which can allow an attacker to provide custom HTTP headers on a request to any website, hence allow a forged request.

An easy and effective solution is to use a CSRF filter such as OWASP's CSRFGuard. The filter intercepts responses, detects if it is a html document and inserts a token in to the forms and optionally inserts script to insert tokens in ajax functions. The filter also intercepts requests to check that the token is present.

Details

• ModuleId - 81C9D7ED-0E33-4478-99D5-CD20B978617B
• Type - Vulnerability
• Active or Passive - Active

The Custom Directory Module contains one example attack.

The description for the Example Directory Attack.

Recommendations

Refer to your web server's documentation for instructions.

Details

• ModuleId - 3A586D24-C653-4461-96BA-AC345FDE8C53
• Type - Best Practice
• Active or Passive - Medium

The Parameter Directory Module contains one example attack.

The description for the Example Parameter Attack.

Recommendations

Refer to your web server's documentation for instructions.

Details

• ModuleId - EE998B28-1CE8-4094-8E90-BF2D61E4C5F9
• Type - Vulnerability
• Active or Passive - Medium

The Passive Module contains one example attack.

The description for the Example Passive Attack.

Recommendations

The description for the Example Passive Attack.

Details

• ModuleId - 1DE8C004-C53D-4B89-A41E-6B98DC6FD3B4
• Type - Best Practice
• Active or Passive - Medium

The Directory Indexing module checks the application for vulnerabilities that lead to directory index listings. If the application or server can be manipulated into revealing directory information, then a user would be able to enumerate source and configuration files used by the application. Vulnerabilities discovered by this module lead to exploits that range from listing directory contents to revealing application source code. A full list of a directory's content can be viewed. This reveals each file and subdirectory, regardless of whether or not it is related to the web application. A directory listing may also reveal backup files, include files, or configuration files that are not normally viewable by users.

When these types of files can be found, they often disclose sensitive information about the application.

Recommendations

Refer to your web server's documentation for instructions on prohibiting directory listings.

Details

• ModuleId - 2CE90A40-3F70-4F80-961E-381BE19CCA2F
• Type - Vulnerability
• Active or Passive - Active

This attack modules checks for Email address Disclosure.

Recommendations

Avoid exposing user email addresses.

Details

• ModuleId - 240EBB4A-7202-4BA5-8583-3EB1F1AB4EC0
• Type - Best Practice
• Active or Passive - Passive

What is Expression Language Injection (ELi)?

An expression language is a more compact form of code. You can create expressions and hand them off to an interpreter or processor. It can get data, call methods, and pass on results. It’s a way to take some code and compact it so that it can be set as an attribute of an object. The original EL is used in JavaServer Pages (JSP) and JavaServer Faces(JSF), but other Java web technologies use their own expression languages like Object-Graph Navigation Language (OGNL) for Apache Struts, and Spring Expression Language (SpEL) for the Spring Framework.

Expression Language Injection is where an attacker is able to feed data into an expression language and have it run through an interpreter. Although ELi cannot do everything code can do, an attacker can eventually achieve remote code execution.

Why do we need to protect against this type of vulnerability?

There are a number of scenarios where ELi can occur. One example is Double resolution of expression language. In a Java program, you may have a static string that represents expression and hand this on to an interpreter. You might create an expression by using static strings, user input and then concatenating everything and sending it to the interpreter. If the data that came over the parameter looked like an expression language, it would just run it.

Resulting from this, if a user knows what kinds of objects they can get access to, they could manipulate session objects. They could also call functions that are on the backend. The attacker could obtain values for request parameters, headers, cookies, or Java bean values with sensitive data. In a worst-case scenario, the attacker could just run arbitrary commands and processes (i.e. remote code execution).

How do we protect against this vulnerability?

• When you create expressions, don’t take user data and directly pass it on to the interpreter. It’s best to avoid user controlled expressions, but if you need to use user input, be careful to check that it doesn’t contain certain characters like ‘.’, ‘’, ‘()’, or anything that could change the flow of the expression. Attackers could find a way to hijack the expression and do something malicious.
• If you're using JSP, Spring, or similar, ensure you have the right configuration and disable double resolution. Use up-to-date versions of frameworks and make sure that you're using the right configuration to disallow some of the features that can be exploited.

Rapid7 detects this by doing some straight-forward detection methods and operational tests. Specifically for JSP, we provide an expression that tries to get the application scope. We check the result to see if it could parse this and grab the application scope. We provide an expression that on its own just looks like an arbitrary expression and we look at the response to see if the expression was actually processed.

Associated severity/classification

The risk associated with this is High.

OWASP 2021: A03 (injection)

Force Browsing by manipulating parameter values. Forced browsing is an attack where the aim is to enumerate and access resources that are not referenced by the application, but are still accessible.

Recommendations

Ensure Role Based Authentication and Authorization: In web application always try to distinguish users and their roles. If a page is only made for admin, then check whether the user is admin before granting access to the page or user has permission to access the page. This makes it secure and protects against URL based forced browsing attack.

Details

• ModuleId - D07D5C8E-F866-4392-A0CC-1509A6DE5940
• Type - Vulnerability
• Active or Passive - Active

Form Session Strength module checks session identifiers, to determine if they could be vulnerable to prediction, or brute force attacks. Session tokens that exhibit low entropy ("randomness") are often susceptible to prediction attacks. Insecure tokens can be due to inadequate pseudo-random number generator, time-based values, static values, or values based on user attributes (username or user ID). This means that an attacker would be able to guess a valid session token after monitoring the application for a short period of time and gathering the session tokens it creates. If the attacker determines a valid session token for another user, then it may be possible to view, modify, or delete arbitrary users' data without having to guess the victim's username or password. Consequently, the ability to deduce valid session tokens enables the attacker to bypass login pages and obviate the need to brute force accounts.

Additionally, static tokens can enable the attacker to target users even if the victim is not currently logged into the application. This increases the pool of victims which the attacker can target. Session tokens should be created with a strong random number generator and gathered from a large pool of numbers. For example, an operating system's rand() function can usually be sufficient if it can produce 32-bit values that are a statistically uniform distribution. Poor session tokens are incremental, rely on the user's account ID, only use time stamps, or have other highly deterministic information. Other methods of protecting a session token's security are to always transmit them over SSL, automatically expire the token after a certain period of time, and explicitly expiring the token whenever a user logs out of the application.

Recommendations

• If the session values exhibit strong randomness, but are chosen from a small pool of values, then the attacker has a better chance of simply guessing a valid token. A web application's session management can be improved by implementing several complementary techniques:
• Make sure that the Token values are at least 32 bits in size, especially for applications with large numbers of concurrent users and high amounts of daily page requests.
• The bit size of the source of the entropy (random values) is more important than the bit size of the actual session token. For example, an MD5 hash produces a 128 bit value. However, the MD5 hash of incremental values, a timestamp, or 8-bit random numbers are each insecure because the source of the random values can be easily predicted. Consequently, the 128 bit size does not represent an accurate measure of the session token. The minimum size of the entropy source is 32 bits, although larger pools (48 or 64 bits) may be necessary for sites with over 10,000 concurrent users per hour.
• In most cases, application-generated tokens (e.g. ASP.NET_SessionId, ASPSESSIONID, JSPSESSIONID, PHPSESSIONID) provide sufficiently large random values to prevent session prediction attacks. The application should use these session management alogorithms unless a custom session mechanism has been thoroughly reviewed and tested.
• Track user attributes associated with the session token with server-side objects to prevent user impersonation attacks. If the application does not strictly associate a user's session token with that user's profile information, then an attacker may be able to view arbitrary information by manipulating client-side values. For example, if the application sets a strong session token, but performs SQL queries based on a "UserId" cookie, then an attacker only needs to modify the "UserId" cookie to impersonate someone else. The application would be more secure if it associated the "UserId" value with the server- side session object because the attacker would not be able to modify the value.
• Expire session tokens when the user logs out of the application or after a predetermined period of inactivity. We recommend using a 20 minute timeout for a session token, although this largely depends on the type of application and the expected usage.

Details

• ModuleId - 7B61BD81-D278-490C-9B1A-7B0568E94E30
• Type - Vulnerability
• Active or Passive - Active

Checks Microsoft FrontPage Server Extensions. Windows and Unix servers with Microsoft FrontPage Extensions installed and enabled can have their permissions misconfigured, exposing information for reading and possibly modification. The data exposed can potentially include user credentials and other private information.

Recommendations

Ensure that the FrontPage Extensions are correctly configured with permissions set to protect private information and operations.

Details

• ModuleId - 5032DAF0-D8FE-4294-B23F-0D1DAA4C0337
• Type - Vulnerability
• Active or Passive - Active

HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. This is a way for a man-in-the-middle attack where the redirect could be exploited to direct a user to a malicious site instead of the secure version of the original page.

Recommendations

HSTS header is a mechanism that web sites have to communicate to the web browsers that all traffic exchanged with a given domain must always be sent over https, this will help protect the information from being passed over unencrypted requests. Considering the importance of this security measure is important to verify that the web site using this HTTP header, in order to ensure that all the data travels encrypted from the web browser to the server. HTTP Strict Transport Security header should specify the includeSubDomains directive.

Details

• ModuleId - EBEE6CA2-515F-4FBE-B8B7-EC0197C5A74F
• Type - Best Practice
• Active or Passive - Passive

HTTP Authentication over insecure channel module validates that the authentication method used over secured channel.

Recommendations

Enable HTTP Authentication on TLS pages only. All pages which are available over non-TLS must not require user credentials. Refer to your web server's manual for information on how to enable the TLS.

Details

• ModuleId - F25AF638-7E8A-429F-8E66-4F31E2974054
• Type - Vulnerability
• Active or Passive - Passive

All pages which are available over Transport Layer Secure (TLS) must not be available over a non-TLS connection. A user may inadvertently bookmark or manually type a URL to a HTTP page (e.g. http://site.com/myaccount) within the authenticated portion of the application. If this request is processed by the application then the response, and any sensitive data, would be returned to the user over the clear text HTTP.

Recommendations

Do Not Provide Non-TLS Pages for Secure Content. All pages which are available over TLS must not be available over a non-TLS connection.

Details

• ModuleId - 60B0D575-97EF-4542-A15F-CB8D907669B0
• Type - Best Practice
• Active or Passive - Active

What is HTTP Headers?

The HTTP Headers module reports on potential vulnerabilities in relation to charset attributes and content type options that are open to attack. These include:

• Missing or undeclared charset attributes/encoding from the content type header or HTML meta tags.
• The byte-order-mark being found within the webpage.
• The page’s character set does not match the recommended set of UTF-8.

Why do we need to protect against this type of vulnerability?

A charset attribute that is set incorrectly or not set at all can cause the browser to interpret characters incorrectly, leading to consequences like display or rendering issues and potentially harmful attacks like cross-site scripting (XSS), privilege escalation, Denial of Service and more.

How do we protect against this vulnerability?

Always declare the character encoding of your document. This can be done by in-document declaration with the HTML meta tag. It is recommended to use UTF-8 as it is compatible with most modern web technologies and considered the safest charset to use. Developers should try to avoid using the byte-order mark (BOM) as it can cause compatibility issues or be interpreted by some programming languages e.g. Java. UTF-8 does not require a BOM to indicate byte order. Always ensure that your HTML code is saved in Unicode normalization form C (NFC). Ensure that the X-Content-Type-Options header is set to nosniff to avoid MIME type sniffing. Validate and sanitize user input to remove any non-allowed characters.

This module attempts to search for vulnerabilities within an application by analyzing HTML meta tags or the content-type header for issues with the charset attribute or content-types (e.g. if UTF-7 is set). Vulnerabilities will be listed depending on specific settings. For example, different content-types are checked depending on whether the X-Content-Type-Options Header is set to nosniff or not.

Associated severity/classification

The risk associated with this is Informational.

Details

• ModuleId - 55D76EB2-0CE5-4C01-856E-43223232E3DD
• Type - Vulnerability
• Active or Passive - Passive

HTTP Response splitting is a new application attack technique which can be used to execute various new attacks such as web cache poisoning, cross user defacement, hijacking pages with sensitive user information and classic, Cross-Site Scripting (XSS). These attack techniques are relevant to most web environments and is the result of the applications failure to reject illegal user input, in this case, input containing malicious or unexpected characters.

Recommendations

1. Apply robust input filtering for all user-supplied data.
2. Prevent users from supplying any special characters, such as line breaks.
3. Use output filters to strip malicious escape strings or other HTTP header keywords.

Details

• ModuleId - DE08B6DD-D872-440E-9134-7969D514CFD6
• Type - Vulnerability
• Active or Passive - Active

Use TLS or Other Strong Transport Everywhere

Unencrypted HTTP connections create a vulnerability and expose potentially sensitive information about users. This data can include browser identity, website content, search terms, and other user-submitted information. To address these concerns, many commercial organizations have already adopted HTTPS-only policies to protect visitors to their websites and services.

Recommendations

All networks, both external and internal, must utilize TLS or an equivalent transport layer security mechanism for all communication. By always using HTTPS, web services don not have to make a subjective judgment call about what's sensitive. This leaves less room for error, and makes deployment simpler and more consistent.

Details

• ModuleId - 1712CD45-3B07-4C78-A8A5-61E0ED66DD1F
• Type - Best Practice
• Active or Passive - Low

HTTP User-Agent Check is performed to understand whether user-agent sniffing is turned on.

The most common reason to perform user agent sniffing is to determine which type of device and browser is being used to access the resource in question. This information can be used by an attacker to launch a more focussed attack against a particular user, or to identify and attempt the attack deemed most likely to succeed.

Recommendations

In order to remove the risk associated with User Agent Sniffing, consider making use of a custom User agent, although be warned that making use of a custom User Agent may cause some functionality to break in certain web apps.

Details

• ModuleId - 881B35A8-4141-4BBA-A050-84A2A8CE7904
• Type - Vulnerability
• Active or Passive - Active

Checks web site content for Information Disclosure issues. A path was found in the error information returned by the server. This can give an attacker clues as to the directory topology and setup of your web application.

Recommendations

Remove all references to local path from the web application. Avoid information disclosure in response. Cleanse the web application of any form posts that allow sending binary data.

Details

• ModuleId - FD1C7602-70CE-493D-92F5-0C347C79218F
• Type - Vulnerability
• Active or Passive - Active
• Active or Passive - Passive
• Type - Best Practice

Searches response for Information Leakage. Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack. An information leak occurs when system data or debugging information leaves the program through an output stream or logging function.

Recommendations

Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.

Details

• ModuleId - E617D008-F753-4C80-8064-D2B1A4BFE81A
• Type - Vulnerability
• Active or Passive - Passive

The Java Grinder module examines the Java-based components of the application. It downloads JAR files, extracts and decompiles class files, and examines their content for security-related code. If the application places too many security-related functions in user-accessible JAR files or applets, then an attacker could reverse-engineer those functions. Vulnerabilities discovered by this module may be simple code-disclosure problems or they could be as severe as obtaining database connection strings or encryption keys. This does not correspond to a specific OWASP Top-10 Vulnerability, but it illustrates vulnerabilities of inadequate code management and protection of sensitive application data.

Recommendations

Java applets that are downloaded to users' browsers should not contain any sensitive data or functions related to authentication, database connectivity, session management, or encryption. More appropriate uses for client-side Java applets are UI enhancements or basic input validation routines. Review the java applet. If the file is not intended for client-side usage, then remove it from the document root or execute it as a server-side servlet. Examine the server's web document root and remove all .class files.

Details

• ModuleId - B86A3A67-D710-4568-98A9-009DBF6A4989
• Type - Vulnerability
• Active or Passive - Active

The module reports unintentional memory leaks in embedded client-side JavaScript sources used by the site.

Recommendations

To prevent these mistakes from happening, add 'use strict' at the beginning of your JavaScript files. This enables a stricter mode of parsing JavaScript that prevents accidental globals. Strict mode makes several changes to normal JavaScript semantics. First, It prevents, or throws errors, when relatively "unsafe" actions are taken. Second, strict mode eliminates some JavaScript silent errors by changing them to throw errors.

Details

• ModuleId - F10ACEB0-A680-4D0F-9351-6428E64B46FD
• Type - Vulnerability
• Active or Passive - Passive

LDAP Injection module checks the application for LDAP injection vulnerabilities attacks - a type of injection attack, in which LDAP commands are injected into data-plane input in order to effect the execution of predefined LDAP commands. An LDAP injection attack consists of insertion or "injection" of an LDAP query via the input data from the client to the application.

Recommendations

Several techniques can be used to block LDAP injection attacks. These techniques complement each other and address security at different points in the application. The impact of an LDAP injection attack is minimized by implementing multiple defense measures.

1. Normalize all user-supplied data before applying filters, regular expressions, or submitting the data to a database. This means that all URL-encoded (%xx), HTML-encoded (&#xx;), or other encoding schemes should be reduced to the internal character representation expected by the application. This prevents attackers from using alternate encoding schemes to bypass filters.
2. Implement positive filters that examine user-supplied data for expected characters. Define data types for user-supplied values and ensure that submitted data match these types, such as numeric or date. String or text values should be carefully matched to a limited subset of characters such as alpha, numeric, spaces, or certain punctuation characters as necessary. If any value received by the application contains an unexpected character, then it should be rejected.
3. Negative filtering can also prevent attacks, but may be more unreliable or more difficult to implement for language sets that require non-ASCII characters. Examine all data received from the web browser for LDAP syntax characters. If any of these characters are present, then they should be escaped or removed. The single quote (') or double quote (") are often used to envelope parameters in an LDAP query. Other malicious characters include the asterisk, pipe (|), ampersand, and parentheses. These characters could be used to prematurely end a query statement.
4. Avoid string concatenation for LDAP query construction. String concatenation, where the query is created programmatically by appending values together, makes an injection attack easier to accomplish because the syntax of the query can be easily disrupted by malicious characters.
5. Store user-supplied values with appropriate data types within the database. For example, dates should be stored as DATE types (if available) instead of a VARCHAR string.

Details

• ModuleId - B7FD0D45-4CB2-46AC-85A2-9AF53C27157F
• Type - Vulnerability
• Active or Passive - Active

Detects and reports usage of local and session storage. The application might leak sensitive information through local storage usage. Browser local or session storage was used to store information.

Recommendations

To prevent information leakage please verify that sensitive information is not being stored in the local or session storage.

Details

• ModuleId - FCD9A41A-D392-47C0-B45A-8D42FF7A4E5E
• Type - Best Practice
• Active or Passive - Passive

Business logic can have security flaws that allow a user to do something that isn't allowed by the business. For example, if there is a limit on reimbursement of $1000, could an attacker misuse the system to request more money than it is intended? Or, perhaps, users are supposed to do operations in a particular order, but an attacker could invoke them out of sequence. Or can a user make a purchase for a negative amount of money? Frequently, these business logic checks simply are not present in the application.

Automated tools find it hard to understand context, hence it's up to a person to perform these kinds of tests. The following two examples will illustrate how understanding the functionality of the application, the developer's intentions, and some creative "out-of-the-box" thinking can break the application's logic and pay huge dividends. The first example starts with a simplistic parameter manipulation, whereas the second is a real world example of a multi-step process leading to complete destruction of the application. (Note that this was a real world application penetration test, so complete destruction was not actually carried out but a proof of concept was done instead).

Recommendations

• Limit the degree of escalation. Do not permit a user to gain extra privilege after successful authentication, because the user is already authorized to hold some privilege.
• Setup generic response for error conditions. The error page should not disclose information about the success or failure of a sensitive operation. For instance, the login page should not confirm that the login is correct and the password incorrect.
• Obfuscate the transaction data and validate pricing with back end processing.

Details

• ModuleId - 466E4CC2-94D9-4A11-AFD5-0FD01D56261F
• Type - Vulnerability
• Active or Passive - Active

Use-after-free vulnerability in nginx web server allows remote HTTP servers to obtain sensitive information from process memory via a crafted backend response, in conjunction with a client request. An attacker embeds one or more null bytes in input to the target software. This attack relies on the usage of a null-valued byte as a string terminator in many environments. The goal is for certain components of the target software to stop processing the input when it encounters the null byte(s).

Recommendations

Use-after-free vulnerability in nginx before 1.0.14 and 1.1.x before 1.1.17 allows remote HTTP servers to obtain sensitive information from process memory via a crafted backend response, in conjunction with a client request.

Details

• ModuleId - 7D06B46D-9156-44E9-870F-4A6B903FC09F
• Type - Vulnerability
• Active or Passive - Active

What is NoSQL Injection?

The NoSQL Injection module checks the application for NoSQL Injection vulnerabilities. These occur when an application accepts malicious user input as part of a NoSQL statement to query a backend database. The query parameters get altered into data-plane input in order to affect the server side execution of attacker-predefined commands. Traditional SQL Injection techniques do not work on NoSQL databases because they use a specific query language which does not support SQL.

Why do we need to protect against this type of vulnerability?

Consequences of NoSQL attacks lead to attackers being able to view data that they are not normally able to retrieve or gain administrative access to back-end servers.

How do we protect against this vulnerability?

Protect against this vulnerability by:

• Verifying that user data cannot modify the meaning of commands and queries sent to any site or software package invoked by the application.
• Checking the code that processes input and output parameters or data.
• Escaping all user supplied input.

Additionally you can:

• Apply principle of least privilege - To minimize the potential damage of a successful NoSQL injection attack, you should minimize the privileges assigned to every database account in your environment. Do not assign DBA or admin type access rights to your application accounts. We understand that this is convenient, but it comes with a high level of risk. Start from the ground up to determine what access rights your application accounts require, rather than trying to figure out what access rights you need to take away. Make sure that accounts that only need read access are only granted read access to the tables they need access to. If an account only needs access to portions of a table, consider creating a view that limits access to that portion of the data and assigning the account access to the view instead, rather than the underlying table. Rarely, if ever, grant create or delete access to database accounts.
• Apply Input Validation.

Rapid7’s attack module searches for NoSQL vulnerabilities through a number of attacks. These attacks include a wide number of characters standardly used by NoSQL attackers to add as part of a NoSQL statement to trigger a database error. They include using special characters and also their ASCII/Unicode/USC-2 encoded versions. Responses are checked against a series of regex values to detect these errors.

Associated severity/classification

The risk associated with this is High.

OWASP 2021: A03

Details

• ModuleId - 0DB5A159-4A06-4363-BA72-9F5E8E50B04B
• Type - Vulnerability
• Active or Passive - Active

What is Command Injection?

Command injection is where an attacker is able to execute arbitrary commands on an operating system in a vulnerable application. In situations like this the application is like a pseudo system shell, executing unwanted system commands. The attacker may use it as any authorized system user. However, commands are executed with the same privileges and environment as the application has. Command injection attacks are possible in most cases because of lack of correct input data validation, which can be manipulated by the attacker (forms, cookies, HTTP headers, etc.).

Why do we need to protect against this type of vulnerability?

Command Injection attacks take two forms:

• An attacker can change the command that the program executes, so that the attacker explicitly controls what the command is.
• An attacker can change the environment in which the command executes, so that the attacker implicitly controls what the command means.

In this case we are primarily concerned with the first scenario, in which an attacker explicitly controls the command that is executed.

Command Injection vulnerabilities of this type occur when:

• Data enters the application from an untrusted source.
• The data is part of a string that is executed as a command by the application.

By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

How do we protect against this vulnerability?

Ensure you handle all user input carefully:

• Design - Where possible, use library calls rather than external processes to recreate the desired functionality.
• Implementation - Ensure that all external commands called from the program are statically created, or if they must take input from a user that the input and final line generated are vigorously checked.
• Run time - Run time policy enforcement may be used in an allowlist fashion to prevent use of any non-sanctioned commands.

The Command Injection attack module checks the application for vulnerabilities that allow an attacker to inject and execute commands specified by the attacker in the vulnerable application. The Rapid7 attack module tests for this by appending shell or system commands to a query or search form. If the change we make is returned in the response, this suggests the host system is vulnerable. We then attempt to run additional commands to see if additional information about the system can be obtained.

Associated severity/classification

The risk associated with this is High.

OWASP 2021: A03

Details

• ModuleId - 99E5E4DD-1B73-4047-B954-02FB7C76BEC3
• Type - Vulnerability
• Active or Passive - Active

When an application logs data using certain versions of Log4j (2.0-beta9 to 2.14.1), because of CVE-2021-44228, it will parse and resolve JNDI lookup strings in the data by default. This means that if an application logs any data from an untrusted source, then that source could provide a JNDI lookup string that references a malicious, remotely-hosted java object. Log4j would then deserialize and load that object into the application, resulting in Remote Code Execution (RCE) and compromise the application.

Recommendations

Though official mitigation steps are changing as new information arises, we recommend that applications upgrade Log4j to at least version 2.3.1 for Java 6, 2.12.3 for Java 7, or 2.17.0 for Java 8 and later, but preferably the latest version available to fix any new issues as they are discovered. If upgrading Log4j is not an option, the Apache Software Foundation advises that in any release other than 2.16.0, you can remove the JndiLookup class from the log4j-core class path, but we recommend only using this method when upgrading is not possible.

Details

• ModuleId - 87C67177-A0C6-45BF-A084-D1082166C32F
• Type - Vulnerability
• Active or Passive - Active

What is Out of Band SQL injection (OOB SQLi)?

OOB SQLi is a type of SQL injection. OOB is similar to SQL injection, but where it differs is the attack and collecting of data cannot be carried out using the same channel. The hacker can send the response to an endpoint of their choosing. This is made possible by certain features in the database server.

Why do we need to protect against this type of vulnerability?

Very similarly to SQL injection, data can be taken or modified in the database, compromising the app. If the client is able to inject a SQL query that comes through the app service and run their own commands, the attacker will potentially have the same permissions and can do anything the app service can do, including accessing user entries or passwords. The attacker may be able to run commands on the database server, which could escalate to takeover.

OOB SQLi can collect data by making use of DNS or HTTP requests. One example of this is the xp_dirtree command in Microsoft SQL Server, which can be used to reach out to a server of the attacker’s choosing using DNS protocol.

How do we protect against this vulnerability?

We test for this vulnerability by sending a specially crafted request that would, in the event of a vulnerable server, result in a DNS lookup being performed. Our DNS listener service watches for this lookup on our domain and uses this to determine if SQL Injection occurred.

The following steps can also be taken to protect against this vulnerability:

• Your database server should have firewalls configured to prevent outbound connections to random machines.
• In general, the database server should need to reach out to many places, other than, for example, to get Windows system updates, asset management services, vulnerability management or security tools. You should have a list of what the machine needs to reach out to.
• Appropriate validation of requests.
• Proper error handling.
• In addition, access to the database should follow the principle of least privilege.

Note: Out of band can be more easily detected than traditional SQL injection as it is noticeable when a database server is reaching out to an unfamiliar IP address. OOB SQL injection is generally more conspicuous and noisier than traditional SQL injection.

Associated severity/classification

The severity associated with OOB SQLi is High, due to the potential for access to all data within the database.

OWASP 2021: A03

Out of band allows attackers to expose local DNS records, code and data, allowing potentially devastating attacks. It has proven possible to execute a JavaScript file located on a remote server. Code vulnerable to out of band inclusion allows attackers to include remote hostile code and data to do such things as diverting users to fake sites and gathering sensitive information, or expose local code and data, allowing potentially devastating attacks.

Recommendations

Preventing out of band inclusion flaws takes some careful planning at the architectural and design phases, through to thorough testing. In general, a well-written application will not use user-supplied input in any filename for any server-based resource (such as images, XML and XSL transform documents, or script inclusions), and will have firewall rules in place preventing new outbound connections to the Internet or internally back to any other server. However, many legacy applications will continue to have a need to accept user supplied input.

Details

• ModuleId - 2934BC76-771C-4016-BD35-24B432CEBCA8
• Type - Vulnerability
• Active or Passive - Active

What is Parameter Fuzzing?

The Parameter Fuzzing module checks the application for vulnerabilities that allow manipulation of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, etc. Usually, this information is stored in cookies, hidden form fields, or URL Query Strings, and is used to increase application functionality and control.

Why do we need to protect against this type of vulnerability?

An invalid character submitted in a URL parameter causes an error in the database query or script execution. This indicates that the application has not fully validated user-supplied input. These errors can lead to HTML injection, SQL injection, or arbitrary code execution.

How do we protect against this vulnerability?

• Normalize all user-supplied data before applying filters, regular expressions, or submitting the data to a database. This means that all URL-encoded (%xx), HTML-encoded (&#xx;), or other encoding schemes should be reduced to the internal character representation expected by the application. This prevents attackers from using alternate encoding schemes to bypass filters.
• Implement positive filters that examine user-supplied data for expected characters. Define data types for user-supplied values and ensure that submitted data match these types, such as numeric or date. String or text values should be carefully matched to a limited subset of characters such as alpha, numeric, spaces, or certain punctuation characters as necessary. If any value received by the application contains an unexpected character, then it should be rejected. Negative filtering can also prevent attacks, but may be more unreliable or more difficult to implement for language sets that require non-ASCII characters.
• Examine all data received from the web browser for SQL syntax characters. If any of these characters are present, then they should be escaped or removed. The single quote (') or double quote (") are often used to envelope parameters in a SQL query. Other malicious characters include the asterisk, semi-colon, dash (minus sign), and parentheses. These characters could be used to prematurely end a query statement.

The Rapid7 Parameter Fuzzing module checks the application for vulnerabilities that allow manipulation of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, etc. Usually, this information is stored in cookies, hidden form fields, or URL Query Strings, and is used to increase application functionality and control. An invalid character submitted in a URL parameter causes an error in the database query or script execution. This indicates that the application has not fully validated user-supplied input. These errors can lead to HTML injection, SQL injection, or arbitrary code execution. The attack involves attempting to inject malicious characters into data input locations in the request from client to server. When such unsanitized input is used to dynamically generate requests, execution can result in unexpected behavior.

Associated severity/classification

The risk associated with this is Informational.

Details

• ModuleId - A8AB603E-ABC0-4875-A5B2-320CF6990C24
• Type - Vulnerability
• Active or Passive - Active

Authentication information stored in cleartext in a cookie. The application stores sensitive information in cleartext in a cookie.

Recommendations

Because the information is stored in cleartext, attackers could potentially read it. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

Details

• ModuleId - FAC53175-FF1E-4478-AA6D-3E2DD4D66B6D
• Type - Vulnerability
• Active or Passive - Passive

Website collects sensitive personal information. The software collects sensitive personal information or security-critical data. Examples: Driver’s License Number, Nationally-Issued Identification Number, State or Province-Issued Identification Number, Social Security Number, Taxpayer Identification Number, Credit Card Number.

Recommendations

If the collection of personal information is not required and violates a policy directive, do not collect it.

Details

• ModuleId - 243C315A-46A1-4C92-A271-7A29A4290167
• Type - Best Practice
• Active or Passive - Passive

PHP Code Execution module checks the application for vulnerabilities that allows manipulation of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, etc. Usually, this information is stored in cookies, hidden form fields, or URL Query Strings, and is used to increase application functionality and control.

Recommendations

Normalize all user-supplied data before applying filters, regular expressions, or submitting the data to a database. This means that all URL-encoded (%xx), HTML-encoded (&#xx;), or other encoding schemes should be reduced to the internal character representation expected by the application. This prevents attackers from using alternate encoding schemes to bypass filters. Implement positive filters that examine user-supplied data for expected characters. Define data types for user-supplied values and ensure that submitted data match these types, such as numeric or date. String or text values should be carefully matched to a limited subset of characters such as alpha, numeric, spaces, or certain punctuation characters as necessary. If any value received by the application contains an unexpected character, then it should be rejected. Negative filtering can also prevent attacks, but may be more unreliable or more difficult to implement for language sets that require non-ASCII characters. Examine all data received from the web browser for SQL syntax characters. If any of these characters are present, then they should be escaped or removed. The single quote (') or double quote (") are often used to envelope parameters in a SQL query. Other malicious characters include the asterisk, semi-colon, dash (minus sign), and parentheses. These characters could be used to prematurely end a query statement.

Details

• ModuleId - B97A2968-3AEE-4AA2-B94F-C26BFC2694A9
• Type - Vulnerability
• Active or Passive - Active

Checks response for privacy disclosure issues.

A privacy information was found on the site.

Recommendations

Avoid exposing user private data.

Details

• ModuleId - AFF041E3-8E44-4889-B271-CDE1B24378EA
• Type - Best Practice
• Active or Passive - Low

Checks for cookie usage transparency. Natural persons may be associated with online identifiers such as cookie identifiers. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.

Recommendations

Enforce a privacy policy to get consent from users to store or retrieve any information on a computer.

Details

• ModuleId - FF01402D-B708-48D8-8ACB-0736B6E4BCF5
• Type - Best Practice
• Active or Passive - Active

Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed, and such elevation/changes should have been prevented by the application. This is usually caused by a flaw in the application. The result is that the application performs actions with more privileges than those intended by the developer or system administrator.

Details

• ModuleId - 433C43A5-4C71-4F08-B822-B7932D410A78
• Type - Best Practice
• Active or Passive - Active and Passive

Searches response for profanity.

Profanity was found on the website.

Recommendations

Cleanse the web application of any profanity.

Details

• ModuleId - ED2E98EF-F9A1-4BF7-ACA0-6A7B28FF97BE
• Type - Best Practice
• Active or Passive - Passive

Reflection analysis

Dangerous character was reflected in response. This can indicate a potential XSS vulnerability.

Recommendations

Escape all dangerous characters.

Details

• ModuleId - 0AE25E41-D6F4-4F29-9001-04EF86B04191
• Type - Best Practice
• Active or Passive - Active

What is File Inclusion?

The File Inclusion module attempts to determine whether a web application or API allows local or remote file inclusion (LFI/RFI). File Inclusion allows attackers to include remote hostile code, or expose local data.

Why do we need to protect against this type of vulnerability?

Consequences of File Inclusion includes exposure of private information, leaking of system configuration details or installation/execution of external code. File Inclusion occurs often with manipulation of a URL or local file and/or path. Code becomes vulnerable to file inclusion (RFI/LFI) through design/implementation errors, usually inadequate input validation.

File Inclusion (RFI/LFI) allows attackers to include remote hostile code and data, or expose local code and data, allowing potentially devastating attacks. Code vulnerable to file inclusion (RFI/LFI) allows attackers to include remote hostile code and data, or expose local code and data, allowing potentially devastating attacks.

How do we protect against this vulnerability?

Preventing file inclusion (RFI/LFI) flaws takes some careful planning at the architectural and design phases. In general, a well-written application does not use user-supplied input in any filename for any server-based resource (such as images, XML and XSL transform documents, or script inclusions), and has Web Application Firewall (WAF) technology in place preventing new outbound connections to the Internet or internally back to any other server. However, many legacy applications continue to have a need to accept user supplied input. If inputs are to be used, whitelists should be employed to ensure that unexpected resources cannot be requested.

The Rapid7 attack module attempts to search for file inclusion vulnerabilities both locally and remotely. For local vulnerabilities, the scanner searches the directories for specific file locations that should contain confidential information within system files. For Remote vulnerabilities. We create a HTTP request by targeting a URL that contains a specific phrase. If the scanner detects this phrase, the remote file inclusion has worked correctly and a vulnerability is noted. The scanner also focuses on PHP file inclusion, attempting to identify weaknesses through common parameters or known vulnerabilities.

Associated severity/classification

The risk associated with this is Medium/High.

Details

• ModuleId - 8CB2F93C-E7F2-43B9-8D3C-83A9A3E6EA4B
• Type - Vulnerability
• Active or Passive - Active

HTTP Verb Tampering is an attack that is generally used in conjunction with syntactic and semantic attacks as way to bypass certain defense measures. A page which is expecting only GET requests, receives a POST. This attack module builds a custom POST request and sends it to a page which has been accessed by GET requests. When an application does not properly handle user supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. By requesting the link with a modified http verb, the page renders the parameter values.

Recommendations

Some resources may allow both GET and POST methods e.g. an edit form may be hyperlinked using a parameter value defining the record to be edited, but the form is submitted by POST to itself. Users may bookmark a page that is the result of a POST and return to it at a later date. To protect yourself from syntactic HTTP verb manipulation attacks, make sure you only include user-supplied data from where it’s expected to be received (Query string or POST data), or sanity check them both the same if necessary. Also only include the parameter names in the session object you expect to receive. Don’t allow attackers to add arbitrary name/value pairs.

Details

• ModuleId - 63430695-B689-41DF-99BF-242F5AE1674B
• Type - Vulnerability
• Active or Passive - Active

Predictable Resource Location is an attack technique used to uncover hidden web site content and functionality. By making educated guesses via brute forcing an attacker can guess file and directory names not intended for public viewing. Brute forcing filenames is easy because files/paths often have common naming convention and reside in standard locations. An "include" file was found within the web document root and its content could be read. Application include files are used to centralize common functions or code that is to be shared among several scripts. They often contain sensitive information such as database connection credentials, database query constructions, and other application logic. Another significant problem with include files is that their file extension (commonly .inc) is parsed as plain-text by the server, which reveals raw source code. This is different from script files with extensions such as .asp, .cgi, or .php. The content of a script file is interpreted by the server, which sends the result of the script's source code to a user's web browser. If the server does not recognize the file's extension as special, then the file's source code is not interpreted and the raw content is sent to the user's web browser.

Recommendations

Make sure that all include files have a file extension that is known to and interpreted by the application engine. For example, all of the include files for an ASP application should have the .asp file extension, whereas include files for a PHP-based application should have a .php extension. The file's functionality will not be affected, but users will be unable to view source code between the application script tags (such as <% or <?). Amend your deployment policy to include the addition of appropriate file extensions to all include files.

Details

• ModuleId - D8741C75-60B8-431A-9AE7-4E9B4FEB4F45
• Type - Vulnerability
• Active or Passive - Active

Reverse ClickJacking vulnerability arises when a JSONP callback parameter (i.e. a user-controlled parameter reflected in a JS context) is controllable by an attacker by passing an attack to a routine that builds the JSONP call in an insecure way (for instance, using string concatenation).

Recommendations

When a web application is vulnerable to Reverse ClickJacking attack, it will pass unvalidated input sent through requests to the client. The common modus operandi of the attack includes a design step, in which the attacker creates and tests an offending URI, a social engineering step, in which she convinces her victims to load this URI on their browsers, and the eventual execution of the offending code - using the victim's credentials. Commonly the attacker's code is written in the Javascript language, but other scripting languages are also used, e.g., ActionScript and VBScript. Attackers typically leverage these vulnerabilities to execute javascript code in the context of the page, thus performing actions with side effects, such as clicking buttons and submitting forms, on the same page or on different pages in the same origin, using frames or popups. One of the important matters about exploiting Reverse ClickJacking vulnerabilities is character encoding. In some cases, the web server or the web application may not be filtering some encodings of characters.

Details

• ModuleId - 13623AA1-62FA-4488-8521-16B7EC0DE49E
• Type - Vulnerability
• Active or Passive - Active

The Reverse Proxy Detection module determines if the application server honors proxied HTTP requests. If the server acts as a proxy, then a user may be able to attack un-related web applications via the server or even target other hosts on the server's local network regardless of firewall configurations. Vulnerabilities discovered by this module enable malicious users to attack other web application and servers with a greater degree of anonymity.

A web proxy is normally intended to act as a centralized server that relays traffic from internal network users to external web servers. A server that acts as a reverse proxy enables external network users to make web requests through the proxy server (victim) to hosts on the victim's local or peer networks. Such a proxy misconfiguration can allow external users to bypass firewall or other network restrictions because the proxy relays traffic that would normally be blocked. In some cases, the proxy may not be limited to relaying web traffic, but will relay traffic to arbitrary ports.

A reverse proxy may even expose web services with "non-routable" (RFC 1918) IP addresses such as 10.x.x.x, 172.16.x.x, 192.168.x.x, or other Intranet servers. In other cases the proxy capability may be exploited to attack web-based administrator interfaces. A misconfigured proxy enables an attacker to access private web applications, web application administration interfaces, or non-web services such as database ports.

Recommendations

A reverse proxy is typically due to misconfiguration of the web server or application engine. The proxy's functionality should only be accessible from the server's internal network interface. Refer to the server's documentation for instructions on how to disable reverse proxy capabilities.

Details

• ModuleId - A4181634-42A5-4BB9-BB0F-1E591881A835
• Type - Vulnerability
• Active or Passive - Active

Searches for sensitive information in the client-side scripts.

Comments were discovered in the script body. While not necessarily vulnerable, it is too easy to inadvertently leave sensitive information (usernames, passwords, absolute paths, ...) in the page content.

Recommendations

Remove comments from anything that could be pushed to the client as a webpage.

Details

• ModuleId - 2C7D393B-ABA4-4517-B0A3-7DC8ADCF9630
• Type - Best Practice
• Active or Passive - Passive

Check that there is no non-secure content on secure pages. A page that is available over TLS must be comprised completely of content which is transmitted over TLS. The page must not contain any content that is transmitted over unencrypted HTTP. This includes content from unrelated third-party sites.

Recommendations

Ensure that cookies secure flag is set and all content loaded with HTTP is loaded over HTTPS. This includes all resources such as links, javascript, stylesheets, and media.

Details

• ModuleId - 07BD211A-5809-44E5-91F7-8B40FF3F3489
• Type - Best Practice
• Active or Passive - Passive

Checking if the software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

Recommendations

• The GET method should never be used in a form that transmits sensitive data such as username and password, because they are displayed clear in the URL.
• Ensure that the algorithms used to encrypt sensitive data are considered strong enough, with secure generation of cipher keys.
• Ensure that sensitive data is transmitted over a secure protocol such as HTTPS.

Details

• ModuleId - FD28B5D4-1E06-4D37-B554-3CE22BBC6306
• Type - Best Practice
• Active or Passive - Passive

Server Configuration module checks response for information about the configurations of web servers that often provide too much information about their platform and version.

Default configurations of web servers often provide too much information about their platform and version in HTTP headers and on error pages. This data is not itself dangerous, but it can help an attacker focus on vulnerabilities associated with your specific web server platform/version.

Recommendations

Configure your web server to avoid having it announce its own details. For example in Apache you would want these two configuration directives in your config file:

Configure your web server to avoid having it announce its own details. In Apache Web Server, the following configuration directives should be added to the config file:

• ServerSignature Off
• ServerTokens Prod

In Microsoft IIS/10.0 Web Server, the "removeServerHeader" attribute should be added to the "security" configuration in web.config file: <requestFiltering removeServerHeader="true" />

Details

• ModuleId - 34A0F038-EFA2-48B5-94E7-F17447F4CF2E
• Type - Vulnerability
• Active or Passive - Active

Submits SSI injection attacks against input parameters. Server Side Include (SSI) Injection can be used to cause a web server to execute arbitrary code, with results similar to Cross Site Scripting. While SSI directives are far more limited than a typical scripting language, they can still potentially be used to expose sensitive information.

Recommendations

Disable SSI execution entirely if possible. If not, restrict the directories and files that SSI applies to, and properly sanitize input to encode or remove special characters that could be used to create SSI directives.

Details

• ModuleId - DC8E0D09-314B-44D3-9915-AAF8439B4F53
• Type - Vulnerability
• Active or Passive - Active

What is Server-Side Request Forgery (SSRF)?

SSRF is when an attacker can trick an application into making a request on behalf of the attacker. This has grown in significance since the advent of cloud. In AWS, Azure, GCP and similar, every virtual machine instance has access to a metadata service, which runs locally. Using this you can send HTTP requests to it to get metadata and to make changes. If an attacker gets access to the metadata service and gets an access token from the AWS CLI to make requests to your cloud environment, they can potentially do anything that the virtual machine has access to in the environment.

Even when not in the cloud, if an attacker can get the server to do requests on their behalf, there could be computers that are not network accessible to the internet, for example, database instance. All kinds of services that don’t use traditional access control based on access control and credentials.

Why do we need to protect against this type of vulnerability?

When an attacker finds this vulnerability, they can start probing your network and sending requests to random IP addresses. Once an attacker gets a sense of what the IP base looks like or ports or local hosts they can just start probing and sending requests. They could request or push data as they wish, running arbitrary commands and overwriting data.

The metadata service in the cloud is the most significant issue. Cloud environments may not have been set up in a secure way and an attacker may probe the cloud environment.

How do we protect against this vulnerability?

To prevent this:

• When taking user input and then constructing code or url from this, you should know what kind of user input you should be expecting. Inputs coming from all users should be sanitized.
• Reduce the character set that you allow.

Rapid7 incorporates the following:

• We do a blind SSRF to check whether we can connect to the appspidered domain, sending a unique value. We confirm whether or not we were able to get the service to send requests to our service.
• We also do an SSRF to check whether we can connect to the appspidered domain, receiving a unique value and confirming if the response contains this value.
• We do the same thing with Azure and AWS metadata services. We try to pull certain pieces of data from the metadata service and check if the response fits the expected format.

Associated severity/classification

The risk associated with this is High.

OWASP 2021: A03 (injection)

Server Side Template Injection (SSTI) is a vulnerability that allows the attacker to include malicious template code into another template to escape a template engine sandbox and access the operating system or execute commands on the server-side. The impact of this attack is significant and can lead to devastating results for victims.

Recommendations

• Normalize all user-supplied data before embedding it into the template.
• Implement positive filters that examine user-supplied data for expected characters.
• Negative filtering can also prevent attacks.

Details

• ModuleId - 0F5408AB-9FF9-4320-AA58-FCFE80EDEF59
• Type - Vulnerability
• Active or Passive - Active

Session Fixation is an attack that permits an attacker to hijack a valid user session.

Recommendations

This attack can be largely avoided by changing the session ID when users log in. Also, do NOT accept session ID's in GET or POST parameters; use HTTP cookies at the very least to encode session information. These two rules of thumb establish a sufficient level of security for most applications. However, for those willing to incur further development and maintenance effort for higher security, the SID can be regenerated on a per-request basis and also, on systems that support it, SSL/TLS session identifiers may be used.

Details

• ModuleId - DB1340E1-8575-4021-9DF8-4A6A9DC0494C
• Type - Vulnerability
• Active or Passive - Active

HTTP Query Checks parameter values

So at the network level, URL parameters are secure, but there are some other ways in which URL based data can leak:

• URLs are stored in web server logs - typically the whole URL of each request is stored in a server log. This means that any sensitive data in the URL (e.g. a password) is being saved in clear text on the server. Query strings may be stored in the server log when a query string was used to send a password over HTTPS, e.g. 2017-03-03 17:59:59 W3SVC4326 WWW 192.168.1.1 GET /Default.htm password=mypassword 443
• URLs are stored in the browser history - browsers save URL parameters in their history even if the secure pages themselves are not cached.
• URLs are passed in Referrer headers - if a secure page uses resources, such as javascript, images or analytics services, the URL is passed in the Referrer request header of each embedded request. Sometimes the query string parameters may be delivered to and stored by third party sites.

Recommendations

• Only pass around sensitive data if absolutely necessary. Once a user is authenticated it is best to identify them with a session ID that has a limited lifetime.
• Use non-persistent, session level cookies to hold session IDs and other private data.

Details

• ModuleId - 6B1B2812-012D-4124-9BDE-E83FFAEB523D
• Type - Vulnerability
• Active or Passive - Active

Session Strength module checks session identifiers, to determine if they could be vulnerable to prediction, or brute force attacks. Session tokens that exhibit low entropy ("randomness") are often susceptible to prediction attacks. Insecure tokens can be due to inadequate pseudo-random number generator, time-based values, static values, or values based on user attributes (username or user ID). This means that an attacker would be able to guess a valid session token after monitoring the application for a short period of time and gathering the session tokens it creates. If the attacker determines a valid session token for another user, then it may be possible to view, modify, or delete arbitrary users' data without having to guess the victim's username or password. Consequently, the ability to deduce valid session tokens enables the attacker to bypass login pages and obviate the need to brute force accounts. Additionally, static tokens can enable the attacker to target users even if the victim is not currently logged into the application. This increases the pool of victims which the attacker can target. Session tokens should be created with a strong random number generator and gathered from a large pool of numbers. For example, an operating system's rand() function can usually be sufficient if it can produce 32-bit values that are a statistically uniform distribution. Poor session tokens are incremental, rely on the user's account ID, only use time stamps, or have other highly deterministic information. Other methods of protecting a session token's security are to always transmit them over SSL, automatically expire the token after a certain period of time, and explicitly expiring the token whenever a user logs out of the application.

Recommendations

If the session values exhibit strong randomness, but are chosen from a small pool of values, then the attacker has a better chance of simply guessing a valid token. A web application's session management can be improved by implementing several complementary techniques:

1. Make sure that the Token values are at least 32 bits in size, especially for applications with large numbers of concurrent users and high amounts of daily page requests.
2. The bit size of the source of the entropy (random values) is more important than the bit size of the actual session token. For example, an MD5 hash produces a 128 bit value. However, the MD5 hash of incremental values, a timestamp, or 8-bit random numbers are each insecure because the source of the random values can be easily predicted. Consequently, the 128 bit size does not represent an accurate measure of the session token. The minimum size of the entropy source is 32 bits, although larger pools (48 or 64 bits) may be necessary for sites with over 10,000 concurrent users per hour.
3. In most cases, application-generated tokens (e.g. ASP.NET_SessionId, ASPSESSIONID, JSPSESSIONID, PHPSESSIONID) provide sufficiently large random values to prevent session prediction attacks. The application should use these session management algorithms unless a custom session mechanism has been thoroughly reviewed and tested.
4. Track user attributes associated with the session token with server-side objects to prevent user impersonation attacks. If the application does not strictly associate a user's session token with that user's profile information, then an attacker may be able to view arbitrary information by manipulating client-side values. For example, if the application sets a strong session token, but performs SQL queries based on a "UserId" cookie, then an attacker only needs to modify the "UserId" cookie to impersonate someone else. The application would be more secure if it associated the "UserId" value with the server-side session object because the attacker would not be able to modify the value.
5. Expire session tokens when the user logs out of the application or after a predetermined period of inactivity. We recommend using a 20 minute timeout for a session token, although this largely depends on the type of application and the expected usage.

Details

• ModuleId - F729A709-9806-4A1F-99A8-BEA8512D31AE
• Type - Vulnerability
• Active or Passive - Active

The module reports a risk factor for exposing or binding the user session between states of anonymous users and authenticated users.

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application.

Recommendations

During the authentication process, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.

Details

• ModuleId - 0DB2C131-1DA7-4B80-A153-A8733C74D6CC
• Type - Vulnerability
• Active or Passive - Passive

Source code disclosure attacks allow a malicious user to obtain the source code of a server-side application. This vulnerability grants the attacker deeper knowledge of the Web application logic.

A server vulnerability can be exploited to read arbitrary files. This vulnerability can be used to reveal the source code of application files as well as display configuration files. Source code disclosure exposes sensitive application information such as input validation filters, database connection strings and queries, or hard-coded passwords.

An attacker with information about input validation filters may be able to craft a specific request that would bypass the filter.

Information about database connection strings exposes the user name and password used to access the database. Information about how database queries are constructed can help attackers create SQL injection exploits that pull specific information from the database.

Hard-coded passwords within configuration files or application source code may enable an attacker to access portions of the application that are otherwise restricted.

Recommendations

1. Apply Microsoft patch Q267559. This patch is also referenced in Microsoft's MS01-004 bulletin.
2. If the .htr file extension is not used, then it should be disabled. The .htr extension uses the ISM.DLL and serves as a password management interface for IIS. File extensions such as .htr are disabled by using the Internet Services Manager:
   • Right click on the "Default Web Site" (or the name of the web site to be modified, if different from the default setting).
   • Left click on the "ISAPI Filters" tab.
   • Highlight (left click) the filter to be removed.
   • Left click the "Remove" button. This is preferable to using the "Disable" button.

Details

• ModuleId - 7A7B3239-AB81-4683-9A8A-EF170807ED1E
• Type - Best Practice
• Active or Passive - Active

Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack. An information leak occurs when system data or debugging information leaves the program through an output stream or logging function.

Recommendations

Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.

Details

• ModuleId - 59646365-E0E4-4520-BE42-97C3ABAA7E75
• Type - Vulnerability
• Active or Passive - Passive

SQL Injection module checks the application for SQL injection vulnerabilities attacks - a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

Recommendations

Use of Prepared Statements (Parameterized Queries)

Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied. Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker.

Details

• ModuleId - B6F559D3-74B5-451E-B424-A1C1FB264FA6
• Type - Vulnerability
• Active or Passive - Active

SQL injection Auth Bypass module checks the application for SQL injection vulnerabilities attacks that can be used to fool the application into authenticating without the attacker needing valid credentials.

Recommendations

Use of Prepared Statements (Parameterized Queries)

Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied. Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker.

Details

• ModuleId - 0496353D-9270-4F2E-942B-FE1B575D9B7C
• Type - Vulnerability
• Active or Passive - Active

SQL Parameter Check module checks parameters for embedded sql statements. A SQL syntax was discovered in a parameter. This indicates that a database injection attack could be accomplished. These types of attacks manipulate database queries in order to access, modify, or delete arbitrary data. In many cases these attacks can subvert authentication and authorization schemes, which would enable an attacker to gain privileged access to restricted portions of the application. If the database injection attack can be used to read arbitrary data, then users' stored information such as authentication credentials, e-mail address, social security number, or financial information will be exposed.

Some databases provide methods for executing system commands via SQL queries. Thus, a successful injection attack could compromise the database host and other hosts on its local network even if they are protected from the Internet by a firewall.

Recommendations

Use of Prepared Statements (Parameterized Queries)

Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied. Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker.

Details

• ModuleId - CEB40EE4-9056-4D60-B4F9-B3CE79C009B5
• Type - Vulnerability
• Active or Passive - Passive

What is SSL (Secure Sockets Layer) Strength?

SSL is used to encrypt data that is shared on the web. SSL is the means of authentication used to ensure that the sender of the data is who it says it is. The SSL Certificate Details provide information about the certificate associated with the HTTPS server. This information describes important attributes of the certificate and should be reviewed for the correctness of the contact information, whether it is self-signed, and how soon it will expire. The Supported Ciphers provides information about each available encryption scheme available for each of the three possible SSL protocols.

Why do we need to protect against this type of vulnerability?

Vulnerabilities related to SSL/TSL are commonly exploited by attackers, with attacks like POODLE and BEAST taking advantage of these. Absent or incorrectly configured SSL can result in:

• Interference with and manipulation of data being transmitted or even theft of data
• MiTM attacks
• Weak ciphers may result in decryption by attackers
• Poorly configured SSL can even be used in a Denial of Service attack

How do we protect against this vulnerability?

To prevent this the expiration date for certificates should be monitored. New certificates should be available before the expiration date in order to maintain continuity of service and avoid downtime or displaying certificate expiration errors in users' web browsers. The highest level of TLS protocol should be used and renegotiation down to less secure SSL protocols should be forbidden. By default, browsers should connect via the TLS1.2 protocol with a 256 bit encryption scheme. Allowing clients to renegotiate down from TLS to SSLv3 is a serious highly exploitable vulnerability as is allowing SSLv3 at all and should be avoided.

Rapid7 assesses which version of TSL/SSL is used. We flag SSLv2 and SSLv3 as high severity. We also flag TLS1.0 and TLS1.1 as medium. We report back on cipher strength by looking at the cipher length. 256 bit SSL security is reported as low, 128 bit - 168 bit as medium and anything lower as high.

Associated severity/classification

The risk associated with this is Medium.

OWASP 2021: A02 (cryptographic failures)

Discovers subdomains, Found an existing subdomain to the top level domain.

Recommendations

Review the usage of the subdomain, and disable subdomains that are no longer in use.

Details

• ModuleId - 5D9A66E5-961B-4644-AAF5-EC655E18EE66
• Type - Vulnerability
• Active or Passive - Active

The module reports flaws in subresource integrity. For example, the integrity attribute could be missing in a script or a link.

Recommendations

To prevent unexpected or malicious modifications of script resources the integrity attribute is used in script elements to verify the content.

Details

• ModuleId - 31E0A650-FB94-4E68-9DF4-6B7A98F35A5F
• Type - Vulnerability
• Active or Passive - Passive

An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation. This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it.

Recommendations

Safe use of redirects and forwards can be done in a number of ways:

1. Simply avoid using redirects and forwards.
2. If used, don't involve user parameters in calculating the destination. This can usually be done.
3. If destination parameters can't be avoided, ensure that the supplied value is valid, and authorized for the user.
4. It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL.
5. Applications can use ESAPI to override the sendRedirect() method to make sure all redirect destinations are safe.
6. Avoiding such flaws is extremely important as they are a favorite target of phishers trying to gain the user's trust.

Details

• ModuleId - 9A22444A-C7C6-42AB-BC59-8CBCA4738C3B
• Type - Vulnerability
• Active or Passive - Active

URL rewriting Attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users. The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately. As such, it is important that they are protected from eavesdropping at all times – particularly whilst in transit between the Client browser and the application servers.

Recommendations

The primary recommendation for an organization is to make available to developers:

A single set of strong authentication and session management controls. Such controls should strive to:

1. meet all the authentication and session management requirements defined in OWASP's Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management).
2. have a simple interface for developers. Consider the ESAPI Authenticator and User APIs as good examples to emulate, use, or build upon.
3. Strong efforts should also be made to avoid XSS flaws which can be used to steal session IDs.

Details

• ModuleId - B69E8383-1D26-496B-B2CC-0C0D70181EC3
• Type - Best Practice
• Active or Passive - Passive

ASP.NET ViewState security module checks for ViewState security misconfigurations. ASP.NET view state is the technique used by an ASP.NET Web page to persist changes to the state of a Web Form across postbacks. By default, view state data is stored on the page in a hidden field and is encoded using base64 encoding.

Recommendations

The ASP.NET page framework creating an empty view state bag can affect the performance of your application, so turn off view state unless you need it.

Encrypting view state data can affect the performance of your application, so do not use encryption unless you need it. It can be difficult for malicious users to reverse-engineer the MAC key based on the value in the page and the view state. Thus, MAC encoding is typically a reliable way to determine whether anyone has tampered with the view-state data.

Enable the ASP.NET feature to apply a MAC if the page uses the view-state data. However, in some cases controls might use view state to store information that no users should have access to. For example, the page might contain a data-bound control that stores item identifiers (data keys) in view state. If those identifiers contain sensitive data, such as social security numbers or customer IDs, you should encrypt the view-state data.

It is also important that you continually keep your Web server computer up to date with the latest security updates for Microsoft Windows and Internet Information Services (IIS).

Details

• ModuleId - 4DE84100-F318-49A7-B845-FE5F62D2FD7A
• Type - Vulnerability
• Active or Passive - Passive

Web beacons are typically used by third parties to monitor the activity of customers at a site. A messenger gif was found on the website. This is an invisible image that can be used to signal an attacker's website that a given page is being browsed.

Recommendations

Remove any tags that get images out of domain in particular and any whose dimensions make them invisible.

Details

• ModuleId - 0BE4C251-F44C-4CF1-9241-04ADFD86289C
• Type - Best Practice
• Active or Passive - Active

Cross-site tracing (XST) is a network security vulnerability exploiting the HTTP TRACE method. The TRACE verb supported by most web servers can be manipulated to produce a Cross-Site Scripting attack that results in sending arbitrary HTML to the victim's browser. The TRACE verb is designed to echo a user's input and intended for debugging or testing a web server. The TRACE verb is not required for web applications to function (web applications and we/b browsers usually only need the HEAD, GET, and POST verbs).

Recommendations

Refer to your web server's manual for information on how to disable the TRACE method.

Details

• ModuleId - 74FB936F-2BBA-499F-8D0A-F3B7A29B4F9E
• Type - Vulnerability
• Active or Passive - Active

Web Service Parameter Fuzzing module checks the application for vulnerabilities that allows manipulation of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, etc.

Usually, this information is stored in cookies, hidden form fields, or URL Query Strings, and is used to increase application functionality and control.

Recommendations

An invalid character submitted in a URL parameter causes an error in the database query or script execution. This indicates that the application has not fully validated user-supplied input. These errors can lead to HTML injection, SQL injection, or arbitrary code execution.

Details

• ModuleId - 377030BF-E58A-4F01-A112-295D32A0744C
• Type - Vulnerability
• Active or Passive - Active

Checks for X-Content-Type-Options HTTP header. The only defined value, "nosniff", prevents Internet Explorer and Google Chrome from MIME-sniffing a response away from the declared content-type. This also applies to Google Chrome, when downloading extensions. This reduces exposure to drive-by download attacks and sites serving user uploaded content that, by clever naming, could be treated by MSIE as executable or dynamic HTML files.

Recommendations

The X-Content-Type-Options HTTP response header can be used to indicate whether or not a browser should be allowed to sniff a response away from the declared content-type. Sites can use this to avoid MIME-sniffing a response away from the declared content-type.

Details

• ModuleId - 8399FA8E-DF5C-41BC-9D3C-F85DC23DC26B
• Type - Best Practice
• Active or Passive - Passive

Checks for X-Frame-Options HTTP header. A clickjacked page tricks a user into performing undesired actions by clicking on a concealed link. On a clickjacked page, the attackers load another page over it in a transparent layer. The users think that they are clicking visible buttons, while they are actually performing actions on the hidden page.

Recommendations

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid Clickjacking attacks, by ensuring that their content is not embedded into other sites.

Details

• ModuleId - 3E2E60F7-D0E0-4D85-9691-8C2D1F639064
• Type - Best Practice
• Active or Passive - Passive

XML External Entity Attack (or "XXE") is an attack that deceives the server into facilitating malicious operations including: Denial of service, TCP scans, command execution, parsing and displaying the file system, DoSing other machines accessed via TCP, NTLM access to unauthorized data via UNC file access, and doomsday DoS scenarios. It is conducted by inserting a malicious URI into the ENTITY tag of the XML DTD which the vulnerable server then inlines in parsing the XML.

Recommendations

The recommendation for remediating XXE is conceptually simple and, as one expects, potentially subtle.

Any input that can take XML which then gets parsed on the backend should be sanitized. And/or the XML parser or the code invoking it should be configured to be discretionary as to what URI's it inlines via ENTITY tags.

A typical example of an XXE vulnerability involves java servlet or .NET code on the server side using an XML parsing object appropriate to those libraries. The objects are declared and the XML is parsed and the code looks quite innocent but if improperly configured, hostile URIs can be inlined into the parsed XML and the resulting content served up to the client.

The DtdProcessing.Prohibit property should be used with .NET objects such as XmlTextReader and XmlReaderSettings and judicious use of the XmlUrlResolver class can be used to secure .NET web applications. In Java/Xerxes, DocumentBuilder, DocumentBuilderFactory, and SAXParserFactory objects have members setXIncludeAware() and setNamespaceAware().

In any library that offers XML parsing capability, nothing should be taken for granted vis-a-vis defaults and all properties of objects should be researched thoroughly for behaviour and then used in the most secure manner possible. Most configurable parser behaviour is oriented towards turning external references on or off completely. If external entities are desired in some cases for the functionality of the web application, then either data scrubbing of the inputs needs to be done as mentioned earlier in this recommendation or there needs to be a preprocessing/scrubbing step implemented on the server side before calling the XML parser.

Details

• ModuleId - ABFA0759-1980-4435-A25A-22A8CAC191DF
• Type - Vulnerability
• Active or Passive - Active

XPath Injection module checks the application for XPath injection vulnerabilities attacks - a type of injection attack, in which XPath commands are injected into data-plane input in order to effect the execution of predefined XPath queries.

Recommendations

Several techniques can be used to block XPath injection attacks. These techniques complement each other and address security at different points in the application. The impact of an XPath injection attack is minimized by implementing multiple defense measures.

• Normalize all user-supplied data before applying filters, regular expressions, or submitting the data to a database. This means that all URL-encoded (%xx), HTML-encoded (&#xx;), or other encoding schemes should be reduced to the internal character representation expected by the application. This prevents attackers from using alternate encoding schemes to bypass filters.
• Implement positive filters that examine user-supplied data for expected characters. Define data types for user-supplied values and ensure that submitted data match these types, such as numeric or date. String or text values should be carefully matched to a limited subset of characters such as alpha, numeric, spaces, or certain punctuation characters as necessary. If any value received by the application contains an unexpected character, then it should be rejected.
• Negative filtering can also prevent attacks, but may be more unreliable or more difficult to implement for language sets that require non-ASCII characters. Examine all data received from the web browser for XPath syntax characters. If any of these characters are present, then they should be escaped or removed. The single quote (') or double quote (") are often used to envelope parameters in an XPath query. Other malicious characters include the asterisk, semi- colon, dash (minus sign), and parentheses. These characters could be used to prematurely end a query statement.
• Avoid string concatenation for XPath query construction. String concatenation, where the query is created programmatically by appending values together, makes an injection attack easier to accomplish because the syntax of the query can be easily disrupted by malicious characters. Store user-supplied values with appropriate data types within the database. For example, dates should be stored

Details

• ModuleId - BBE9F36A-88A9-44EC-B837-D5193D356E4C
• Type - Vulnerability
• Active or Passive - Active

Checks for X-Powered-By HTTP header that reveals the server configuration.

Recommendations

The X-Powered-By HTTP Header should be removed.

Details

• ModuleId - 6CEF426D-3351-4825-B507-41616DB2120B
• Type - Vulnerability
• Active or Passive - Passive

DOM Based XSS (or as it is called in some texts, "type-0 XSS") is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment”. DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active content on a page, typically JavaScript, obtaininguser input and then doing something unsafe with it to lead to execution of injected code. This document will only discuss JavaScript bugs which lead to XSS.

The DOM, or Document Object Model, is the structural format that may be used to represent documents in the browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie. The DOM is also used by the browser for security - for example to limit scripts on different domains obtaining session cookies for other domains. A DOM-based cross site scripting vulnerability may occur when active content, such as a JavaScript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker.

There have been very few papers published on this topic and, as such, very little standardization of its meaning and formalized testing exists.

Recommendations

Not all XSS bugs require the attacker to control the content returned from the server, but can instead abuse poor JavaScript coding practices to achieve the same results. The consequences are the same as a typical XSS flaw, only the means of delivery is different.

In comparison to other cross site scripting vulnerabilities (reflected and stored XSS), where an unsanitized parameter is passed by the server, returned to the user and executed in the context of the user's browser, a DOM based cross site scripting vulnerability controls the flow of the code by using elements of the Document Object Model (DOM) along with code crafted by the attacker to change the flow.

Due to their nature, DOM based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may result in many of the general XSS filtering and detection rules impotent against such attacks.

The consequences of DOM based cross site scripting flaws are as wide ranging as those seen in more well-known forms of XSS, including cookie retrieval, further malicious script injection, etc. and should therefore be treated with the same severity as such.

Details

• ModuleId - 46A8FE46-9F6C-44BF-B994-6C021A2BCDC8
• Type - Vulnerability
• Active or Passive - Passive

DOM Based XSS (or as it is called in some texts, "type-0 XSS") is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim's browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

Recommendations

Not all XSS bugs require the attacker to control the content returned from the server, but can instead abuse poor JavaScript coding practices to achieve the same results. The consequences are the same as a typical XSS flaw, only the means of delivery is different. In comparison to other cross site scripting vulnerabilities (reflected and stored XSS), where an unsanitized parameter is passed by the server, returned to the user and executed in the context of the user's browser, a DOM based cross site scripting vulnerability controls the flow of the code by using elements of the Document Object Model (DOM) along with code crafted by the attacker to change the flow. Due to their nature, DOM based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may result in many of the general XSS filtering and detection rules impotent against such attacks.

The consequences of DOM based cross site scripting flaws are as wide ranging as those seen in more well known forms of XSS, including cookie retrieval, further malicious script injection, etc. and should therefore be treated with the same severity as such.

Details

• ModuleId - BD57F92E-956A-493D-A39A-DDF215B29D96
• Type - Vulnerability
• Active or Passive - Active

Persistent XSS is an XSS attack, where the attack loads with the vulnerable web application. Attack may is originated by improper neutralization of input during web page generation.

Recommendations

1. Filter all information sent to the client with a particular emphasis on filtering out HTML-specific characters.
2. Understand the context in which your data will be used and the encoding that will be expected.
3. For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side.

Details

• ModuleId - 62AA6A08-FA76-4E20-9551-B4A4C479F08D
• Type - Vulnerability
• Active or Passive - Passive

Persistent Cross-site Scripting (XSS) is the attack that is loaded with the vulnerable web application. The attack is originated by the victim loading the offending URI. Cross-Site Scripting vulnerabilities were found. From these attackers can inject hostile html source into page content to do such things as diverting users to fake sites and gathering sensitive information.

Recommendations

Filter all information sent to the server via form POST/GET and URL query parameters with a particular emphasis on filtering out HTML-specific characters.

1. Escape the escape characters, which attackers can use to neutralize your attempts to be safe. Use a security-focused encoding library to make sure these rules are properly implemented.
2. Never insert untrusted data into your HTML document.
3. For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side.

Details

• ModuleId - 050ABD8C-F99F-4EE4-AA18-C12F06FA3051
• Type - Vulnerability
• Active or Passive - Active

Reflected Cross-site Scripting (XSS) is another name for non-persistent XSS, where the attack doesn't load with the vulnerable web application but is originated by the victim loading the offending URI. In this article we will see some ways to test a web application for this kind of vulnerability.

Recommendations

Reflected XSS attacks are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will pass unvalidated input sent through requests to the client. Reflected attacks are delivered to the victim in various ways, such as in an e-mail message, or through some specially crafted URI. When a user is tricked into clicking on the malicious link, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser. The browser then executes the offending code because it came from a "trusted" server.

Commonly the attacker's code is written in the Javascript language, but other scripting languages are also used, e.g., ActionScript and VBScript.

Attackers typically leverage these vulnerabilities to install key loggers, steal victim cookies, perform clipboard theft, and change the content of the page (e.g. download links).

To remediate against reflected XSS vulnerabilities, strict filtering of HTML character encodings must be adhered to. In some cases, the web application may not be filtering some character encodings. For example, it may filter out <script>, but might not filter %3Cscript%3E which simply includes another encoding of tags. A nice tool for testing character encodings is OWASP's CAL9000.

Filtering of all information sent to the server via form POST/GET and URL query parameters with a particular emphasis on filtering out HTML-specific characters is advised.

Details

• ModuleId - ABEB2E59-0AA2-4A39-BB6F-E7DBD6338277
• Type - Vulnerability
• Active or Passive - Active

Submits XSS attacks against all input parameters. The application does not filter text or other data for potentially malicious HTML content. This enables an attacker to craft arbitrary HTML content. This vulnerability typically requires that an attacker be able to submit JavaScript <script> tags as part of a field that is re-displayed to one or more users. The <script> tag contains instructions that are executed in a user's web browser, not on the web application server. JavaScript functions can be used to write r aw HTML, read cookie values, pull JavaScript code from a third-party web server, or send data to a third-party web server.

Consequently, a user could cause arbitrary HTML such as JavaScript tags to be displayed to other users. Usually, an attacker will attempt to manipulate an XSS vulnerability in order to present malicious HTML as if it came from a legitimate source. This attack is often combined with a social engineering attack that attempts to trick users into divulging their passwords, financial, or personal information.

In this case, the JavaScript payload appears to be embedded within another HTML tag. The application is still vulnerable to this attack, but the payload requires additional formatting characters in order to be successful. Thus, you may not see a pop-up alert when you click the "Validate" button.

Recommendations

Cross-Site Scripting and HTML injection attacks can be defeated by applying robust input validation filters for all data received from the web browser. Strong countermeasures include:

1. Do not permit users to include HTML content in posts, notes, or other data that will be displayed by the application.
2. If users are permitted to include HTML entities, then limit access to specific elements or attributes.
3. Formatting elements such as <b>, <i>, and <u> should be checked to ensure they only contain the expected character (b, i, or u).
4. Elements such as <a> and <img> should only permit the href or src attribute to be modified. Check the content of these attributes to ensure that dynamic code (JavaScript, VBscript, etc.) has not been inserted.
5. Use validation filters that match allowed, expected items and reject all unmatched items. Do not attempt to use validation filters that reject known malicious strings because they can often be bypassed by alternate character encoding. The validation filter should deny all HTML entities by default.
6. Use output filters to strip malicious tags or convert angle brackets to their HTML-encoded equivalent.
7. Use the programming language's built-in routines to remove potentially malicious characters.
8. The PHP htmlentities() function prevents potentially malicious HTML characters from being passed through variables. The following example demonstrates how to protect a parameter (screen) from HTML injection:
   • \(screen_safe = htmlentities(\)_REQUEST["screen"]);

Details

• ModuleId - FFBF4640-C8A4-475E-93E0-99018951B409
• Type - Vulnerability
• Active or Passive - Active

Checks for use of the X-XSS-Protection HTTP header which can lead to vulnerabilities caused by XSS filtering.

Recommendations

To avoid vulnerabilities related to the X-XSS-Protection header, it is recommended to use the Content-Security-Policy header instead as it uses the 'unsafe-inline' option to disable the use of inline resources such as JavaScript.

Details

• ModuleId - 615D72F4-01BC-447A-B4A2-139654BC9945
• Type - Best Practice
• Active or Passive - Passive