Inventar

tomy86

Aber zusammenfassend kann man sagen, das nur in Verbindung mit einem Server, der alles interne regelt also Besitz, Schadensberechnungen usw und der Client überwiegend Ausgabe Funktion hat die bestmögliche Sicherheit zu gewährleisten ist?
Also vergleichsweise wie HTML/JavaScript und PHP vom Prinzip her?

tomy86

hustbaer schrieb:

@tomy86
Wieso sollte ein Webserver oder PHP nur auf nem Server laufen?
Du kannst Apache, IIS oder welchen Webserver du auch immer verwenden willst auch einfach lokal auf deinem PC installieren.
Sind schliesslich auch ganz normale Programme.

(OK, IIS ist ne Windowskomponente, und MS hat die IIS Versionen die auf Desktop-Windowsen laufen etwas kastriert - z.B. dass man nur eine einzige Webseite laufen lassen kann. Aber grundsätzlich geht es und reicht es zum Testen.)

Also soweit ich weiß, kann PHP nur auf einem Server laufen? Bzw auf einer Software die ein Server darstellt? Deswegen benötigt man ja für die Programmierung mit PHP XAMPP o.ä.

hustbaer

Also...
* Du brauchst ein geschlossenes System, also eines das du gegen Modifikationen schützen kannst (Konsole, Dongle der signierten & verschlüsselten Code ausführen kann, Server)
* Die relevanten Berechnungen müssen auf dem geschlossenes System durchgeführt und auch dort abgespeichert bzw. von dort verteilt werden

Dann kann das ganze sicher sein.

Das geschlossene System kann dein Server sein.
Und wenn die dort laufenden Berechnungen im Prinzip die gesamte Spielmachanik darstellen, und die Ergebnisse auch wieder dort gespeichert bzw. von dort an die Mitspieler verteilt werden...
Dann kann man das ganze als sicher ansehen.

WENN das geschlossene System wirklich geschlossen ist. Wenn das "geschlossene System" natürlich voll von Sicherheitslöchern ist, dann ist es natürlich nicht wirklich geschlossen, und damit wird das ganze System wieder manipulierbar.

tomy86

hustbaer schrieb:

WENN das geschlossene System wirklich geschlossen ist. Wenn das "geschlossene System" natürlich voll von Sicherheitslöchern ist, dann ist es natürlich nicht wirklich geschlossen, und damit wird das ganze System wieder manipulierbar.

Ja das ist klar. Dinge die vom Client an den Server geschickt werden, wie z.B. Spielerposition usw. müssen Serverseitig auf Richtigkeit geprüft usw werden.

Jo, dann hab ich ja jetzt einiges, wo ich mich reinlesen darf
Ich danke herzlichst für die hilfreichen Informationen

hustbaer

tomy86 schrieb:

Also soweit ich weiß, kann PHP nur auf einem Server laufen?

PHP gibt's als ganz normales Commandline-Programm. Kann man verwenden wie Batchfiles bzw. Shellskripte.

php.exe MeinSkript.php Argument1 Argument2 Argument3

,
und schon läuft das Ding.

Etwas genauer: PHP ist einfach nur eine Sprache, genau so wie C, C++, C#, Java, Visual Basic etc.
Damit kann man ganz normale Programme schreiben. Und genau so wie man C# oder Visual Basic .NET z.B. mit ASP .NET verwenden kann um recht einfach dynamische Webseiten zu entwickeln, kann man halt PHP auch mit Apache o.ä. verwenden um dynamische Webseiten zu entwickeln.

tomy86 schrieb:

Bzw auf einer Software die ein Server darstellt?

Damit kommen wir der Sache schon näher, denn...

tomy86 schrieb:

Deswegen benötigt man ja für die Programmierung mit PHP XAMPP o.ä.

...was du meinst wenn du PHP schreibst ist nicht PHP, sondern PHP welches über CGI oder als Plugin bei Apache (bzw. einem anderen Webserver) eingebunden wird.
Wenn du das PHP Programm über einen Browser ansprechen willst, dann brauchst du natürlich irgendwo ein HTTP Server Programm.
(So ein HTTP Server Programm könnte man natürlich auch direkt in PHP schreiben, aber das tut man einfach nicht, man verwendet dafür fertige Server wie eben z.B. Apache.)

tomy86

Ah super vielen dank. Wieder was gelernt

hustbaer

tomy86 schrieb:

hustbaer schrieb:

WENN das geschlossene System wirklich geschlossen ist. Wenn das "geschlossene System" natürlich voll von Sicherheitslöchern ist, dann ist es natürlich nicht wirklich geschlossen, und damit wird das ganze System wieder manipulierbar.

Ja das ist klar. Dinge die vom Client an den Server geschickt werden, wie z.B. Spielerposition usw. müssen Serverseitig auf Richtigkeit geprüft usw werden.

Nö, den Teil hatte ich ja schon beschrieben, also dass alle relevanten Berechnungen in dem geschlossenen System gemacht bzw. zumindest überprüft werden müssen.

Was ich hier meine ist ein ganz anderes Problem.
Es werden ja immer wieder Sicherheitslöcher in diversen Programmen gefunden, darunter auch Serverprogramme.
Viele dieser Sicherheitslöcher ermöglichen es dem Angreifer ausführbaren Code an den Server zu schicken, und der Server führt den dann einfach aus.

Das ermöglicht es einem Angreifer dann ... naja, im Prinzip am Server zu machen was auch immer er machen will. Alle Accounts aus der Datenbank auslesen und dem Angreifer zurückschicken. Viel Geld auf sein eigenes Konto zu überweisen. Oder eben auch bestimmte Werte für bestimmte Waffen im Serverprogramm auszutauschen.
Der Knackpunkt dabei ist: wenn es so ein Sicherheitsloch gibt, dann ist das geschlossene System einfach nicht mehr geschlossen.

