When developing Acrolinx software we place a high priority on security and our development procedures that ensure that the security of our software components is reviewed on a regular basis. We have implemented a robust set of standards and practices that are designed to address the most common security risks and vulnerabilities.
The Acrolinx development team adheres to the principle of pair programming. All developers are observed by another developer who is responsible for assessing the strategic consequences of code changes which include the identification of potential security risks. Additionally, the development team conducts regular code reviews and static code analysis to locate any potentially vulnerable source code before the software is deployed.
The Acrolinx Dashboard is the main web-facing component of Acrolinx and is created using the Google Web Toolkit (GWT). The GWT project includes clear guidelines on how to secure GWT applications. All our GWT developers adhere strictly to these guidelines.
The back end of the Acrolinx server is written primarily in Java. All of our Java developers are familiar with the CERT Oracle Secure Coding Standard for Java and aim to comply with this standard as much as possible.
The following table elaborates on some of the most common security risks and vulnerabilities and explains how these issues are prevented in the Acrolinx software.
|Issue||Description||Acrolinx Prevention Measures|
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.
We sanitize all data that is passed between the Acrolinx software components such as the clients and the servers. Our API provides a parameterized interface that helps to prevent most forms of injection. All input, including SQL and XML input, is sanitized and any input from untrusted sources is validated. Where possible, we use command interpreters and parsers that have built-in sanitization and validation methods.
|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.
All Acrolinx sessions have a built-in timeout which helps to prevent attackers from stealing sessions.
Web browsers are prevented from auto-completing fields that contain sensitive information such as the Dashboard login fields and user creation fields.
All cookies that are issued from the Acrolinx Server are flagged as secure and HTTP-only. These flags prevent scripts from accessing the cookies and ensure that the cookies are not transmitted using unencrypted channels.
We also use the secure Java Authentication and Authorization Service (JAAS) for authenticating users against LDAP servers.
|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 web browser which can hijack user sessions, deface websites, or redirect the user to malicious sites.
We also sanitize user input in the following areas:
|Missing function level access Control|
Most web applications verify function level access rights before making that functionality visible in the UI. However, applications must 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 to access functionality without proper authorization.
|The Acrolinx server includes a role-based access control system with fine-grained privileges for specific actions. These privileges are checked on the server- and client-side and do not rely on “presentation layer access control”. Unauthorized users cannot perform specific actions by bypassing the user interface.|
|Using components with known vulnerabilities|
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.
|As part of the code review, the Acrolinx development team reviews all third-party libraries and components for any new security risks or vulnerabilities. Any problematic components are upgraded or replaced before any software is deployed.|
Cross site tracing (XST)
A Cross-Site Tracing (XST) attack involves the use of Cross-site Scripting (XSS) and the TRACE or TRACK HTTP methods. According to RFC 2616, "TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information.", the TRACK method works in the same way but is specific to Microsoft's IIS web server. XST could be used as a method to steal the user's cookies via Cross-site Scripting (XSS) even if the cookie has the "HttpOnly" flag set and/or expose the user's Authorization header.
The TRACE and TRACK methods have been completely deactivated in the Acrolinx Server so that they cannot be exploited by potential attackers.
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack. An information leak occurs when system data or debugging information leaves the program through an output stream or logging function.
Information leakage can often occur through default error pages that display when a page is not found. These pages can reveal the information about the HTTP server platform.
Information leakage can also occur as a result of serializing data. Serializable classes are effectively open classes since data cannot be hidden in them. An attacker can write out the class to a byte stream in which they can extract the important data from it.
When users enter an incorrect URL with the Acrolinx server address as the base URL, the Acrolinx server displays customized error page instead of the server default. This page does not reveal any information about the HTTP server.
When creating Java classes, we explicitly define a final
|Failure to encrypt data|
The failure to encrypt data passes up the guarantees of confidentiality, integrity, and accountability that properly implemented encryption conveys.
|Acrolinx provides the option to secure all Acrolinx server communication. For cryptographic purposes, we rely on tried and tested open source libraries.|
Configuring Acrolinx to Sanitize Exported Files
By default, the Acrolinx server does not sanitize files that you export from the Dashboard and display in your web browser. However, you can configure the Acrolinx server to sanitize these files as well. The only risk is that the layout of your exported file might be corrupted.
Exported files are not sanitized by default because the sanitization can remove or change characters that are important for defining the file layout. This problem mostly occurs with exported CSV files. For example, if you use the ";" character to delimit your columns, the column layout could become corrupted. Therefore it is important to do a few test exports after you enable this feature.
To configure the Acrolinx server to sanitize export files, follow these steps:
- Open your overlay of the core server properties file.
You find the overlay for the core server properties file in the following location:
Add the following property:
- Save your changes and restart the core server.