Skip to main content

Sicherheitsherausforderungen mit Snyk Code und Symbolic AI meistern

Artikel von
blog feature ai pink

27. Februar 2025

0 Min. Lesezeit

Wie gut eignet sich Symbolic AI als automatisiertes Expertensystem, um Codepfade zu analysieren und Sicherheitslücken zu erkennen? Snyk Code wurde getestet und zeigt die Vorteile regelbasierter algorithmischer Systeme.

Was ist die Symbolic-AI-Security-Engine von Snyk?

Die SAST-Engine von Snyk, die statische Sicherheitsanalysen von Codebasen durchführt, basiert auf einem Symbolic-AI-System und bietet dadurch höhere Genauigkeit und schnellere Ausführung. Darüber hinaus nutzt sie das Fachwissen von Sicherheitsforscherinnen und -forschern intensiv, um ein Sicherheits-Expertensystem mit einer Grundlage aus Schwachstellenregeln bereitzustellen.

Diese Eigenschaften von Snyk Code verschaffen der Lösung einen technologischen Vorsprung gegenüber herkömmlichem Pattern-Matching (grep-ähnlichen Suchen mit regulären Ausdrücken), wenn es darum geht, Sicherheitslücken in Ihrem Code zu erkennen.

SAST meistert Herausforderungen der Code-Sicherheit

Florin Walter ist Sicherheitsexperte und Penetrationstester. In den vergangenen Monaten hat er auf LinkedIn Sicherheitsherausforderungen und Quizbeiträge zu sicherem Code veröffentlicht.

Ich wollte wissen, ob Snyk Code-Schwachstellen in verschiedenen Programmiersprachen erkennen würde, und habe deshalb Florins Code-Repository importiert. Im weiteren Verlauf dieses Beitrags sehen wir uns die Ergebnisse an.

Open-Redirect-Schwachstelle in einer Python-Flask-Anwendung

Flask ist ein beliebtes Webanwendungs-Framework für Python. Der folgende Python-Code verwendet verschiedene Routen, um eine Startseite und eine Loginseite darzustellen.

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)

Leider entsteht durch die Möglichkeit für Nutzer und andere Systeme, eine Weiterleitungs-URL anzugeben, auch eine inhärente Open-Redirect-Schwachstelle.

Als Entwickler haben Sie das vielleicht übersehen, weil Sie sich vor allem auf Aufgaben im Produkt-Backlog konzentrieren mussten. Snyk führt jedoch einen statischen Anwendungssicherheitstest durch, um diesen Python-Code zu analysieren und die Open-Redirect-Schwachstelle zu erkennen:

Snyk Code findet eine Open-Redirect-Schwachstelle in einer Python-Flask-Anwendung

Snyk geht über das bloße Erkennen von unsicherem Code hinaus. Dank der Machine-Learning-Engine von Snyk, die Sicherheitslücken und ihre Behebung anhand von Daten aus der Open-Source-Community analysiert, kann das Tool eine passende Sicherheitskorrektur ableiten und Entwicklern vorschlagen, mit der sie diese Open-Redirect-Schwachstelle in ihrem Code beheben können.

Der folgende Screenshot zeigt eine von drei vorgeschlagenen Codekorrekturen von Snyk, zusammen mit Best Practices zur Prävention und kontextbezogenen Informationen zu dieser Art von Sicherheitslücke:

Die Snyk-Fix-Analyse schlägt Codekorrekturen zur Behebung der Sicherheitslücke vor

SSRF und XSS in JavaScript-Code für eine Node.js-Anwendung

Die nächste Sicherheitsherausforderung ist in JavaScript geschrieben und basiert auf einer serverseitigen Node.js-Webanwendung, die mit Express erstellt wurde:

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');
});

Nehmen Sie sich kurz Zeit, den Code zu überfliegen und die Sicherheitslücken zu erkennen.

Ich habe auch diese Herausforderung in Snyk importiert. Im Folgenden sehen Sie einige der von Snyk erkannten Probleme.

Server-Side Request Forgery (SSRF) mit Axios

Snyk hat erkannt, dass nicht bereinigte Eingaben aus einem HTTP-Parameter (req.query.url) in Zeile 24 an die HTTP-Clientbibliothek axios weitergegeben werden. Diese Variable url gibt die Remote-URL an, an die eine HTTP-Anfrage gesendet wird.

Da Nutzer die vollständige URL kontrollieren können, könnten sie diese missbrauchen und eine interne Adresse wie http://localhost oder andere interne und reservierte IP-Adressen angeben, um Daten abzurufen und Informationen auszulesen.

Snyk hat diesen unsicheren Code wie folgt identifiziert und zeigt dabei alle betroffenen Codepfade und relevanten Codezeilen:

SSRF-Schwachstelle in Code mit axios, erkannt von Snyk

Cross-Site-Scripting-Schwachstelle in der HTTP-Antwort von Express

Im oben gezeigten Code, der aufgrund einer HTTP-Anfrage mit einer vom Nutzer kontrollierten vollständigen URL für SSRF anfällig ist, hat Snyk noch eine weitere Schwachstelle erkannt.

Cross-Site-Scripting-Schwachstelle in einer Express-HTTP-Antwort

Diese Schwachstelle ist subtiler und geht über ein SSRF-Sicherheitsproblem hinaus. Wenn Sie genau auf den in Zeile 25 von Snyk markierten Code achten, sehen Sie, dass die HTTP-Antwort unverändert an den Browser gesendet wird:

res.send(response.data)

Standardmäßig setzt Express die HTTP-Antwort-Header auf application/html. Wenn der Angreifer also den Remote-Server kontrolliert, kann er dort schädlichen JavaScript-Code platzieren, der clientseitig einen XSS-Angriff auslöst, während der Browser die vollständige HTML-Antwort interpretiert.

Ein weiterer von Snyk erkannter unsicherer Codebefund ist eine mögliche CRLF-Injection. Sehen Sie sich diesen Teil des oben gezeigten Codes der Express-Webanwendung an:

    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');
    }

Snyks SAST erkennt diese mögliche CRLF-Injection problemlos als eine der gefundenen Schwachstellen:

CRLF-Injection durch benutzergesteuerte Eingaben

Wie kann Snyk meinen Code vor Sicherheitslücken schützen?

Das statische Anwendungssicherheitstest-Tool von Snyk, Snyk Code, hilft Entwicklern, Sicherheitslücken in ihrem Code in Echtzeit zu finden, indem es Befunde zu unsicherem Code direkt in ihrer IDE anzeigt.

Der Einstieg ist kostenlos: Installieren Sie die Snyk-Erweiterung für VS Code und machen Sie Sicherheitsfehlern den Garaus!

Screenshot der Snyk-Erweiterung für VS Code

Kostenloses Online-Tool zur Codeprüfung

Sichern Sie Ihren Code, bevor Sie Ihren nächsten Commit erstellen.