Given that Revo is a business management system for HoReCa (restaurants, etc.) and Retail stores, including control sales, cash and users, safety is considered a key point in all our products, both technical and functional, avoiding any possible fraudulent processes on the part of employees.

Servers

Our servers are hosted in Rackspace, one of the leading companies in the cloud platform sector.

Servers can only be accessed via SSH with a private rsa key. Furthermore, each server has its own key, which cannot be used to enter others.

High Availability

We have a high availability infrastructure through 4 web servers behind a load balancer. Attacking an instance of MySQL, replicated in 2 read-only slave instances, each of which can replace the Master in a matter of seconds, if it falls.

All external APIs enter through other server(s), to prevent an inappropriate use of these from destabilizing the main system.

Backups

The system makes daily backups of all accounts on a 2-week rotation, as well as a weekly backup of the main server.

Backend

Revo uses the Laravel framework, which includes a set of security elements detailed below:

SQL Injection

All queries to the database go through a filter that prevents any type of SQL injection.

Thus, if a user enters as 'jason@example.com'; drop table users; the following query would be made:

SELECT * FROM users WHERE email = 'jason@example.com'; drop table users;

However, with the filter, the remaining result is totally harmless:

SELECT * FROM users WHERE email = 'jason@example.com or 1=1'
Cross-Site Request Forgery

All POST requests that are not part of the api pass through thecross-site request filter. This prevents anyone from linking to Revo from another web page with a malicious action and carrying int out with the authentication stored in the session cookies. Thanks to this filter, you can only make requests if you start from Revo itself.

Cross-Site Scripting

A user could try to execute javascript code using the technique called cross-site scripting. This consists of storing the script to be executed in the database. Thus, by displaying this text on the web page, the code would be executed.

For example, if a user puts the user name <script>alert(" spam spam spam!")</Script>, when displayed on the web page, the script would be launched.

My list <script>alert("spam spam spam!")</Script>

However, with the filter neutralizing everything that is written on the website coming from the database, it remains as follows:

My list \<script\>alert("spam spam spam!")\</script\>

Password

The passwords of the users are stored in the database encrypted with Bcrypt, which is the current security standard, by means of a private key stored in the App code.

There is no way to see any password clearly.

In case users cannot remember their password, they can only reset and replace it by a new one.

Revo has three different passwords, the Back End password, the App password, and the Revo Control password.

On the other hand, if the identification is wrong (by username or password), a generic message is displayed, thus preventing a dictionary attack from being made on the knowledge of the users already registered.

Cookies

All cookies are encrypted before storing.

Error Management

A hidden error management is used, registering errors in the Rollbar platform and showing the end user only a generic page without any kind of clue about it.

Malicious Files Upload Management

Revo only allows to upload image files and, if any other type of file is uploaded, it is completely ignored and an error is reported.

Device Authorization on the Back End

All the devices that connect to the Back End are registered and you can disable their access at any time through a Back End screen.

App

Since it is a totally native iOS application, by default it has all the iOS security points:

Security guide
Seguridad en iOS

In addition, we also follow protocols, so that sensitive data stored in persistent memory are first encrypted with an industry-standard algorithm AES of 256.

These data, from iOS 9.3 onward, are no longer easily accessible in physical memory.

Compiling with the security mechanisms of the Apple SDK

  • Flag -fPIE -pie: The application has been compiled with the PIE (Position Independent Executable) flag. This activates the ASLR (Address Space Layout Randomization), a mechanism of memory protection for the prevention of exploits.
  • Flag -fstack-protector-all: The application has been compiled with the SSP flag (Stack Smashing Protector) that prevents attacks from Stack Overflow and Stack Smashing.
  • Flag -fobjc-arc: The application has been compiled with the ARC (Automatic Reference Counting) flag. ARC is a compiler feature that provides automatic memory management for Objective-C objects and prevents exploit attacks and memory corruption vulnerabilities.

Users

In order to use the application, apart from the password of the account, a user must be used that is recognized by an identifier.

This can be a 4-digit pin, a magnetic card, or an individual Bar / QR code.

All actions performed in the app are recorded for 15 days to detect any type of incident either in the App use or in the business management.

The user identification screen is automatically displayed after X seconds without using the App (or at the end of a payment), to prevent another user from using it without identifying himself.

Api

All requests to the api are authenticated, that is, if access is modified in the Back End, it cannot be used until the password is updated in the App.

All the app communication to the server is done through a SSL secured connection, using an EV-type certificate that guarantees the maximum possible security.