Politique de sécurité

Pour Genuka comme pour tout outil commercial, les rapports de bugs sont une source importante de feedback concernant la sécurité. Des équipes de tests sont donc dédiées à vérifier le code et à signaler les problèmes de sécurité. Aussi, pour des portions de code qui sont publiques, les développeurs sont encouragés à nous signaler des risques potentiels. Les processus de R&D de Genuka comportent des étapes de révision du code qui incluent les aspects de sécurité, pour les nouveaux éléments de code et les éléments de code contribués.

Genuka est conçu de manière à éviter l'introduction des vulnérabilités de sécurité les plus courantes :

• * Les injections SQL sont empêchées par l'utilisation d'une API de niveau supérieur qui ne nécessite pas de requêtes SQL manuelles.
• * Les attaques XSS sont évitées grâce à l'utilisation d'un système de modélisation de haut niveau qui échappe automatiquement aux données injectées.
• * Le framework empêche l'accès RPC aux méthodes privées, rendant plus difficile l'introduction de vulnérabilités exploitables.

Consultez également la section sur Les principales vulnérabilités OWASP pour voir comment Genuka est conçu à tous les niveaux pour empêcher l'apparition de telles vulnérabilités.

Voici la position de Genuka sur les principaux problèmes de sécurité des applications web, tels que répertoriés par Open Web Application Security Project (OWASP) :

• * Failles d'injection

  Des failles d'injection, telles que l'injection SQL, sont courantes dans les applications web. L'injection se produit lorsque des données fournies par l'utilisateur sont envoyées à un interpréteur en tant qu'élément d'une commande ou d'une requête. Les données hostiles de l'attaquant peuvent duper l'interpréteur afin de l'amener à exécuter des commandes fortuites ou accéder à des données non autorisées. Genuka s'appuie sur un cadre de mapping objet-relationnel (ORM) qui abstrait la construction des requêtes et empêche les injections SQL par défaut. Notamment les développeurs ne créent pas de requêtes SQL manuellement, elles sont générées par l'ORM et les paramètres sont toujours correctement échappés.

• * Cross Site Scripting (XSS)

  Les failles XSS se produisent chaque fois qu'une application prend des données fournies par l'utilisateur et les envoie à un navigateur web sans d'abord valider ou encoder ce contenu. XSS permet à des attaquants d'exécuter des scripts dans le navigateur de la victime afin de détourner des sessions d'utilisateurs, défigurer des sites web, ou rediriger l'utilisateur vers des sites malveillants, etc. Le framework Genuka échappe par défaut toutes les expressions rendues dans les vues et les pages, ce qui empêche les XSS. Les développeurs doivent spécialement marquer les expressions comme "sûres" pour les inclure dans les pages rendues.

• * Cross Site Request Forgery (CSRF)

  Une attaque par falsification de requête intersite force le navigateur d'une victime authentifiée à envoyer une requête HTTP forgée, comprenant le cookie de session de la victime, ainsi que toute autre information automatiquement comprise, à une application web vulnérable. Ceci permet à l'attaquant de forcer le navigateur de la victime à générer des requêtes dont l'application vulnérable pense qu'elles émanent légitimement de la victime. Le moteur de site web de Genuka comprend un mécanisme de protection CRSF intégré. Il empêche tout contrôleur HTTP de recevoir une requête POST sans le jeton de sécurité correspondant. C'est la technique recommandée pour la prévention CSRF. Ce jeton de sécurité n'est connu et présent que lorsque l'utilisateur a réellement accédé au formulaire du site web concerné et un attaquant ne peut pas falsifier une requête sans ce jeton.

• * Exécution de fichier malveillant

  Un code vulnérable à l'inclusion de fichier à distance (RFI) permet à des attaquants d'inclure du code et des données hostiles, ayant pour résultat des attaques dévastatrices, telle que la compromission totale d'un serveur. Genuka n'expose pas de fonctions permettant d'effectuer des inclusions de fichier à distance. Cependant, il permet aux utilisateurs privilégiés de personnaliser les fonctions en ajoutant des expressions personnalisées qui seront évaluées par le système. Ces expressions sont toujours évaluées par un environnement sandbox qui ne permet que l'accès aux fonctions autorisées.

• * Référence directe non sécurisée à un objet

  Une référence directe à un objet se produit quand un développeur publie une référence à un objet d'exécution interne, tel qu'un fichier, un dossier, un enregistrement de base de données, ou une clé, comme un paramètre d'URL ou de formulaire. Les attaquants peuvent manipuler ces références pour avoir accès à d'autres objets sans autorisation. Le contrôle d'accès à Genuka n'est pas mis en œuvre au niveau de l'interface utilisateur. Il n'y a donc aucun risque à exposer des références à des objets internes dans les URLs. Les attaquants ne peuvent pas contourner la couche de contrôle d'accès en manipulant ces références, car chaque requête doit toujours passer par la couche de validation de l'accès aux données.

• * Stockage cryptographique non sécurisé

  Les applications web utilisent rarement correctement les fonctions cryptographiques pour protéger les données et les droits d'accès. Les attaquants utilisent des données faiblement protégées pour perpétrer un vol d'identité et d'autres crimes, tels que la fraude à la carte de crédit. Genuka utilise un hachage sécurisé conforme aux normes industrielles pour les mots de passe des utilisateurs (par défaut PKFDB2 + SHA-512, avec étirement de clé) pour protéger les mots de passe stockés. Il est également possible d'utiliser des systèmes d'authentification externes tels que OAuth 2.0 ou LDAP, afin d'éviter tout stockage local des mots de passe des utilisateurs.

• * Communications non sécurisées

  La plupart du temps, les applications ne chiffrent pas le trafic réseau quand il est nécessaire de protéger des communications sensibles. Genuka fonctionne sur HTTPS par défaut.

• * Défaillance dans la restriction des accès URL

  Fréquemment, une application protège seulement la fonctionnalité sensible en empêchant l'affichage des liens ou des URLs aux utilisateurs non autorisés. Les attaquants peuvent utiliser cette faiblesse pour accéder et effectuer des opérations non autorisées en accédant à ces URLs directement. Le contrôle d'accès de Genuka n'est pas mis en œuvre au niveau de l'interface utilisateur et la sécurité ne repose pas sur le masquage d'URLs spéciales. Les attaquants ne peuvent pas contourner la couche de contrôle d'accès en réutilisant ou en manipulant n'importe quelle URL, parce que chaque requête doit toujours passer par la couche de validation de l'accès aux données. Dans les rares cas où une URL fournit un accès non autorisé à des données sensibles, comme les URLs spéciales que les clients utilisent pour confirmer une commande, ces URLs sont signées numériquement avec des jetons uniques et uniquement envoyées par email au destinataire prévu.

Si vous devez signaler une vulnérabilité de sécurité, veuillez consulter notre page de divulgation responsable. Ces rapports sont traités avec une haute priorité et le problème est immédiatement évalué et résolu par l'équipe de sécurité de Genuka, en collaboration avec le rapporteur et ensuite divulgué de manière responsable aux clients et utilisateurs de Genuka.