Inventar
-
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
-
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.)
-
Ah super vielen dank. Wieder was gelernt
-
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.
-
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?
-
DER Klassiker ist der "unchecked buffer".
-
hustbaer schrieb:
DER Klassiker ist der "unchecked buffer".
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.
-
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
-
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.
-
@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?
-
@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überlaufvll 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
-
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.
-
@tomy86
Wenn du die ganzen "..._s" Funktionen meinst...
Erstmal ist es in vielen Projekten quasi unmöglich einfach mal so alle Warnings die da ausgespuckt werden zu fixen indem man auf die "..._s" Funktionen umstellt. Sei's weil es einfach zu viele sind, oder weil das Projekt nicht nur mit VS compilierbar sein muss sondern auch mit anderen Compilern.
Die "Lösung" ist dann meist dass man diese Warnings deaktiviert (_CRT_SECURE_NO_WARNINGS, _SCL_SECURE_NO_WARNINGS).Weiters meckert VS hier natürlich nur für eigene Funktionen. Wenn man selbst irgendwo unsichere Kopierschleifen schreibt meckert VS nicht. Weil es nicht "versteht" dass man hier ein unsicheres Konstrukt gebaut hat. Die Warnings die VS bei Funktionen wie
std::strcpyliefert, werden ja nur ausgespuckt, weil alle "potentiell problematischen" Funktionen, für die es "..._s" Alternativen gibt, speziell in den Header Files "markiert" sind.Und davon abgesehen wird halt auch lange nicht jedes Programm mit VS compiliert. Selbst bei den Windows Programmen gibt es noch viel wo z.B. GCC (MinGW & Co.) zum Einsatz kommt.
Es gibt natürlich Static-Analysis Tools die solche Fehler finden können. Aber die verwendet ja leider auch kaum jemand.
-
wut schrieb:
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.
(...)Was meinst du jetzt?
Was genau soll hier ein "uneducated guess" sein?
-
hustbaer schrieb:
wut schrieb:
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.
(...)Was meinst du jetzt?
Was genau soll hier ein "uneducated guess" sein?Die Aussage aus Wikipedia, dass es immer noch eine so dramatisch breit vertretene Sicherheit-Lücke wäre.
Meinetwegen wenn man die ganze uralt Software berücksichtigt. Aber Software, die in einem angemessenem Rahmen entwickelt worden sind werden wohl kaum noch sonderlich häufig anfällig gegenüber Buffer-Overflow attacks sein.
Das klingt einfach viel zu sehr nach einer über-Dramatisierung dieses Problems.
