¶ Network security with CloudFlare
All Run-odoo offers benefit from CloudFlare protection and network services including:
- WAF services (Documentation)
- CDN services (Details & benefits)
- SSL services (Why and How)
NB: Cloudflare features are activated by default on all freshly deployed instances. It is possible to bypass the CloudFlare Proxy service and change your Cloudflare settings inside the domain tab of your instance.
¶ VALUE offers
Run-Odoo VALUE offers are backed by Digital Ocean infrastructure and services.
This section includes the security details of the physical data center security, networking components, and virtualization infrastructure. DigitalOcean’s infrastructure is continually maintained following internationally recognized security controls. It is monitored 24/7/365 and is subjected to third-party audits and targeted testing conducted annually. For physical security, each of the data center colocation providers maintains industry-recognized certifications, and the networks are MANRS-certified.
¶ Networking
DigitalOcean networks are collections of servers connected by wires provided by an Internet Service Provider (ISP). The DO Team develops, documents, and maintains a current baseline for all machines and network device hardware. The following list is an example of controls we maintain for network security:
- Update the baseline configuration for network devices at least annually or when a significant change occurs.
- Use the least privilege method when provisioning infrastructure components. Any unnecessary ports or protocols are disabled. Network scanning is performed to validate that any ports or protocols are in use as defined.
- Use industry standard transport protocols such as TLS between devices and DigitalOcean data centers, and within data centers themselves.
- Employ a defense-in-depth strategy for boundary protection, including secure segmentation of network environments through several methods including VLAN segmentation, ACL restrictions, and encrypted communications for remote connectivity.
- Define, implement, and evaluate processes, procedures, and defense-in-depth techniques for protection, detection, and timely response to network-based attacks.
- Establish procedures to synchronize servers and network devices in the DigitalOcean environment with NTP Pool Project servers that sync off of the Global Positioning System (GPS) satellites.
¶ Servers
DigitalOcean servers are hardware connected by a network housed in a data center. Every DigitalOcean data center implements controls to help ensure physical access to the facilities, backup data, and other system components such as virtual systems and servers is restricted. The following list is an example of controls DigitalOcean and its data centers maintain for server security:
- Biometric, proximity card, and/or personal identification number (PIN) reader systems (varies by data center facility) used to restrict data center access to only those individuals provisioned with access; the systems are also used to monitor, log, and notify personnel of physical security alarms.
- Maintain monitoring mechanisms over infrastructure to check server performance, data, traffic, and load capacity.
- Detect and route issues experienced by hosts in real time and employ orchestration tooling that has the ability to regenerate hosts.
- Third parties provide a certificate of destruction upon the destruction of physical production assets maintained in the collocated data centers.
- Documented logical access policies and procedures to guide personnel in information security practices that include, but are not limited to: password requirements, acceptable use, access provisioning, and access termination
¶ Storage
DigitalOcean storage is the physical disk on the server that runs your Droplet. These devices are encrypted at rest based on industry standards. Our storage devices have the same physical security protections as our servers. The following list is an example of additional controls DigitalOcean maintains for storage security:
DigitalOcean’s asset inventory includes serial number tracking for servers, disks, and other assets necessary to provide infrastructure for customers.
Systems are configured to require at least one of the following authentication requirements:
- Authorized user account and password
- MFA
- SSO
- SSH
¶ Virtualization
Cloud hosting environments are broken down into two main parts: the virtual servers that apps and websites can be hosted on, and the physical hosts that manage the virtual servers.
Virtualization makes cloud hosting possible: the relationship between the host and the virtual server provides flexibility and scaling that are not available through other hosting methods. Virtualization allows multiple DigitalOcean customers to host their products on the same disk with inherent logical separation. The following list is an example of security measures we maintain for securing your virtualized instance:
Initial permission definitions, and changes to permissions, associated with logical access roles of production-impacting systems are approved by authorized personnel.
We maintain device configuration policies for infrastructure and virtual instances, driven by operational and security requirements.
Customer environments are isolated using numerous mechanisms, technologies, policies, processes, and architectural elements. Customer tenants and Virtual Machine deployments are kept logically separated. Customer data may be encrypted in-transit and at-rest through configurable and standards-based providers using a variety of protocols.
¶ Backups R2 buckets security
VALUE offer backups are using CloudFlare R2.
¶ Backup data Encryption at Rest
All objects stored in R2, including their metadata, are encrypted at rest. Encryption and decryption are automatic, do not require user configuration to enable, and do not impact the effective performance of R2.
Encryption keys are managed by Cloudflare and securely stored in the same key management systems we use for managing encrypted data across Cloudflare internally.
Objects are encrypted using AES-256 ↗, a widely tested, highly performant and industry-standard encryption algorithm. R2 uses GCM (Galois/Counter Mode) as its preferred mode.
¶ Backup data Encryption in Transit
Data transfer between a client and R2 is secured using the same Transport Layer Security ↗(TLS/SSL) supported on all Cloudflare domains.
Access over plaintext HTTP (without TLS/SSL) can be disabled by connecting a custom domain to your R2 bucket and enabling Always Use HTTPS.
¶ PERFORMANCE offers
Run-Odoo PERFORMANCE offers are backed by AWS infrastructure and services.
- AWS EC2 Compute Instances
- AWS Elastic LB / CloudFront service
- AWS RDS PostgreSQL Database service
- AWS Elastic FileStore / S3 service
¶ EC2 local storage
The data on NVMe instance store volumes is encrypted using an XTS-AES-256 cipher implemented on a hardware module on the instance. The keys used to encrypt data that's written to locally-attached NVMe storage devices are per-customer and per volume. The keys are generated by and only reside within the hardware module, which is inaccessible to AWS personnel. The encryption keys are destroyed when the instance is stopped or terminated and cannot be recovered. You cannot disable this encryption, and you cannot provide any external encryption key.
¶ Elastic S3 Storage
¶ Server-side encryption
Amazon S3 encrypts your objects before saving them on disks in AWS data centers and then decrypts the objects when you download them. All Amazon S3 buckets have encryption configured by default, and all new objects that are uploaded to an S3 bucket are automatically encrypted at rest. Server-side encryption with Amazon S3 managed keys (SSE-S3) is the default encryption configuration for every bucket in Amazon S3. To use a different type of encryption, you can either specify the type of server-side encryption to use in your S3 PUT requests, or you can set the default encryption configuration in the destination bucket. If you want to specify a different encryption type in your PUT requests, you can use server-side encryption with AWS Key Management Service (AWS KMS) keys (SSE-KMS), dual-layer server-side encryption with AWS KMS keys (DSSE-KMS), or server-side encryption with customer-provided keys (SSE-C). If you want to set a different default encryption configuration in the destination bucket, you can use SSE-KMS or DSSE-KMS.
¶ Client-side encryption
You encrypt your data client-side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, encryption keys, and related tools.
¶ RDS Service and database storage encryption
¶ Encryption at rest
Amazon RDS encrypted DB instances provide an additional layer of data protection by securing your data from unauthorized access to the underlying storage. We use Amazon RDS encryption to increase data protection of your applications deployed in the cloud and to fulfill compliance requirements for encryption at rest.
¶ Encryption in transit
AWS provides secure and private connectivity between DB instances of all types. In addition, some instance types use the offload capabilities of the underlying Nitro System hardware to automatically encrypt in-transit traffic between instances. This encryption uses Authenticated Encryption with Associated Data (AEAD) algorithms, with 256-bit encryption. There is no impact on network performance.
More information is provided by AWS here.
¶ Odoo security
Odoo is a product of Odoo SA. The Odoo standard security details are detailed in this dedicated section.
¶ Integrating Odoo technology safely
¶ Odoo Authentication
¶ Web-based authentication
The Odoo authentication implies that before reaching the condition to run an authentication process, the client already satisfied the following conditions:
- The client’s IP was whitelisted or NOT banned by Fail2ban.
- SSL handshake and certificate were accepted.
- Reverse-proxy upstream forwarding was operated based on domain/subdomain validation.
- Generated POST request at login time is not offending Fail2ban rules or NginX settings and limits.
Aside from manually managing access using custom code, Odoo provides two main data-driven mechanisms to manage or restrict access to data.
Both mechanisms are linked to specific users through groups: a user belongs to any number of groups, and security mechanisms are associated to groups, thus applying security mechanisms to users.
¶ Access Control
Managed by the “ir.model”, access records define access to a whole model. Each access control has a model to which it grants permissions, the permissions it grants, and optionally, a group. Access controls are additive, for a given model, a user has access to all permissions granted to any of its groups: if the user belongs to one group that allows writing and another that allows deleting, they can both write and delete. If no group is specified, the access control applies to all users. Otherwise, it only applies to the members of the given group. Available permissions are creation (perm_create), searching and reading (perm_read), updating existing records (perm_write), and deleting existing records (perm_unlink)
¶ Record Rules
Record rules are conditions that records must satisfy for an operation (create, read, update or delete) to be allowed. It is applied record-by-record after access control has been applied.
A record rule has:
- a model on which it applies
- a set of permissions to which it applies (e.g. if perm_read is set, the rule will only be checked when reading a record)
- a set of user groups to which the rule applies, if no group is specified the rule is global
- a domain used to check whether a given record matches the rule (and is accessible) or does not (and is not accessible). The domain is evaluated with two variables in context: user is the current user's record and time is the time module
Global rules and group rules (rules restricted to specific groups versus groups applying to all users) are used quite differently:
- Global rules are subtractive, they must all be matched for a record to be accessible
- Group rules are additive, if any of them matches (and all global rules match) then the record is accessible
This means the first group rule restricts access, but any further group rule expands it, while global rules can only ever restrict access (or have no effect).
¶ Field Access
An ORM Field can have a groups attribute providing a list of groups (as a comma-separated string of external identifiers).
If the current user is not in one of the listed groups, he will not have access to the field:
- restricted fields are automatically removed from requested views
- restricted fields are removed from fields_get() responses
- attempts to (explicitly) read from or write to restricted fields results in an access error
¶ Workflow transition rules
Workflow transitions can be restricted to a specific group. Users outside the group can not trigger the transition.
¶ XML-RPC authentication
Odoo is usually extended internally via modules, but many of its features and all of its data are also available from the outside for external analysis or integration with various tools. Part of the Model Reference API is easily available over XML-RPC and accessible from a variety of languages.
¶ Logging in
Odoo requires users of the API to be authenticated before they can query most data.
The xmlrpc/2/common endpoint provides meta-calls that don’t require authentication, such as the authentication itself or fetching version information. To verify if the connection information is correct before trying to authenticate, the simplest call is to ask for the server’s version. The authentication itself is done through the authenticate function and returns a user identifier (uid) used in authenticated calls instead of the login.
- Python 2x/3x
- Ruby
- PHP
- Java
common = xmlrpclib.ServerProxy('{}/xmlrpc/2/common'.format(url))
common.version()
{
"server_version": "8.0",
"server_version_info": [8, 0, 0, "final", 0],
"server_serie": "8.0",
"protocol_version": 1,
}¶ Calling methods
The second endpoint xmlrpc/2/object, is used to call methods of odoo models via the execute_kw RPC function.
Each call to execute_kw takes the following parameters:
- the database to use, a string
- the user ID (retrieved through authenticating), an integer
- the user’s password, a string
- the model name, a string
- the method name, a string
- an array/list of parameters passed by position
- a mapping/dictionary of parameters to pass by keyword (optional)
For instance to see if we can read the “res.partner” model we can callcheck_access_rights with operation passed by position and raise_exceptionpassed by keyword (to get a true/false result rather than true/error):
models = xmlrpclib.ServerProxy('{}/xmlrpc/2/object'.format(URL))
models.execute_kw(db, uid, password,
'res.partner', 'check_access_rights',
['read'], {'raise_exception': False})
Reply:
true¶ Odoo Authorization
Users and user roles are critical points concerning internal security in Odoo. Odoo provides several security mechanisms concerning user roles, all implemented in the Odoo Server. They are implemented at the lowest server level, which is the ORM engine. Odoo distinguishes three different concepts:
- user: a person identified by his login and password. Note that all employees of a company are not necessarily Odoo users; a user is somebody who accesses the application.
- group: a group of users that has some access rights. A group gives its access rights to the users that belong to the group. Ex: Sales Manager, Accountant, etc.
- security rule: a rule that defines the access rights a given group grants to its users. Security rules are attached to a given resource, for example, the Invoice model.
Security rules are attached to groups. Users are assigned to several groups. This gives users the rights that are attached to their groups. Therefore controlling user roles is done by managing user groups and adding or modifying security rules attached to those groups.
¶ Users
Users represent physical persons using Odoo. They are identified with a login and a password,they use Odoo, they can edit their own preferences, ... By default, a user has no access rights. The more we assign groups to the user, the more he or she gets rights to perform some actions. A user may belong to several groups.
¶ User groups
The groups determine the access rights to the different resources. A user may belong to several groups. If he belongs to several groups, we always use the group with the highest rights for a selected resource. A group can inherit all the rights from another group
The following screenshot shows how group membership is displayed in the web client. The user belongs to Sales / Inventory / Manufacturing / Accounting & Finance / Purchases / Employees / Expenses / Point of Sale / Administration etc... Those groups define the user access rights.
¶ Rights
Security rules are attached to groups. You can assign several security rules at the group level, each rule being of one of the following types :
- access rights are global rights on an object,
- record rules are records access filters,
- fields access right,
- workflow transition rules are operations rights.
You can also define rules that are global, i.e. they are applied to all users, indiscriminately of the groups they belong to. For example, the multi-company rules are global; a user can only see invoices of the companies he or she belongs to.
Concerning configuration, it is difficult to have default generic configurations that suit all applications. Therefore, like SAP, Odoo is by default pre-configured with best-practices.
¶ Access rights
Access rights are rules that define the access a user can have on a particular object . Those global rights are defined per document type or model. Rights follow the CRUD model: create, read (search), update (write), delete. For example, you can define rules on invoice creation. By default, adding a right to an object gives the right to all records of that specific object.
Figure 4 shows some of the access rights of the Accounting / Accountant group. The user has some read access rights on some objects.
Figure 4: Access rights for some objects.
¶ Record rules applied to access rights
When accessing an object, records are filtered based on record rules. Record rules or access filters are therefore filters that limit the records of an object a group can access. A record rule is a condition that each record must satisfy to be created, read, updated (written), or deleted. Records that do not meet the constraints are filtered.
For example, you can create a rule to limit a group in such a way that users of that group will see business opportunities in which he or she is flagged as the salesman. The rule can be salesman = connected_user. With that rule, only records respecting the rule will be displayed.
¶ Field access rights
OpenERP now supports real access control at the field level, not just on the view side. Previously it was already possible to set a group attribute on a <field> element (or in fact most view elements), but with cosmetics effects only: the element was made invisible on the client side, while still perfectly available for read/write access at the RPC level.
¶ Software security
Access control mechanisms must be configured to achieve a coherent security policy.
¶ Group-based access control mechanisms
Groups are created as normal records on the model “res.groups”, and granted menu access via menu definitions. However even without a menu, objects may still be accessible indirectly, so actual object-level permissions (read, write, create, unlink) must be defined for groups. They are usually inserted via CSV files inside modules. It is also possible to restrict access to specific fields on a view or object using the field's groups attribute.
¶ Access rights
Access rights are defined as records of the model ir.model.access. Each access right is associated with a model, a group (or no group for global access), and a set of permissions: read, write, create, and unlink. Such access rights are usually created by a CSV file named after its model :ir.model.access.csv.
id,name,model_id/id,group_id/id,perm_read,perm_write,perm_create,perm_unlink
access_idea_idea,idea.idea,model_idea_idea,base.group_user,1,1,1,0
access_idea_vote,idea.vote,model_idea_vote,base.group_user,1,1,1,0¶ Record rules
A record rule restricts the access rights to a subset of records of the given model. A rule is a record of the model ir.rule, and is associated to a model, a number of groups (many2many field), permissions to which the restriction applies, and a domain. The domain specifies to which records the access rights are limited.
Here is an example of a rule that prevents the deletion of leads that are not in state “cancel”. Notice that the value of the field groups must follow the same convention as the method write() of the ORM.
<record id="delete_cancelled_only" model="ir.rule">
<field name="name">Only cancelled leads may be deleted</field>
<field name="model_id" ref="crm.model_crm_lead"/>
<field name="groups" eval="[(4, ref('base.group_sale_manager'))]"/>
<field name="perm_read" eval="0"/>
<field name="perm_write" eval="0"/>
<field name="perm_create" eval="0"/>
<field name="perm_unlink" eval="1" />
<field name="domain_force">[('state','=','cancel')]</field>
</record>¶ Odoo Password security & complexity policy requirements
¶ Embedded password encryption and safety mechanisms
- Customer passwords are protected with industry-standard PBKDF2+SHA512 encryption (salted + stretched for thousands of rounds)
- Odoo 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
- As of Odoo 12.0, customer database administrators even have the option to configure the rate-limiting and cooldown duration for repeated login attempts.
- Password policies: as of Odoo 12 database administrators have a built-in setting for enforcing a minimum user password length. For older versions, it is possible to achieve the same effect through customization. Other password policies like required character classes are not supported by default because they have been proven counter-productive.
¶ Password policies confronted with statistical approach stress testing
Summary of password attributes and creation failure on the first attempt. A password can fail in multiple ways. We omit failure from blank fields and confirmation mismatch. Dict shows the percentage of comp8 participants who failed the dictionary check on their first attempt. It also shows the percentage of final passwords in other conditions that would have failed the dictionary check.
The full study report and collected data are available here.
¶ The standard Odoo response to OWASP top vulnerabilities
OWASP stands for Open Web Application Security Project. Its below key points have been noted and related with Odoo mechanisms in order to point out the reliability of the technology provided:
| OWASP Criteria | Odoo standard |
|
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. |
Odoo 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 Odoo 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. |
The Odoo website 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 genuinely accessed the relevant website form, and an attacker cannot forge a request without it. |
|
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. |
Odoo does not expose functions to perform remote file inclusion. However it allows privileged users to customize features by adding custom expressions that will be evaluated by the system. These expressions are always evaluated by a sandboxed and sanitized environment that only allows access to permitted 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 those references to access other objects without authorization. |
Odoo 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. |
Odoo 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. |
Odoo Cloud runs on HTTPS by default. For on-premise installations, it is recommended to run Odoo behind a web server implementing the encryption and proxying request to Odoo, for example Apache, Lighttpd or nginx. |
|
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 |
Odoo 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. |
¶ Odoo (the software) updated security terms
Odoo SA engagements concerning the security of their solution can be consulted below
¶ Secure by design
Odoo 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.
See also the OWASP Top Vulnerabilities section to see how Odoo is designed from the ground up to prevent such vulnerabilities from appearing.
¶ Independent Security Audits
Odoo is regularly audited by independent companies that are hired by our customers and prospects to perform audits and penetration tests. The Odoo Security Team receives the results and takes appropriate corrective measures whenever it is necessary.
We can't however disclose any of those results, because they are confidential and belong to the commissioners. Please don't ask ;-)
Odoo also has a very active community of independent security researchers, who continuously monitor the source code and work with us to improve and harden the security of Odoo. Our Security Program is described on our Responsible Disclosure page.
¶ Reporting Security Vulnerabilities
If you need to report a security vulnerability, please head over to our responsible disclosure page. These reports are treated with high priority, the problem is immediately assessed and solved by the Odoo security team, in collaboration with the reporter, and then disclosed in a responsible manner to Odoo customers and users.