Zum Inhalt springen
BlogSicherheitSicherheit in Ihrer DevOps-Pipeline

Sicherheit in Ihrer DevOps-Pipeline

Ein undichtes Rohr mit dem Text "Security in your DevOps Pipeline: Is your GraphQL API leaky?"

Bei der Softwareentwicklung und Ihren DevOps-Prozessen - vom Entwurf bis zur Bereitstellung - muss die Sicherheit an erster Stelle stehen. Wenn Sie daran erst später denken, werden Sicherheitsvorfälle auf Sie zurückfallen.

In diesem Beitrag befassen wir uns mit einem häufigen, aber kritischen Versäumnis von Entwicklern von GraphQL-APIs - der Aktivierung von Introspektionsfunktionen in Produktionsumgebungen. Introspektion ist eine unglaubliche Funktion zum Verstehen und Testen Ihrer API-Funktionen in der Entwicklungsphase. Wenn Sie sie jedoch vor der Inbetriebnahme nicht deaktivieren, öffnen Sie Ihre Anwendung für erhebliche Schwachstellen. Wir werden erörtern, wie dies zu einem großen Sicherheitsrisiko eskalieren kann und welche vorbeugenden Maßnahmen Sie ergreifen können, um die Sicherheit in Ihrer DevOps-Pipeline zu erhöhen.

Das Szenario

Stellen Sie sich ein Entwicklungsteam vor, das die Implementierung der GraphQL-API seines Unternehmens anführt. GraphQL ist eine leistungsstarke Abfragesprache, mit der Kunden in einer einzigen Abfrage genau das anfordern können, was sie benötigen. Dies steht im Gegensatz zu herkömmlichen REST-APIs, die unter Umständen mehrere Anfragen erfordern, um komplexe Daten und Beziehungen zusammenzustellen. Die Struktur der Daten in GraphQL wird in einem Schema definiert, das die verfügbaren Datentypen, Abfragen und Mutationen beschreibt.

Das Entwicklerteam hat sich mächtig ins Zeug gelegt und etwas ziemlich Beeindruckendes geschaffen. Diese API ist nicht nur robust, sondern auch skalierbar und kann dank der automatischen Skalierungsfunktionen, die das Team entwickelt und gebaut hat, Millionen von Transaktionen pro Minute verarbeiten. Mit ihrem Fokus auf Leistung und Skalierbarkeit haben sie dafür gesorgt, dass diese API eine enorme Last ohne Schluckauf bewältigen kann.

In ihrer Eile, diese glänzende neue GraphQL-API bereitzustellen und damit zu beeindrucken, haben sie jedoch ein kleines Detail übersehen - die Introspektion ist in der Produktionsumgebung immer noch aktiviert. Die Introspektion ist ein leistungsstarkes Tool für Entwickler, mit dem sie abfragen können, welche Ressourcen in der API verfügbar sind. Es ist nur nicht etwas, das für den Zugriff in der Produktion geöffnet werden sollte.

Was sind die Folgen?

Nun, da die API skaliert wird, um der Nachfrage gerecht zu werden, vervielfacht jede neue Instanz das potenzielle Risiko. Jetzt hat sich die erhebliche Sicherheitslücke über eine wachsende Anzahl von Knoten verbreitet. Damit haben wir die Voraussetzungen für eine mögliche Ausnutzung durch böswillige Akteure geschaffen. Sie haben alles, was sie brauchen, um detaillierte Informationen über die Struktur und die Fähigkeiten dieser glänzenden neuen API zu entdecken.

Durch das Vergessen eines einfachen Umschalters hat das Team eine gut gemeinte Funktion in eine klaffende Sicherheitslücke verwandelt.

Die Anfälligkeit verstehen

Wenn die Introspektion aktiviert ist, kann ein Entwickler die GraphQL-API abfragen, um das vollständige Schema mit allen Datentypen, Feldern, Abfragen und Mutationen zu sehen. Dies ist wie eine detaillierte Karte aller operativen Endpunkte und Datenstrukturen für eine API. Das ist eine großartige Ressource für einen Entwickler. Aber es ist nichts, was man in die Hände eines Cyberangreifers geben sollte.

