Blind Command — Technical Due Diligence
Der folgende Artikel beschreibt in Form eines technischen Due Diligence die Technologien von dem Minimal Viable Prototypen “Blind Command” mit dem Fokus IT Security und Privatsphäre. Dazu wird zunächst das Produkt und der Prototyp eingeleitet und die Software-Architektur beschrieben, um erläutern zu können, wo ein Sicherheitsfeature im Produkt notwendig ist. Cyber-Attacken sind weit verbreitet und richten hohen Schaden für ein Unternehmen an. Daher gibt dieser Artikel ebenfalls Lösungsansätze, die umgesetzt werden können, wodurch der sinnvollste im Nachhinein im Detail erklärt wird. Dieser Artikel durchleuchtet die Herangehensweise zur Vermeidung und Prävention eines SQL-Injection Server-Angriffs.
Videospiele bieten ein Zielpublikum in allen Altersgruppen, Geschlechtern und sozialen Schichten. Der deutsche Markt für Computer- und Videospiele erreichte 2021 einen Umsatz von 163 Millionen Euro [1]. Weltweit erreichte die Gaming Branche sogar einen Wert von über 173 Milliarden US-Dollar im Jahre 2021. Prognosen gehen davon aus, dass im Jahre 2027 mehr als 314 Milliarden US-Dollar in diesem Segment erreicht werden können. [2] Trotz dieser enormen Gewinnsteigerung bieten die meisten Computerspiele große Einschränkungen bei Minderheiten. So haben seheingeschränkte und blinde Menschen funktionale Einschränkungen während des Spielens eines Videospiels, die den Spielspaß erheblich mindern oder die intendierte Nutzung komplett untersagen. Deswegen haben wir mit Blind Command ein sogenanntes Audio-Game entwickelt, womit Menschen mit und ohne Seheinschränkungen ein Computerspiel komplett mit ihren auditiven Sinnen spielen können. Ein Bildschirm und visuelle Fähigkeiten werden daher nicht benötigt. Gleichzeitig bekommen Hardcore- und Casualgamer mit einem sehr selten genutzten Computerspiel-Genre eine neue Spielererfahrung. Blind Command verbindet die beliebten Videospiel-Genres Action-Adventure und Narrative Games auf ein neuartiges und akustisches Konzept: über Audio Spatialisation und Pitch Modulation kann sich der Spieler auf einem virtuellen Raumschiff orientieren. Audio Spatialisation dient hierbei zur Lokalisierung von Audio-Signalen zu einer dreidimensionalen, realistischen Stereo-Verteilung. Pitch Modulation dient zur Unterscheidung von Sounds über die Tonhöhe bzw. Frequenz eines Signals. Somit ist eine neuartige Charakterbewegung in Computerspielen möglich. In der Game Jam „Games for Blind Gamers Jam 2021“ erreichte Blind Command in der Kategorie „Good use of audio / blind friendly“ den vierten Platz. Während der Konzeption und Validierung der Spielidee und der ersten Playtests bekam das Spiel u.a. die Unterstützung vom Deutschen Blinden- und Sehbehindertenverein e.V. sowie vom Royal National Institute of Blind People aus dem Vereinigten Königreich.
Ein Playtester hat das bisherige Spielkonzept folgendermaßen beschrieben:
“Blind Command is a very entertaining, well-produced audio game, which relies highly on the details of your hearing. This includes pitch details, as well as the sense of direction. I say it is useful when testing someone’s hearing.”
Tatsächlich gibt es einen wissenschaftlich geprüften Zusammenhang zwischen einer Verbesserung des Hörvermögens einer Person und Audio Games, wenn sie gezielt mit Audio Games trainiert hat. [3]
Zum derzeitigen Standpunkt ist „Blind Command“ ein Singleplayer-Spiel mit keinerlei Online-Anbindung. Der stetig wachsende Umsatz von InApp-Käufen bei Computerspielen sowie der Wunsch unserer Early Adopters nach dem Vergleichen der Spieler-Scores sowie die Möglichkeit ihre Spiel-Umgebung in Form von kaufbaren Game-Sounds zu personalisieren, macht eine Online-Anbindung für Blind Command unerlässlich.
Aufgrund von vielen Cyberangriffen, wie z.B. SQL-Injections, DDoS-Angriffen, oder Ransom-Ware, an Videospielfirmen, die jene erhebliche Kosten bereiten, ist es notwendig, eine sorgfältige Planung und Prävention im Security und Privacy Bereich dieses Unternehmens durchzuführen, Lösungsansätze von Sicherheits-Problemen zu geben, um mögliche Cyberangriffe gänzlich zu verhindern oder abzumildern.
Unser Spiel soll Online-Features besitzen. Dazu ist es notwendig, dass es einen Server gibt, der in einer Datenbank Userdaten persistent speichert. Als verwendete Datenbank haben wir uns wegen der hohen Verbreitung und der leichten Integration mit der Unity Game Engine für MySQL entschieden. Die Unity Game Engine ist eine weit verbreitete, moderne und leistungsstarke Game Engine, die die Portierung des Spiels auf mobile, PC- und Konsolenplattformen leicht ermöglich. Außerdem ist die Integration der Musik-Bibliothek FMOD in Unity realisierbar, womit ein adaptives Audio-System im Spiel erstellt werden kann, welches die Immersion bei der Spielererfahrung stark unterstützt. Unsere Early Adopters gaben zur ersten Validierung der Spielidee an, dass sie ein Audio-Game viel immersiver empfanden als ein herkömmliches Videospiel, da sie sich komplett auf das hörbare Geschehen konzentrieren konnten. Externe Assets und Bibliotheken von Drittanbietern werden von Unity Technologies auf Viren und anderer Schadsoftware sorgfältig geprüft, sodass Fremd-Assets problemlos aus dem Unity Asset Store heruntergeladen und verwendet werden können.
Die Datenbank soll in einer UserScore-Tabelle den Nutzernamen und der in einer Spielrunde des Arcade-Modes erreichte Score speichern. Der Nutzername ist hierbei UNIQUE. Ein Spieler kann als Client diese Tabellendaten vom Server im Layout eines Leaderboards anfordern.
Weiterhin soll es eine Tabelle UserPurchases geben, die den Usernamen mit seinen getätigten InApp-Käufen bereitstellt. Dazu muss der Client sich mit einem bei der Registrierung eines Nutzeraccounts selbst gewählten Passwortes authentifizieren. Das Passwort soll verschlüsselt in der Tabelle UserPurchases gespeichert werden. Der Spieler kann die gekauften Objekte, wie z.B. die Ambience Sounds, für den Arcade und Story Mode im Menü zuvor auswählen und somit personalisieren. Er muss weiterhin seine Zahlungsoption und die dazugehörigen Daten angeben, um den Kauf abzuschließen. Dazu fordert er als Client seine gekauften Daten vom Server an. Weiterhin kann der Spieler als Client zum Kauf stehende Sound-Objekte vom Server anfordern. Dazu benötigt man weiterhin eine Tabelle, die alle kaufbaren Sound-Objekte mit Namen, der kaufbaren Soundfile und den Preis bereitstellt.
Eine Spiele-Anwendung, die mit einer Anbindung zu einer Datenbank eine serverseitige Kommunikation voraussetzt, besitzt in der Schnittstelle der Datenbank viele Sicherheits- und Privatsphäre-Risiken. Angreifer können sich unerlaubt Zugang zur Datenbank verschaffen, Daten auslesen, verkaufen, bearbeiten oder gar löschen. Angreifer können die Server-Betreiber ebenfalls erpressen. Das Injizieren von schädlichen Daten (meist ausführbarer SQL-Code) in eine Datenbank, kann für Unternehmen und ihre Nutzerinnen und Nutzer zu immensen Problemen des finanziellen Schadens und/oder des Vertrauens in das Unternehmen führen. Sogenannte SQL-Injection Attacken verzeichnen über 65% aller webbasierten Attacken von 2017 bis 2019. [4] Das Risiko, dass der Server bei keinen besonderen Vorsichtsmaßnahmen eine SQL-Injection erleiden kann, ist daher sehr hoch.
„In February 2021, cybercriminals launched a ransomware attack against the Polish video game company CD Projekt. […] After CD Projekt refused to pay the ransom, the hackers auctioned the source code and other confidential data with a reported starting price of $1 million and a buy-it-now price of $7 million.“ — Lance Whitney, 2021 [5]
Aber auch die Spielerinnen und Spieler, die Kundinnen und Kunden des Unternehmens, können eine erhebliche Frustration verspüren, wenn ihr Spielfortschritt und/oder High Score aus der Datenbank gelöscht werden kann. Auch das Ausspähen von Passwörtern von Nutzerinnen und Nutzern ist für sie sehr gefährlich, sofern sie für mehrere Accounts, z.B. PayPal oder andere Bezahloptionen, dasselbe Passwort verwenden. Aus diesem Grund gibt dieser Artikel Problemlösungen bei einem SQL-Injection-Angriff auf einer Datenbank eines Online-Spiels.
Im Folgenden soll ein technischer Due Diligence durchgeführt werden, um die Technologie und Architektur des Produkts analysieren und evaluieren zu können.
Damit ein SQL-Injektion-Datenbankangriff verhindert werden kann, ist es einerseits ratsam, automatische Eingaben der Anwendung zu überwachen, insbesondere zu prüfen und zu filtern. Dazu können ebenfalls “Prepared Statements” eingesetzt werden.
Ferner ist es zu empfehlen, dass der Blind Command-Server einen umfassenden Schutz bekommt. Es sollten nur für die Datenbank notwendige externe Dienste installiert und aktiviert werden. Benutzerkonten, die nicht genutzt oder benötigt werden, sollten in regelmäßigen Abständen gelöscht werden. Außerdem sollte man darauf achten, dass relevante System- und Softwareupdates auf die neuesten Versionen aktualisiert werden. Je höher die Softwareaktualisierung ist, desto größer sind meist die Anforderungen von installierten Erkennungssystemen von Server-Angriffen, wie z.B. Intrusion-Detection-Systemen (IDS) oder Intrusion-Prevention-Systemen (IPS). Über ein Application Layer Gateway kann zusätzlich der Datenverkehr zwischen Spieleanwendung und Datenbankanwendung auf Applikationsebene überwacht und geschützt werden, welches die höchste Ebene im OSI-Modell zur Gliederung einer Netzwerkkommunikation ist.
Weiterhin ist es zu empfehlen, dass sensible Daten nur verschlüsselt über sichere Hash-Funktionen gespeichert werden. Das wären im Falle von Blind Command Passwörter und Bezahlungsoptionen. Hier könnte zum Beispiel ein Prüfalgorithmus des “Secure Hash Algorithm” (SHA) in einer hohen Bitlänge verwendet werden (z.B. SHA-256 oder SHA-512), um die Wahrscheinlichkeit zu verringern, dass sensible Daten ausgespäht werden.
Eingabefelder sollten in der Spiele-Anwendung begrenzt werden, da Angreifer sich so Zugang zur Datenbank verschaffen könnten. Wenn Eingabefelder erforderlich sind (z.B. beim Login, der Eingabe von Username und Passwort), sollten Sonderzeichen (einfache, doppelte Hochkommata, Backslash, Steuerzeichen r, n, x00, x1a) nicht zulässig sein und maskiert werden. So kann verhindert werden, dass „Fremdcode“ in die Datenbank gespeichert wird. Dazu müssen entsprechende Funktionen im Programmcode verwendet werden, oder eine vergleichbare, eigene Coderoutine implementiert werden. Dies hängt von der zu verwendenden Backend-Technologie ab.
Zur Prävention und Verhinderung von Server-Angriffen seitens SQL-Injektions sind die oben genannten Lösungsansätze alle zu empfehlen. Trotzdem soll hier versucht werden, eine Rangfolge der Wichtigkeit dieser Lösungen aufzulisten.
Die stetig aktualisierende Software der Server-Dienste ist ein Lösungsansatz, bei den ein Unternehmen wenig Einfluss hat. Des Weiteren überwachen diese Dienste den Datenverkehr. Server-Angriffe können so oft erkannt werden, allerdings werden sie meist nur schwer verhindert. Das Application Layer Gateway ist ein Software-Bestandteil der Firewall und empfängt Daten vom Client, die sie dann zum Ziel-Server weitersenden kann. Dazwischen werden die empfangenen Daten auf Verletzungen der übertragenen Protokolle (z.B. http(s)) lediglich analysiert oder blockiert.
Das Verschlüsseln von gespeicherten, sensiblen Daten schützt vor dem Missbrauch von geklauten Daten. Dabei empfiehlt es sich eine Hash-Funktion mit großer Hash-Länge und hoher Iteration bei der Verschlüsselung zu verwenden. Den Zugriff bzw. die Manipulation der Datenbank kann so allerdings von außen nicht verhindert werden. Sensible Daten sind immerhin in den meisten Fällen für Angreifer kodiert. Aus diesem Grund ist es ratsam, eine Möglichkeit, schädliche Datenbank-Anweisungen in die Datenbank zu schreiben, zu vermeiden.
Der wichtigste Schritt, einen Angriff durch SQL-Injection zu vermeiden, ist also keinen Weg für Anwender oder Angreifer zu ermöglichen, SQL-Anweisungen aus der Spiel-Anwendung einzuschleusen, die dann als ausgeführten SQL-Code verkettet wird. Auch bei diesem Lösungsansatz gibt es verschiedene Wege, die hier im Detail aufgezeigt und gewertet werden sollen.
Bei einem solchen Server-Angriff wird der Anwender eine Eingabemöglichkeit gegeben, beispielsweise die seines Benutzernamens. In der Anwendung könnte der ausgeführte SQL-Code folgendermaßen aussehen. Das folgende Code-Beispiel zeigt eine Implementierung in der Programmiersprache C#:
UserName = Request.form (“BlindCommandUser”);var sql = “select * from UsersScore where Username = ‘“ + UserName + “‘“;
Bei einem Angriff kann der Anwender allerdings neben seinem normalen Nutzernamen auch folgendes eingeben:
BlindCommandUser'; drop table UserScore--Dabei wird diese Eingabe in den SQL-Befehl wie oben übernommen und, wegen korrekter Syntax, ausgeführt:
var sql = "select * from UsersScore where Username = '" + "BlindCommandUser'; drop table UserScore--" + “‘“;Nach dem Semikolon wird der neue Befehl DROP TABLE ausgeführt, was zur Löschung der Tabelle UserScore mit allen gespeicherten Spieler-Scores führt. Die doppelten Bindestriche — — sorgen dafür, dass das hintere Hochkommata ‘ als Kommentar gewertet werden soll.
Deswegen ist es notwendig, Benutzereingaben in Datentyp, Länge, Format und Wertebereich zu testen. Es sollten folgende Sonderzeichen in Benutzereingaben abgefangen und ersetzt werden:
Mit einer einfachen Methode kann eine zu überprüfende Eingabe entsprechend nach unzulässigen Sonderzeichen gefiltert werden:
private string SafeSqlLiteral(string inputSQL){ string[] codes = {"'", ";","--", "/", "_xp"}; for(int i=0; i<codes.Length; i++) { inputSQL = inputSQL.Replace(codes[i], "''"); } return inputSQL;}
Der Nachteil dieser Methode ist, dass die geprüften SQL-Eingaben sehr lang werden können, sodass eine Datenbank diese Ausführung nicht mehr korrekt speichern kann. Die Prüfung der Eingaben nach Datentyplänge kann so nicht sichergestellt werden. Eine bessere Methode, jegliche Sonderzeichen in alphanumerische Textfelder unzulässig zu machen, ist es die Eigenschaft „Content Type“ des Textfeld-Objekts im Unity Inspector von „Standard“ zu „Alphanumeric“ zu wechseln.
Diese Methode kann verwendet werden, wenn die Unity Engine zur Entwicklung genutzt wird.
Zusätzlich sollten allerdings auch die eingegeben Daten nochmals auf Sonderzeichen und ASCII-Code im Backend-Code geprüft werden. Es empfiehlt sich die Serverprogrammierung für Blind Command in PHP zu implementieren, da PHP in Kombination mit MySQL vielerlei Funktionen enthält, die dieses Vorgehen übernimmt. Eine Integration zwischen Unity und PHP muss dafür vorgenommen werden, ist aber möglich.
Mit der PHP-internen Funktion mysqli_real_escape_string() wird ein legaler SQL Ausdruck erstellt und Sonderzeichen wie das einfache und doppelte Hochkommata werden ersetzt:
$conn = mysqli_connect(‚localhost‘,‘root‘, ‚root‘, ‚unityaccess‘);$userName = mysqli_real_escape_string($conn, $_POST[‚USERNAME‘]);
Weiterhin ist es sinnvoll, den geprüften String auf alphanummerische ASCII-Zeichen zu filtern. Mit der php-internen Funktion filter_var() und den dazugehörigen Flags ist dies möglich:
$userNameFiltered = filter_var($userName, FILTER_SANITIZE_STRING, FILTER_FLAG_STRIP_LOW, FILTER_FLAG_STRIP_HIGH);Dabei entfernt das Flag FILTER_SANITIZE_STRING HTML-Tags und HTML kodierte Hochkommata, die Flags FILTER_FLAG_STRIP_LOW und FILTER_FLAG_STRIP_HIGH entfernen die Kodierung von ASCII-Zeichen, die nicht alphanummerisch sind. Eine komplette URL-Kodierung würde man mit dem Filter FILTER_SANITIZE_ENCODED erreichen.
Wenn $userName mit $userNameFiltered nun auf Gleichheit geprüft werden, und unterschiedlich sind, weiß man, dass eine ungültige Eingabe gegeben wurde, die man dem Nutzer mitteilen kann:
if(strcmp($userName, $userNameFiltered) !== 0) {echo „Invalid input! Please try again.“;}
Somit würde die Fehlermeldung greifen und eine SQL-Injection-Attacke verhindert werden.
Das durchgeführte Technical Due Dilligence zeigt, dass ein Server Angriff durch SQL-Injektions ernstzunehmen ist, da sie häufig auftreten und hohe Schäden verursachen. Gleichzeitig gibt es aber viele Möglichkeiten, präventive Maßnahmen zu ergreifen, die diese Art der Angriffe verhindern oder abmildern. Die Systemarchitektur von Blind Command kann diesbezüglich, sofern ein Online Feature in Form von Online-Ranglisten implementiert worden ist, mit geringem Mehraufwand integriert werden. Die Filterung von Nutzereingaben wird als effizienter Lösungsweg angesehen. Die Entwicklung mit der Unity Engine ist eine vielgenutzte und professionelle Spiele Engine, die laufend Sicherheits- und Programmupdates erhält.
Audio-Games sind zurzeit von Konkurrenz-Unternehmen ein wenig genutztes Genre, welches nichtsdestotrotz viele Chancen bietet, viele Casual- und Hardcore-Gamern mit Neugierde und Interesse zu erreichen. Blind Command verbindet dieses neuartige Konzept mit beliebten Genres von Videospielen. Zusätzlich legt dieses Spiel hohen Wert auf Accessibillity für seheingeschränkten Menschen, was während der Konzeption dieses Spiels gute Unterstützung von tragenden Blinden- und Sehbehindertenvereine europaweit geführt hat. Security und Privacy Features zur Behebung von SQL-Injections in der Datenbank kann dieses Spiel mit einer geringen zusätzlichen Implementierung erfüllen.
Quellen:
[1] https://www.game.de/marktdaten/infografik-deutscher-games-markt-2021/ Abgerufen am 26.01.2022
[2] https://www.mordorintelligence.com/industry-reports/global-gaming-market
[3] Navigational audio games: an effective approach toward improving spatial contextual learning for blind people. Oana Balan, Alin Moldoveanu und Florica Moldoveanu. 2014. https://doi.org/10.1515/ijdhd-2014-0018
[4] https://techmonitor.ai/techonology/cybersecurity/sql-injection-attacks
[5] Lance Whitney. 2021. Abgerufen am 21.01.2022. https://www.techrepublic.com/article/why-hackers-are-increasingly-targeting-video-game-companies/
[6] https://www.ionos.de/digitalguide/server/sicherheit/sql-injection-grundlagen-und-schutzmassnahmen/
Bildquellen:
https://unsplash.com/photos/fPkvU7RDmCo , 28.01.2022
