Attack Modules

Anonymous Access

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

Apache Struts 2 Framework Checks

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

Apache Struts Detection

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

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

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

  1. 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.
  2. 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

Autocomplete attribute

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:
<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)

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 (leaking sensitive information)

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

Brute Force (HTTP Auth)

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

  • Require that all passwords have a six-character minimum length.
  • Require that all passwords have mixed-case alphanumeric content.
  • Have all passwords expire every 180 days and do not allow users to re-use previously expired
  • passwords.
  • Include rules for password content, password expiration, and password re-use.

Details

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

Brute Force (Form Auth)

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 six-character minimum length.
  • Require that all passwords have mixed-case alphanumeric content
  • Have all passwords expire every 180 days and do not allow users to re-use previously expired
  • passwords.
  • Include rules for password content, password expiration, and password re-use

Details

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

Blind SQL Injection

These 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 affected 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. These tests do not generate database errors, no database errors should appear in the HTML response.

Vulnerabilities identified by this module highlight problems with input validation routines and the creation of SQL queries. They should be addressed by the fundamental approaches taken to counter common SQL injection exploits.

Recommendations

Several techniques can be used to block database injection attacks. These techniques complement each other and address security at different points in the application. The impact of a SQL 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 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 parenthesis. These characters could be used to prematurely end a query statement.

Avoid string concatenation for SQL 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. SQL statements should use pre-defined views, parameterized functions, or stored procedures to query the database. These techniques do not enable the content of a parameter to affect the structure of a SQL statement. Even if a parameter contains malicious characters, then the function will always return an error due to incorrect values.

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 - 22E85EEA-6883-4039-82D8-C298AEBC935A

  • Type - Vulnerability
  • Active or Passive - Active

Clients Cross-Domain Policy Files

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

Information Disclosure in comments

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

Cross Origin Resources Sharing (CORS)

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 whitelisting domains over blacklisting 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

Credentials Over Insecure Channel

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 user's 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

Content Security Policy Header

The module reports a missing Content Security Policy attributes from the http headers or html meta tags.

The Content Security Policy hasn't been declared either through the meta-tag or the header, so 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.

Recommendations

The Content-Security-Policy HTTP response header helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header. CSP 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 whitelisted domains, ignoring all other script (including inline scripts and event-handling HTML attributes).

Details

  • ModuleId - C35E7D79-DD6F-4DA4-89BB-F6BC1D9D012B
  • Type - Vulnerability
  • Active or Passive - Passive

Cross-Site Request Forgery (CSRF)

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</li>
  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

Custom Parameter Module

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

Custom Passive Module

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

Directory Indexing

Description: 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

Email Disclosure

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

Expression Language Injection

The Expression Language Injection module tests the application for susceptibility to Java servlet vulnerabilities involving values passed by attribute that are double evaluated by the servlet code processing them. This allows attackers to embed code that, for example, dereferences software objects, or "models" and exposes their contents in the client browser.

Expression Language Injection is an attack that tricks a servlet running EL on the server to "double evaluate" an EL expression. Servlet code is often written with something to the effect of ExpressionEvaluationUtils.evaluateString("scope", this.scope, this.pageContext); This allows for crafting JSP EL such as <spring:message scope="${param.foo}"/>. This particular example will cause JSP to echo the "foo" request parameter to the browser. Of course much more serious exploits can be crafted along the same lines. The hacker might obtain values for request parameters, headers, cookies, or Java bean values with sensitive data

Recommendations

It is tempting to simply disable all EL in JSP with <%@ page isELIgnored ="true" %>. As with other blanket approaches to security, this spills over into legitimate areas and will preclude running functional EL. So the best practice approach is to implement data validation on untrusted inputs with a particular focus on EL metacharacters such as "${" and "#{" and HTML encoded variations of these.

Details

  • ModuleId - 9B62D146-FF00-4563-88F9-822A76F95841
  • Type - Vulnerability
  • Active or Passive - Active

Forced Browsing

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

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

FrontPage Checks

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

Heartbleed Check

Checks for OpenSSL Heartbleed Vulnerability.

Servers using the OpenSSL library, versions 1.0.1 through 1.0.1f, are vulnerable to exposing arbitrary data using a malformed Heartbeat request.

The data exposed can potentially include user credentials, private encryption keys, and other private information.

Recommendations

  • Update OpenSSL to version 1.0.1g or later, or disable heartbeat responses by compiling OpenSSL using -DOPENSSL_NO_HEARTBEATS.
  • Revoke and replace your existing certificates, and advise users to change passwords after the update is complete.

Details

  • ModuleId - 748E90FC-47AB-4B43-8C3A-49660989B44A
  • Type - Vulnerability
  • Active or Passive - Active

