Atès que Revo és un sistema de gestió de negocis HoReCa (restaurants, etc.) i comerços Retail, que implica el control de vendes, caixa i usuaris, considerem la seguretat com un punt clau en tots els nostres productes, tant tècnica com funcional, per tal d'evitar possibles processos fraudulents per part dels treballadors.

Servidors

Els nostres servidors estan allotjats a Rackspace, una de les empreses líders dins del sector de les plataformes cloud.

Només es pot accedir als servidors mitjançant SSH amb una clau rsa privada. D'altra banda, cada servidor disposa de la seva pròpia clau, de manera que no es pot utilitzar per entrar en d'altres.

High Availability

Tenim una infraestructura d'alta disponibilitat amb 4 servidors web darrera d'un equilibrador de càrrega. S’ataca a una instància de MySQL, que es replica a 2 instàncies slave de només lectura; cadascuna d’elles pot substituïr la Màster en qüestió de segons en cas que caigui.

Totes les APIs externes entren a través d'un(s) altre(s) servidor(s) per assegurar que un ús no adequat en pugui desestabilitzar el sistema principal.

Backups

Es realitzen backups diaris de tots els comptes i es manté una rotació de 2 setmanes, i també un backup setmanal del servidor principal.

Backend

Revo utilitza el framework Laravel, que porta implícit un conjunt d'elements de seguretat que us detallem a continuació:

SQL Injection

Totes les consultes a la base de dades passen per un filtre que les protegeix i evita qualsevol tipus de SQL injection.

És a dir, si un usuari entra com a nom `'jason@example.com'; drop table users; es realitzaria la consulta següent:

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

No obstant això, amb el filtre, el resultat serà el següent, totalment inofensiu:

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

Totes les peticions POST que no formen part de la api passen pel filtre del cross-site request. D’aquesta manera s'evita que des d'una altra pàgina web es pugui fer un enllaç a Revo amb una acció maliciosa i que, amb l'autenticació guardada a les galetes de sessió, es pugui arribar a realitzar aquesta acció. Gràcies a aquest filtre, només es podran realitzar les peticions que s'inicïin des del mateix Revo.

Cross-Site Scripting

Un usuari podria intentar executar codi javascript mitjançant la tècnica anomenada cross-site scripting. Això consisteix a emmagatzemar a la base de dades el script que es vol executar. D’aquesta manera, quan es mostrés el text a la plana web, s'aconseguiria executar el codi.

Per exemple, si un usuari posa com a nom d'usuari <script>alert("spam spam spam!")</ Script>, quan es mostrés a la plana web, es llançaria l'script.

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

En canvi, si comptem amb el filtre, tot el que s'escriu a la plana web que prové de la base de dades es neutralitza i queda de la manera següent:

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

Password

Les claus de pas dels usuaris es guarden a la base de dades encriptades amb Bcrypt, que és l'estàndard de seguretat actual, mitjançant una clau privada emmagatzemada al codi de l'aplicació.

No hi ha cap manera de poder veure cap clau de pas en clar.

En cas que algun usuari no pugui recordar la seva clau de pas, l'unica opció és reiniciar-la i substituir-la per una de nova.

Revo té tres claus de pas diferents: La clau de backend, la de l'aplicació i la de Revo Control.

D'altra banda, si la identificació és incorrecta (per usuari o password), es mostra un missatge genèric que evita que es pugui fer un atac de diccionari sabent quins usuaris estan ja registrats.

Cookies

Totes les galetes s'emmagatzemen encriptades.

Gestió d'errors

S'utilitza una gestió d'errors oculta, que els registra a la plataforma Rollbar, mostrant-li a l'usuari final només una pàgina genèrica sense cap tipus de pista sobre el mateix.

Control de pujada de fitxers maliciosos

Revo només permet pujar fitxers d'imatge i, si es puja qualsevol altre tipus de fitxer, aquest s'ignora completament i s'informa de l'error.

Autorització de dispositius en el backend

Tots els dispositius que es connecten a l'backend queden registrats i es pot desactivar el seu accés en qualsevol moment a través d'una pantalla del backend.

App

Com que es tracta d'una aplicació per a iOS totalment nativa, compta per defecte amb tots els punts de seguretat de iOS:

Security guide
Seguretat a iOS

A més, també seguim protocols per tal que les dades sensibles, que es guarden a la memòria persistent, es guardin encriptades amb un algoritme estàndard a la indústria AES de 256.

A partir de la versió iOS 9.3, aquestes dades ja no són fàcilment accessibles dins de la memòria física.

Compilació amb els mecanismes de seguretat de l'SDK d'Apple

  • Flag -fPIE -pie: L'aplicació s'ha compilat amb el flag PIE (Position Independent Executable). Això activa el ASLR (Address Space Layout Randomization), un mecanisme de protecció de memòria per a la prevenció de gestes.
  • Flag -fstack-protector-all: L'aplicació s'ha compilat amb el flag SSP (Stack Smashing Protector) que prevé atacs de Stack Overflow i Stack Smashing.
  • Flag -fobjc-arc: L'aplicació s'ha compilat amb el flag ARC (Automatic Reference Counting). ARC és una característica de l'compilador que proporciona gestió automàtica de memòria per a objectes Objective-C i prevé d'atacs de exploit i vulnerabilitats de corrupció de memòria.

Usuaris

Per tal de poder utilitzar l'aplicació, a part de la clau de pas del compte, cal fer servir un usuari reconegut amb un identificador.

L’usuari pot ser un pin de 4 dígits, una targeta magnètica, o bé un codi de barres/QR individual.

Totes les accions realitzades dins de l'app queden registrades durant 15 dies. D’aquesta manera es pot detectar qualsevol tipus d'incidència en l'ús de l'aplicació o bé en la gestió de l’empresa.

La pantalla d'identificació d'usuari es mostra automàticament al cap de X segons sense utilitzar l'aplicació (o bé a l'acabar un cobrament), per tal d’evitar que un altre usuari el pugui utilitzar sense identificar-se.

Api

Totes les peticions a la api s'autentifiquen, és a dir, si es modifica l'accés al backend, no es podrà continuar utilitzant fins que s'actualitzi la clau de pas de l'aplicació.

Tota la comunicació de l'app al servidor es fa a través d'una connexió segura amb SSL, fent servir un certificat de tipus EV que garanteix la màxima seguretat possible.