The OWASP Top 10 for 2013 is interesting reading for application developers, web site builders and end users. The internet has many good features, but it is not a safe place if you are not aware.
|Each year, the Arts Management team reviews the top 10 and, for those that are applicable, ensures that the web sales module provides a defence against the top 10 per PCI standard 6.5. Requirements are posted here. Merchants should also be aware of these.|
|Description||Thestre Manager Implementation|
|A1||SQL Injection||Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
OWASP's preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface.
In Theatre Manager, all web pages access the web listener using a parameterized API (generally html form) and each parameter is scrubbed on the way to the web listener for specific values. Only acceptable parameters are verified. Unacceptable parameters are rejected and ignored.
|A2||Broken Authentication and Session Management||Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.
If the web listener notices that the cookie comes back and contains an unexpected date and time setting, then it discards the request and resets the user.
There are no session IDs in any URL.
|A3||Cross-Site Scripting (XSS)||
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
|A4||Insecure Direct Object References||A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
Theatre Manage does not allow direct access to any object in the database through the use of an API. Users cannot retrieve data in an unauthorized way as all queries are done via a controlled API.
|A5||Security Misconfiguration||Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.
The primary preventative measure for this is PCI security scans and upgrading of Theatre Manager components on a regular basis and following any implementation notes.
Users are encouraged to install operating system upgrades as they are made available and to turn on automatic checking on all workstations. On servers, the practice is to verify weekly for updates and install on a controlled basis.
Theatre Manager regularly offers the latest updates to web servers and SSL security patches when they are made available. Configuration files are hardened as vulnerabilities are detected (example: prevent directory listings is the default browser config).
|A6||Sensitive Data Exposure||Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.
Theatre Manager handles encryption of the key card information and recommends shredding of unused data after a period of time. All credit card information is re-encrypted on a periodic basis per PCI compliance and the only information retained is per PCI standards.
Theatre Manager web services use SSL for all traffic, which means using port 443 to the Apache server, and having a valid SSL certificate.
Ensuring the SSL certificate is current is a responsibility of the monthly PCI scan process, and we contact customers when they are ready to expire.
Users are encouraged to define a card retention period where TM will automatically shred cards based on their policy.
|A7||Missing Function Level Access Control||Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.
This does not directly apply to Theatre Manager's web services due to the APIs used to control access to the system -AND- the very limited number of pages in the Apache directory which are used exclusively for the singular function of web sales.
Accessing the limited number of web pages in the htdocs directory in a direct manner does nothing unless they are processed by a web services. Further, all requests are sent through a specialized Apache module that adds additional tokens not known visible in the browser and reroutes the URL and does some NAT translation of its own.
|A8||Cross-Site Request Forgery (CSRF)||A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
Theatre Manager does not allow access to the database except via API. It also forces a timeout for inactivity and injects a unique form token key for each HTTP POST request.
The cookie is time sensitive and is unique for each request sent from the server and back from the client. It is encrypted and contains other non-visible data that must be verified upon receipt back at the server. Failure to meet the verification requirements causes rejection of the request and the process to start over. Absence of a properly formatted and encrypted cookie rejects the request and starts over.
The form token is a unique encrypted time-sensitive field that is placed into each web page by the server. When a form is submitted, the server checks the form token with what was sent out. If it does not match, the patron is sent to a 'safe' landing page. Currently, Theatre Manager sends patrons who are logged in to the 'home' page and those that are browsing anonymously to the 'event listing' page. No form can be submitted twice.
|A9||Using Known Vulnerable Components||Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.
Theatre Manager is designed to detect the version of significant components and will not start if the database version, web server version, or other significant components are insufficiently current.
Most importantly, Apache is regularly reviewed and updated with security patches.
|A10||Unvalidated Redirects and Forwards||
Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
Theatre Manager does not use redirects to any unknown source in any commerce web page. All URLs returned by the server are specific to each API. Requests for APIs that do not exist return a proper 404 HTTP response (not found)