Sécuriser les téléchargements de fichiers en Go : se protéger contre 7 attaques courantes
Dans les systèmes sans authentification classique, les téléchargements de fichiers exigent une identification fiable de la source des requêtes. Pour une extension navigateur qui convertit les PDF en Markdown, un modèle basé sur ECDSA P-256 utilisant l'API WebCrypto est mis en œuvre. À sa première utilisation, une paire de clés non exportable est générée :
const keyPair = await crypto.subtle.generateKey(
{ name: 'ECDSA', namedCurve: 'P-256' },
false, // extractable = false
['sign', 'verify']
);
La clé publique est enregistrée sur le serveur, qui retourne un device_id et un device_token. Chaque requête API inclut :
Authorization: Bearer <token>X-Timestamp(±5 minutes)X-Nonce(anti-replay)X-Body-SHA256X-Signature(signature ECDSA sur METHOD+PATH+TIMESTAMP+NONCE+BODY_HASH)
Le serveur vérifie la signature à l’aide de la clé publique, garantissant :
- Limitation de débit par appareil
- Protection contre les attaques par relecture
- Contrôle des slots (max 3 tâches actives)
- Limites d’enregistrement (5/IP/hour)
Ce modèle augmente le coût des attaques : l’émulation nécessite une implémentation complète de la signature ECDSA.
Attaque 1 : Spoofing du type de fichier
Un attaquant masque un exécutable sous forme de PDF. La défense repose sur une couche de sécurité en trois niveaux.
Frontend : validation du type MIME et de l’extension :
const ALLOWED_TYPES = ['application/pdf'];
const ALLOWED_EXTENSIONS = ['.pdf'];
function validateFile(file) {
const isPdf = ALLOWED_TYPES.includes(file.type) ||
ALLOWED_EXTENSIONS.some(ext =>
file.name.toLowerCase().endsWith(ext));
if (!isPdf) return { valid: false, error: 'PDF uniquement' };
}
Backend : routage basé sur Content-Type. Critique : bytes magiques :
pdfMagicBytes := "%PDF"
header4 := make([]byte, 4)
_, err := file.Read(header4)
if string(header4) != pdfMagicBytes {
respondError(w, http.StatusBadRequest,
models.ErrCodeValidationError,
"Le fichier n'est pas un PDF valide")
}
file.Seek(0, 0)
La lecture des premiers octets contourne les en-têtes et les extensions. Les fichiers polyglottes (PDF valides contenant du code malveillant) nécessitent des signatures supplémentaires.
Attaque 2 : Épuisement du disque (DoS)
Attaque par déni de service via des fichiers volumineux. Les mesures préventives incluent :
http.MaxBytesReader(w, r.Body, MaxFileSize + 1MB)— arrêt de la lecture à la limite.- Slots par appareil : max 3 tâches actives (
queued,processing,ready,error). - Limites de débit sur l’enregistrement et les requêtes.
L’identification par appareil rend inopérants le changement d’IP ou le rotation de jeton.
Attaque 3 : Parcours de chemins
Un attaquant utilise ../../../etc/passwd. Solution : chemin fixe {UUID}/input.pdf. L’entrée utilisateur dans les chemins est entièrement ignorée.
Nettoyage côté frontend (couche additionnelle) :
function sanitizeFileName(name) {
return name
.replace(/[/\\?%*:|"<>]/g, '-')
.replace(/^\.+/, '')
.replace(/\.$/, '')
.substring(0, 255)
.trim();
}
Le backend génère le chemin indépendamment du nom de fichier.
Attaque 4 : SSRF via téléchargement depuis URL
Pour la fonctionnalité « télécharger depuis une URL », les éléments suivants sont bloqués :
- Résolution DNS avant le téléchargement
- Redirections
- Adresses IP privées (liste noire : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Attaque 5 : Attaques par relecture
X-Nonce + X-Timestamp + signature. Le nonce est stocké par appareil ; le timestamp est validé dans une fenêtre de ±5 minutes.
Attaque 6 : Impersonnation d’appareil
extractable: false garantit que la clé privée ne peut pas être exportée. Voler device_token est inutile sans signatures valides.
Attaque 7 : Abus au niveau de l’application
Limites de débit + contrôle des slots + signature cryptographique. Max 3 slots, 5 enregistrements/IP/hour.
Points clés
- L’identification cryptographique par appareil remplace les comptes pour le contrôle de débit.
- Les bytes magiques (
%PDF) sont la seule méthode fiable pour vérifier le type de fichier. MaxBytesReader+ gestion des slots empêchent les attaques DoS.- Les chemins fixes éliminent les risques de parcours.
- ECDSA P-256 avec nonce et timestamp bloque les relectures et les impersonnations.
— Editorial Team
Aucun commentaire pour le moment.