Anhand eines Beispiels...
Das mit den wichtigen Berechnungen ist wie wenn ich sage: du musst alle deine Wertgegenstände in den Safe legen, sonst sind die nicht sicher.
Das mit den Sicherheitslöchern ist wie wenn ich sage: wenn der Safe aus Schokolade ist, dann ist er kein Safe sondern ein Scheissdreck
Und im Shokoladensafe sind deine Wertgegenstände halt einfach nicht sicher, auch wenn du brav alle reingelegt hast.

tomy86

hustbaer schrieb:

Anhand eines Beispiels...
Das mit den wichtigen Berechnungen ist wie wenn ich sage: du musst alle deine Wertgegenstände in den Safe legen, sonst sind die nicht sicher.
Das mit den Sicherheitslöchern ist wie wenn ich sage: wenn der Safe aus Schokolade ist, dann ist er kein Safe sondern ein Scheissdreck
Und im Shokoladensafe sind deine Wertgegenstände halt einfach nicht sicher, auch wenn du brav alle reingelegt hast.

Außer der Dieb mag so gern Schokolade, das er hinterher zu satt ist wenn er den Safe aufgegessen hat und nix mehr klauen kann, weil er nix mehr tragen kann

Aber mal Spaß beiseite. Was wäre den effektiv ein solches Loch? Man kann ja nur über den Port X mit dem Server reden. wenn also alle Dateneingänge usw geprüft werden, dann sollte es doch sicher sein?

hustbaer

DER Klassiker ist der "unchecked buffer".

http://en.wikipedia.org/wiki/Buffer_overflow

tomy86

hustbaer schrieb:

DER Klassiker ist der "unchecked buffer".

http://en.wikipedia.org/wiki/Buffer_overflow

Ja das Problem kenn ich zu gut. Hab schon ein paar mal damit Kämpfen müssen. Aber mit der Zeit lernt man glaub ich, wie man diese Fehler nicht mehr macht.

hustbaer

Nur weil ich mir nicht sicher bin ob dir das Ausmass des Problems "unchecked buffer" klar ist...

Das "interessante" dabei ist nicht dass dadurch das Programm z.B. abkacken kann.

Das "interessante" dabei ist dass man dadurch ausführbaren Code in z.B. Datenfiles, oder auch Nachrichten die man an einen Server schickt, "verpacken" kann, so dass die "verarbeitung" dieser Files/Nachrichten dazu führt dass der "verpackte" Code ausgeführt wird.

Wenn ich z.B. weiss dass du Programm X zum Angucken von JPEG Files verwendest, und weiss dass Programm X so ein unchecked Buffer Problem hat...
Dann kann ich dir ein speziell präpariertes JPEG File schicken, das dir deine Festplatte formatiert (sobald du es in Programm X aufmachst)

Besonders blöd ist das wenn Programm X z.B. eine Gruppe vieler Windows Anwendungen (Outlook, Outlook Express, Explorer, Internet Explorer, ...) ist, und es wirklich um JPEG Files geht. Die ja in Emails und auch im Web bekanntlich nur extremst selten anzutreffen sind, und daher sofort Verdacht erregen.
Was übrigens nicht erfunden ist

tomy86

Ok, nee das habe ich nicht gewusst. Das ist ja echt übel! Kann ein unchecked puffer eigentlich auch aus welchen Grund auch immer beim Kompilieren unbemerkt bleiben?

tomy86 schrieb:

Kann ein unchecked puffer eigentlich auch aus welchen Grund auch immer beim Kompilieren unbemerkt bleiben?

Nein, das kann nicht sein, das ist ganz sicher so.

hustbaer

@tomy86
Willst du mich jetzt verarschen?
Natürlich kann der unbemerkt bleiben. Oder meinst du dass alle Firmen die auf Grund von unchecked Buffers verwundbare Produkte ausgeliefert haben das einfach nur absichtlich ignoriert haben?

DocShoe

@OP
Vielleicht möchtest du dir das hier mal angucken: RakNet. Ist eine MultiPlayer Network Engine, die jetzt wohl Open Source ist.

Buffer-Overflow attacks sind immer noch nen Ding?

Also, in praktischer Realität?!

Wut schrieb:

Buffer-Overflow attacks sind immer noch nen Ding?

Also, in praktischer Realität?!

also als erstes geht es hier ja eig um ein praktisch relevantes beispiel ...

desweiteren ließ hier mal die ersten Zeilen :
http://de.wikipedia.org/wiki/Pufferüberlauf

vll ist dir dann logisch warum das theoretisch wie praktisch relevant ist ...
für die meisten ist das ja "unrelevante" theorie ...

lg

für die meisten ist das ja "unrelevante" theorie ...

den satz hab ich vergessen weg zu machen.
der hat keine bedeutung und kein sinn,
entschuldigung für den doppel-post, aber edit geht nicht.

lg

tomy86

hustbaer schrieb:

@tomy86
Willst du mich jetzt verarschen?
Natürlich kann der unbemerkt bleiben. Oder meinst du dass alle Firmen die auf Grund von unchecked Buffers verwundbare Produkte ausgeliefert haben das einfach nur absichtlich ignoriert haben?

Die Frage stellte sich mir, weil VS sich ja "eigentlich" bei mir immer beschwert hat. Was ich somit meine ist, unter welchen Voraussetzungen das unbemerkt bleiben kann, und wie man es am besten überprüfen kann?

Meh, hört sich für mich eher wie eine uneducated guess Aussage an.

Gleiche wie alle immer Sagen 90% der Websites wären XSS-gefährdet.
Ist doch in heutiger Zeit, wo jede Website auf irgendeinem fertigen Framework aufbaut, totaler Blödsinn.