[en] Injection

[en] 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.

[en] We sanitize all data that is passed between the Acrolinx Platform components such as the Acrolinx Integrations and the Acrolinx Platform. 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.

[en] By default, we don't sanitize terminology exports, since this could corrupt your file format. You can configure Acrolinx to sanitize exported files.

[en] Broken authentication and session management

[en] 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.

[en] All Acrolinx sessions have a built-in timeout, which helps to prevent attackers from stealing sessions.

[en] Web browsers are prevented from auto-completing fields that contain sensitive information such as the Dashboard sign-in fields and user creation fields.

[en] When accessing Acrolinx through a secure connection, all cookies that are issued from the Acrolinx Platform are highlighted as secure and HTTP-only. These highlights prevent scripts from accessing the cookies and ensure that the cookies aren’t transmitted using unencrypted channels.

[en] We also use the secure Java Authentication and Authorization Service (JAAS) for authenticating users against LDAP servers.

[en] Cross-site scripting (XSS)

[en] 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. This allows an attacker to hijack user sessions, deface websites, or redirect the user to malicious sites.

[en] It’s possible to add HTML content to custom fields in the Acrolinx Dashboard. However, before the HTML content is displayed in the web browser, the Acrolinx Platform sanitizes the HTML and removes any potentially malicious content. All untrusted data is escaped based on the HTML context (for example, body, attribute, JavaScript, CSS, or URL).

[en] We also sanitize user input in the following areas:

[en] By default, we don't sanitize terminology exports, since this could corrupt your file format. You can configure Acrolinx to sanitize exported files.

[en] Missing function level access Control

[en] 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 aren’t verified, attackers will be able to forge requests to access functionality without proper authorization.

[en] The Acrolinx Platform 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 don’t rely on “presentation layer access control”. Unauthorized users can’t perform specific actions by bypassing the user interface.

[en] Using components with known vulnerabilities

[en] Components, such as libraries, frameworks, and other platform 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.

[en] 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 platform is deployed.

[en] Cross site tracing (XST)

[en] 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" highlight set and/or expose the user's Authorization header.

[en] The TRACE and TRACK methods have been completely deactivated in the Acrolinx Platform so that they cannot be exploited by potential attackers.

[en] Information leakage

[en] 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.

[en] Information leakage can often occur through default error pages that display when a page isn’t found. These pages can reveal the information about the HTTP server platform.

[en] Information leakage can also occur as a result of serializing data. Serializable classes are effectively open classes since data can't 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.

[en] When users enter an incorrect URL with the Acrolinx URL as the base URL, Acrolinx displays a customized error page instead of the server default. This page doesn’t reveal any information about the HTTP server.

[en] When creating Java classes, we explicitly define a final writeObject() function to prevent serialization. writeObject() throws an exception that explicitly denies serialization.

[en] Failure to encrypt data

[en] The failure to encrypt data passes up the guarantees of confidentiality, integrity, and accountability that properly implemented encryption conveys.

[en] Acrolinx provides the option to secure all Acrolinx Platform communication. For cryptographic purposes, we rely on tried and tested open-source libraries.