NB: Make sure any testing uses only test cards and never use real credit cards in a non-production environment.
When altering any code that deals with credit card information, it is important that key tests are performed to ensure the software remains in PCI compliance. All security patches and system and software changes need to be tested before being deployed, including but not limited to testing for the following.
| PA-DSS | Requirement | Testing Procedure | What we do in Theatre Manager |
| 5.1.1.1 | Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.) | Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.) | When using the Theatre Manager application, input validation for almost all fields is done through the specialzed protected class called oEditCheck which does specialized validation on inputs. Every text input field in the system will invoke a method from this class. Test your code in the 'evAfter' clauses to make sure that it does for all entry fields.
Since the Theatre Manager 'fat' client is a compliled application and not web based, much of this PCI requirement does not apply. The Theatre Manager commerce web server uses the same edit routines as the 'fat' client but has cleansing routines for parsing data prior to it hitting the edit routines. Refer to OWASP below. |
| 5.1.1.2 | Validation of proper error handling | Validation of proper error handling | particularly for credit card information, make sure that data is not diplayed back to an operator or customer that shows the entire PAN when errors occur. Refer to 5.1.1.5 for routines to display protected information appropriately. |
| 5.1.1.3 | Validation of secure cryptographic storage | Validation of secure cryptographic storage | all card information is updated in the database using a single protected classes called tfCreditCard.$reviseCreditCard. All access to cards is through that protected class and any use will ensure that cards are encrypted properly. However, after a test using credit cards, do an sql query on CD_CARD_NO to make sure nothing exists in clear text. |
| 5.1.1.4 | Validation of secure communications | Validation of secure communications | Card authorization occurs in via https and the merchant providerl. The protected classes oCCAuthorize handle all https communication and will not respond unless the merchant provider supports TLS 1.2 or later (high encryption) |
| 5.1.1.5 | Validation of proper role-based access control (RBAC) | Validation of proper role-based access control (RBAC) | Access to card information is managed in Theatre Manager through a protected class called oSecurity. All display of credit card information is done through another protected class called oEditCheck.$fetchCreditCard which converts all items for display using RBAC. |
For web based components (i.e oWebComxxx), ensure that OWASP vulnerabilities are also tested and verified per PA-DSS standards 5.2.1-5.2.10. This section in the PA-DSS document repeats the current top 10 OWASP vulnerabilities (circa 2010) and are repeated below. Make sure to test those as well as review OWASP to keep this section of the test requirements evergreen.
Above all, read the OWASP top 10 when developing a Web API because they explain clearly what things mean and strategies how to avoid.
| PA-DSS | Requirement | Testing Procedure | What we do in Theatre Manager |
| 5.2.1 | Cross-site scripting (XSS). | Cross-site scripting (XSS) (Validate all parameters before inclusion.) | Look at any incoming parameters for javascript and other characters and simply removes them. We have determined that there is no valid need to have words like <script> in a enterable fields like name or address. Refer to rtWebSales.cleanUpParameters |
5.2.2 |
Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws, as well as other injection flaws. | Injection flaws, particularly SQL injection (Validate input to verify user data cannot modify meaning of commands and queries.) | none of the API's in any oWebComXXX accept SQL for input. Make sure each parameter is checked for existance and validity using oWebComBase.$getWebParameters. |
| 5.2.3 | Malicious file execution | Malicious file execution (Validate input to verify application does not accept filenames or files from users.) | ensure that oWebComXXXX does not accept file names and does not read the file system. All input is sanitized and merged into variables of fixed length (the nature of Omnis Studio) so buffer overflows are not possible. |
| 5.2.4 | Insecure direct object references. | Insecure direct object references (Do not expose internal object references to users.) | OWASP recommends use of API's to address this issue. Build a new oWebComXXX for each web function. |
| 5.2.5 | Cross-site request forgery (CSRF). | Cross-site request forgery (CSRF) (Do not rely on authorization credentials and tokens automatically submitted by browsers.) | TM puts tokens in the cookie that are unique per session and per request. |
| 5.2.6 | Information leakage and improper error handling | Information leakage and improper error handling (Do not leak information via error messages or other means.) | ensure all messages are read from a table (tmError.txt) and only provide user direction, not system state. |
| 5.2.7 | Broken authentication and session management | Broken authentication and session management (Properly authenticate users and protect account credentials and session tokens.) | use the build in tCookie function to read and write cookies. Cookies are 3DES encrypted and contain time information to know if the patron is going back or forward. Requests that cannot be decrypted and have stale information are discared before they get to the oWebComXXX |
| 5.2.8 | Insecure cryptographic storage | Insecure cryptographic storage (Prevent cryptographic flaws). | make sure all internal keys and pw are never clear text in variables. Always store encrypted and use decryption to get the true value. |
| 5.2.9 | Insecure communications | Insecure communications (Properly encrypt all authenticated and sensitive communications.) | Implemented using TLS for the entire web site. Specific tokens like cookies and CC data are AES256 encrypted within the TLS layer. Always test for this. |
| 5.2.10 | Failure to restrict URL access. | Failure to restrict URL access (Consistently enforce access control in presentation layer and business logic for all URLs.) | All access to the web components are throught an API call. These are routed through a single apache module that adds some tokens of its own and redirects the URL to a specific machine, changes the IP and crosses a firewall from the DMZ using NAT. There is never direct access to any oWebComXXX |