Skip to main content

Résoudre les défis de sécurité avec Snyk Code et l’IA symbolique

Écrit par
blog feature ai pink

27 février 2025

0 minutes de lecture

Quelle est l’efficacité de l’IA symbolique en tant que système expert automatisé pour analyser les chemins d’exécution du code et détecter les failles de sécurité ? Snyk Code a été mis à l’épreuve et démontre les avantages des systèmes algorithmiques fondés sur des règles.

Qu’est-ce que le moteur de sécurité par IA symbolique de Snyk ?

Le moteur SAST de Snyk, qui effectue une analyse statique de sécurité des bases de code, repose sur un système d’IA symbolique offrant une meilleure précision et une exécution plus rapide. Il tire également pleinement parti de l’expertise de chercheurs en sécurité pour fournir un système expert fondé sur des règles de détection des vulnérabilités.

Ces caractéristiques de Snyk Code lui confèrent une supériorité technologique sur les approches traditionnelles de recherche par correspondance de motifs (recherches d’expressions régulières de type grep) pour détecter les vulnérabilités dans votre code.

SAST remporte les défis de sécurité du code

Florin Walter est un professionnel de la sécurité et un testeur d’intrusion qui a publié ces derniers mois sur LinkedIn des défis de sécurité et des quiz sur le code sécurisé.

Je me demandais si Snyk détecterait certaines vulnérabilités dans du code écrit dans différents langages ; j’ai donc importé le dépôt de code de Florin. Nous examinerons les résultats dans la suite de cet article.

Redirection ouverte dans une application Flask en Python

Flask est un framework populaire pour les applications web en Python. Le code Python suivant utilise différentes routes pour afficher une page d’accueil et une page de connexion.

from flask import Flask, request, redirect, url_for
import logging

app = Flask(__name__)

logging.basicConfig(level=logging.INFO)

def is_authenticated_user():
    # This function checks if the user is authenticated and is omitted for brevity
   pass

@app.route('/')
def home():
    if not is_authenticated_user():
        logging.info('Unauthorized access attempt.')
        return redirect(url_for('login'))

    redirect_url = request.args.get('redirect_url')
    if redirect_url:
        logging.info(f'Redirecting to: {redirect_url}')
        return redirect(redirect_url)

    return 'Welcome to the home page!'

@app.route('/login')
def login():
    # Simulated login page
    return 'Login Page - User authentication goes here.'

if __name__ == '__main__':
    app.run(debug=False)

Malheureusement, une vulnérabilité de redirection ouverte est également inhérente à la possibilité pour les utilisateurs et les systèmes externes de spécifier une URL de redirection.

En tant que développeur, vous avez peut-être pu passer à côté, car vous deviez vous concentrer avant tout sur les tâches produit de votre backlog. Pourtant, Snyk exécute un test statique de sécurité des applications pour analyser ce code Python et détecter la vulnérabilité de redirection ouverte :

Snyk Code détecte une vulnérabilité de redirection ouverte dans une application Python Flask

Snyk va au-delà de la simple détection du code non sécurisé. Grâce à son moteur de machine learning, qui analyse les failles de sécurité et leurs correctifs issus de la communauté open source, Snyk peut déduire et suggérer le correctif de sécurité que les développeurs pourraient appliquer à leur code pour corriger cette vulnérabilité de redirection ouverte. 

Voici la capture d’écran de l’un des trois correctifs de code suggérés par Snyk, accompagnée de bonnes pratiques de prévention et d’informations contextuelles sur ce type de faille de sécurité :

L’analyse de correction de Snyk suggère des correctifs de code pour remédier à la vulnérabilité de sécurité

SSRF et XSS dans du code JavaScript pour une application Node.js

Le défi de sécurité suivant est écrit en JavaScript et repose sur une application web côté serveur Node.js créée avec Express :

const express = require('express');
const axios = require('axios');

const app = express();

app.get('/profile', (req, res) => {
    console.log('Received request for /profile');

    // Simulated profile data
    const profileData = {
        name: 'John Doe',
        role: 'Developer'
    };

    res.json(profileData);
    console.log('Sent profile data response');
});

app.get('/fetch-data', async (req, res) => {
    const url = req.query.url;
    console.log(`Received request for /fetch-data with URL: ${url}`);

    try {
        const response = await axios.get(url);
        res.send(response.data);
        console.log(`Data fetched and sent for URL: ${url}`);
    } catch (error) {
        console.error(`Error fetching data from URL: ${url}`, error);
        res.status(500).send('Error fetching data');
    }
});

