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.
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.
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.
The system makes daily backups of all accounts on a 2-week rotation, as well as a weekly backup of the main server.
Revo uses the Laravel framework, which includes a set of security elements detailed below:
All queries to the database go through a filter that prevents any type of SQL injection.
Thus, if a user enters as 'firstname.lastname@example.org'; drop table users; the following query would be made:
SELECT * FROM users WHERE email = 'email@example.com'; drop table users;
However, with the filter, the remaining result is totally harmless:
SELECT * FROM users WHERE email = 'firstname.lastname@example.org or 1=1'
Cross-Site Request Forgery
POST requests that are not part of the api pass through the
cross-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. 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\>
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.
All cookies are encrypted before storing.
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.
Since it is a totally native iOS application, by default it has all the iOS security points:
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.
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.
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.