Security Policy

For Genuka, as with any commercial tool, bug reports are an important source of feedback regarding security. Dedicated testing teams verify the code and report security issues. Additionally, for public code portions, developers are encouraged to report potential risks. Genuka's R&D processes include code review stages that encompass security aspects for both new and contributed code elements.

Genuka is designed to avoid the introduction of the most common security vulnerabilities:

• * SQL injections are prevented by using a high-level API that does not require manual SQL queries.
• * XSS attacks are avoided through the use of a high-level modeling system that automatically escapes injected data.
• * The framework prevents RPC access to private methods, making it more difficult to introduce exploitable vulnerabilities.

See also the section on OWASP Top Vulnerabilities to see how Genuka is designed at all levels to prevent the occurrence of such vulnerabilities.

Here is Genuka's stance on the main web application security issues, as listed by the Open Web Application Security Project (OWASP):

• * Injection Flaws

  Injection flaws, such as SQL injection, are common in web applications. Injection occurs when untrusted user 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. Genuka relies on an object-relational mapping (ORM) framework that abstracts query construction and prevents SQL injections by default. Notably, developers do not manually create SQL queries; they are generated by the ORM, and parameters are always properly escaped.

• * Cross-Site Scripting (XSS)

  XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or encoding. XSS allows attackers to execute scripts in the victim's browser, hijacking user sessions, defacing websites, or redirecting the user to malicious sites. Genuka's framework escapes all rendered expressions by default, preventing XSS. Developers must explicitly mark expressions as "safe" to include them in rendered pages.

• * Cross-Site Request Forgery (CSRF)

  A CSRF attack forces a victim's authenticated browser to send a forged HTTP request, including the victim's session cookie and other automatically included credentials, to a vulnerable web application. This allows the attacker to force the victim's browser to generate requests the vulnerable application thinks are legitimate. Genuka's web engine includes a built-in CSRF protection mechanism. It prevents any HTTP controller from receiving a POST request without the corresponding security token. This is the recommended technique for CSRF prevention. This security token is only known and present when the user has genuinely accessed the web form, and an attacker cannot forge a request without this token.

• * Malicious File Execution

  Vulnerable code to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as complete server compromise. Genuka does not expose functions that allow remote file inclusions. However, it allows privileged users to customize functions by adding custom expressions evaluated by the system. These expressions are always evaluated in a sandbox environment that only permits access to authorized functions.

• * 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 these references to access other objects without authorization. Genuka's access control is not implemented at the user interface level. There is no risk in exposing references to internal objects in URLs. Attackers cannot bypass the access control layer by manipulating these references, as each request must always pass through the data access validation layer.

• * Insecure Cryptographic Storage

  Web applications rarely use cryptographic functions correctly to protect data and access rights. Attackers exploit poorly protected data to commit identity theft and other crimes, such as credit card fraud. Genuka uses industry-standard secure hashing (by default PKFDB2 + SHA-512 with key stretching) for user passwords to protect stored passwords. It is also possible to use external authentication systems such as OAuth 2.0 or LDAP to avoid local storage of user passwords.

• * Insecure Communications

  Often, applications do not encrypt network traffic when it is necessary to protect sensitive communications. Genuka operates on HTTPS by default.

• * Failure to Restrict URL Access

  Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can exploit this weakness to access and perform unauthorized operations by directly accessing these URLs. Genuka's access control is not implemented at the user interface level, and security does not rely on hiding special URLs. Attackers cannot bypass the access control layer by reusing or manipulating any URL, as each request must always pass through the data access validation layer. In the rare cases where a URL provides unauthorized access to sensitive data, such as special URLs clients use to confirm an order, these URLs are digitally signed with unique tokens and only sent by email to the intended recipient.

If you need to report a security vulnerability, please consult our responsible disclosure page. These reports are treated with high priority, and the issue is immediately evaluated and resolved by the Genuka security team, in collaboration with the reporter, and then responsibly disclosed to Genuka customers and users.