ClickCease Schwachstellen: Die Wanzen dahinter Teil 4

Inhaltsübersicht

Abonnieren Sie unseren beliebten Newsletter

Schließen Sie sich 4.500+ Linux- und Open-Source-Experten an!

2x im Monat. Kein Spam.

Die Bugs hinter den Schwachstellen Teil 4

Joao Correia

April 21, 2023 - Technischer Evangelist

Willkommen zum vierten Teil der fünfteiligen Serie, in der wir uns mit den Codefehlern befassen, die die vielen regelmäßig gemeldeten Sicherheitslücken erklären. Wir werden uns mit den Mitre CWE Top 25 Liste für 2022 und gehen die Einträge #10 bis #6 der Liste durch. Ein herausragender Eintrag in diesem Teil ist "Use After Free", ein bekannter Name für ein sehr häufiges Vorkommnis.

Sie finden Teil 1 hier, Teil 2 hierund Teil 3 hier.

Kommen wir gleich zur Sache.

 

10. Uneingeschränkter Upload von Dateien mit gefährlichem Typ

 

Uneingeschränkter Datei-Upload liegt vor, wenn eine Anwendung Benutzern das Hochladen von Dateien ohne ordnungsgemäße Validierung ermöglicht, so dass sie Dateien mit gefährlichen Inhalten oder Typen hochladen können. Angreifer können diese Schwachstelle ausnutzen, um bösartigen Code auszuführen oder andere Sicherheitslücken innerhalb der Anwendung oder des Servers auszunutzen.

 

# Example of unrestricted file upload in Python

@app.route('/upload', methods=['POST'])

def upload_file():

    file = request.files['file']

    file.save(os.path.join('uploads', file.filename))

    return 'File uploaded successfully'

 

Um das unkontrollierte Hochladen von Dateien zu verhindern, sollten Entwickler robuste Mechanismen zur Dateivalidierung implementieren, die Dateitypen auf eine bekannte sichere Liste beschränken und serverseitige Prüfungen durchführen, um sicherzustellen, dass nur sichere Dateien akzeptiert werden.

 

9. Cross-Site Request Forgery (CSRF)

 

Cross-Site Request Forgery (CSRF) ist eine Art von Angriff, bei dem Benutzer dazu gebracht werden, unerwünschte Aktionen in einer Webanwendung auszuführen, bei der sie gerade authentifiziert sind. Dies geschieht, wenn eine bösartige Website, E-Mail oder ein Programm den Browser eines Benutzers dazu bringt, eine Aktion auf einer anderen Website ohne das Wissen oder die Zustimmung des Benutzers auszuführen.

 

<!-- Example of CSRF attack in an HTML form -->

<form action="http://example.com/transfer_funds" method="POST">

  <input type="hidden" name="amount" value="1000" />

  <input type="hidden" name="destination_account" value="attackers_account" />

  <input type="submit" value="Click here for a free gift!" />

</form>

 

Um CSRF-Angriffe abzuschwächen, sollten Entwickler Anti-CSRF-Tokens implementieren, sichere Kodierungspraktiken anwenden, z. B. das SameSite-Attribut in Cookies befolgen, und angemessene Authentifizierungs- und Autorisierungsprüfungen für sensible Aktionen sicherstellen.

 

8. Unzulässige Beschränkung eines Pfadnamens auf ein eingeschränktes Verzeichnis (auch bekannt als "Path Traversal")

 

Path Traversal ist eine Sicherheitslücke, die auftritt, wenn eine Anwendung externe Eingaben verwendet, um Datei- oder Verzeichnispfade zu konstruieren, ohne spezielle Elemente ordnungsgemäß zu neutralisieren. Dies kann es Angreifern ermöglichen, auf Dateien oder Verzeichnisse außerhalb des vorgesehenen eingeschränkten Speicherorts zuzugreifen, was zu unberechtigtem Zugriff, Änderung oder Offenlegung sensibler Informationen führen kann.

 