Überlegen Sie, wie ein Angreifer die Introspektionsfunktionen ausnutzen könnte, um mehr über Ihre GraphQL-API zu erfahren. Zunächst können sie Fragmente definieren, um ihre Abfrageergebnisse leserfreundlicher zu gestalten.

  fragment FullType on __Type {
    kind
    name
    description
    fields(includeDeprecated: true) {
      name
      description
      args {
        ...InputValue
      }
      type {
        ...TypeRef
      }
      isDeprecated
      deprecationReason
    }
    inputFields {
      ...InputValue
    }
    interfaces {
      ...TypeRef
    }
    enumValues(includeDeprecated: true) {
      name
      description
      isDeprecated
      deprecationReason
    }
    possibleTypes {
      ...TypeRef
    }
  }

  fragment InputValue on __InputValue {
    name
    description
    type { ...TypeRef }
    defaultValue
  }

  fragment TypeRef on __Type {
    kind
    name
    ofType {
      kind
      name
      ofType {
        kind
        name
        ofType {
          kind
          name
          ofType {
            kind
            name
            ofType {
              kind
              name
              ofType {
                kind
                name
                ofType {
                  kind
                  name
                }
              }
            }
          }
        }
      }
    }
  }

Dann können sie eine Abfrage senden, um sich über die __schema Feld, das auf dem Root-Typ einer Abfrage verfügbar ist. Die GraphQL-Abfrage könnte wie folgt aussehen:

{
  __schema {
    queryType {
      name
    }
    mutationType {
      name
    }
    subscriptionType {
      name
    }
    types {
      ...FullType
    }
    directives {
      name
      description
      locations
      args {
        ...InputValue
      }
    }
  }
}

Indem er diese Abfrage zusammen mit den Fragmentdefinitionen an eine GraphQL-API mit aktivierter Introspektion sendet, erhält ein Angreifer eine Antwort mit einem umfassenden JSON-Objekt mit allen Ihren API-Details. Anschließend kann er ein Tool wie GraphQL Voyager verwenden, um die GraphQL-API als interaktive Grafik anzuzeigen.

Hier ist ein Beispiel für die Visualisierung einer GraphQL-API, die auf der Antwort auf die oben gezeigte Introspektionsabfrage basiert:

Graphql-Visualisierung

Wie Sie sehen können, offenbart dies eine Menge der Struktur und Details im Zusammenhang mit sensiblen Zahlungsvorgängen. Dies sind äußerst nützliche Informationen für einen Angreifer, der versucht, in Ihre API einzudringen. Auch hier gilt: Großartig für Entwickler und leider auch großartig für Angreifer.

Wenn Sie die Introspektion in der Produktion aktiviert lassen, sind Sie folgenden Risiken ausgesetzt:

  • Offenlegung von Informationen: Detaillierte Schemainformationen können Angreifern Einblicke in Ihre Backend-Systeme, Datenmodelle und Geschäftslogik verschaffen. Indem Sie ihnen die Baupläne Ihrer Festung aushändigen, machen Sie es ihnen leicht, gezielte Angriffe zu planen.
  • Erleichterung von Angriffen: Ausgestattet mit diesen Details über Ihre API können Angreifer Abfragen erstellen, die Schwachstellen ausnutzen. Dies kann zu Datenverletzungen oder Dienstunterbrechungen führen.
  • Ressourcenverbrauch: Angreifer können dieses Wissen auch nutzen, um böswillige Abfragen als Denial-of-Service-Angriffe (DoS) zu starten. Diese Angriffe zehren an den Ressourcen und können Ihr System vollständig zum Erliegen bringen.

Aber verzweifeln Sie nicht! Die Schritte zur Minderung dieses Risikos sind einfach und unkompliziert. Als ersten Schritt, um uns zu schützen, sollten wir uns ansehen, was OWASP zu sagen hat.

Anleitungen aus dem OWASP GraphQL Cheat Sheet

Das OWASP GraphQL Cheat Sheet ist eine wertvolle Ressource für die Absicherung Ihrer GraphQL APIs. Es bietet Anleitungen, die Ihnen in den folgenden Bereichen helfen:

  • Validierung von Eingaben
  • Begrenzung oder Vermeidung teurer Abfragen
  • Sicherstellung einer angemessenen Zugangskontrolle
  • Deaktivierung unsicherer Konfigurationen, wie z. B. der Introspektion

Der Spickzettel enthält einen Abschnitt, der sich mit Introspektion und GraphiQL befasst. GraphiQL ist eine browserinterne IDE zur Erforschung von GraphQL. Ähnlich wie die Introspektionsfähigkeiten kann GraphiQL detaillierte Informationen über das Innenleben und den Entwurf Ihrer API offenlegen.