HTTP Strict Transport Security

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

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

HTTPS Downgrade

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

HTTP Headers

The module reports a missing charset attribute from the content type header or html meta tags. The encoding hasn’t been declared either through the meta-tag, the byte-order-mark or the header, so the browser will make an attempt to detect the document’s encoding. This exploit only works if the document reflects user input and the browser can be tricked into encoding the page as UTF-7 instead of UTF-8. Some of the browsers actually support UTF-7.

Recommendations

Always declare the encoding of your document. Use the HTTP header if you can. Always use an in- document declaration too. You can use @charset or HTTP headers to declare the encoding of your style sheet, but you only need to do so if your style sheet contains non-ASCII characters and, for some reason, you can't rely on the encoding of the HTML and the associated style sheet to be the same. Try to avoid using the byte-order mark in UTF-8, and ensure that your HTML code is saved in Unicode normalization form C (NFC).

Details

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

HTTP Response Splitting

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

HTTPS Everywhere

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

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

Information Disclosure in Response

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

Information Leakage In Response

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

Java Grinder

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

LDAP Injection

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

Local Storage Usage

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 Abuse

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

Nginx NULL code

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

NoSQLi Injection

NoSQL Injection module checks the application for NoSQL injection vulnerabilities. The query parameters get altered into data plane input in order to effect the server side execution of attacker-predefined commands.

Recommendations

  • 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 process input and output parameters or data.
    • Escape all user supplied input
  • Additional defenses:

    • 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 easy, and everything just 'works' when you do it this way, but it is very dangerous. 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

Details

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

Command Injection

OS Commanding module checks the application for vulnerabilities that allows an attacker to inject and execute commands specified by the attacker in the vulnerable application. In situation like this, the application, which executes unwanted system commands, is like a pseudo system shell, and 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.).

OS Commanding attacks take two forms:

  • An attacker can change the command that the program executes: the attacker explicitly controls what the command is.
  • An attacker can change the environment in which the command executes: 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.

OS Commanding 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.

Recommendations

Careful handling of all user input is crucial.

  • Design: If at all 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 white-list. checked.
  • Run time: Run time policy enforcement may be used in a white-list fashion to prevent use of any non- sanctioned commands.

Details

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

Out of Band Stored Cross-site scripting (XSS)

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

Parameter Fuzzing

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. 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.

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 - 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

Collecting Sensitive Personal Information (Personal Sensitive Information)

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

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

Privacy Disclosure

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

Privilege Escalation

Privilege Escalation

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

Recommendations

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

Profanity

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

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

File Inclusion

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.

Recommendations

Preventing file inclusion (RFI/LFI) 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 - 8CB2F93C-E7F2-43B9-8D3C-83A9A3E6EA4B
  • Type - Vulnerability
  • Active or Passive - Active

HTTP Verb Tampering (Request Method Tampering)

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 (Resource Finder)

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

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

Reverse Proxy

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

Information Disclosure in scripts

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

Server Configuration

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

Server Side Include (SSI) Injection

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

Server Side Request Forgery

Server Side Request Forgery allows the attacker to abuse functionality on the server to read or update internal resources.

Recommendations

Preventing Server Sider Request Forgery 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.

The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.

Details

  • ModuleId - F74CCB33-1413-4B21-A3B5-D5D78BECEADB
  • Type - Vulnerability
  • Active or Passive - Active

Session Fixation

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 Session Check

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

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

Session Upgrade

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

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

SQL Information Leakage (SQL Errors)

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

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

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

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

SSL Strength

Test SSL Strength. 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. 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.

Recommendations

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.

Details

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

Subdomain discovery

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

Unvalidated Redirect

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

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 (ViewState Check)

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 Beacon

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 – Web Method)

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

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

X-Content-Type-Options

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

X-Frame-Options

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 &lt;frame&gt; or &lt;iframe&gt;. 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

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 URI's 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

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

Cross-site scripting (XSS), (DOM based)

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

Cross-site scripting (XSS), (DOM based Reflected via Ajax Request, DOM Comprehensive)

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 Cross-site scripting (XSS) (passive – XSS Persistent)

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), (active - XSS PersistentActive )

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,Reflected)

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

Reflected Cross Site Scripting Simple (XSS,Simple)

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 &lt;script&gt; tags as part of a field that is re-displayed to one or more users. The &lt;script&gt; tagn 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 &lt;b&gt;, &lt;i&gt;, and &lt;u&gt; should be checked to ensure they only contain the expected character (b, i, or u).
  4. Elements such as &lt;a ...&gt; and &lt;img ...&gt; 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:
  1. \(screen_safe = htmlentities(\)_REQUEST["screen"]);

Details

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