ijVine Security Policy

Last updated 2 Dec 2022

   

This is the Security Policy of ijVine Corporation and its affiliated companies and subsidiaries (collectively, “ijVine”) regarding your use and interaction with ijVine and its “ijVine” software application and all related software applications, websites, portals and cloud servers (collectively, the “Application”).  By using our Application, you consent to this Security Policy, as amended from time to time.

We will not sell, share, or rent this information to others in ways other than those outlined in this Security Policy. ijVine collects information from our users at several different points on the Application. Personal Information (defined below) provided by users (“you”) will be used by ijVine to improve the Application and provide a more personalized experience for the user, but information which identifies a specific individual will not be disclosed to others without the user’s permission unless necessary to provide services which the user has requested.

This online Security policy applies only to information collected through our website and not to information collected offline.

ijVine is based in Washington, USA and is only required to comply with Washington and applicable U.S. data and privacy laws. Do not use the Application or if any provision of this Security Policy does not comply with any laws of your jurisdiction. 

Any capitalized terms not defined herein shall have the meaning ascribed to them in the Terms of Use which are incorporated herein by reference (the “Terms”). This Security Policy incorporates, by reference, the Terms and the ijVine Security Policy. 

 In the event of a conflict between this Security Policy and the Terms, the provisions of this Security Policy will prevail.

The Application operates on top of the Odoo community software application, which is owned by Odoo, SA (“Odoo”).  This Security Policy covers the ijVine Application only, and ijVine is not liable or responsible for any acts or omissions by Odoo.  Please consult Odoo’s terms, Privacy Policy and Security Policies.

Backups / Disaster Recovery 

  • We keep 14 full backups of each ijVine database for up to 3 months: 1/day for the last 7 days, 1/week (last day for every 7 days backup) for 4 weeks, 1/month (latest from the 4 weeks backups) for 3 months.

  • Backups are stored thru the Amazon S3.

  • You can also download manual backups of your live data at any time using the control panel.

  • You can contact our Helpdesk to restore any of those backups on your live database (or on the side).

Database Security

  • Customer data is stored in a dedicated database - no sharing of data between clients.

  • Data access control rules implement complete isolation between customer databases running on the same cluster, no access is possible from one database to another.

Password Security

  • Customer passwords are protected with industry-standard PBKDF2+SHA512 encryption (salted + stretched for thousands of rounds).

  • ijVine staff does not have access to your password, and cannot retrieve it for you, the only option if you lose it is to reset it.

  • Login credentials are always transmitted securely over HTTPS.

  • Currently, customer database administrators even have the option to configure the rate limiting and cooldown duration for repeated login attempts.

  • Password policies: Configurable expiration days, length requirement, minimum number of lowercase letters, minimum number of uppercase letters, minimum number characters, minimum number of special characters, and strength estimation.

Staff Access

System Security

  • All ijVine Cloud servers are running hardened Linux distributions with up-to-date security patches.

  • Installations are ad-hoc and minimal to limit the number of services that could contain vulnerabilities (no PHP/MySQL stack for example).

  • Only a few trusted ijVine engineers or administrators have clearance to remotely manage the servers - and access is only possible using an encrypted personal SSH keypair, from a computer with full-disk encryption.

Physical Security

ijVine Cloud servers are hosted in trusted data centers in various regions of the world (e.g., OVH,AWS*), and they must all exceed our physical security criterions:

*See https://aws.amazon.com/compliance/data-center/controls/ for more information.

Credit Card Safety

  • We never store credit card information on our own systems.

  • Your credit card information is always transmitted securely directly between you and our  PCI-Compliant payment acquirers, such as Paypal and Stripe.

Communications

  • All data communications to client instances are protected with state-of-the-art 256-bit SSL encryption (HTTPS).

  • All internal data communications between our servers are also protected with state-of-the-art encryption (SSH).

  • Our servers are kept under a strict security watch, and always patched against the latest SSL vulnerabilities, enjoying Grade A SSL ratings at all times.

  • All our SSL certificates use robust 2048-bit modulus with full SHA-2 certificates chains.

Network defense

  • All data center providers used by ijVine is AWS EC2. The infrastructure is designed to have a built-in Distributed Denial of Service (DDoS) protection service called AWS Shield that defends the running application in AWS.

  • AWS Shield have two tiers: Standard and Advanced. Click here to know more.

Software Security

ijVine is open source, so the whole codebase is continuously under examination by ijVine users. We encourage our developers to audit the code and report security issues. 

ijVine Secure by Design

ijVine is designed in a way that prevents introducing most common security vulnerabilities: 

  • SQL injections are prevented by the use of a higher-level API that does not require manual SQL queries.

  • XSS attacks are prevented by the use of a high-level templating system that automatically escapes injected data.

  • The framework prevents RPC access to private methods, making it harder to introduce exploitable vulnerabilities.

OWASP Top Vulnerabilities

Here is where ijVine stands on the top security issue for web applications, as listed by the  Open Web Application Security Project  (OWASP):

  • Injection Flaws:  Injection flaws, particularly SQL injection, are common in web 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.

ijVine relies on an object-relational-mapping (ORM) framework that abstracts query building and prevents SQL injections by default. Developers do not normally craft SQL queries manually, they are generated by the ORM, and parameters are always properly escaped.

  • Cross Site Scripting (XSS):  XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.

The ijVine framework escapes all expressions rendered into views and pages by default, preventing XSS. Developers have to specially mark expressions as "safe" for raw inclusion into rendered pages.

  • Cross Site Request Forgery (CSRF):  A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

  • Malicious File Execution:  Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise.

ijVine does not expose functions to perform remote file inclusion.

  • 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.

ijVine access control is not implemented at the user interface level, so there is no risk in exposing references to internal objects in URLs. Attackers cannot circumvent the access control layer by manipulating those references, because every request still has to go through the data access validation layer.

  • Insecure Cryptographic Storage:  Web 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.

ijVine uses industry-standard secure hashing for user passwords (by default PKFDB2 + SHA-512, with key stretching) to protect stored passwords. It is also possible to use external authentication systems such as OAuth 2.0 or LDAP, in order to avoid storing user passwords locally at all.

  • Insecure Communications:  Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

ijVine Cloud runs 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 use this weakness to access and perform unauthorized operations by accessing those URLs directly.

ijVine access control is not implemented at the user interface level, and the security does not rely on hiding special URLs. Attackers cannot circumvent the access control layer by reusing or manipulating any URL, because every request still has to go through the data access validation layer. In rare cases where a URL provides unauthenticated access to sensitive data, such as special URLs customers use to confirm an order, these URLs are digitally signed with unique tokens and only sent via email to the intended recipient.