Public missions & guidelines

Secure Coding Made Practical

Explore secure coding guidelines to understand and mitigate software vulnerabilities like the OWASP Top 10, and dive into guided training Missions to practices in real-world app simulations.

book a demo

Browse all missions

Afficher plus
Évolutif et engageant

SQL par injection

try now
Évolutif et engageant

Spring MVC RequestMatchers

try now
Évolutif et engageant

Signatures psychiques - Utilisation de composants vulnérables connus

try now
Évolutif et engageant

Apache Path Traversal : utilisation de composants vulnérables connus

try now
Évolutif et engageant

Log4j - Connue Vulnérable Utilisation des composants

try now
Évolutif et engageant

Trojan Source - Utilisation de composants provenant de sources non fiables

try now
Évolutif et engageant

Codestashbin - Fonction de réinitialisation de mot de passe non sécurisée

try now
Évolutif et engageant

Scripting intersite (XSS) dans « ChatterGPT »

try now

Browse all guidelines

Parcourir par :
Masquer les filtres
Selection
Afficher les filtres
Selection
Effacer les filtres
Balise
Super Icon [★]
Thème
Afficher plus

Enregistrement et surveillance insuffisants

Meilleures pratiques :

Journalisation des audits pour les fonctions sensibles
Enregistrement des erreurs
Stockage des journaux dans un emplacement centralisé
Conserver les journaux pendant une durée définie
Auditez régulièrement les journaux pour les informations personnelles

