Web Security

The following list is based on: The Ten Most Critical Security Vulnerabilities for Java Enterprise Applications from OWASP

 Note: This is not a certification of compliance or an offer to indemnify anyone from damage caused by a violation of any of these attacks.

 A1 – Cross Site Scripting (XSS)

XSS flaws occur whenever a Java EE application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim’s browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.

 Tolven: In general, user-entered fields are encoded before being sent to the browser. This is inherent in the underlying Web architecture used by Tolven. There are other places where encoding must occur directly by Tolven code. Customer-defined pages can also be vulnerable and should also be reviewed for XSS. All pages in Tolven are xhtml thus making attacks using HTML syntax weaknesses more difficult.

Tolven prefers to encode (escape) user-entered data that is output to the browser rather than trying to validate that data input by users is not harmful. In other words, encoding renders potentially harmful text safe regardless of what it looked like when it was stored.

A2 – Injection Flaws

Injection flaws, particularly SQL injection, are common in Java EE applications.
Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker’s hostile data tricks the interpreter into executing unintended commands or changing data.

 

Tolven: Queries in tolven never add user input directly into the query string (eg dynamic queries). All queries use strongly-type query parameters. As an additional safeguard, all applicable queries are qualified by account thus preventing cross-account access from a partial-insider (someone with legitimate access to one account but not other accounts).

A3 – Malicious File Execution Code

Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect any Java EE framework which accepts filenames or files from users.

Tolven: Only file uploads provide an opportunity for an attacker to specify a filename in Tolven. Otherwise, this attack does not apply to Tolven. The file upload mechanism is provided by the Apache file upload library. The resulting file content is never executed by Tolven. Tolven does not explicitly scan uploaded documents for harmful content. That function is left to the code that interprets the content when displayed.

 

A4 – Insecure Direct Object Reference
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

 

Tolven: The account mechanism in Tolven is responsible for preventing this type of attack. The most an attacker can do is to access other information within their own account. The server simply ignores (never sees) the result of queries directed to another account because the user’s account id is stored on the server and used in all queries. There are exceptions to the account-boundary rule but these only apply to general lookup and validation data, not to sensitive data.

A5 – Cross Site Request Forgery (CSRF)
A CSRF attack forces a logged-on victim’s browser to send a pre-authenticated request to a vulnerable Java EE application, which then forces the victim’s browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.

Tolven: This type of attack is difficult to guard against. Tolven mitigates this risk in three ways:
a. All submissions to the server occur in two phases. The first phase updates the server in a sandbox (Tolven calls this work in process). The second phase, which cannot update the server, allows the user to review all data that is about to be acted upon before the user “submits”. The submit action does not upload any data but rather is directs the server to process the data from the sandbox. In this way, a user never blindly submits data to the server.
b. Server state prevents action to be taken on previously submitted data. In other words, even though the browser disables the “Submit” button in these cases, a script that has been tampered with would not be able to affect a re-submission.
c. Sensitive submissions can be flagged to require a signature (user password) to accompany the submission.

A6 – Information Leakage and Improper Error Handling
Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data or conduct more serious attacks.

Tolven: As an open-source solution, some technical details are impossible to hide from an attacker.
However, Tolven makes an effort to avoid revealing information that can aid an attack. For example, the
message displayed when a user supplies an incorrect password is: “Invalid username or password!” thereby revealing nothing specific about the actual error.

A7 – Broken Authentication and Session Management
Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users’ identities.

Tolven: Tolven follows the advice provided on this section: Use the standard session
management mechanism, Do not allow the login process to start from an unencrypted page, etc.

A8 – Insecure Cryptographic Storage
Java EE applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

Tolven: This is a large area but Tolven never stores passwords in clear-text and, with the exception of optional password recovery, has no way to recover a password from any type of storage.

A9 – Insecure Communications

Java EE applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

Tolven: All Tolven data (except static scripts, CSS and icons) are accessed via HTTPS (SSL).

A10 – Failure to Restrict URL Access

Frequently, a Java EE application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

Tolven: All pages except static resources such as icons and scripts require protected (HTTPS) and authenticated (logged in user) access. No Personal Health Information is ever protected simply by hiding the URL.

 

Back to the top
Back to the top

Support & Consulting

Tolven offers a number of training packages and access to an ongoing Webinar series to enable you to make the most of the Tolven Platform and application framework. For ongoing support and maintenance, we offer four levels of technical support to enable you to select what's right for your organization.

Visit TolvenHealth.com

In Production

The Tolven Platform is rapidly becoming the most widely adopted open source solution for healthcare information technology globally. Tolven clients in Europe, North America, and Asia are leveraging the breadth of solutions the Tolven technology can support to serve their needs.

See sample client descriptions

The Tolven Platform

The Tolven Platform takes advantage of a broad, flexible, and open source architecture that gives healthcare and life sciences professionals as well as patients the information they need in an open and extensible solution. The Tolven Platform and applications have global applicability.

Read more