LogicNets Security Architecture


Security prevention is an important and fast-changing area of focus for any software company, and LogicNets takes the security of our software and the applications you create with it very seriously. Security holes can exist on multiple levels in the system and there are many different types, each requiring a different approach. These approaches, however, can also have consequences; for example, checking input and output to verify that harmful data is not being introduced requires additional processing power. LogicNets works to continually address security risks and ensure the smooth, safe running of our application and yours.

Security in LogicNets Applications

LogicNets addresses security protection and implementation on multiple levels:

  • The LogicNets platform
  • Frameworks and solutions built on top of the LogicNets platform
  • Infrastructure hosting the platform and frameworks
  • Client computers running the platform and solutions  during development and production
  • Each organization using the platform and platform-based applications, who has access to what and from where

Additionally, LogicNets considers factors such as the security of a client's computer and who might access client applications. While it might sound slightly paranoid, we generally assume the outside world should be considered unsafe and potentially harmful. It's how we keep you safe.

Hosted LogicNets Applications

The LogicNets infrastructure is primarily hosted on Amazon Web Services (AWS) cloud computing platforms. AWS provides LogicNets with active security protection functionality that includes web application firewall (WAF); strict user and password control, including IP whitelisting, for accessing infrastructure, databases, and instances; separating infrastructure components into different subnets, domains, and traffic monitoring; and port whitelisting.

The WAF helps us to protect the platform and solutions against common security leaks/attacks. However, while it uses general rules and forbidden words to filter unsafe content, it cannot provide complete protection and sometimes blocks legal content that may contain blacklisted words. Therefore, LogicNets focuses on a creating security architecture at the platform and solution level to further strengthen the overall security.

LogicNets implements security measures to protect against malicious end users or external hackers as well as malicious design users that have access to a shared design environment. 

OWASP Top 10 Analysis

The Open Web Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software, and LogicNets tests against their top 10 security areas. If you are newly considering software security, OWASP (owasp.org) is a good starting point for learning about security threats and how to protect your system against them.


Injection flaws, such as SQL-, NoSQL-, 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.

LogicNets offers high-level database parts, such as get_recordsadd_recordsupdate_records, and delete_records, that all build up queries based on the given input. LogicNets properly escapes all of the input to avoid SQL injection.

Broken Authentication

Application functions related to authentication and session management are often implemented incorrectly in software, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws. This allows hackers to assume other user's identities temporarily or permanently.

LogicNets has implemented several protections against this vulnerability: hashing/salting passwords, SSO solutions, forced password renewal, minimal password strength, session-pinning, regular and use-case-based session-pinning cookie renewal, automatic account blocking, MFA, and secure connections. Built-in user and role management helps our users to avoid common mistakes in solutions, and our software allows us to quickly roll out fixes.

Sensitive Data Exposure

Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and Personal Identifiable Information (PII). Attackers may steal or modify weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

LogicNets ensures our public parts do not allow session data to be read or modified from other sessions without proper authorization. Additionally, accessing files on disk is blocked except for whitelisted paths and files. We escape the $ in $(..) during content rendering to prevent double-interpolation from allowing exposure of sensitive data from the session context.

XML External Entities (XXE)

Many older or poorly configured XML processors evaluate external entity references within XML documents. These external entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks. LogicNets' XML processors do not support external entity references.

Broken Access Control

When restrictions on what authenticated users are allowed to do are not properly enforced, attackers can exploit these flaws to access unauthorized functionality and/or data, such as accessing other users’ accounts, viewing sensitive files, modifying other users’ data, or changing access rights. LogicNets implemented several protections against this vulnerability. Our built-in user and role management helps users to avoid common mistakes. User accounts and roles are managed by internal libraries to avoid unauthorized access to user data.

Security Misconfiguration

Security misconfiguration is one of the most commonly seen issues, and it is the result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. By default, LogicNets sets configuration parameters to the most secure option and enables authentication by default when a user creates a new project. We work to ensure all operating systems, frameworks, libraries, and applications are securely configured and also patched/upgraded in a timely fashion.

Cross-Site Scripting/XSS

Cross-site scripting, or XSS, flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping. It can also happen when a user updates an existing web page using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts that can hijack user sessions, deface web sites, or redirect the user to malicious sites.

LogicNets provides libraries for custom part developers to use to build XSS-safe functionality efficiently. These library APIs are designed to avoid making mistakes that might introduce security leaks. Our public parts are configured to render XSS-safe outputs, and the LogicNets Designer includes validation tools that allow users to validate the security of their models.

Insecure Deserialization

Insecure deserialization often leads to remote code execution, and it can also be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks. $(..) does not support harmful code execution.

Using Components with Known Vulnerabilities

Components such as libraries, frameworks, and other software modules, frequently run with the same privileges as an application. If a hacker exploits a vulnerable component, they can facilitate serious data loss or server takeover. As such, applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

Most third-party libraries used by LogicNets run in the browser. The LogicNets architecture defenses against security leaks run server-side, as we assume that the browser should not be trusted. LogicNets ensures that the third-party libraries we use on the server-side are well reviewed and kept current.

Insufficient Logging and Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems; maintain persistence; pivot to more systems; and tamper with, extract, or destroy data. Most breach studies show that the time to detect a breach is more than 200 days and that it is typically detected by external parties rather than by internal processes or monitoring. To help combat this, LogicNets has set up extensive logging and traffic monitoring in AWS.

Reply Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
Like Follow
  • 1 yr agoLast active
  • 41Views
  • 3 Following