// Example of a path traversal vulnerability in PHP

$filename = $_GET['file'];

$content = file_get_contents("/restricted_directory/$filename");

echo $content;

 

Um Path-Traversal-Angriffe zu verhindern, sollten Entwickler Benutzereingaben validieren, sichere Funktionen oder Bibliotheken für Pfadmanipulationen verwenden und geeignete Zugriffskontrollen auf der Serverseite anwenden, um den Zugriff auf sensible Dateien und Verzeichnisse zu beschränken.

 

7. Verwendung nach Frei

 

"Use after free" ist ein Problem der Speicherkorruption, das auftritt, wenn ein Programm einen Zeiger weiter verwendet, nachdem er freigegeben wurde. Dies kann zu Datenverfälschung, Abstürzen oder sogar zur Ausführung von beliebigem Code führen, je nach Zeitpunkt und Instanziierung des Fehlers.


// Example of a use after free error in C

char *ptr = (char *)malloc(SIZE);

if (err) {

    abrt = 1;

    free(ptr);

}

...

if (abrt) {

    logError("operation aborted before commit", ptr);

}



Um "Use after free"-Probleme zu vermeiden, sollten Entwickler sichere Kodierungspraktiken anwenden, wie z. B. eine ordnungsgemäße Speicherverwaltung, die Verwendung von intelligenten Zeigern in Sprachen wie C++ und eine ordnungsgemäße Fehlerbehandlung, um "Dangling Pointer" zu verhindern.

 

6. Unsachgemäße Neutralisierung von speziellen Elementen, die in einem OS-Befehl verwendet werden ("OS Command Injection")

 

OS-Befehlsinjektion tritt auf, wenn eine Anwendung einen Betriebssystembefehl unter Verwendung extern beeinflusster Eingaben konstruiert, ohne spezielle Elemente ordnungsgemäß zu neutralisieren. Dies kann es Angreifern ermöglichen, beliebige Befehle oder Code auf dem Zielsystem auszuführen, was zu unbefugtem Zugriff oder Kontrolle über das System führen kann.

 

import os

user_input = input("Enter the name of the file to search: ")

command = f"find / -name {user_input}"

os.system(command)

 

Um die Einschleusung von Betriebssystembefehlen zu verhindern, sollten Entwickler Benutzereingaben validieren und bereinigen, parametrisierte APIs oder Funktionen verwenden, die keine Befehlstrennzeichen zulassen, und das Prinzip der geringsten Privilegien anwenden, um die möglichen Auswirkungen eines erfolgreichen Angriffs zu minimieren.

 

Zusammenfassend lässt sich sagen, dass es für Entwickler und Systemadministratoren gleichermaßen wichtig ist, sich dieser häufigen Schwachstellen bewusst zu sein und zu wissen, wie sie entschärft werden können. Durch die Befolgung sicherer Programmierpraktiken und die Implementierung geeigneter Schutzmaßnahmen können Sie das Risiko einer Ausnutzung erheblich verringern und Ihre Anwendungen und Systeme vor potenziellen Bedrohungen schützen.

Zusammenfassung
Die Bugs hinter den Schwachstellen Teil 4
Artikel Name
Die Bugs hinter den Schwachstellen Teil 4
Beschreibung
Lesen Sie hier den vierten Teil der fünfteiligen Serie, in dem wir uns mit den Codefehlern befassen, die die vielen regelmäßig gemeldeten Sicherheitslücken erklären.
Autor
Name des Herausgebers
TuxCare
Logo des Herausgebers

Möchten Sie das Patchen von Sicherheitslücken ohne Kernel-Neustart, Systemausfallzeiten oder geplante Wartungsfenster automatisieren?

Erfahren Sie mehr über Live-Patching mit TuxCare

Werden Sie ein TuxCare-Gastautor

Los geht's

E-Mail

Beitreten

4,500

Linux & Open Source
Fachleute!

Abonnieren Sie
unseren Newsletter