Sécurité

Puisque Revo est une solution globale (software) qui comprend un ensemble d’outils spécialisés pour la gestion des établissements du secteur CHR (restaurants, bar, etc…) et des commerces de détail, impliquant le contrôle des ventes, de la trésorerie et des utilisateurs, nous considérons la sécurité comme un élément clé pour tous nos produits (technique et fonctionnelle), ainsi que laprévention d’éventuels processus frauduleux de la part des employés.

Serveurs

Nos serveurs sont hébergés sur Rackspace, une des entreprises leaders dans le secteur des plateformes cloud.

Les serveurs sont accessibles uniquement via SSH avec une clé rsa privée. D’autre part, chaque serveur a sa propre clé, qui ne peut pas être utilisé pour entrer dans d’autres serveurs.

High Availability

Nous disposons d’une infrastructure de haute disponibilité au moyen de 4 serveurs web derrière un équilibreur de charge, qui attaquent une instance de MySQL, laquelle est répliquée en 2 instances clé “read-only”. En cas de chute, chacune d’elles peut remplacer le Master en quelques secondes.

Toutes les APIs externes entrent à travers d’autre(s) serveur(s), afin de veiller à ce qu’une utilisation inappropriée de celles-ci ne déstabilise le système principal.

Backups

Des backups journaliers de tous les comptes sont réalisés et une rotation de 2 semaines est maintenue, ainsi qu’un backup hebdomadaire du serveur principal.

Back-office

Revo utilise le framework Laravel, qui comprend implicitement un ensemble d’éléments de sécurité détaillés ci-dessous:

SQL Injection

Toutes les requêtes adressées à la base de données passent par un filtre, ce qui leur garantit d’éviter tout type de SQL injection.

Par exemple, si un utilisateur entre avec le nom ‘jason@example.com’; drop table users; la requête suivante serait faite:

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

Cependant, avec le filtre, le résultat suivant reste totalement inoffensif:

SELECT * FROM users WHERE email = 'jason@example.com or 1=1'

Cross-Site Request Forgery

Toutes les requêtes POST qui ne font pas partie de l’API passent par le filtre du cross-site request. Cela évite qu’à partir d’une autre page Web, un lien vers Revo puisse être créé avec une action malveillante et qui, avec l’authentification stockée dans les cookies de session, puisse effectuée cette action. Grâce à ce filtre, seules les requêtes pourront être faites si elles sont démarrées depuis Revo.

Cross-Site Scripting

Un utilisateur pourrait essayer d’exécuter un code javascript en utilisant la technique appelée Cross-Site Scripting. Cette technique consiste à sauvegarder le script à exécuter dans la base de données. Ainsi, en affichant ce texte dans la page Web, il serait possible d’exécuter le code.

Par exemple, si un utilisateur entre avec le nom <script>alert(“spam spam spam!”)</script>, au moment de l’afficher dans la page Web, le script serait lancé.

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

Cependant, nous disposons d’un filtre à travers lequel tout ce qui est écrit sur la page web provenant de la base de données est neutralisé et reste comme suit:

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

Mot de passe

Les mots de passe des utilisateurs sont stockés dans la base de données (cryptée avec Bcrypt), qui est le standard de sécurité actuel, au moyen d’une clé privée stockée dans le code de l’application.

Aucun mot de passe ne peut être visualisé.

Si un utilisateur oublie son mot de passe, il ne pourra être substitue que par un nouveau.

Revo compte 3 mots de passe différents: Un pour le Back Office, un pour l’Application et un pour Revo Control.

D’autre part, si l’identification est incorrecte (utilisateur ou mot de passe), un message générique s’affiche ce qui évite une attaque de dictionnaire sachant quels sont les utilisateurs déjà enregistrés.

Cookies

Tous les cookies sont sauvegardés en cryptés.

Gestion d'erreurs

On utilise une gestion des erreurs cachée, qui les enregistre dans la plate-forme Rollbar, ne montrant à l’utilisateur final qu’une page générique sans aucune piste sur celles-ci.

Contrôle de téléchargement de fichiers malveillants

Revo ne permet que le téléchargement de fichier d’images. Si un autre type de fichier est téléchargé, il est complètement ignoré et une erreur est signalée.

Autorisation de dispositifs dans le Back-office

Tous les dispositifs se connectant au back-office sont enregistrés et leur accès peut être désactivé à tout moment via un écran sur la même plateforme.

App

S’agissant d’une application iOS totalement native, elle possède par défaut tous les points de sécurité iOS:

Security guide
Sécurité iOS

De plus, nous suivons également une série de protocoles afin que les données sensibles gardées dans la mémoire persistante soient cryptées avec un algorithme standard dans l’industrie AES de 256.

À partir de iOS 9.3, ces données dans la mémoire physique ne sont pas facilement accessible.

Compilation avec les mecanismes de sécurité du SDK d'Apple

  • Flag -fPIE -pie: L’Application est compilée avec le flag PIE (Position Independent Executable). Ceci active l’ASLR (Address Space Layout Randomization), un mécanisme de protection de mémoire pour la prévention d’exploits.
  • Flag -fstack-protector-all: L’Application est compilée avec le flag SSP (Stack SmashingProtector), qui protège d’attaques de Stack Overflow et Stack Smashing.
  • Flag -fobjc-arc: L’Application est compilée avec le flag ARC (Automatic Reference Counting). ARC est une caractéristique du compilateur qui fournit la gestion automatique de mémoire pour les objets Objective-C et prévient des attaques d’exploit et vulnérabilités de corruption de mémoire.

Utilisateurs

Pour utiliser l’Application, en plus du mot de passe du compte, il faut utiliser un utilisateur qui sera reconnu par un identifiant.

Il peut s’agir d’un code PIN à 4 chiffres, d’une carte magnétique ou d’un code à barres/ code QR individuel.

Toutes les actions effectuées dans l’Application sont enregistrées pendant 15 jours afin de détecter quelque incident que ce soit, que cela soit dans l’utilisation de l’Application ou dans la gestion de l’établissement (Action Log).

L’écran d’identification de l’utilisateur s’affiche automatiquement après X secondes si l’Application n’est pas utilisée (ou à la fin d’un règlement), afin d’éviter qu’un autre utilisateur puisse y accéder sans s’identifier

Api

Toutes les requêtes à l’API sont authentifiées, c’est-à-dire, que si l’accès est modifié dans le back office, il ne pourra pas être utilisé tant que le mot de passe n’a pas été actualisé dans l’Application.

Toute la communication de l’Application au serveur se réalise via une connexion sécurisée avec SSL, en utilisant un certificat de type EV qui garantit un maximum de sécurité.