Tâches publiques et directives

Programmation sécurisée dans la pratique

Veuillez vous informer sur les directives relatives à la programmation sécurisée afin de comprendre et de corriger les failles de sécurité des logiciels telles que celles répertoriées dans le Top 10 de l'OWASP, et participez à des missions de formation guidées pour vous exercer à des simulations pratiques d'applications.

Réserver une démonstration
apprendre bg
Missions publiques
Directives

Veuillez consulter toutes les missions

Table des matières
Injection SQLDemander les matchers Spring MVCSource de chevaux de Troie — Utilisation de composants provenant de sources non fiablesSignatures psychiques — Utilisation de composants connus pour être vulnérablesTraversée de chemin Apache — Utilisation de composants vulnérables connusCodestashbin - Fonction de réinitialisation du mot de passe non sécuriséeLog4j - Utilisation de composants connus pour être vulnérablesScripting inter-pages (XSS) dans « ChatterGPT »
En savoir plus
Augmentez votre productivité
Injection SQL
Un utilisateur nous a signalé qu'il avait réussi à exploiter une vulnérabilité de type injection SQL dans la fonction de recherche de transactions de la solution de banque en ligne. Il a indiqué qu'il avait pu voir des transactions appartenant à d'autres utilisateurs et a souligné que cette vulnérabilité pouvait permettre à un attaquant de faire toutes sortes de choses désagréables dans la base de données, comme supprimer des tables, voir des données d'autres tables, insérer des données, etc. Essayez de reproduire ce que l'utilisateur a fait dans cette mission.
Essayez dès maintenantConsulter l'article de blog
Augmentez votre productivité
Spring MvcRequestMatchers
En mars 2023, Spring a publié un correctif pour une vulnérabilité découverte en interne, appelée CVE-2023-20860, où l'utilisation d'un double caractère générique ** dans mvcRequestMatchers pourrait entraîner une non-concordance des modèles entre Spring Security et Spring MVC. Cela pourrait conduire à ce que des utilisateurs obtiennent un accès non autorisé à certains points de terminaison. Nous avons mis en place une application bancaire très simplifiée avec quelques points de terminaison. Suivez les instructions et essayez de reproduire l'impact de cette vulnérabilité de contrôle d'accès.
Essayez dès maintenantConsulter l'article de blog
Augmentez votre productivité
Signatures psychiques - Utilisation de composants vulnérables connus
CVE-2022-21449 a l'alias le plus cool pour une vulnérabilité, Psychic Signatures in Java (Signatures psychiques en Java). Comment a-t-elle obtenu ce nom ? Il s'agit d'une référence aux papiers psychiques de Doctor Who. Lorsqu'on les montrait à quelqu'un, ces feuilles de papier vierges étaient remplies de ce qu'il s'attendait à voir. Un phénomène similaire s'est produit dans l'implémentation Java (versions 15 à 18) de l'algorithme ECDSA, ce qui a un effet sur la vérification de la signature des JWT. Nous pouvons soumettre une signature non valide, mais Java pensera qu'elle est valide. Vous voulez voir comment cela fonctionne ? Commençons.
Essayez dès maintenantConsulter l'article de blog
Augmentez votre productivité
Apache Path Traversal - Utilisation de composants vulnérables connus
Le 4 octobre 2021, l'équipe Apache a publié la version 2.4.49 d'Apache pour corriger une vulnérabilité de traversée de chemin et d'exécution de code à distance dans Apache 2.4.48, également connue sous le nom de CVE-2021-41773. Le 7 octobre 2021, la version 2.4.51 a été publiée car le correctif de la version 2.4.50 n'était pas complet. Cette vulnérabilité était connue sous le nom de CVE-2021-42013. Essayez cette mission pour voir par vous-même comment cette vulnérabilité peut être exploitée.
Essayez dès maintenantConsulter l'article de blog
Augmentez votre productivité
Log4j - Utilisation de composants vulnérables connus
L'annonce, début décembre 2021, d'un exploit 0-day (CVE-2021-44228) dans la très populaire bibliothèque de journalisation Log4j, a fait l'effet d'une bombe dans la communauté Java. L'exploit, baptisé Log4Shell, affecte les versions 2.0-beta9 à 2.14.1 de Log4j v2, et pourrait conduire à l'exécution de code à distance. Nous avons mis en place un environnement pour simuler l'exploit, afin que vous puissiez voir l'impact de première main. Essayez-le maintenant.
Essayez dès maintenantConsulter l'article de blog
Augmentez votre productivité
Trojan Source - Utilisation de composants provenant de sources non fiables
L'un des développeurs de Viking Bank a naïvement copié du code provenant d'une source non fiable sur Internet, qui contient potentiellement des composants vulnérables, afin d'aider à écrire un contrôle d'autorisation de l'administrateur pour gérer les cartes de crédit. Nous avons remarqué que des utilisateurs modifiaient la limite de leur carte de crédit, alors que seuls les administrateurs devraient avoir ce privilège. Nous pensons qu'il y a un problème avec ce code. Essayez la mission pour enquêter sur le code.
Essayez dès maintenantConsulter l'article de blog
Augmentez votre productivité
Codestashbin - Fonction de réinitialisation de mot de passe non sécurisée
CodeStashBin est l'une des plus grandes sociétés d'hébergement de contrôle de version de code au monde. La rumeur veut que le processus d'oubli du mot de passe soit entaché d'une vulnérabilité de la fonction de réinitialisation du mot de passe. Il pourrait être possible de modifier le mot de passe d'un utilisateur privilégié et d'accéder à son compte. Participez à cette mission pour enquêter sur ce problème.
Essayez dès maintenantConsulter l'article de blog
Augmentez votre productivité
Scripting intersite (XSS) dans 'ChatterGPT' (en anglais)
Cette mission révèle l'interface familière d'un LLM populaire et utilise un extrait de code réel généré à la fin du mois de novembre 2023. Les utilisateurs peuvent interpréter ce bout de code et étudier les problèmes de sécurité potentiels s'il devait être utilisé dans le but prévu.
Essayez dès maintenantConsulter l'article de blog