L'enregistrement et la surveillance sont souvent relégués au second plan lorsque quelque chose s'est déjà mal passé, mais en réalité, ne pas s'assurer d'une journalisation et d'une surveillance appropriées peut s'avérer très coûteux. D'un côté, lorsqu'un incident survient (qu'il soit lié à la sécurité ou non), le fait d'avoir peu ou pas de journaux rend impossible de comprendre ce qui s'est réellement passé. À l'autre extrême, l'enregistrement d'une trop grande quantité de données peut entraîner des problèmes de confidentialité, qui peuvent ensuite entraîner des problèmes avec les régulateurs. Lisez notre guide pour connaître les meilleures pratiques afin d'éviter une journalisation et une surveillance insuffisantes.

view guidelines

Utilisation de composants présentant des vulnérabilités connues

{
« dépendances » : {
« foo » : « 1.0.0 - 2.9999.9999",
« barre » : « >=1,0.2 <2.1.2 »
}
}

La plupart des applications utilisent de grandes quantités de composants tiers. Ces composants fournissent tout, de la journalisation à la création de modèles, en passant par l'accès à la base de données, etc. Cela facilite grandement le développement de logiciels et permet de gagner beaucoup de temps. Mais ils sont également fabriqués par des personnes, ce qui signifie que certains contiendront inévitablement des vulnérabilités. Lisez le guide pour en savoir plus.

view guidelines

Injection SQL

importer mysql.connector
base de données = mysql.connector.connect
Pratique #Bad. Evite ça ! C'est juste pour apprendre.
(host="localhost », user="newuser », passwd="pass », db="sample »)
cur = db.cursor ()
name = raw_input ('Entrez le nom : ')
cur.execute (« SELECT * FROM sample_data WHERE Name = '%s' ; » % name) pour la ligne dans cur.fetchall () : print (row)
db.fermer ()

L'injection SQL (SQLi) injecte du code dans des instructions SQL pour attaquer et collecter des informations importantes à partir d'une application. Il s'agit d'une faille de sécurité Web. Il s'agit de la technique de piratage la plus courante qui manipule la base de données et en extrait des informations cruciales.

view guidelines

Mauvaise configuration de la sécurité

De nombreux frameworks disposent également d'un ensemble de points de terminaison qui peuvent être activés, ce qui permet de surveiller l'application, que ce soit dans un environnement de production ou de test/développement. Il peut s'agir notamment des éléments suivants :

Métriques (Prometheus)
Journaux
Informations sur l'environnement
Mappages chemin/URL

La mauvaise configuration de sécurité est en quelque sorte un terme générique qui couvre les vulnérabilités courantes qui apparaissent en raison des paramètres de configuration d'une application, plutôt que d'un code incorrect. Il s'agit d'un sujet très varié qui dépend fortement de facteurs tels que votre infrastructure technologique. La résolution de ces problèmes semble souvent 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 guide pour en savoir plus sur cette vulnérabilité et sur la manière de l'atténuer.

view guidelines

Falsification des demandes de serveur

ts
let url = request.params.url ;

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

renvoie render.export () ;

Les vulnérabilités liées à la falsification des requêtes côté serveur se produisent lorsqu'un utilisateur parvient à demander à une application d'envoyer des requêtes HTTP à 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. Nous examinerons cela de plus près à l'aide de quelques exemples pour mieux comprendre à quoi cela ressemble en action dans cette directive.

view guidelines

Stockage des mots de passe

Feature Cryptographic hash Password hash Speed Very fast Intentionally slow Work factor can be adjusted No Yes

Si votre application authentifie les utilisateurs, il y a de fortes chances qu'elle traite également des mots de passe. La gestion des mots de passe des utilisateurs est très importante et leur gestion appropriée l'est encore plus. Il est difficile d'imaginer un scénario pire que celui d'une application attaquée et de la fuite des mots de passe des utilisateurs sur Internet à la vue de tous. Comment les mots de passe peuvent-ils être stockés en toute sécurité et conformément aux meilleures pratiques ? Jetons un coup d'œil à quelques méthodes.

view guidelines

Mass Affectation

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 leur objet associé qui peuvent être modifiées par un utilisateur. Cette vulnérabilité peut survenir lors de l'utilisation d'une bibliothèque/framework qui permet la liaison automatique de paramètres HTTP sur 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 la directive pour plus de détails.

view guidelines

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

xml
< ? version xml = « 1.0 » ? >
< ! Élément extérieur DOCTYPE [
< ! ENTITY ExternalEntity SYSTEM « file : ///etc/passwd » >] >
<outerElement>&Entité externe ;</outerElement>

La classe de vulnérabilité « XML External Entities » (XXE) est une erreur de configuration de sécurité impliquant des analyseurs XML. La norme XML inclut des moyens de référencer des « entités », telles que des fichiers et des URL. Par défaut, les analyseurs résolvent 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. Lisez la directive complète pour plus d'informations.

view guidelines

Injection - Traversée de trajectoire

pseudo
let BaseFolder = « /var/www/api/documents/ » ;
let path = BaseFolder + request.params.filename ;

renvoie file.read (chemin) ;

Path Traversal est un autre type de vulnérabilité d'injection assez courant. Ils ont tendance à se produire lorsque la construction d'un URI (qu'il s'agisse d'une URL, d'un chemin de fichier ou autre) ne garantit pas correctement que le chemin entièrement résolu ne pointe pas en dehors de la racine du chemin 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 global qui a été effectué. Lisez le guide pour en savoir plus.

view guidelines

Authentification et autorisation

cs

//Assurez-vous que le comportement par défaut est d'authentifier les demandes et de vérifier si elles sont d'origine administrative
[Authentifier]
[Autoriser (« Admin »)]
classe publique SecureController : Controller
{

}

classe publique MyController : SecureController
{

//Remplace l'attribut Authorize hérité pour permettre à n'importe quel utilisateur d'accéder à la page

view guidelines

Injection - XSS

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

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 un attaquant dans le navigateur d'un autre utilisateur. XSS peut également être considéré comme une vulnérabilité d'injection HTML/JavaScript. Examinons les types de XSS que vous pouvez rencontrer.

view guidelines

Injection 101

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

Injection SQL
Scripting intersite (injection HTML/JavaScript)
Traversée de chemin (injection de chemin/URL)
Injection de commandes
Injection de code

L'une des catégories de vulnérabilités les plus connues est généralement celle des vulnérabilités liées à l'injection, en particulier, et cela ne surprend personne, la référence incontestée : SQL Injection. Il est difficile d'éviter d'entendre parler de l'injection SQL dans le monde de la technologie, alors nous allons simplement en parler. Lisez la suite pour obtenir une brève introduction aux défauts d'injection.

view guidelines

Download of files

chaîne publique UploadProfilePicture (FormFile UploadedFile)
{
//Génère le chemin pour enregistrer le fichier téléchargé dans
var path = $ ». /uploads/avatars/ {request.user.id}/{uploadedFile.FileName} » ;

//Sauvegarde du fichier
var LocalFile = File.OpenWrite (chemin) ;
LocalFile.write (UploadedFile.readToEnd ()) ;
Fichier local .Flush () ;
LocalFile.close () ;

//Mise à jour de la photo de profil
UserProfile.UpdateUserProfilePicture (request.User, chemin)

chemin de retour ;
}

Il est très courant que les applications aient besoin, à un moment ou à un autre, de permettre aux utilisateurs de télécharger un fichier (pour l'utiliser ou simplement pour le stockage) quelque part dans l'application. Bien que cela semble assez simple, la manière dont cette fonction est implémentée peut être assez critique en raison des risques potentiels associés à la gestion des téléchargements de fichiers. Lisez la directive pour plus d'informations.

view guidelines

Injection de commandes

let ip = request.params.IPAddress ;

système (« ping" + ip) ;

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

view guidelines