Holen Sie sich die UMFANGREICHSTE Abdeckung für die Einhaltung von MISRA C! Erfahren Sie mehr >>

SQL Injections und Wahlsicherheit

Von Arthur Hicken

6. November 2018

5  min lesen

Ist dein Kopf im Sand? Wenn Sie keine ausreichenden Sicherheitstests durchführen, werden Sie möglicherweise dazu gebracht fühlen sicher, aber wenn Sie die Schwachstellen Ihres Codes nicht kennen, werden Ihre Systeme nicht sicher sein. Erfahren Sie, wie Sie mehr Transparenz erhalten und Sicherheit in Ihren Code integrieren.

So wie faire und genaue Wahlen eine Grundlage der Demokratie sind, ist sichere Software für unser modernes digitales Leben von entscheidender Bedeutung. Ich vergleiche diese nicht mit süß, sondern grabe mich in die Kreuzung der beiden, was katastrophal sein kann. Aktuelle Analyse unserer Abstimmungssysteme in den USA haben uns gezeigt, dass dies der Fall ist voller UnsicherheitenWählerdaten wird leicht und oft gestohlen. Wenn Sie nun über diese Sicherheitsanfälligkeit in den rund 10,000 lokalen Wahlgebieten nachdenken, ist es natürlich wahrscheinlich, dass einige dieser Systeme nicht sicher sind.

Die vielleicht beängstigendste und informativste dieser Geschichten ist die bei a letzter DefCon HackathonEin 11-Jähriger konnte mit meinem alten Favoriten, der SQL-Injection, auf die Wahlergebnisdaten eines Testsystems zugreifen. Es dauerte alle 10 Minuten. Ich denke, ich bin nicht überrascht, da ich SQL Injection lange als Kinderspiel angesehen habe (deshalb habe ich das gemacht SQLi Hall of Shame). Ein DefCon-Organisator bemerkte:

"Diese Websites sind so einfach zu hacken, dass wir sie nicht an erwachsene Hacker weitergeben können - sie würden von der Bühne gelacht werden."

Wahlbeamte behaupten in diesem Fall, dass die realen Systeme viel schwerer zu hacken sind, aber ich bin skeptisch. Diese Art der Ablehnung ist in der Software-Sicherheitsbranche bis zu dem Zeitpunkt, an dem ein tatsächlicher Hack stattfindet, üblich. Schauen Sie zurück zu Heartbleed, das die meisten erst ernst nahmen, als es gründlich bewiesen wurde. Oder wenn Schwachstellen in Reifendrucksensoren wurden entdeckt, nachdem Branchenleute sagten, es sei zu schwer, mit zu vielen Sorten, egal usw. Das gleiche gilt für Auto-Schlüsselanhänger-Angriffe, die erst kürzlich stattgefunden haben vor ein paar Wochen.

In einem weiteren allzu häufigen Schritt haben viele Wahlbeamte habe keine Tests durchgeführt. Dieser Head-in-the-Sand-Ansatz kann ihnen helfen, sich besser zu fühlen, aber wenn Sie nicht wissen, welche Sicherheitsrisiken Sie haben, sind Ihre Systeme nicht sicher. Ich garantiere, dass schlechte Schauspieler genau wissen, welche Schwachstellen es gibt.

Wir müssen es besser machen

Wir müssen anfangen, einen besseren Job zu machen. Es ist schwer genug, mit dem Internet verbundene Systeme zu sichern - wir müssen keine Hacker geben einfacher Zugriff.

In der Cybersecurity-Community wird häufig davon Abstand genommen, dass 100% ige Sicherheit nicht möglich ist. Aber während das stimmt, ist das im Moment NICHT das Problem. Das Problem ist, dass wir das nicht einmal machen einfaches Zeug um unsere Software zu sichern - zum Beispiel weder für die Wähler-Website noch für Wahlmaschinen. Ich weiß, dass jeder, der mein Auto wirklich will, es stehlen kann, aber ich schließe immer noch die Türen ab und lasse die Schlüssel nicht darin. Wenn Sie Ihre mit dem Internet verbundene Anwendung nicht vor eingabebasierten Angriffen schützen, können Sie jemanden mit all Ihren Daten davonfahren lassen.

Wie machen wir einen besseren Job?

Unabhängig von den Motivationen von Wahlhackern, seien es Nationalstaaten, politische Organisationen oder Hacker in ihrem Keller, die nach Spaß suchen, ist es wichtig, alles zu tun, um die Sicherheit und Zuverlässigkeit unserer Wahlsysteme zu erhöhen. Die Probleme können enorm erscheinen, aber tatsächlich gibt es einige grundlegende Dinge, die wir tun können, um die offensichtlichsten Löcher in unserem undichten System zu schließen.

Secure-by-Design

Secure-by-Design bedeutet, dass wir anfangen müssen, über Anwendungssicherheit und sichere Codierung anders nachzudenken. Dies bedeutet, dass wir die Sicherheit unserer Software nicht mehr testen können, als wir die Qualität eines Produkts testen können. Der Teil „by-design“ bedeutet, dass wir zuerst über Sicherheit nachdenken und dann sichere Anwendungen erstellen und Sicherheitstests wie Penetrationstests durchführen, um die Sicherheit zu validieren, NICHT um Sicherheitslücken zu finden.