Rechercher toutes les directives

Rechercher :
Masquer le filtre
Sélection
Afficher le filtre
Sélection
Supprimer le filtre
Mot-clé
Super icône [★]
Thème
En savoir plus

Insuffisance de la journalisation et de la surveillance

Bonnes pratiques :

Journalisation des audits pour les fonctions sensibles
Journalisation des erreurs
Stockage des journaux dans un endroit centralisé
Conservation des journaux pendant une période définie
Audit régulier des journaux pour les IPI

La journalisation et la surveillance sont souvent envisagées après coup lorsque quelque chose a déjà mal tourné, mais en réalité, l'absence d'une journalisation et d'une surveillance adéquates peut s'avérer très coûteuse. D'une part, lorsqu'un incident se produit (qu'il soit lié à la sécurité ou non), il est impossible de comprendre ce qui s'est réellement passé si les journaux sont peu nombreux ou inexistants. D'autre part, l'enregistrement d'un trop grand nombre de données peut entraîner des problèmes de protection de la vie privée, qui peuvent à leur tour entraîner des problèmes avec les autorités de réglementation. Lisez notre guide des meilleures pratiques pour éviter une journalisation et une surveillance insuffisantes.

Consulter les directives

Utilisation de composants dont les vulnérabilités sont connues

{
 "dependencies": {
   "foo": "1.0.0 - 2.9999.9999",
   "bar": ">=1.0.2 <2.1.2"
 }
}

La plupart des applications utilisent un grand nombre de composants tiers. Ces composants fournissent tout ce dont vous avez besoin, depuis la journalisation jusqu'à l'accès aux bases de données, en passant par la création de modèles et bien d'autres choses encore. Cela facilite grandement le développement de logiciels et permet de gagner beaucoup de temps. Mais ces composants sont également créés par des personnes, ce qui signifie que certains d'entre eux contiennent inévitablement des vulnérabilités. Lisez les lignes directrices pour en savoir plus.

Consulter les directives

Injection SQL

import mysql.connector
db = mysql.connector.connect
#Mauvaise pratique. Evitez ceci ! C'est juste pour apprendre.
(host="localhost", user="newuser", passwd="pass", db="sample")
cur = db.cursor()
name = raw_input('Enter Name : ')
cur.execute("SELECT * FROM sample_data WHERE Name = '%s' ;" % name) for row in cur.fetchall() : print(row)
db.close()

L'injection SQL (SQLi) consiste à injecter du code dans les instructions SQL afin d'attaquer une application et d'en recueillir des informations importantes. Il s'agit d'une vulnérabilité de la sécurité web. C'est la technique de piratage la plus courante qui manipule la base de données et en extrait des informations cruciales.

Consulter les directives

Mauvaise configuration de la sécurité

De nombreux frameworks disposent également d'un ensemble de points d'extrémité qui peuvent être activés pour permettre la surveillance de l'application, que ce soit dans un environnement de production ou de test/développement. Il peut s'agir de :

Metrics (Prometheus)
Logs
Environment information
Path/Url Mappings

La mauvaise configuration de la sécurité est en quelque sorte un terme générique qui couvre les vulnérabilités communes qui entrent en jeu à cause des paramètres de configuration d'une application, plutôt qu'à cause d'un mauvais code. Il s'agit d'un sujet très vaste qui dépend fortement de facteurs tels que votre pile technologique. Souvent, la résolution de ces problèmes semble simple, comme la modification d'un fichier de configuration ou même d'une seule ligne de code, mais l'impact et les conséquences de ces vulnérabilités peuvent être graves. Lisez notre ligne directrice pour en savoir plus sur cette vulnérabilité et sur la manière de l'atténuer.

Consulter les directives

Falsification de requête côté serveur

ts
let url = request.params.url ;

let response = http.get(url) ;
let render = response.render() ;

return render.export() ;

Les vulnérabilités liées à la falsification des requêtes côté serveur se produisent lorsqu'un utilisateur est en mesure d'amener une application à effectuer des requêtes HTTP vers un domaine déterminé par l'attaquant. Si une application a accès à des réseaux privés/internes, un attaquant peut également amener l'application à envoyer des requêtes à des serveurs internes. Dans cette ligne directrice, nous examinerons de plus près ce phénomène à l'aide de quelques exemples afin de mieux comprendre ce qu'il représente en action.

Consulter les directives

Stockage du mot de passe

Caractéristique Hachage cryptographique Hachage du mot de passe Vitesse Très rapide Intentionnellement lent Facteur de travail ajustable Non Oui

Si votre application authentifie des utilisateurs, il y a de fortes chances qu'elle traite également des mots de passe. La gestion des mots de passe des utilisateurs est une affaire très importante, et la gestion appropriée de ces mots de passe l'est encore plus. Il est difficile d'imaginer un scénario pire qu'une application attaquée et des mots de passe d'utilisateurs divulgués sur l'internet à la vue de tous. Comment stocker les mots de passe en toute sécurité et conformément aux meilleures pratiques ? Examinons quelques méthodes.

Consulter les directives

Affectation des masses

html
<form method="POST">
     <input name="Id" type="hidden" value="666">
     <input name="Name" type="text" value="Bad guy">
     <input name="EmailAddress" type="text" value="hacker@attacker.com">
     <input name="IsAdmin" type="hidden" value="true">
     <input type="submit">
</form>  

Mass Assignment est une vulnérabilité dans laquelle les points de terminaison de l'API ne limitent pas les propriétés de l'objet associé qui peuvent être modifiées par un utilisateur. Cette vulnérabilité peut survenir lors de l'utilisation d'une bibliothèque ou d'un cadre qui permet de lier automatiquement des paramètres HTTP à un modèle qui est ensuite utilisé sans aucune validation. L'utilisation de la liaison automatique d'une requête à un objet peut parfois être extrêmement utile, mais elle peut également entraîner des problèmes de sécurité si le modèle possède des propriétés qui ne sont pas censées être accessibles à l'utilisateur. Lisez les lignes directrices pour plus de détails.

Consulter les directives

Mauvaise configuration de la sécurité - XXE détaillé

xml
<?xml version="1.0" ?>
<!DOCTYPE outerElement [
   <!ENTITY externalEntity SYSTEM  "file:///etc/passwd" > ]>
<outerElement>&externalEntity;</outerElement>

La classe de vulnérabilité "XML eXternal Entities" (XXE) est une mauvaise configuration de sécurité impliquant les analyseurs XML. La norme XML comprend des moyens de référencer des "entités", telles que des fichiers et des URL. Les analyseurs syntaxiques ont souvent pour défaut de résoudre entièrement les entités externes, ce qui signifie que les documents XML peuvent entraîner la divulgation de fichiers et d'autres informations sensibles à des attaquants potentiels. Pour plus d'informations, lisez l'intégralité des lignes directrices.

Consulter les directives

Injection - Traversée de chemin

pseudo
let baseFolder = "/var/www/api/documents/" ;
let path = baseFolder + request.params.filename ;

return file.read(path) ;

Le détournement de chemin est un autre type assez courant de vulnérabilité par injection. Elle se produit généralement lorsque la construction d'un URI (qu'il s'agisse d'une URL, d'un chemin d'accès à un fichier ou autre) ne garantit pas que le chemin entièrement résolu ne pointe pas en dehors de la racine du chemin d'accès prévu. L'impact d'une vulnérabilité de traversée de chemin dépend fortement du contexte dans lequel la traversée se produit et du renforcement général qui a été effectué. Lisez les lignes directrices pour en savoir plus.

