Payment Card Industry Report

 Scan Name: webscantest
 Date: 10/24/2017 7:44:45 AM
 Authenticated User: admin
 Total Links / Attackable Links: 475 / 475
 Target URL: https://webscantest.com
http://webscantest.com
 Reports:

Important Compliance Information and Limit of Liability

This information has been gathered during a scan of your web application. By checking your online properties for issues such as insecure data collection forms, cookie presence, third-party links, cross-site-scripting vulnerabilities, and SQL-injection vulnerabilities, the scan generates an automatic checklist of potential compliance issues. By taking advantage of this information, you can then proactively filter and prioritize identified issues to ensure faster remediation of your organization's most critical regulatory compliance concerns.

It is important to note that while this automatically-generated information is intended to greatly enhance the efficiency with which you may remediate compliance issues, it does not presume to represent the full scope of compliance with Payment Card Industry regulations. These results represent a subset of the requirements that can be gathered automatically from your web application. Further, as regulations are subject to change, this report may have been generated with a version of the application that has not been updated to reflect those changes. It is therefore the sole responsibility of the user to know the regulations and comply with them.

The issues presented in this report correspond to the Payment Card Industry Data Security Standard v3.2 (PCI-DSS).

The information presented here is not to be regarded as legal advice. It does not express or imply any guarantee of compliance with any law or regulation. It is the sole responsibility of the user of this report to seek competent legal counsel for advice on compliance with any laws and regulatory requirements and to otherwise take whatever measures are necessary for such compliance. Rapid 7 Inc. assumes no responsibility for any use or misuse of any information presented in this report.


PCI Compliance Results

The results of this report do not cover the full set of requirements for PCI-DSS compliance. This information has been gathered during a scan of your web application, and will only cover the following requirements as is possible from a "blackbox" analysis.
For details on the PCI Security Council, and a full copy of the PCI-DSS visit their website https://www.pcisecuritystandards.org/.

Pass or Fail for a requirement is based on the sub-requirements we are able to test for in an automated Web Application Assessment. All other sub-requirements are not factored in.

Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
N/A
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Requirement 2.1: Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, Simple Network Management Protocol (SNMP) community strings, etc.).
Failed
Requirement 2.2: Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
Requirement 2.2.1: Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)
Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.
N/A
Requirement 2.2.2: Enable only necessary services, protocols, daemons, etc., as required for the function of the system.
Failed
Requirement 2.2.3: Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be completed.
N/A
Requirement 2.2.4: Configure system security parameters to prevent misuse.
Failed
Requirement 2.2.5: Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
Failed
Failed
Requirement 2.3: Encrypt all non-console administrative access using strong cryptography.
Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be completed.
N/A
Requirement 2.6: This section applies to hosting providers only - Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.
N/A
Requirement A.1.1: This section applies to hosting providers only - Ensure that each entity only runs processes that have access to that entity’s cardholder data environment.
N/A
Requirement A.1.2: This section applies to hosting providers only - Restrict each entity’s access and privileges to its own cardholder data environment only.
N/A
Requirement A.1.3: This section applies to hosting providers only - Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10.
N/A
Requirement A.1.4: This section applies to hosting providers only - Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider.
N/A
Failed

Protect Cardholder Data

Requirement 3: Protect stored cardholder data
Requirement 3.1: Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes.
Failed
Requirement 3.2: Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.
It is permissible for issuers and companies that support issuing services to store sensitive authentication data if:
-There is a business justification and
-The data is stored securely.
Requirement 3.2.1: Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic- stripe data.
Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained:
-The cardholder’s name
-Primary account number (PAN)
-Expiration date
-Service code
To minimize risk, store only these data elements as needed for business.
N/A
Requirement 3.2.2: Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used to verify card-not- present transactions) after authorization.
N/A
Requirement 3.2.3: Do not store the personal identification number (PIN) or the encrypted PIN block after authorization.
N/A
N/A
Requirement 3.3: Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.
Note: This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, legal or payment card brand requirements for point-of-sale (POS) receipts.
N/A
Requirement 3.4: Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:
  • One-way hashes based on strong cryptography, (hash must be of the entire PAN)
  • Truncation (hashing cannot be used to replace the truncated segment of PAN)
  • Index tokens and pads (pads must be securely stored)
  • Strong cryptography with associated key-management processes and procedures.

Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.
N/A
Requirement 3.5: Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse:
Note: This requirement applies to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data-encrypting keys-such key-encrypting keys must be at least as strong as the data-encrypting key.
N/A
Requirement 3.6: Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data.
Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.
N/A
Requirement 3.7: Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.
N/A
Failed
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Requirement 4.1: Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following:
  • Only trusted keys and certificates are accepted.
  • The protocol in use only supports secure versions or configurations.
  • The encryption strength is appropriate for the encryption methodology in use.

Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be completed.
Failed
Requirement 4.2: Never send unprotected PANs by end- user messaging technologies (for example, e- mail, instant messaging, SMS, chat, etc.).
N/A
Requirement 4.3: Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.
N/A
Failed

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
N/A
Requirement 6: Develop and maintain secure systems and applications
Requirement 6.1: Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.
N/A
Requirement 6.2: Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.
Failed
Requirement 6.3: Develop internal and external software applications (including web-based administrative access to applications) securely.
Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party.
Requirement 6.3.1: Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.
Failed
Requirement 6.3.2: Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes).
Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle.
Code reviews can be conducted by knowledgeable internal personnel or third parties. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6.
N/A
Failed
Requirement 6.4: Follow change control processes and procedures for all changes to system components.
Requirement 6.4.1: Separate development/test environments from production environments, and enforce the separation with access controls.
N/A
Requirement 6.4.2: Separation of duties between development/test and production environments
N/A
Requirement 6.4.3: Production data (live PANs) are not used for testing or development
N/A
Requirement 6.4.4: Removal of test data and accounts from system components before the system becomes active / goes into production.
N/A
N/A
Requirement 6.5: Address common coding vulnerabilities in software-development processes as follows:
  • Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities.
  • Develop applications based on secure coding guidelines.
Requirement 6.5.1: Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.
Failed
Requirement 6.5.2: Buffer overflows
Failed
Requirement 6.5.3: Insecure cryptographic storage
Failed
Requirement 6.5.4: Insecure communications
Failed
Requirement 6.5.5: Improper error handling
Failed
Requirement 6.5.6: All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).
Passed
Requirement 6.5.7: Cross-site scripting (XSS)
Failed
Requirement 6.5.8: Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).
Failed
Requirement 6.5.9: Cross-site request forgery (CSRF)
Failed
Requirement 6.5.10: Broken authentication and session management.
Note: Requirement 6.5.10 is a best practice until June 30, 2015, after which it becomes a requirement.
Failed
Failed
Requirement 6.6: For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.
Installing an automated technical solution that detects and prevents web- based attacks (for example, a web- application firewall) in front of public- facing web applications, to continually check all traffic.
N/A
Requirement 6.7: Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected part