Avoka Transact Security Architecture. Version 4.0

Size: px

Start display at page:

Download "Avoka Transact Security Architecture. Version 4.0"

Roger Gregory
5 years ago
Views:

1 Avoka Transact Security Architecture Version 4.0

2 Avoka Transact Version 4.0 All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the written permission of the publisher. Products that are referred to in this document may be either trademarks and/or registered trademarks of the respective owners. The publisher and the author make no claim to these trademarks. While every precaution has been taken in the preparation of this document, the publisher and the author assume no responsibility for errors or omissions, or for damages resulting from the use of information contained in this document or from the use of programs and source code that may accompany it. In no event shall the publisher and the author be liable for any loss of profit or any other commercial damage caused or alleged to have been caused directly or indirectly by this document.

3 Table of Contents Part I Introduction 5 Part II Deployment Architecture 6 1 Application... Web Access 7 2 Shared... Service Architecture 8 Part III User Security Management 9 1 Authentication Account... Creation 15 3 Authorization Access... Control 18 5 Security... Auditing 19 Part IV Data Security 20 1 Data Encryption Key Management Data Storage Data Retention Virus Scanning Information... Assurance 23 Part V TransactField App Security 24 Part VI PCI Security 26 Part VII Denial of Service 28 Part VIII System Testing 29 Part IX 30 OWASP Security Threats 1 A1 - Injection A2 - Broken... Authentication and Session Management 30 3 A3 - Cross-Site... Scripting (XSS) 31 4 A4 - Insecure... Direct Object References 32 5 A5 - Security... Misconfiguration 32 6 A6 - Sensitive... Data Exposure 33 7 A7 - Missing... Function Level Access Control 34 8 A8 - Cross-Site... Request Forgery (CSRF) 34 9 A9 - Using... Known Vulnerable Components A10 - Unvalidated... Redirects and Forwards 35

5 1 Introduction Introduction This document describes the security architecture of the Avoka Transact and provides advice for deploying and operating Transaction Manager in a secure manner. There are several important themes people should be considering as they read this document. 1. Providing a secure system is not just about the right technical architecture, but is also about ensuring systems are installed and configured correctly, security procedures are in place and staff are properly trained. 2. The security landscape is constantly changing, and organizations must be keep abreast of these changes to keep their systems secure and security procedures up to date. This will involve organizations updating their security procedures to address the latest social engineering attacks and also ensuring system security patches are up to date. 3. Most organizations have different security risks and their system security requirements should reflect this. Creating and maintaining a highly secure system will incur additional costs, so the systems security requirements should reflect the nature of the risks and their potential impact on the organization. For example a system providing a small business "Contact Us" form will probably not have the same security requirements as a system hosting a Federal Government tender applications. 4. Avoka Transact undergoes continual security penetration tests by international security assessment firms on behalf of our customer's. Through this process Avoka Transact has been substantially hardened. Avoka incorporates advices from a range of leading security firms, continually improving the product. 5. Security is a collaborative process. Avoka Transact is constantly evolving to meet the security requirements of our customers and to adopt emerging industry best practices. If you have specific security requirements you need to fulfill please contact your Avoka Transact account representative so we can start a discussion. It is quite possible the system can be configured to meet your requirements or enhancements can be developed to meet them. Also if you have some good advice or recommendations, we would love to hear them. 5

6 2 Deployment Architecture Deployment Architecture The deployment architecture is a critical component in developing secure systems. It is recommended that organizations use a DMZ style deployment architecture, with layered defense in depth. System components should be deployed into isolated tiers, so if one tier is compromised, the next tier should retains its security integrity. Access between tiers must be minimized to the reduce the surface attack area, using firewalls with restrictions on valid ports and IP addresses. A standard on-premise Transaction Manager deployment architecture is depicted below: Transaction Manager Network Deployment Architecture The standard DMZ deployment tiers include: App Server Tier which host the business application servers Enterprise Information Tier which host the enterprise services and persistent data Internally each Transaction Manager server node is comprised of the following service components. 6

7 Deployment Architecture Transaction Manager Node Services Note in a Shared Service, or Hybrid Cloud, deployment model businesses may have the EIS tier provided in a completely separate data center which Transaction Manager delivers form transaction data into via Web Services. Please see Shared Service Architecture for details of this deployment model. 2.1 Application Web Access The Avoka Transact application server nodes include the Apache Web server which act as a reverse proxy ensuring only configured Transaction applications are exposed to customers and staff. The Avoka Transact application root URLs are detailed in the table below. Root URL Application Customer Access /portal/ Web Portal Yes /web-plugin/ Web Plug-in /field-worker/ TransactField App Yes For customers using TransactField App application performing remote data synchronization /finder/ SmartForm Finder Yes For customers searching for forms Transaction Manager No For business, development and IT staff managing the system Business Reports No For business staff running business reports /manager/ /webreport/ Role For customers using the Self Service Portal, note the root URL is configured at build time. For customers accessing forms via the Web Plug-in. Transact applications which should not be accessible to customers (e.g. Transaction Manager or Business Reports), should be protected by an IP Address white list so only business staff from known networks can access these applications. The Transaction Manager application is not XSS hardened to the same extent as the public facing applications, as it needs to provide facilities to author and edit JavaScript and HTML content online. Please note with standard Transaction Manager deployments there is no requirement to expose Adobe LiveCycle to external web access. 7

8 2.2 Deployment Architecture Shared Service Architecture Organizations can deploy Transaction Manager in a shared service model where all the Transaction Manager system components in a shared service data center (cloud), and enterprise integration performed in a separate client data centers using the Transact Integration Agent (TIA). In this deployment model the Transact Integration Agent will pull form submissions data from the Transaction Manager server using Web Services and integrate it into the departments' business systems. By using an asynchronous pull based delivery model, external organizations do not have to open their firewalls to incoming calls from Transaction Manager. Shared Service Deployment Architecture In highly secure shared service deployment models, it is recommended that Virtual Private Networks be used to secure the server to server communication channels between data centers. Alternatively IP address white lists can be use with the shared Transaction Manager servers to prevent access from unknown networks. 8

3 User Security Management User Security Management Transaction Manager provides a comprehensive user Security Management subsystem which features: configurable Security Managers configurable

9 3 User Security Management User Security Management Transaction Manager provides a comprehensive user Security Management subsystem which features: configurable Security Managers configurable Authentication Providers LDAP integration support SSO integration support Roles and Permissions based authorization model Multi-Tenanted organization support for administrative functions Form, Group and Portal access control facilities for external users In Transaction Manager there are two general categories of users: Internal Users who generally business and IT staff supporting the system, and Public Users who are customers, contractors or field staff using public facing applications Transaction Manager User Types Internal User Security Model Internal or staff user are managed using a sophisticated security model with: roles and permissions based security portal or application access control organization based access control form group access control The main security entities of the internal user security model are depicted in the relationship diagram below. 9

User Security Management Internal User Security Model External User Security Model External or public users have a simplified security model featuring: authentication

10 User Security Management Internal User Security Model External User Security Model External or public users have a simplified security model featuring: authentication portal or application access control form group access control The main security entities of the external user security model are depicted in the relationship diagram below. 10

11 User Security Management External User Security Model 3.1 Authentication User authentication in Transaction Manager Portal applications is managed using the Security Manager subsystem, with provide authentication and authorization services. Configurable Security Managers A portal applications Security Manager will delegate user authentication its configured one or more Authentication Providers. Internally Transaction Manager uses the Spring Security framework to provide low level authentication and authorization support. Conceptually a Transaction Manager Authentication Provider maps to the Spring AuthenticationProviders. 11

User Security Management Security Manager Authentication Provider Local Security Manager The default Security Manager provided with Transaction Manager is the "Local Security Manager".

12 User Security Management Security Manager Authentication Provider Local Security Manager The default Security Manager provided with Transaction Manager is the "Local Security Manager". This Security Manager is configured with a "Local Authenticator" which will authentication users against user accounts stored in the Transaction Manager database. The Security Manager provides configurable options for the maximum number of unsuccessful authentication attempts, after which the user account will be locked out for a configurable period. This prevents automated and manual attacks to guess users' passwords. By default a user account is locked after 5 consecutive unsuccessful login attempts and the lockout duration is set to 15 minutes. Security Manager Max Login Attempts Configuration By setting the lockout duration to 15 minutes it prevents a denial of service attack on user accounts. The system does not leak information about whether the user name or password was incorrect or inform the attacker that they have reached a lockout threshold. The system does not attempt to progressively delay the attackers login attempts by waiting on the user thread, as this can readily be used by attackers to achieve a "Slowloris" style Denial of Service (DoS) attack. High volume automated repeated login attempts are prevented by the Apache Mod Security module. Application login fields and account creation fields use the HTML "autocomplete=off" attribute to ensure browsers do not track this information. Unless configured otherwise Portal applications will use this default "Local Security Manager" for user authentication. To make another Security Manager the default can be configured on the alternative Security Manager. You can also configure Portals individually on which Security Manager they should use. 12

13 User Security Management Configuring Portals to use a Security Manager LDAP Security Manager The system also provides an "LDAP Security Manager" for delegated authentication to LDAP identity management systems. This security manager uses an "LDAP Authentication Provider" to authentication user logins with the the configured the LDAP server via Java JNDI LDAP interface. This security manager will create linking LDAP user accounts in the local database to support users form transactions, but it will never store the user's password in the database and will always rely on the LDAP server to authenticate users. The LDAP Security Manager has optimized support for Microsoft Active Directory LDAP interface which special behavior when performing user bind authentication and user search calls. Microsoft ADSF Security Manager The system includes an "Microsoft ADSF Security Manager" for delegated authentication to external Microsoft Active Directory Federation Services (ADFS) identity management system. 13

14 User Security Management Microsoft ADSF Security Manager SSO Auth Filter SSO Security Manager The system also provides an "SSO Security Manager" for delegated authentication to external identity management systems. This security manager use the SSO Authentication Filter to validate the SSO authentication tokens such as SAML assertions. This security manager then uses a Groovy Authentication Provider to create a linking SSO user account in the local database which link to the external identity management system. Transact Manager supports the configuration of PKI certificates for the verification and decryption SAML tokens. 14

15 User Security Management SSO Certificate management These features enable SSO integration wit out having to deploy Java application code or libraries. Transaction Manager ships with the OpenSAML 2 Java libraries for integration with SAML identity providers. Examples of these types of authentication integration include: SAML based SSO integration with Microsoft Active Directory Federated Services (ADFS) SAML based SSO integration with Sun OpenSSO SAML based SSO integration with Microsoft.Net WS-Security and WS-Federation OpenID SSO integration with Janrain 3.2 Account Creation Transaction Manager provides a number of account creation methods. For organization staff using of the Transaction Manager Administration Console, new user accounts can be created in the Administration Console which are authenticated against the TM database or a configured LDAP service. When new user accounts are created in the Transaction Manager Console it is recommended that the "Change Password On Login" flag is specified. This will force the new user to change their password after they have logged into the application for the first time. With the Self Service Portal and FieldWorker applications, external users can self register using the account creation facilities. 15

16 User Security Management Self Service Portal User Account Creation The account creation facility uses a configurable User Enrollment service which supports: recaptcha security checks to deter robots from creating user accounts automated verification manual administrator account verification processes, with notifications for account verifiers. Portal User Account Enrollment Service The User Enrollment Service is also a pluggable system component so organizations can develop their own customized implementations. Please note that the user account creation feature supports both TM database managed users and LDAP based user accounts. For LDAP user accounts, the use will need to already exist in the configured LDAP directory. When integrating with SSO Identity Management providers, Transaction Manager will generally redirect the users to the account creation facilities provided by the Identity Management system. Once the user has been created by the Identity Management system, they are redirected back to the Transaction Manager application at which point a new linking account is created in Transaction Manager. Password Requirements Local user accounts password requirements can be configured using the Local Security Manager. This can help ensure users do not create weak passwords which are easy to guess. 16

17 User Security Management The available password requirements include: minimum length in characters optional requirement to contain at least one character and one letter optional requirement to contain at least one character non alpha numeric character, e.g. optional requirement to contain at least one upper case and one lower case character must not contain a blacklisted password value, default configuration includes the top 45 most commonly used password values Security Manager Password Options 3.3 Authorization Transaction Manager provides a roles and permissions based security authorization model for system administration functions. Organization administrative users can belong to multiple roles, which in turn contain a series of permissions that will enable these user to access components of the Transaction Manager Administration Console. The Administration Console permission sets are highly configurable with over 140 separate view, edit and remove permissions for key system functions. By default Transaction Manager provides 5 roles: Administrator - for use by system administrators Form Developer - for users who can develop and test forms Operations - for staff who can monitor and manage form transactions Organization User Manager - for staff who can manager user accounts for their organization System Support - for technical support staff diagnosing system issues 17

18 User Security Management Organizations can develop their own customized security roles to meet their own needs. The Transaction Manager authorization model can be used in customized Portal applications if required as each Portal can define its own Permission set. Configuring authorization roles and permission sets 3.4 Access Control Transaction Manager also provides Access Control features including: Organization Access Control Administrative users which are assigned to an organization are only able to access forms, their associated configurations and transaction data for that organization. Organization administrative users cannot view data belonging to other organizations. This data access control is implemented at a Data Access layer in the system. Portal Access Control All users need to be explicitly granted access to Portal applications which feature user authentication. Form Group Access Control Form Groups provide the ability to define groups of forms which are only accessible to users belonging to the same group. With LDAP and SSO user accounts, these users can have a mixture of externaly managed Groups and Transaction Manager Groups to control their access to forms belonging to a Form Group. Form Groups support access control to associated forms, tasks and submissions in the Self Service Portal and Mobile FieldWorker applications. Access control permissions include: o New Forms - access control allowing users to open new forms o Saved / Assigned Forms - access control allowing users to open saved work group forms and group assigned tasks o Completed - Forms - access control allowing users to view completed form submissions 18

19 User Security Management Form Group Access Control 3.5 Security Auditing Transaction Manager provides data access layer security auditing, which will audit all changes to key system entities recording which user made the change, when they did this and what changes were made. This feature enables administrators to track what changes have been made to specific database entities for security auditing purposes. This facility is also extremely useful for doing post incident analysis to determine what changes were made to system configurations prior to an incident. System Security Audit Log 19

20 4 Data Security 4.1 Data Encryption Data Security Transaction Manager provides secure storage of sensitive transaction data and user credentials by cryptographically strong encryption. All sensitive user form transaction data (form XML) is stored in the Transaction Manager database as encrypted BLOB values. This data encrypted with the Advanced Encryption Standard (AES) algorithm using a 256-bit key and Cipher Block Chaining (CBC). All Transaction Manager managed user passwords are stored in the system database as SHA-512 hash values, using a randomly generated salt and with greater than 1,000 hashing iterations. When users attempt to log in, their plain text password value is hashed and compared to the hashed value stored in the database. In this manner plain text password values are not stored in the system. These encryption hashing algorithms are approved in US Government FIPS and Australian Government ISM: The Transaction Manager cryptographic sub-system is a tamper proof module. The Java byte code of this module has been obfuscated using an advanced 3rd generation byte code obsfucation system to defeat modern Java decompilers. The cryptographic sub system also had boot loading protection, and will not initialize if the module has been modified. 4.2 Key Management Transaction Manager incorporates a encryption key management system for the symmetrical encryption of user entered transaction data. Each client organization of the system has its own set of secret encryption keys. These organization secret keys are stored in a Java KeyStore (JKS) which is maintained in the Transaction Manager database as binary BLOB record values. Access to these key stores is protected with a system master secret key. All organization secret key values are randomly generated 256 bit values. These secret key values are never revealed in the application user interface or are logged to the file system. Automatic roll over of secret key values can be configured on an organization level. When secret keys are rolled over, a new key created and used for new transactions, while the old keys are kept to enable access to previous transaction data. The system does not attempt to re-encrypt transaction data when organization keys are rolled over as this may interrupt service operations 20

21 Data Security Organization Level Encryption and Key Management Settings 4.3 Data Storage Transaction Manager also supports plug-able Submission Data Storage services, which can be used to store sensitive user transaction data in external systems. Organizations with very high data security requirements can look at using their own storage service implementation to store user transaction data in their own systems. By default Transaction Manager provides Submission Data Storage services for: Transaction Manager database storage Amazon S3 storage 4.4 Data Retention Transaction Manager provides data retention policies for the deletion of sensitive user form submission data. These data retention policies are specified at the organization level with global system defaults used if not specified. Organisation Data Retention Policies Global system data retention policy configuration is depicted below. 21

22 Data Security Configuring Data Retention Policies All sensitive binary user form submission or form prefill data is stored in separate child database tables so they can be excluded from database backups. This can be used to prevent sensitive data from being persisted to backup storage, at which point it can be very difficult to destroy. These sensitive user data tables include: submission_data submission_history_data submission_extract_data file_upload_data request_log_data error_log_data It is recommended that Transaction Manager systems which handle very sensitive data or which have strict privacy requirements should be configured to purge this data once it has been delivered to the delivery endpoint (back office system). For these systems, configuring the maximum transaction data age to a couple of days will provide system administrators with a few days to recovers form submission data, if there is some data loss failure with the back office system. 4.5 Virus Scanning Transaction Manager supports users uploading file attachments with their form submissions. This poses a potential attack vector for computer viruses, which could be delivered into back office systems or business users. To mitigate this risk, file attachments are stored in the database in encrypted BLOB records and are never written to disk where they could be potentially executed. 22

23 Data Security When users upload attachments to the server, the files are immediately scanned by online virus scanners to prevent viruses from entering the system. If the virus scanner is temporarily offline, users can still upload attachments but the form submission will not be deliverable until the virus scanner comes back online and verifies that the attachments do not contain any viruses. Supported virus scanners include: ClamAV Symantec Protection Engine Symantec Scan Engine 4.6 Information Assurance The submission data delivery Web Services incorporate data delivery confirmation steps, where by the Submission Delivery Web Service consumer must reply with an SHA-256 hash of the delivered form XML data and file attachment data to the Transaction Manager server. All Web Service data delivery services are configured to run over SSL connections. For organizations with very sensitive data or strict privacy requirements, web service delivery should be conducted over site to site Virtual Private Networks (VPN). 23

24 5 TransactField App Security TransactField App Security TransactField App is self contained user application for interacting with SmartForms on a variety of devices including PCs, ipad and Android tablets. This application enables known users to work with SmartForms while disconnected from networks. This is very useful for field staff working in remote locations without any network coverages. TransactField App has the same security requirements as the Web Portal: users must be authenticated to access the application, users must be authorized to access the application, and user entered data, such as saved forms must be securely encrypted. These security requirements must also be maintained while the application is in offline mode. Users must be authenticated before accessing the application and users saved form data must be securely encrypted. When the TransactField application has network connectivity to the Transaction Manager server. However if there is no connectivity to the server, the application will authenticate user against a locally stored SHA-256 hash of their password. User entered data, such as saved form XML is stored in a locally database encrypted using the AES-128 algorithm. All communications between the TM server and TransactField App are performed over HTTPS, with calls being authenticated against the users credentials on the server. Online Authentication To access the TransactField application users must initially authenticate against a Transaction Manager server. The TransactField application also support user account creation in the application. When a user logs in with TransactField App a REST authentication service is called via HTTPS, sending the entered username and password. Transaction Manager authenticates the user against the configure Security Authentication service (which could be either TM database account or a LDAP server) and responds accordingly. From that point, all calls to Transaction Manager REST services are secured with standard HTTP Basic Authentication (by including an Authorization header containing Base64 encoded credentials) and protected from man-in-the-middle attacks using SSL. An authentication sequence diagram is provided below. Field Worker with LDAP Authentication Sequence With TransactField App and all Transaction Manager applications it is critical that HTTPS is configured for all communications. 24

25 TransactField App Security Offline Authentication Once a user successfully authenticates against a Transaction Manager server, the users password is stored as a SHA-256 hash value in the local application device storage. On ios and Android devices application storage has security protection features preventing data access by other applications. Please see the Apple ios Security white paper below: When TransactField App is offline, and cannot connect to Transaction Manager, users are authenticated against the locally stored user credentials. The user entered plain text password is SHA-256 hashed and compared to local credentials. The user entered password is never stored on the devices as plain text. When offline, TransactField App compares a hash of your entered password against against a hash that was created (using SHA 256 algorithm) and stored with your username when you last logged in successfully online. The entered password itself is never stored on the device, but is used as a secret key in memory for 128 bit AES data encryption / decryption. Local Data Encryption All local form submission data, user profile information, tasks and saved forms are stored as encrypted using AES-128 bit symmetrical encryption with the user's plain text password uses as the secret key. 25

26 6 PCI Security PCI Security The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e-purse, ATM, and POS cards. Transaction Manager supports PCI DSS through its design features of never storing card holder data or transmitting cardholder data across open public networks. Transaction Manager error logging facilities are designed to ensure cardholder data is also not accidentally logged in a payment error scenario. Transaction Manager integrates with Payment Gateway providers using two models: 2 Party Model (Server to Server) Where TM makes a direct server to server call to the Payment Gateway provider to perform a transaction 3 Party Model (User Redirect) Where Transaction Manager redirects the user away to the Payment Gateway provider's web site where they perform the payment transaction, after which the are returned to the Transaction Manager application Each of these models has different advantages and disadvantages. The 2 Party Model provides a faster and more consistent user experience, as the user never leaves the Self Service Portal. However, as cardholder details pass through the Transaction Manager systems network, the system may require PCI certification depending upon the payment transaction volumes and the Payment Gateway provider's requirements. The 3 Party Model does not require any PCI compliance as no cardholder data passes through the Transaction Manager systems network. However, the disadvantage is that the user experience is not as consistent across the applications and tends to be slower. Supported 2 Party Payment Gateways include: BizGate BPoint CommWeb NAB SecurePay TNS Westpac Supported Hosted 3 Party Gateways include: BizGate BPoint NAB PayPal SecurePay TNS 26

27 PCI Security Westpac WoldPay 27

28 7 Denial of Service Denial of Service Denial of Service (DoS) attacks ( can take many forms including: direct attack by targeting system web servers and network infrastructure deploying viruses/worms onto the system's servers indirect attack such as targeting domain name servers social engineering attacks Each of the DoS attack risks need to be mitigated by different means. Organizations also need to assess whether DoS is a significant risk for their system, and what level of effort should be expended to mitigate this risk. Web Service DoS DoS attacks on web servers and network infrastructure should be mitigated on the network perimeter preferably using a smart switches such as F5 BIG-IP or Cisco CSS. This will help ensure the more sensitive application servers and enterprise information systems deeper in the network are not impacted. Avoka Transact provides layered defense against DoS attacks with: Apache Mod Security ( providing a application firewall protecting against common DoS attacks such as Slowloris which will exhaust server resources Transaction Manager Quality of Service (QoS) features will deflect very high request loads at configurable thresholds 28

29 8 System Testing System Testing Non Production server such as Staging, Test and Development should be configured securely. Organizations should NOT perform system testing on systems without SSL configured or with selfsigned certificates because this will invalidate system testing. This will also make it more difficult to trouble shoot configuration issues as these servers will not accurately reflect production. Please note that self-signed certificates are generally not recognized by Adobe Reader for security reasons, and these types of certificates also cause issues with web service integrations. Some orgnizations attempt to save a few hundred dollars by using self-signed certificates, but will then spend many thousands of dollars and time chasing down non-existent issues during testing. A best practice is for organizations to use sub-domains for non-production systems, for example: -> Production -> Testing -> Development It is recommended that organizations set up IP address white lists so that these servers can only be accessed from known networks. Please Note: Wildcard SSL certificates for sub-domains can be used to save cost, however they do have additional risks of: If one server or sub-domain is compromised, all sub-domains may be compromised. If the wildcard certificate needs to be revoked, all sub-domains will need a new certificate. 29

30 9 OWASP Security Threats OWASP Security Threats Security threats to information systems are wide ranging and include: account or identity theft theft of intellectual property tampering with data denial of service being used as an attack vector to target another system When considering the security architecture it is important to keep these various threats in mind. The Open Web Application Security Project (OWASP) provides a Top Ten Project which identifies the most important security issues that organizations should be addressing. The Transaction Manager system addresses these Top Ten security items through its technical architecture and through correct deployments. A summary of how the OWASP Top Ten Project 2013 risks are addressed is provided below. 9.1 A1 - Injection Security Risk 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 unauthorized data. Risk Mitigation Transaction Manager mitigates database SQL injection attacks through its Object Relational Management layer (Apache Cayenne). This layer uses JDBC prepared statements for all database interactions which correctly escapes input entered by the user. Access to OS shell commands via Groovy services are prevented with by a customized Groovy run-time which prevents executing shell commands. 9.2 A2 - Broken Authentication and Session Management Security Risk Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users identities. Risk Mitigation Transaction Manager uses best practice authentication and session management techniques to mitigate these risks. While this is a broad topic, risk management features provided by the system include: user credentials (passwords) managed by Transaction Manager are stored in the database as SHA512 hash values, using a randomly generated salt and with greater than 1,000 hashing iterations 30

31 OWASP Security Threats system error and security auditing logs explicitly prevent logging of user password values user created account passwords have a configurable complexity checks to ensure users do not create trivial passwords. These complexity checks include minimum length, mixed alpha-numeric characters, require special character, required mixed case values and a password value black list HTML form login and account creation fields use the HTML autocomplete=off attribute to ensure browsers do not track this information change password and change address features require user to confirm the changes with their existing password user login and user account creation flows will recreate the session to prevent session fixation attacks session IDs are not exposed in the URL, and are maintained via HTTPS only secure cookie values with HTTPOnly flag to prevent JavaScript from accessing these values all system user interactions occur over HTTPS connections the user password recovery facility does not leak login name information to attackers the user password recovery facility resets the password to an 8 character randomly generated alphanumeric value user accounts have a configurable 5-attempt lockout facility to prevent attackers from guessing trivial passwords the user login facility does not reveal valid user name information to attackers, or user account lockout status user log out facilities clear user session, and by default user sessions will timeout after 30 minutes of inactivity 9.3 A3 - Cross-Site Scripting (XSS) Security Risk XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and 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. Risk Mitigation Transaction Manager uses a number of techniques to mitigate this risk. Risk management features provided by the system include: portal pages use the Apache Click web application framework which automatically escapes HTML content in web applications request parameter filtering to prevent URL XSS injection filter portal user entered values against a XSS black list, based on the OWASP XSS Filter Evasion Cheat Sheet recommendations form XML data extract value filtering against XSS values black list prevent XSS exploit via POST of XML form prefill data ensure session cookies are secure and use the HTTPOnly flag to prevent JavaScript from being able to access these values 31

32 OWASP Security Threats Please note the Transact Management Console application is used edit HTML content including JavaScript, and does not have the same XSS black list prevention the public facing Portal applications do. We recommend that Management Console application should not be public facing, as as a minimum should be protected from public access through an IP address white list. 9.4 A4 - Insecure Direct Object References Security Risk 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. Risk Mitigation To mitigate this risk the Self Service Portal uses cryptographically strong 128-bit pseudo random numbers for object references on secured and unsecured paths. The Transact applications uses a number of strategies to mitigate this risk: all user interaction takes place in secure authenticated sessions data access layer security to prevent users from accessing system information they are not authorized to view, portals Portal and Field Worker shared submission data access control using authenticated user and form group access control security model Management Console user roles and permissions security model prevents users from accessing parts of the system they are not authorized to use organizations can also use IP address white lists to prevent parties from accessing the Transact Management Console application from unknown sites 9.5 A5 - Security Misconfiguration Security Risk Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application. Risk Mitigation Ensuring Transaction Manager systems are securely configured is a team effort. Organizations need to design the system infrastructure to enable security. The software needs to be installed correctly and should be independently verified. In addition to this, organizations need to put in place processes which review security alerts and keep their systems properly patched. To support this effort Avoka Technologies and Transaction Manager provide: Transaction Manager Installation Guides which detail how to correctly deploy and configure the system, and include Installation Checklists which specifically cover security configuration issues. Transaction Manager Setup Wizard helps to ensure repeatable installs and includes sensible security defaults. For example the root administrator password must be changed once the administrator logs in for the first time. 32

33 OWASP Security Threats Avoka provides quarterly Transaction Manager updates to customers, which incorporates security fixes and system library and run time updates. The latest Oracle Java 1.7 update is generally provided with each release and also tested against the latest Apache 2.2.x production release. Avoka will provide security advisories for customers if security issues are identified with specific versions of Transaction Manager. 9.6 A6 - Sensitive Data Exposure Security Risk 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. Risk Mitigation Sensitive data in transit is protected by a strong SSL cypher suite configuration. We recommend 2024 bit key lengths for SSL key exchange and 256 bit AES symmetrical encryption. The server cypher suite configuration must not allow the client to negotiate down the cypher strength. Sensitive data at rest is protected by Transaction Manager secure storage subsystem. This uses a combination of cryptographically strong encryption, encryption key rollover and configurable data retention policies to prevent access sensitive data. Data encryption features include: All sensitive user form transaction data (form XML, file attachments, PDF receipt) is stored in the Transaction Manager database as encrypted BLOB values. This data is encrypted with the Advanced Encryption Standard (AES) algorithm using a 256-bit key and Cipher Block Chaining (CBC). All Transaction Manager managed user passwords are stored in the system database as SHA-512 hash values, using a randomly generated salt and with greater than 1,000 hashing iterations. When users attempt to log in, their plain text password value is hashed and compared to the hashed value stored in the database. In this manner plain text password values are not stored in the system. Repeated login attempts will result in the user account being locked to prevent brute force password guessing. Client transaction data symmetrical encryption keys can be configured to automatically rollover, so that a theoretically compromised encryption key will be constrained to a particular system client for the configured duration. Please note transact data symmetrical encryption keys are managed automatically by the system and are not exposed to any system users. Data retention policies can be configured at a global or client organization level so that sensitive transaction data is purged from the system as soon as it has been delivered. This limits the potential access to sensitive transaction. It is recommended that Transaction Manager systems which handle very sensitive data or which have strict privacy requirements should be configured to purge this data once it has been delivered to the delivery endpoint (back office system). For these systems, configuring the maximum transaction data age to a couple of days will provide system administrators with a few days of XML form transaction data, if there is some data loss failure with the back office system. All sensitive transaction BLOB data is stored in separate child database tables so they can be excluded from database backups. This can be used to prevent sensitive data from being persisted to backup storage, at which point it can be very difficult to destroy. These sensitive user data tables include: submission_data 33

34 OWASP Security Threats submission_history_data submission_extract_data file_upload_data request_log_data error_log_data 9.7 A7 - Missing Function Level Access Control Security Risk 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. Risk Mitigation The Transact Management Console application mitigates this risk through its user authentication and authorization security framework. All access to the Transact Management Console application requires the user to be authenticated and granted access to use this application. In addition Transaction Manager protects restricted resources through its user roles and permissions based security authorization framework. Users of the Management Console need to be granted roles which in turn will have a set configured application permissions. Only by having the correct permission set will users be able to access restricted resources. The Management Console permission sets are highly configurable with over 140 separate view, edit and remove permissions for key system functions. By default Transaction Manager provides 3 roles: Administrator - for use by system administrators Form Developer - for users who can develop and test forms Operations - for staff who can monitor and manage form transactions Organization User Manager - for staff who can manager user accounts for their organization System Support - for technical support staff diagnosing system issues Organizations can develop their own customized security roles to meet their own needs. The Self Service Portal and Mobile FieldWorker applications mitigate this risk through the same user authentication framework and security authorization security model based on portal and form group access controls. User must be explicitly granted access to portal applications and security groups before the can accessing protected resources. 9.8 A8 - Cross-Site Request Forgery (CSRF) Security Risk 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 34

35 OWASP Security Threats application thinks are legitimate requests from the victim. Risk Mitigation Transaction Manager mitigates this vulnerability by incorporating one time use cryptographically strong 128-bit tokens into HTML and PDF SmartForms and also for HTML forms inside the Self Service Portal. Self Service Portals support configurable 'X-Frame-Options' HTTP header to prevent Clickjacking attacks. 9.9 A9 - Using Known Vulnerable Components Security Risk 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. Risk Mitigation The Avoka Transact development process reviews the system components with each release to identify any security related issues. Each release will often include a number of updated components because of fixed security vulnerabilities or new feature capabilities. A manifest of dependent components is maintained by the development team. The most important system components are the Oracle Java Runtime environment, which is updated at least quarterly, and the Apache HTTP web server which is updated based on a regular based depending upon the security vulnerabilities which have been fixed A10 - Unvalidated Redirects and Forwards Security Risk 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. Risk Mitigation Transaction Manager mitigates this risk by not using generic redirect or forward facilities in its applications. User flows where users are redirected through login pages for authentication use session base redirect facilities, rather than generic URL parameters which could be hijacked. 35

Copyright

Copyright 1 Security Test EXTRA Workshop : ANSWER THESE QUESTIONS 1. What do you consider to be the biggest security issues with mobile phones? 2. How seriously are consumers and companies taking these threats?