Consulter les directives

Authentification et autorisation

cs

// Ensure the default behaviour is to authenticate requests, and check if they are admin
[Authenticate]
[Authorize("Admin")]
public class SecureController : Controller
{

}

public class MyController : SecureController
{

    // Overrides the Authorize attribute inherited to allow any user to access the page

Consulter les directives

Injection - XSS

```html
<!--- UNSAFE: The htmlSnippet will get interpreted without any escaping --->
@Html.Raw(htmlSnippet)
```

Le Cross-Site Scripting, également connu sous le nom de XSS, est un autre type de vulnérabilité d'injection qui conduit à l'évaluation d'un script contrôlé par l'attaquant dans le navigateur d'un autre utilisateur. Le XSS peut également être considéré comme une vulnérabilité d'injection HTML/JavaScript. Examinons les types de XSS que vous pouvez rencontrer.

Consulter les directives

Injection 101

Parmi les types d'injection les plus courants, citons :

Injection SQL
Cross-Site Scripting (injection HTML/Javascript)
Path Traversal (injection Path/Url)
Command Injection (injection de commande)
Code Injection (injection de code)

L'une des catégories de vulnérabilités les plus connues est celle des vulnérabilités par injection, en particulier, ce qui ne surprend personne, l'enfant-vedette incontesté : l'injection SQL. Il est difficile d'éviter d'entendre parler de l'injection SQL dans le monde de la technologie, c'est pourquoi nous allons en parler. Lisez ce qui suit pour obtenir une brève introduction aux failles d'injection.

Consulter les directives

Téléchargement de fichiers

public string UploadProfilePicture(FormFile uploadedFile)
{
    // Generate path to save the uploaded file at
    var path = $"./uploads/avatars/{request.User.Id}/{uploadedFile.FileName}";

    // Save the file
    var localFile = File.OpenWrite(path);
    localFile.Write(uploadedFile.ReadToEnd());
    localFile.Flush();
    localFile.Close();

    // Update the profile picture 
    UserProfile.UpdateUserProfilePicture(request.User, path)

    return path;
}

Il est très fréquent que les applications doivent, à un moment ou à un autre, permettre aux utilisateurs de télécharger un fichier (soit pour l'utiliser, soit pour le stocker) quelque part dans l'application. Bien que cela semble assez simple, la manière dont cette fonction est mise en œuvre peut être très critique en raison des risques potentiels associés à la manière dont les téléchargements de fichiers sont gérés. Lisez les lignes directrices pour plus d'informations.

Consulter les directives

Injection de commande

let ip = request.params.ipAddress ;

system("ping " + ip) ;

Examinons l'injection de commande en elle-même. Nous allons surtout nous concentrer sur quelques exemples différents pour qu'il soit plus facile de voir à quoi cela ressemble en action. Pour rappel, les vulnérabilités liées à l'injection de commande se produisent lorsque l'utilisateur utilise une partie d'une commande du système d'exploitation. Lisez les lignes directrices pour plus d'informations.

Consulter les directives