app.listen(3000, () => {
    console.log('Server running on port 3000');
});

Prenez un instant pour parcourir le code et repérer les vulnérabilités de sécurité.

J’ai également importé ce défi dans Snyk. Voici quelques-unes des vulnérabilités détectées.

Falsification de requête côté serveur (SSRF) avec Axios

Snyk a détecté qu’une entrée non assainie provenant d’un paramètre HTTP (req.query.url) est transmise à la bibliothèque cliente HTTP axios à la ligne 24. La variable url spécifie l’adresse URL distante à laquelle une requête HTTP sera envoyée.

Comme l’utilisateur peut contrôler l’URL complète, il peut en abuser et spécifier une adresse interne telle que http://localhost, ainsi que d’autres adresses IP internes ou réservées, afin de recueillir des données et d’extraire des informations.

Snyk a identifié le code non sécurisé suivant, en indiquant tous les chemins d’exécution et les lignes de code concernées par la vulnérabilité :

Vulnérabilité SSRF dans du code utilisant axios détectée par Snyk

Faille de script intersites dans une réponse HTTP Express

Dans la continuité du code ci-dessus, vulnérable aux attaques SSRF en raison d’une requête HTTP utilisant une variable contrôlée contenant une URL complète, Snyk a détecté une autre vulnérabilité.

Vulnérabilité de type cross-site scripting dans la réponse HTTP d’Express

Cette vulnérabilité est plus subtile : il ne s’agit pas seulement d’un problème de SSRF. Si vous examinez attentivement le code mis en évidence à la ligne 25 par l’analyse de Snyk, vous verrez que la réponse HTTP est envoyée telle quelle au navigateur :

res.send(response.data)

Par défaut, Express définit les en-têtes de réponse HTTP sur application/html. Si l’attaquant contrôle le serveur distant, il peut donc y intégrer du code JavaScript malveillant pour déclencher une XSS côté client, le navigateur interprétant l’intégralité de la réponse HTML.

Snyk détecte également un autre problème de code non sécurisé : une possible injection CRLF. Examinez cette partie du code de l’application web Express ci-dessus :

    try {
        const response = await axios.get(url);
        res.send(response.data);
        console.log(`Data fetched and sent for URL: ${url}`);
    } catch (error) {
        console.error(`Error fetching data from URL: ${url}`, error);
        res.status(500).send('Error fetching data');
    }

L’analyse SAST de Snyk repère facilement cette possible injection CRLF parmi les vulnérabilités détectées :

Injection CRLF due à une entrée contrôlée par l’utilisateur

Comment Snyk peut-il protéger mon code contre les failles de sécurité ?

L’outil de test statique de sécurité des applications de Snyk, Snyk Code, aide les développeurs à repérer les vulnérabilités dans leur code en temps réel, en affichant les problèmes de code non sécurisé directement dans leur IDE.

C’est gratuit pour commencer : installez l’extension Snyk pour VS Code et éliminez ces bugs de sécurité !

Capture d’écran de l’extension Snyk pour VS Code

Outil gratuit de vérification de code en ligne

Sécurisez votre code avant votre prochain commit.

Lire la suite

blog feature ai pink
Blog

Le risque lié à un modèle d’IA dépend de ce à quoi il peut accéder

Le score de risque d’un modèle ne raconte qu’une partie de l’histoire : son impact dépend des données, des outils et des actions auxquels son application peut accéder. Découvrez comment les équipes de sécurité peuvent vérifier cette portée et choisir des mesures de contrôle ciblées.

AI Background min crop
Blog

L’IA fait surgir tous les risques que vous avez acceptés : sept enseignements du panel de sécurité de l’IA sans filtre

L’IA rend les attaques moins coûteuses et plus rapides, exposant des risques déjà présents dans les organisations. Quatre responsables de la sécurité expliquent pourquoi une défense à la vitesse des machines et une remédiation accélérée sont désormais indispensables.

blog feature ai violet
Blog

VulnBump : les agents IA peuvent-ils corriger les dépendances vulnérables sans casser la build ?

VulnBump évalue des agents IA sur 307 mises à niveau réelles de dépendances. Une correction n’est validée que si la vulnérabilité disparaît et que la build et les tests restent au vert.