Payment Card Industry Report

 Scan Name: Webscantest-includeAPIs-reactjs
 Date: 8/24/2016 11:24:23 PM
 Authenticated User: testuser
 Total Links / Attackable Links: 416 / 416
 Target URL: 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.1 (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.

Note: 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, 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—for example, use secured technologies such as SSH, S-FTP, TLS, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.
Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016.
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. Use technologies such as SSH, VPN, or TLS for web-based management and other non-console administrative access.
Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016.
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 the full 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)
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 (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.
Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016.
Passed
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
Passed

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.
Passed
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 before production systems become active
N/A
N/A
Requirement 6.5: Address common coding vulnerabilities in software-development processes
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
Passed
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 parties.
N/A
Failed

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need to know
Requirement 7.1: Limit access to system components and cardholder data to only those individuals whose job requires such access.
Requirement 7.1.1: Define access needs for each role, including:
System components and data resources that each role needs to access for their job function
Level of privilege required (for example, user, administrator, etc.) for accessing resources.
N/A
Requirement 7.1.2: Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.
N/A
Requirement 7.1.3: Assign access based on individual personnel’s job classification and function.
N/A
Requirement 7.1.4: Require documented approval by authorized parties specifying required privileges.
N/A
N/A
Requirement 7.2: Establish an access control system for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.
N/A
Requirement 7.3: Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.
N/A
Failed
Requirement 8: Identify and authenticate access to system components
Requirement 8.1: Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components.
Requirement 8.1.1: Assign all users a unique ID before allowing them to access system components or cardholder data.
Passed
Requirement 8.1.2: Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
N/A
Requirement 8.1.3: Immediately revoke access for any terminated users.
N/A
Requirement 8.1.4: Remove/disable inactive user accounts within 90 days.
N/A
Requirement 8.1.5: Manage IDs used by vendors to access, support, or maintain system components via remote access as follows:
Enabled only during the time period needed and disabled when not in use.
Monitored when in use.
N/A
Requirement 8.1.6: Limit repeated access attempts by locking out the user ID after not more than six attempts.
N/A
Requirement 8.1.7: Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
N/A
Requirement 8.1.8: If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.
N/A
Passed
Requirement 8.2: In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:
Something you know, such as a password or passphrase
Something you have, such as a token device or smart card
Something you are, such as a biometric.
Requirement 8.2.1: Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.
N/A
Requirement 8.2.2: Verify user identity before modifying any authentication credential-for example, performing password resets, provisioning new tokens, or generating new keys.
N/A
Requirement 8.2.3: Passwords/phrases must meet the following:
-Require a minimum length of at least seven characters.
-Contain both numeric and alphabetic characters.
Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.
N/A
Requirement 8.2.4: Change user passwords/passphrases at least once every 90 days.
N/A
Requirement 8.2.5: Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used.
N/A
Requirement 8.2.6: Set passwords/phrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.
N/A
N/A
Requirement 8.3: Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance).
Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication.
Examples of two-factor technologies include remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; and other technologies that facilitate two-factor authentication.
N/A
Requirement 8.4: Document and communicate authentication procedures and policies to all users including:
-Guidance on selecting strong authentication credentials
-Guidance for how users should protect their authentication credentials
-Instructions not to reuse previously used passwords
-Instructions to change passwords if there is any suspicion the password could be compromised.
N/A
Requirement 8.5: Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:
-Generic user IDs are disabled or removed.
-Shared user IDs do not exist for system administration and other critical functions.
-Shared and generic user IDs are not used to administer any system components.
Requirement 8.5.1: Additional requirement for service providers only: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.
Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.
Note: Requirement 8.5.1 is a best practice until June 30, 2015, after which it becomes a requirement.
N/A
N/A
Requirement 8.6: Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:
-Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
-Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
N/A
Requirement 8.7: All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:
-All user access to, user queries of, and user actions on databases are through programmatic methods.
-Only database administrators have the ability to directly access or query databases.
-Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).
N/A
Requirement 8.8: Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.
N/A
Passed
Requirement 9: Restrict physical access to cardholder data
N/A

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 10.4: Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.
Note: One example of time synchronization technology is Network Time Protocol (NTP).
N/A
Requirement 10.5: Secure audit trails so they cannot be altered.
N/A
Requirement 10.6: Review logs and security events for all system components to identify anomalies or suspicious activity.
Note: Log harvesting, parsing, and alerting tools may be used to meet this Requirement.
N/A
Requirement 10.7: Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup).
N/A
Requirement 10.8: Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.
N/A
N/A
Requirement 11: Regularly test security systems and processes
N/A

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security for all personnel
N/A