Fragen Sie sich - was machen Sie, wenn der Pen-Test etwas findet? Führen Sie anschließend eine Flussanalyse durch, um ähnliche Schwachstellen zu finden? Suchen Sie dann nach Standards wie denen von CERT für Strategien, die Ihnen zeigen, wie Sie so codieren, dass Sie vermeiden, was Ihr Pen-Test findet? Im Fall von SQLi bedeutet dies, dass die Eingabevalidierung auf deterministische Weise durchgeführt wird, ohne dass die Wahrscheinlichkeit besteht, dass Benutzereingaben fehlen.

Passwörter

Angreifer greifen häufig über Kennwörter auf Geräte zu. Wenn Geräte Kennwörter von schlechter Qualität zulassen oder sich nicht vor Versuchen schützen, Kennwörter zu erraten, sind sie anfällig. Im schlimmsten Fall werden Geräte tatsächlich ohne Kennwörter ausgeliefert, bis Sie eines konfigurieren, oder mit einigen fest codierten Standardanmeldeinformationen. Dies ist ein Problem, das der Branche seit mehreren Jahrzehnten bekannt ist, das jedoch weiterhin besteht. Die jüngste Gesetzgebung in Kalifornien schreibt vor, dass Gerätehersteller grundlegende Schritte in diesem Bereich unternehmen müssen. Es ist sicherlich keine vollständige Lösung, aber ein ausgezeichneter Start.

Sichere Codierungsstandards

Es gibt viele Cybersicherheitsstandards und -frameworks, anhand derer Sie festlegen können, welche Praktiken und Prozesse zum Erstellen von sicherem Code implementiert werden sollten, z. B. Komponententests, Messen der Abdeckung, Ausführen statischer Analysen, Peer Review usw. Auf Softwareebene muss dies erfolgen letztendlich zu spezifischen Kodierungsstandards führen.

Die Kodierungsstandards enthalten Richtlinien für verschiedene Sorten. Einige von ihnen suchen nach Codierungsfehlern und identifizieren Sicherheitsprobleme, ohne den Code tatsächlich ausführen zu müssen. Andere sind Anti-Patterns, was bedeutet, dass sie nach schlechtem Code suchen, den Sie niemals verwenden sollten, oder nach „Code-Gerüchen“. Wieder andere schreiben Vorschriften vor und zeigen Ihnen einen besseren Weg zum Codieren.

Diese letzte Gruppe ist der einzige Weg, um der Cybersicherheit einen Schritt voraus zu sein. Diese Standards eignen sich gut für eine Secure-by-Design-Initiative und helfen Ihnen dabei, Code zu erstellen, der in erster Linie sicherer ist. Achten Sie bei der Implementierung Ihrer statischen Analyseinitiative für eine sichere Codierung auf die verfügbaren Prüfer und stellen Sie sicher, dass Sie eine gute Mischung aus Detektoren, Gerüchen und Prävention haben. Zusammen können alle drei Ihre Anwendung nicht nur gegen SQL-Injection, sondern auch gegen alle anderen gängigen eingabebasierten Angriffe schützen.

So starten Sie durch

Parasoft bietet Unterstützung für eine Vielzahl dieser Regeln für Entwickler, die C, C ++, Java und .NET verwenden. Wir unterstützen gängige Sicherheitsstandards wie CWE, OWASP, CERT und UL 2900. Da wir unsere Angebote für statische Analysen auf der Grundlage technischer Standards gestartet haben, scheint es so zu sein, dass wir über die größten verfügbaren Präventionsregeln verfügen. Zum Beispiel haben wir eine einfache Eingabevalidierungsregel, die, wenn sie befolgt wird, die Möglichkeit von SQLi beendet. Dies geschieht nicht, indem versucht wird, verdorbene Daten durch die unzähligen (und nahezu unendlichen) Abläufe einer Anwendung zu jagen (Secure-by-Testing), sondern indem Code erstellt wird, bei dem keine Pfade für die Umgehung der Eingabevalidierung vorhanden sind (Secure-by-Testing). von Entwurf).

Dies ist eine grundlegend andere Art, über Sicherheit nachzudenken. Wenn Sie einen Ingenieurabschluss haben, ist Ihnen dieser standardbasierte Ansatz sehr vertraut. Wenn Sie Ihr Leben damit verbracht haben, Software zu erstellen, scheint dies neu zu sein. Damit sind Sie der Software-Sicherheit immer einen Schritt voraus. Rufen Sie uns an und probieren Sie es selbst aus.

Bauen Sie von Anfang an Sicherheit in Ihre Anwendung ein

Von Arthur Hicken

Arthur ist seit über 25 Jahren bei Parasoft im Bereich Software-Sicherheit und Testautomatisierung tätig. Er hilft bei der Erforschung neuer Methoden und Techniken (einschließlich 5 Patente) und hilft Kunden dabei, ihre Software-Praktiken zu verbessern.

Erhalten Sie die neuesten Nachrichten und Ressourcen zum Testen von Software sofort.