Bewährte Sicherheitsmethoden bei der Spieleentwicklung
In diesem Artikel werden bewährte Methoden für die Spieleentwicklung erläutert.
- Introduction (Einführung)
- Beispiele für unsicheren Code
- Möglichkeiten zur Verbesserung der Sicherheit
- Zusammenfassung
Einführung
Immer mehr Benutzer spielen Online- und Spiele mit benutzerdefinierten Inhalten. Dies in Kombination mit der zunehmenden Sicherheit des Microsoft Windows-Betriebssystems bedeutet, dass Spiele ein wachsendes und verlockenderes Ziel für Angreifer sind, diese auszunutzen. Spielentwickler sollten einen starken Schwerpunkt darauf legen, sicherzustellen, dass die von ihnen veröffentlichten Spiele keine neuen Sicherheitslücken schaffen, die Angreifer ausnutzen können. Spieleentwickler haben eine Verantwortung und ein großes Interesse daran, zu verhindern, dass die Computer ihrer Kunden durch schädliche Netzwerkdaten, Benutzeränderungen oder Manipulationen gehackt werden. Wenn ein Sicherheitsrisiko ausgenutzt wird, kann dies zum Verlust von Kunden und/oder Geld führen. In diesem Artikel werden einige gängige Methoden und Tools beschrieben und erläutert, um die Codesicherheit zu erhöhen, ohne die Entwicklungszeit zu überdimensionieren.
Die drei häufigsten Fehler, die ein Entwicklungsteam beim Veröffentlichen eines Produkts gemacht hat, sind:
- Erfordern von Administratorrechten. Spiele sollten keine Administratorrechte erfordern. Weitere Informationen finden Sie unter Benutzerkontensteuerung für Spieleentwickler.
- Keine Verwendung des automatisierten Schutzes. Entwickler verwenden in der Regel nicht /GS, /SAFESEH oder /NX. Die Verwendung dieser Kompilier-/Linkflags kann viele grundlegende Sicherheitslücken erkennen oder beseitigen, ohne die Workload erheblich zu erhöhen. Diese Flags werden weiter unten in diesem Artikel erläutert.
- Verwenden von unzulässigen APIs. Es gibt viele APIs (strcpy, strncpy usw.), die anfällig für Programmiererfehler sind und problemlos Sicherheitslücken generieren. Entwickler sollten diese APIs durch die sicheren Versionen ersetzen. Visual Studio 2005 enthält ein Tool zum Analysieren von Binärdateien, mit dem Objektdateien automatisch auf Verweise auf unsichere APIs überprüft werden können. Weitere Informationen zu den mit diesem Tool generierten Informationen finden Sie unter Repel Attacks on Your Code with the Visual Studio 2005 Tresor C and C++ Libraries von Martyn Lovell. Außerdem können Sie die Headerdatei banned.h abrufen, mit der Sie gesperrte Funktionen aus dem Code entfernen können.
Jeder der aufgeführten Fehler ist nicht nur üblich, sondern leicht zu korrigieren, ohne dass sich die Entwicklungsworkload, die Codierungsstandards oder die Funktionalität erheblich ändern.
Beispiele für unsicheren Code
Im Folgenden ist ein einfaches Beispiel für alles, was erforderlich ist, um einem Angreifer das Ausführen eines Pufferüberlaufangriffs zu ermöglichen:
void GetPlayerName(char *pDatafromNet)
{
char playername[256];
strncpy(playername, pDatafromNet, strlen(pDatafromNet));
// ...
}
Auf der Oberfläche sieht dieser Code in Ordnung aus– schließlich ruft er eine sichere Funktion auf. Daten aus dem Netzwerk werden in einen Puffer mit 256 Bytes kopiert. Die strncpy-Funktion basiert darauf, ein NULL-Abschlusszeichen in der Quellzeichenfolge zu finden, oder ist durch die angegebene Pufferanzahl beschränkt. Das Problem besteht darin, dass die Puffergröße falsch ist. Wenn Daten aus dem Netzwerk nicht überprüft werden oder die Puffergröße falsch ist (wie in diesem Beispiel), könnte ein Angreifer einfach einen großen Puffer bereitstellen, um Stapeldaten nach dem Ende des Puffers mit daten im Netzwerkpaket zu überschreiben. Dadurch kann der Angreifer beliebigen Code ausführen, indem er den Anweisungszeiger überschreibt und die Rückgabeadresse ändert. Die einfachste Lektion dieses Beispiels besteht darin, Eingaben nie zu vertrauen, bis sie überprüft wurden.
Auch wenn die Daten anfänglich nicht aus dem Netzwerk stammen, besteht weiterhin ein potenzielles Risiko. Die moderne Spieleentwicklung erfordert, dass viele Personen dieselbe Codebasis entwerfen, entwickeln und testen. Es gibt keine Möglichkeit zu wissen, wie die Funktion in Zukunft aufgerufen wird. Fragen Sie sich immer, woher die Daten stammen und was ein Angreifer steuern könnte? Netzwerkbasierte Angriffe sind zwar die gängigsten, aber nicht die einzigen Methoden zum Erstellen von Sicherheitslücken. Könnte ein Angreifer einen Mod erstellen oder eine gespeicherte Datei auf eine Weise bearbeiten, die eine Sicherheitslücke öffnet? Was ist mit vom Benutzer bereitgestellten Bild- und Sounddateien? Schädliche Versionen dieser Dateien können im Internet veröffentlicht werden und zu gefährlichen Sicherheitsrisiken für Ihre Kunden werden.
Als Randnotiz verwenden Sie strsafe.h oder Tresor CRT anstelle von strncpy, um das Beispiel zu korrigieren. Tresor CRT ist eine vollständige Sicherheitsüberholung der C-Runtime und wird im Rahmen Visual Studio 2005 geliefert. Weitere Informationen zu Tresor CRT finden Sie unter Security Enhancements in the CRT (Sicherheitsverbesserungen in der CRT) von Michael Csv.
Möglichkeiten zur Verbesserung der Sicherheit
Es gibt mehrere Möglichkeiten, die Sicherheit im Entwicklungszyklus zu verbessern. Hier sind einige der besten Methoden:
-
Informationen zur Sicherheit
-
Das Buch Writing Secure Code( Schreiben von sicherem Code, zweite Edition) von Michael Flync und David LeBlanc bietet eine ausführliche und klare Erläuterung der Strategien und Methoden zur Verhinderung von Angriffen und zur Entschärfung von Exploits. Beginnend mit Methoden zum Entwerfen von Sicherheit in eine Version von Techniken zum Schützen von Netzwerkanwendungen behandelt das Buch alle Aspekte, die ein Spieleentwickler benötigt, um sich selbst, seine Produkte und seine Kunden vor Angreifern zu schützen. Das Buch kann verwendet werden, um eine Kultur der Sicherheit in einem Entwicklungsstudio zu fördern. Stellen Sie sich Codesicherheit nicht nur als Entwickler- oder Testerproblem vor. Stellen Sie sich Sicherheit als etwas vor, das das gesamte Team – vom Programmmanager über Designer über Entwickler bis hin zu Testern – überlegen sollte, wann es an einem Projekt arbeitet. Je mehr Augen Teil des Überprüfungsprozesses sind, desto größer ist die Wahrscheinlichkeit, dass vor der Veröffentlichung eine Sicherheitslücke abfängt.
Writing Secure Code, Second Edition (Schreiben von sicherem Code, zweite Edition) finden Sie unter Microsoft Learning. Allgemeinere Sicherheitsinformationen finden Sie unter Fending Off Future Attacks by Reducing Attack Surface ( Abwehren zukünftiger Angriffe durch Reduzieren der Angriffsfläche) von Michael Editions.
Michael Fly, David LeBlanc und John Viega haben ein weiteres Buch zu diesem Thema geschrieben, das alle gängigen Betriebssysteme und Programmiersprachen mit dem Titel 19 Deadly Sins of Software Security behandelt.
Sicherheitspräsentationen, die sich auf Spiele konzentrieren, finden Sie auf der Downloadseite microsoft XNA Developer Presentations .
-
Analyse der Bedrohungsmodellierung
-
Eine Analyse der Bedrohungsmodellierung ist eine gute Möglichkeit, die Systemsicherheit zu bewerten, nicht in einer bestimmten Sprache oder mithilfe eines Tools, sondern in einer umfassenden End-to-End-Methode, die in einigen Besprechungen durchgeführt werden kann. Bei ordnungsgemäßer Implementierung kann ein Threadmodell alle Stärken und Schwachstellen eines Systems identifizieren, ohne dem Projekt eine erhebliche Arbeitsauslastung oder Besprechungszeit hinzuzufügen. Die Methode der Bedrohungsmodellierung hebt auch die Idee hervor, die Systemsicherheit vor und während des Entwicklungsprozesses zu bewerten, um sicherzustellen, dass eine umfassende Bewertung durchgeführt wird, während der Schwerpunkt auf den riskantesten Features liegt. Sie kann sich als Profiler für die Sicherheit wähnen. Da sie nicht auf einer bestimmten Sprache basiert oder sich auf ein bestimmtes Tool verlässt, kann die Bedrohungsmodellierung in jedem Entwicklungsstudio verwendet werden, das an einem beliebigen Projekt in einem beliebigen Genre arbeitet. Die Bedrohungsmodellierung ist auch eine hervorragende Methode, um die Idee zu fördern, dass Sicherheit in der Verantwortung aller liegt und nicht das Problem einer anderen Person.
Achten Sie bei der Bedrohungsmodellierung besonders auf:
- UDP-Datenquellen
- Datenquellen, die keine Authentifizierung erfordern
- Datenquellen, die häufig und normalerweise im Rahmen der umfangreichen Informationssammlung untersucht werden
- Möglichkeit eines Clients, Daten direkt an andere Clients zu senden
Dies sind die Bereiche, die ein gutes Potenzial für Sicherheitsrisiken haben.
Weitere Informationen zur Bedrohungsmodellierung finden Sie unter Bedrohungsmodellierung im MSDN Security Development Center und im Buch Threat Modeling von Frank Swiderski und Window Snyder.
-
Verhinderung der Datenausführung (/NX)
-
Ein aktuelles Tool zum Mindern mehrerer Exploits ist die Verhinderung der Datenausführung (Data Execution Prevention, DEP). Wenn Sie den Schalter /NX in den Buildbefehl einschließen, markiert Visual Studio Speicherseiten mit Flags, die kennzeichnen, ob der Code ausgeführt werden darf oder nicht. Jedes Programm, das versucht, auf einer Speicherseite auszuführen, die nicht mit der EXECUTE-Berechtigung gekennzeichnet ist, verursacht eine forcible Beendigung des Programms. Die Verhinderung wird auf Prozessorebene erzwungen und wirkt sich auf Entwickler aus, die selbständernden Code oder native JIT-Sprachcompiler verwenden. Derzeit unterstützen nur die AMD-Prozessoren Stellig64 und Opteron sowie die Intel-Prozessoren Itanium und neueste Pentium 4 die Ausführungsverhinderung. Es wird jedoch erwartet, dass alle 32-Bit- und 64-Bit-Prozessoren die Ausführungsverhinderung in Zukunft unterstützen. (Ein kopierschutzbasiertes Schema, das von einem Entwickler verwendet wird, kann von der Ausführungsverhinderung betroffen sein, aber Microsoft hat mit Kopierschutzanbietern zusammengearbeitet, um die Auswirkungen zu minimieren.) Es ist eine bewährte Methode, DEP zu verwenden.
Weitere Informationen zu DEP finden Sie unter Verhinderung der Datenausführung.
-
Puffersicherheitsprüfung (/GS) und Image verfügt über Tresor Ausnahmehandler (/SAFESEH)
-
Die Puffersicherheitsprüfung, die durch das Compilerflag /GS angegeben wird, und Image verfügt über Tresor Ausnahmehandler, die durch das Linkerflag /SAFESEH (erstmals in Visual Studio .NET 2003 implementiert) angegeben werden, kann den Entwickler bei der Sicherung von Code ein wenig vereinfachen.
Die Verwendung des /GS-Flags bewirkt, dass der Compiler eine Überprüfung für einige Formen stapelbasierter Pufferüberläufe erstellt, die zum Überschreiben der Rückgabeadresse einer Funktion ausgenutzt werden könnten. Die Verwendung von /GS erkennt nicht jeden potenziellen Pufferüberlauf und sollte nicht als "catch-all", sondern als gute Defense-in-Depth-Technologie betrachtet werden.
Die Verwendung des /SAFESEH-Flags weist den Linker an, nur eine ausführbare Datei oder DLL zu generieren, wenn er auch eine Tabelle der sicheren Ausnahmehandler der ausführbaren Datei oder DLL generieren kann. Tresor Die strukturierte Ausnahmebehandlung (SafeSEH) beseitigt die Ausnahmebehandlung als Ziel von Pufferüberlaufangriffen, indem sichergestellt wird, dass der Ausnahmehandler vor dem Verteilen einer Ausnahme in der Funktionstabelle in der Imagedatei registriert wird. Diese Schutzvorteile werden mit Windows XP SP2, Windows Server 2003, Windows Vista und Windows 7 aktiviert. Damit /SAFESEH ordnungsgemäß funktioniert, muss es auch in einer Alles-oder-Nichts-Methode verwendet werden. Alle Bibliotheken, die Code enthalten, der an eine ausführbare Datei oder DLL gebunden ist, müssen mit /SAFESEH kompiliert werden, andernfalls wird die Tabelle nicht generiert.
Weitere Informationen zur Puffersicherheitsprüfung (/GS) und image has Tresor Exception Handlers (/SAFESEH) finden Sie in MSDN.
Weitere Informationen finden Sie auch in den Informationen zum /SDL-Flag von Microsoft Visual Studio 2012 und zu den Verbesserungen von Visual Studio 2012 am /GS-Flag.
-
PREfast
-
PREfast ist ein kostenloses Tool von Microsoft, das Ausführungspfade in kompilierten C- oder C++-Dateien analysiert, um Laufzeitfehler zu finden. PREfast arbeitet durch alle Ausführungspfade in allen Funktionen und bewertet jeden Pfad auf Probleme. Ursprünglich zum Entwickeln von Treibern und anderem Kernelcode verwendet, kann dieses Tool Spielentwicklern dabei helfen, Zeit zu sparen, indem einige Fehler beseitigt werden, die schwer zu finden sind oder vom Compiler ignoriert werden. Die Verwendung von PREfast ist eine hervorragende Möglichkeit, die Workload zu reduzieren und die Bemühungen des Entwicklungsteams und des Testteams zu konzentrieren. PREfast ist in Visual Studio Team Suite verfügbar und Visual Studio Team Edition for Software Developers als Code Analysis, aktiviert durch den Compilerschalter /analyze. (Diese Option ist auch in der kostenlosen Version des Compilers verfügbar, die im Windows Software Development Kit enthalten ist.)
Hinweis
Visual Studio 2012 unterstützt /analyze in allen Editionen. Weitere Informationen zur Verfügbarkeit der Codeanalyse in allen Editionen von Visual Studio finden Sie unter Neues in Code Analysis.
Durch die Verwendung der Headeranmerkung (insbesondere für Pufferzeigerargumente) kann PREfast zusätzliche Probleme verfügbar machen, z. B. Fehler beim Überschreiben des Arbeitsspeichers, eine häufige Ursache von Abstürzen und potenzielle Sicherheitsrisiken. Dies erfolgt mithilfe der StandardAnmerkungssprache (Standard Annotation Language, SAL), einer Form der Aufmarkierung für C/C++-Funktionsprototypen, die zusätzliche Informationen über die erwartete Zeigerargumentsemantik und Korrelation mit Längenparametern, deklarierten Puffergrößen usw. bereitstellen. Alle Header für Windows-Betriebssysteme werden mit Anmerkungen kommentiert, und das Hinzufügen von SAL-Mark up in öffentlichen API-Headern in Ihren eigenen Bibliotheken ermöglicht PREfast, detailliertere und aggressivere Überprüfungen in Ihrem Clientcode für solche APIs durchzuführen. Eine Einführung in SAL und Links zu anderen Informationen finden Sie im Blogeintrag von Michael Blogs, " A Brief Introduction to the Standard Annotation Language (SAL) ." (Eine kurze Einführung in die Standardanmerkungssprache(SAL)).
-
Windows Application Verifier
-
Der Windows Application Verifier oder AppVerifier kann Testern helfen, indem mehrere Funktionen in einem Tool zur Verfügung stehen. AppVerifier ist ein Tool, das entwickelt wurde, um häufige Programmierfehler besser testbar zu machen. AppVerifier kann Parameter überprüfen, die an API-Aufrufe übergeben werden, fehlerhafte Eingaben injizieren, um die Fehlerbehandlung zu überprüfen, und Änderungen an der Registrierung und dem Dateisystem protokollieren. AppVerifier kann auch Pufferüberläufe im Heap erkennen, überprüfen, ob eine Access Control-Liste (ACL) ordnungsgemäß definiert wurde, und die sichere Verwendung von Socket-APIs erzwingen. AppVerifier ist zwar nicht vollständig, kann aber ein Tool in der Toolbox des Testers sein, um ein Entwicklungsstudio bei der Veröffentlichung eines Qualitätsprodukts zu unterstützen.
Weitere Informationen zu Application Verifier finden Sie unter Application Verifier und Verwenden von Application Verifier in Ihrem Softwareentwicklungslebenszyklus auf MSDN.
-
Fuzz-Tests
-
Fuzztests sind eine halbautomatisierte Testmethode, die die aktuellen Testmethoden verbessern kann. Die zentrale Idee hinter Fuzz-Tests besteht im Durchführen einer vollständigen Bewertung aller Eingaben durch Eingabe zufälliger Daten, um zu sehen, welche Unterbrechungen es gibt. dies schließt alle Netzwerkdaten, Mods und gespeicherten Spiele usw. ein. Fuzz-Tests sind recht einfach. Ändern Sie einfach wohlgeformte Dateien oder Netzwerkdaten, indem Sie zufällige Bytes einfügen, angrenzende Bytes umkehren oder numerische Werte negieren. 0xff, 0xffff, 0xffffffff, 0x00, 0x0000, 0x00000000 und 0x80000000 sind Werte, die sich gut zum Aufstellen von Sicherheitslücken während fuzz-Tests verwenden lassen. Sie können die resultierenden Interaktionskombinationen mithilfe von AppVerifier beobachten. Fuzzing ist zwar nicht vollständig, aber es ist einfach zu implementieren und zu automatisieren, und es kann die leichteren und unvorhersehbareren Fehler abfangen.
Weitere Informationen zu Fuzz-Tests finden Sie in der Gamefest 2007-Präsentation Praktische Schritte in Game Security.
-
Authenticode-Signierung
-
Authenticode ist eine Methode, mit der sichergestellt wird, dass ausführbare Dateien, DLL-Dateien und Windows-Installationspakete (.msi-Dateien), die der Benutzer erhält, nicht von dem geändert werden, was ein Entwickler veröffentlicht hat. Mithilfe einer Kombination aus kryptografischen Prinzipien, vertrauenswürdigen Entitäten und Branchenstandards überprüft Authenticode die Integrität ausführbarer Inhalte. Microsoft stellt die kryptografische API CryptoAPI bereit, die verwendet werden kann, um manipulationsbasierten Code automatisch zu erkennen. Wenn nach einer Veröffentlichung ein Sicherheitsverlust auftritt, kann ein Zertifikat widerrufen werden, und der mit diesem Zertifikat signierte Code wird nicht mehr authentifiziert. Durch das Widerrufen eines Zertifikats wird die Überprüfung aller Titel widerrufen, die mit diesem Zertifikat signiert wurden. Windows wurde für die Arbeit mit Authenticode-Signierung entwickelt und benachrichtigt einen Benutzer in bestimmten Situationen vor nicht signierten Code, der den PC eines Benutzers angriffen kann.
Authenticode sollte nicht als Methode zur Beseitigung von Sicherheitsproblemen betrachtet werden, sondern als Methode zur Erkennung von Manipulationen, nachdem eine ausführbare Datei freigegeben wurde. Eine ausführbare Datei oder DLL, die ein Sicherheitsproblem enthält, das ausnutzbar ist, kann mit Authenticode signiert und überprüft werden, führt jedoch weiterhin zu einem Sicherheitsproblem für das neue System. Erst nachdem ein Produkt oder Update als sicher überprüft wurde, sollte der Code signiert werden, um benutzern zu gewährleisten, dass sie über ein Release verfügen, das nicht manipuliert wurde.
Auch wenn ein Entwickler der Ansicht ist, dass keine Gefahr besteht, dass seine Releases geändert werden, verlassen sich andere Technologien und Dienste auf Authenticode. Die Codesignatur ist einfach zu integrieren und zu automatisieren. Es gibt keinen Grund für Entwickler, ihre Releases nicht signiert zu haben.
Weitere Informationen zur Authenticode-Signierung finden Sie unter Authenticode Signing for Game Developers (Authenticode-Signierung für Spieleentwickler).
-
Minimieren von Berechtigungen
-
Im Allgemeinen sollten Prozesse mit dem mindesten Satz von Berechtigungen ausgeführt werden, die für den Betrieb erforderlich sind. In Windows Vista und Windows 7 wird dies mithilfe der Benutzerkontensteuerung erreicht,sodass das Spiel als Standardbenutzer und nicht als Administrator ausgeführt werden kann. Bei Windows XP werden Spiele in der Regel immer als Administrator ausgeführt. Selbst unter Windows Vista und Windows 7 ist es manchmal erforderlich, für einige bestimmte Vorgänge die Rechte des vollständigen Administrators zu erhöhen.
In Fällen, in denen der Prozess mit vollständigen Administratorrechten ausgeführt wird, sind in der Regel nur wenige Rechte erforderlich, die über die eines Standardbenutzers hinausgehen. Der Administratorzugriff umfasst viele Rechte, die für legitimen Code nicht erforderlich sind, aber von einem Angreifer durch einige Schwachstellen im Prozess verwendet werden können. Beispiele für solche Rechte sind SE _ TAKE _ OWNERSHIP, SE _ DEBUG, SE _ CREATE _ TOKEN, SE _ ASSIGNPRIMARYTOKEN, SE _ TCB, SE _ SECURITY, SE LOAD _ _ DRIVER, SE _ SYSTEMTIME, SE _ BACKUP, SE RESTORE, SE SHUTDOWN und SE AUDIT _ _ _ (siehe Prisedge Constants).
Auch wenn ein Prozess nach dem Start nicht mehr Rechte erhalten kann, kann er problemlos Rechte aufknen. Beim Start kann der Prozess win32-APIs sofort verwenden, um nicht benötigte Rechte zu entfernen.
-
Verwenden Windows-Sicherheit Features
-
Windows Vista und Windows 7 enthalten eine Reihe neuer Features, die die Codesicherheit verbessern. Die Benutzerkontensteuerung ist sicherlich der wichtigste Punkt, der verstanden und berücksichtigt werden muss, aber es gibt auch andere Features. Zusätzlich zu den Windows XP SP2-Technologien wie Windows-Firewall, Datenausführungsschutz, Puffersicherheitsüberprüfung und Tresor-Ausnahmehandlern, die auch unter Windows Vista und Windows 7 verfügbar sind, sind drei neuere Sicherheitsfeatures zu berücksichtigen:
- Das optionale Feature Address Space Layout Randomization (Zufällige Anordnung des Adressraumlayouts). Dies wird durch Verknüpfen mit der Option /DYNAMICBASE auf Visual Studio 2005 Service Pack 1 oder Visual Studio 2008 aktiviert. Dies führt dazu, dass das System die Positionen vieler wichtiger System-DLLs in Ihrem Prozessbereich zufällig verteilt, wodurch es viel schwieriger wird, auswertbare Angriffsprogramme zu schreiben, die weit über das Internet verteilt werden. Dieses Linkerflag wird von xp Windows älteren Versionen von Windows.
- Eine Heapbeschädigung kann zu einer ganzen Klasse von Sicherheitsrisiken führen, sodass das Speichersystem von Windows Vista und Windows 7 jetzt einen Modus unterstützt, der den Prozess beendet, wenn eine Heapbeschädigung erkannt wird. Wenn Sie HeapSetInformation mit HeapEnableTermianteOnCorruption aufrufen, wird dieses Verhalten verwendet. Dieser Aufruf schlägt auf Windows XP und älteren Version von Windows.
- Beim Schreiben von Diensten können sie mithilfe eines neuen Features konfiguriert werden, um anzugeben, welche Berechtigungen tatsächlich erforderlich sind, und um den Ressourcenzugriff auf eine bestimmte SID zu beschränken. Dies erfolgt über ChangeSeviceConfig2unter Verwendung von SERVICE _ CONFIG _ REQUIRED _ PRIVILEGES _ INFO und SERVICE _ CONFIG SERVICE SID _ _ _ INFO.
Zusammenfassung
Die Entwicklung eines Spiels für den aktuellen und zukünftigen Marketplace ist kostspielig und zeitaufwändig. Die Freigabe eines Spiels mit Sicherheitsproblemen kostet letztendlich mehr Geld und Zeit, um dies ordnungsgemäß zu beheben. Daher liegt es im Interesse aller Spieleentwickler, Tools und Techniken zu integrieren, um Sicherheitsrisiken vor der Veröffentlichung zu minimieren.
Die Informationen in diesem Artikel sind nur eine Einführung in die Arbeit eines Entwicklungsstudios, um sich selbst und seine Kunden zu unterstützen. Weitere Informationen zu allgemeinen Sicherheitsmethoden und Sicherheitsinformationen finden Sie im Microsoft Security Developer Center.