Wenn Sie eine GraphQL-API erstellen, empfehlen wir Ihnen, sich mit dem OWASP-Spickzettel vertraut zu machen.

Entschärfung der Sicherheitslücke bei der Introspektion

In Anlehnung an den OWASP-Spickzettel werden wir die Anweisung beherzigen, Introspektionsabfragen in Produktionsumgebungen oder öffentlich zugänglichen Umgebungen zu deaktivieren. Dies ist von entscheidender Bedeutung, um den unbefugten Zugriff auf detaillierte Schemainformationen zu verhindern, die von Angreifern ausgenutzt werden könnten.

Wie können wir das tun?

Hier ist ein einfaches Code-Snippet in JavaScript, das zeigt, wie man die Introspektion in der Produktion ausschaltet, wenn man Apollo Server verwendet:

const { ApolloServer } = require('apollo-server');

const server = new ApolloServer({
  typeDefs,
  resolvers,  // Enable introspection only in development or test environments
  introspection: process.env.NODE_ENV === 'development' ||                 process.env.NODE_ENV === 'test',
});

server.listen().then(({ url }) => {
  console.log(`Server ready at ${url}`);
});

Ja, das ist im Grunde alles, was es zu tun gibt. Dieser einfache Schritt (Einstellung introspection zu false beim Konfigurieren einer neuen Instanz von ApolloServer) verhindert, dass Benutzer über Introspektionsabfragen auf detaillierte Schemainformationen zugreifen können. Damit verringern Sie das Risiko, dass sensible Informationen nach außen dringen.

Dies zu einem Teil Ihrer Secure DevOps-Pipeline machen

Wenn dieser Schritt so einfach ist, warum vergessen ihn die Entwickler dann so oft? Weil sie sich auf andere Dinge konzentrieren und damit beschäftigt sind, wichtige Fristen einzuhalten. Es ist keine Überraschung, dass scheinbar unbedeutende Konfigurationseinstellungen gelegentlich übersehen werden.

Aus diesem Grund gibt es automatisierte Tests und die DevOps-Pipeline - zum Schutz vor menschlichen Fehlern und Vergesslichkeit.

Wie können Sie diese Sicherheitsmaßnahme in Ihre DevOps-Pipeline integrieren? Hier sind zwei Vorschläge:

  • Schreiben Sie einen Test vor der Bereitstellung, der explizit Ihre GraphQL-Serverkonfiguration überprüft, um sicherzustellen, dass die Introspektion bei der Produktionsbereitstellung deaktiviert ist.
  • Schreiben Sie einen Post-Deployment-Test, der eine Introspektionsabfrage in der Produktionsumgebung versucht. Wenn Ihr Versuch eine Fehlerantwort erhält (z.B. Cannot query field '__schema' on type 'Query'), dann sollte Ihr Test erfolgreich sein.

Nutzen Sie die Vorteile von CI/CD-Pipeline-Tools wie Jenkins, GitHub Actions oder CircleCI, um Skripte auszuführen, die Ihre GraphQL-API-Einstellungen als Teil des CI/CD-Prozesses überprüfen.

Fazit

Die Erstellung von GraphQL-APIs kann für Ihr Unternehmen eine großartige Möglichkeit zur Innovation sein, erfordert aber auch ein proaktives Vorgehen in Bezug auf Ihre Sicherheitspraktiken. Ein kleiner Ausrutscher könnte Ihre API großen Schwachstellen aussetzen. In diesem Beitrag haben wir ein hervorragendes Beispiel dafür behandelt: die Deaktivierung der Introspektion für Produktionsbereitstellungen, damit Angreifer keinen Zugriff auf detaillierte Informationen über Ihr GraphQL-Schema haben.

Weitere Anleitungen und Ressourcen finden Sie in Linodes umfassender Bibliothek mit Anleitungen zu den Themen Sicherheit, GraphQL-Entwicklung und https://www.linode.com/docs/guides/platform/.

Kommentare (1)

  1. Author Photo

    Integrating security into your DevOps pipeline is essential for identifying vulnerabilities early and ensuring robust protection throughout the development cycle. Emphasizing automated security checks and continuous monitoring helps mitigate risks and enhances overall system resilience.

Kommentar abgeben

Ihre E-Mail Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit *gekennzeichnet