Pratiques

pour sécuriser des applications

Par Florent FREMONT, LeadDev MAIF

Introduction

Avant de sécuriser une application, il est nécessaire d'identifier ce que cela veut dire.

S'agit-il d'une activité ponctuelle ?
Fait-on tant d'erreurs en matière de sécurité ?
Est-ce l'affaire de tous ?
Comment s'améliorer et inscrire cela dans une démarche agile ?

La sécurité est l'affaire de tous et doit s'inscrire au quotidien

La sécurité

Permet de prévenir des risques informatiques
5 objectifs en général
- L'intégrité : garantir que les données sont bien celles que l'on croit être
- La disponibilité : maintenir le bon fonctionnement du système d'information
- La confidentialité : rendre l'information inintelligible à d'autres personnes que les seuls acteurs d’une transaction.
- La non répudiation : garantir qu'une transaction ne peut être niée
- L'authentification : assurer que seules les personnes autorisées aient accès aux ressources.

Sommaire

Documentation de sensibilisation à la sécurité. Version 2021

1 TOP10 OWASP

On va tenter d'identifier des principes qui peuvent nous aider à mieux concevoir et maintenir nos applications.

2 Principes

3 Pratiques & OWASP SAMM

TOP10 OWASP

Le contrôle d'accès applique une politique telle que les utilisateurs ne peuvent pas agir en dehors de leurs autorisations prévues.

Les défaillances entraînent généralement la divulgation, la modification ou la destruction non autorisées de toutes les données ou l'exécution d'une fonction commerciale en dehors des limites de l'utilisateur.

A01:2021-Contrôles d'accès défaillants

Adéquation à REST

Filtrer les accès / informations retournées

Traçer les défaillances

Deny by default

En passant d'une position à la deuxième position, auparavant connue sous le nom d'exposition aux données sensibles, qui est plus un symptôme large qu'une cause fondamentale, l'accent est mis sur les échecs liés à la cryptographie (ou à l'absence de cryptographie).

Ce qui conduit souvent à l'exposition de données sensibles.

A02:2021-Défaillances cryptographiques

Cryptage de bout en bout ?

Vive HTTPS

Fiabiliser la création de passwords

MD5 / SHA1 poubelle

TLS 1.2+

Une application est vulnérable aux attaques lorsque :

Les données fournies par l'utilisateur ne sont pas validées, filtrées ou épurées par l'application.
Les requêtes dynamiques ou les appels non paramétrés sans échappement contextuel sont utilisés directement dans l'interpréteur....

A03:2021-Injection

Tu valides et je valide

éviter les interprétations dynamiques

échapper les donnéess

Requêtes préparées

La conception non sécurisée est une catégorie large représentant différentes faiblesses, exprimée par « conception de contrôle manquante ou inefficace ».

Il y a une différence entre une conception non sécurisée et une mise en œuvre non sécurisée.

A04:2021-Conception non sécurisée

cycle de dev sécurisé

s'appuyer sur des libs dédiées

limiter les consommations

Autres

Principes

Ne jamais faire confiance
Classer les accès / données
Respecter le protocole
Limiter les accès + deny by default
Diminuer la surface de code
Effacer tout ce que vous pouvez (ne garder que l'essentiel)
Rester à jour

7 Principes

Partie Front

<!-- exploiter la syntaxe JSX -->
<p style={{color: myAppColor}}>{myAppRating}</p>

<!-- pour rendu dynamiquement du HTML -->
<p dangerouslySetInnerHTML={{__html: myAppReview}}></p>
<!-- ou utiliser DomPurify -->

// Pensez à valider les liens avant 
function validateURL(url) {
	const parsed = new URL(url)
	return ['https:', 'http:'].includes(parsed.protocol)
}
<a href={validateURL(url) ? url : ''}>This is a link!</a>

<!-- oubliez les variables pour passer un état -->
<script>window.__STATE__ = ${JSON.stringify({ data })}</script>

// en cas de vulnérabilité XSS
localStorage.setItem('monChat', 'Tom'); // not SAFE
// pour les données non sensibles, préférez IndexDB

Partie Front

Stocker l'authentification, via WorkerJs ou via Cookie 🍪
Utiliser les API : DOM, Angular, React pour le rendu
Votre donnée doit avoir le plus petit cycle de vie
Vérifier les dépendances avec owasp-dependency-check
Exploiter les Subresource Integrity
Eviter les données inline (cf Content Security Policy)
Bannir *storage et IndexDb pour les informations sensibles

Partie Back

Utiliser un runtime à jour (JDK, node à jour)
Concevoir des Api HTTP le plus sémantique (REST)
Miam, les requêtes préparées
Gérer les habilitations
Accès API / BDD au plus juste en terme d'habilitation
Vérifier les dépendances avec dependency-check-maven
Upload : vérifier plus que l'extension !
1. Validation de contenu
2. Nettoyage de nom de fichier
3. Analyse antivirus ou sandbox pour analyse...