 PHP bei vRhs |
1Sm!le
Mitglied
Dabei seit: 05.03.2005
Beiträge: 441
Herkunft: Berlin
 |
|
VRhs aus Besitzer-Sicht sind eine Spielwiese. Als Besitzer kann man da erstmal bei Seiten wie Beepworld basteln. Wenn man mehr will, kann mit HTML basteln. Wer mehr will, nimmt sogar noch CSS und JavaScript dazu. Das sieht dann gut aus und funktioniert auch.
Ganz ehrlich, ich habe so angefangen. Erstmal will man sowas haben ... oi, da geht was nicht, dann nehm ich halt HTML. Muss man üben ... irgendwann funzt es soweit. Bis CSS und in meinem Fall viel JavaScript kommt man auch noch. Ich persönlich habs in einer Zeit gemacht, wo das als vRH-Besitzer noch keine Quasi-Pflicht war. Inzwischen sehen das ja viele als Pflicht an, um überhaupt gut zu wirken (nein, das ist nicht Diskussionsthema, ob alle das so sehen ...). Auf jeden Fall wagen sich immer mehr Leute - gibt ja auch mehr VRHs - an HTML und co. Nix verwerfliches. Da finden sich Tutorials und Helfer, gerade auch bei GB. Ist ja auch super.
Jetzt kommt der Umbruchpunkt ... es gibt ein paar professionelle Pferdespiele mit PHP. Da zähle ich mal sowohl die professionell von Agenturen Betriebenen (equilino, howrse ...) als auch die halb-professionell (auf professionelle Art von nicht- oder halb-professionellen Betreibern ;-)) Betriebenen (Wilder Reiter, equineDreams, ...). Irgendwer kam auf die Idee, das auch zu wollen. Inzwischen gibt es davon immer mehr. Immer mehr Leute wollen das. Wie zuvor wird jetzt also auch mit PHP herumprobiert, Tutorials gelesen, gefragt.
Wo ist das Problem?
PHP ist *nicht* zum Herumprobieren geeignet. PHP ist eine Sprache, mit der man einen Webserver in einem gewissen Sinne steuern kann. Nutzt man Fehler und Möglichkeiten in PHP, kann man den ganzen Webserver auch übernehmen. Bei HTML kann jemand dein Passwort knacken ... bei PHP kann jemand mit deinem Server echten Schaden anrichten. Beispiele, was bei PHP passieren kann, wenn man nicht aufpasst:
* Der Server kann als illegaler Downloadserver übernommen werden ...
* Der Server kann für Angriffe gegen andere Server genutzt werden ...
* Der Server kann als Mail-Schleuder genutzt werden ...
Wenn du als Betreiber für diesen Server registriert bist, stehst du erstmal in der Haftung für solche Dinge. Und selbst wenn dich keiner anklagt ... willst du wirklich, dass "dein" Server von jedem anderen übernommen werden kann?
Wodrauf ich hinaus möchte, ist, dass ein Server, auf dem PHP zur Verfügung steht, viel mehr kann als einer, wo nur HTML aktiv ist ... und auf so einem Server kann auch viel mehr Schaden anrichten. Wenn dir beim Programmieren das bewusst ist, super ... aber ich möchte doch mal alle anderen, die mit PHP spielen, aber sich zum Beispiel über Sicherheit nie Gedanken gemacht haben, ermuntern, das zu tun, bevor sie leichtfertig Dinge aus Tutorials kopieren und einsetzen. Von den Tutorials bei GB, die ich gesehen habe, lassen alle Sicherheitslücken offen. Ein Beispiel: Die Pferdesteckbriefe, wie sie hier eingesetzt werden, braucht man nur mit einer geschickten URL aufrufen ... und zu 95% ist eure Datenbank danach unwiderbringlich weg. Wollt ihr das wirklich?
__________________
|
|
19.06.2009 10:15 |
|
|
Nessa82
Königin v. Passiv-Aggressivistan
Dabei seit: 13.03.2005
Beiträge: 6.254
|
|
Ich persönlich mache von meinen Sachen regelmäßig Sicherheitskopien 
Daher stellt es nicht wirklich ein Problem dar bzw ein ähnliches, als wenn jemand meinen HTML Webspace knackt und alles löscht. Wir spielen es wieder auf, wenn sich da jemand mal Zugang verschafft.
* Der Server kann als illegaler Downloadserver übernommen werden ...
Beschreibe das mal bitte detailliert. Normalerweile kann / darf sowas nicht passieren, wenn man die neusten Sicherheitsupdates pflegt.
* Der Server kann für Angriffe gegen andere Server genutzt werden ...
Soll das ein Exploid sein oder meinst Du, falls jemand das PW knackt ?
* Der Server kann als Mail-Schleuder genutzt werden ...
Ja, möglich, aber dazu muss man erstmal den Zugriff haben. Ein Anruf beim Anbieter, ein neues PW wird generiert und die IP des Angreifers wird festgehalten.
Aber da sicherlich viele nicht drüber nachdenken, danke an dieser Stelle für den Denkanstoss
Auf jeden Fall sollte man nicht einfach drauflos basteln, ohne sich wirklich den Überblick über das alles zu verschaffen, bzw (wie in meinem Fall) jemanden dabei haben, der damit umgehen kann und sich damit auskennt
|
|
|
19.06.2009 11:03 |
|
|
1Sm!le
Mitglied
Dabei seit: 05.03.2005
Beiträge: 441
Herkunft: Berlin
Themenstarter 
|
|
| Zitat: |
Original von NeverlandNessa
Aber da sicherlich viele nicht drüber nachdenken, danke an dieser Stelle für den Denkanstoss
Auf jeden Fall sollte man nicht einfach drauflos basteln, ohne sich wirklich den Überblick über das alles zu verschaffen, bzw (wie in meinem Fall) jemanden dabei haben, der damit umgehen kann und sich damit auskennt
|
Danke erstmal für die Bestätigung insoweit. Das war es ja, wodrauf ich hinauswollte.
Zu den Dingen, die ich da genannt habe: Sowas kann sehr wohl passieren, auch mit aktuellen Sicherheitsupdates, wenn man nicht sicher programmiert. Zum Einen muss man halt - wenn man selbst Kontrolle drüber hat - aufpassen, wie sicher PHP überhaupt konfiguriert hat. Bestes Beispiel ist die Funktion exec ... ist diese aktiv, und wird benutzt, und du schaffst es, diese von außen nutzen zu können, kannst du einiges, im schlimmsten Fall (root) alles tun auf dem Server.
Alle drei Dinge, die ich aufgeführt habe, laufen auf dieselbe Weise ... wenn eine Funktion aktiviert ist, die Angriffe erlaubt, und du (oft über URL-Manipulation) passend den Angriff schaffst, wird dein in der URL codierter Angriffscode ausgeführt.
Was du ansprichst ... Anbieter anrufen ist da kein Heilzweck. Erstmal musst du im Zweifelsfall nachweisen, dass du keinerlei Fehler gemacht hast und es nicht zu verhindern war. Das geht, aber nicht immer einfach. Vor allem ... ich persönlich hab da auch ein Verantwortungsgefühl, was mir sagt "Ich will auch nicht, dass ich nur 5 Minuten irgendwem irgendetwas zur Verfügung stelle". Vor allem ... wer sagt dir, dass du es merkst, wenn jemand deinen Server nebenbei noch für andere Dinge verwendet. Er muss ja dein Zeug gar nicht löschen 
Aber was wir jetzt andiskutieren, geht eigentlich schon viel weiter, als was ich sagen wollte. Mir geht es eigentlich erstmal darum, dass sich die Leute allgemein Gedanken machen, ob sie aufpassen, ob sie sinnvoll arbeiten, ob sie sich schützen. Und das ist eben kaum möglich, wenn man eben mal nen Tutorial ausprobiert ...
__________________
|
|
|
19.06.2009 11:42 |
|
|
Freak
unmotiviert.
Dabei seit: 15.10.2005
Beiträge: 2.590
|
|
Danke für diesen Thread - du sprichst tatsächlich ein Thema an, das sicher wichtig ist und über das sich jeder Gedanken machen sollte.
Allerdings finde ich, wenn du die "Sicherheitslücken" schon ansprichst, die passieren können, solltest du auch noch ein bisschen was dazu sagen, wie man es verhindert.
Sonst macht sich gleich jeder Otto-Normal-PHPler Gedanken, wie er mit seinen über Datenbank generierten Pferdesteckbriefen den Hacker unterstützt
Ich fände es unheimlich schade, wenn ich diese Technik nicht weiterhin nutzen könnte.
__________________
|
|
|
19.06.2009 11:57 |
|
|
Nessa82
Königin v. Passiv-Aggressivistan
Dabei seit: 13.03.2005
Beiträge: 6.254
|
|
Ok, ich verstehe was Du meinst.
Wer Exec aus einem seiner Scripte heraus aufruft, der lebt gefährlich. Wer Eingaben von Aussen ungeprüft verwendet, verdient es eigentlich nicht besser
Ich persönlich fühl mich grad etwas angegriffen, was den Spruch mit dem Verantwortungsgefühl betrifft, aber ich glaube darüber müssen wir hier nicht diskutieren.
Mal noch ne Frage zum Exec : wir nutzen es nicht. Uns fällt allerdings grad kein Beispiel ein, wo mans benutzen könnte, bzw wo es bei anderen Verwendung findet. (Zuviel geackert heute... o.0)
Ich denke allgemein ist das Problem, was Du angesprochen hast, (meiner Meinung nach) der Gruppenzwang á la "Ich muss das auch haben!!" Jeder möchte gerne bei denen ganz oben mitwirken, notfalls eben ohne Plan und mit zweitklassigen Tuts (nein, sind nicht alle schlecht
). Ob das dann so gut ist, möchte ich mal dahingestellt lassen... Ich bin da in der Hinsicht froh, dass mein Mann sich auskennt, hehe. Denn hätte ichs allein gemacht, ich wäre mit Sicherheit das gefundene Fressen für einen Hacker gewesen.
edit : ich fänd mal nen groben Plan prima Marke "Wie verhindere ich die groben Sicherheitslücken", wie Freak schon sagte
Also, mal ran, Du hast da ja Ahnung von
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Nessa82: 19.06.2009 12:08.
|
|
|
19.06.2009 12:07 |
|
|
1Sm!le
Mitglied
Dabei seit: 05.03.2005
Beiträge: 441
Herkunft: Berlin
Themenstarter
|
|
Oh äh so eine komplettes "Wie verhinder ich Angriffe" gibt es nicht. Wenn es das gäbe, wären ja alle Probleme schon behoben und (fast) niemand würde mehr angegriffen 
Ich kann nur mal kurz auflisten, was so ganz wesentlich ist ...
Wer Zugriff auf die Server-Technik hat, möge kontrollieren:
- Was an sicherheitsrelevanten Funktionen nicht benötigt wird, gehört abgeschaltet ... dann kann es keinen Schaden anrichten. Kurzform dafür ist der sogenannte safe_mode, den die meisten Webspace-Anbieter auch schon aktiviert haben. > offizielle Dokumentation zum safe_mode
- Haltet das System aktuell. Gerade Sicherheitsupdates müssen unbedingt gemacht werden.
Das ist nicht(!!!) vollständig, das sind nur die beiden einfachsten und aus meiner Sicht dringendsten Dinge, die man tun sollte, wenn man Zugriff auf die Serverkonfiguration hat.
Viel wichtiger ... beim täglichen Programmieren gibt es gemeine Fallstricke. Der wichtigste dürfte sein: Viele übernehmen Informationen aus der URL einfach ungeprüft. Tut das niemals! Daten von außen sind potenzielle Angriffsversuche.
Zu deutsch: Niemals Variablen aus der URL, aus einem Formular oder aus einer Session ungeprüft weiterverwenden. Immer überprüfen, ob diese Inhalte wirklich das sind, was ihr erwartet (simples Beispiel ... wenn in der URL eine ID stehen soll ... habt ihr wirklich eine Zahl erhalten oder irgendwas anderes? Das kann man leicht überprüfen und im Problemfall abfangen).
Ich mach einfach mal ein Beispiel ... in Eponas Tutorial gibt es folgenden Code bei einem Pferdesteckbrief:
| php: |
1:
2:
3:
4:
5:
6:
|
$id = "$_GET[id]";
$Ergebnis = mysql_query( "SELECT * FROM Pferd where ID='$id'" );
if (@mysql_num_rows($Ergebnis) == 0) {
echo "Dieses Pferd existiert nicht!";
} |
|
Das funktioniert super ... im Regelfall. Jemand ruft die Seite auf mit Pferd.php?id=1. Super.
Aber ... jemand anders ruft auf: Pferd.php?id=1';DELETE * FROM Pferd WHERE ''=' (zur Vollständigkeit: Die Sonderzeichen wie ' müsste man kodieren, aber das ist dann keine Kunst mehr, wenn man als Angreifer soweit ist).
Was würde jetzt passieren ... $id wäre dann der Wert "1';DELETE * FROM Pferd WHERE ''='". Das Query, was danach losgeschickt wird, lautet ... "SELECT * FROM Pferd where ID='1';DELETE * FROM Pferd WHERE ''=''". Ups ... weg sind alle Pferde in der Datenbank. So einfach gehts im harmlosen Fall ...
Und wie macht man es besser?
* Man sollte die $id auf ihren Zahlenwert kontrollieren oder $id einfache hart in eine Zahl umwandeln. Damit würde schädlicher Code rausfliegen.
Einfachste Lösung ist hier mal sogenanntes Typ-Casting. Damit ist sichergestellt, dass in $id am Ende eine Zahl steht, vollkommen egal, was in $_GET[id] vorher drin war ... php versucht hier möglichst viel sinnvolle Zahl aus dem $_GET[id] zu holen und schmeißt den Rest weg.
| php: |
1:
|
$id = (int) "$_GET[id]"; |
|
* Man sollte idealerweise sprintf > offizielle Doku sprintf oder ähnliche Möglichkeiten nutzen, um einen mySQL-Query typgerecht zusammenzubauen, bevor man es an die Funktion mysql_query übergibt.
Was unbedingt zu bedenken ist ... solche URL-Manipulation ist die Spitze vom Eisberg. Man kann schlimmeres anstellen. Aber das lässt sich nicht so leicht und so effizient verhindern.
Zurück zum Grundsätzlichen
Ich habe jetzt einen ganz groben Plan zusammengestellt. Ich werde *nicht* Zeit und Muße haben, Details auszuarbeiten. Ich will das auch gar nicht. Denn ich bin der Meinung ... wer PHP verwendet, sollte sich selbst die Zeit nehmen und das auch so gründlich ansehen, dass er die gröbsten Probleme erkennt.
Da auch an BlackTear ... Du schriebst, während ich grad auch schreibe.
Zwei Dinge:
1. Es geht nicht darum, ob du einen Server abstürzen lässt. Es geht darum, ob du Fehler machst, die es jedem anderen ermöglichen, deinen Server zu missbrauchen! Und zwar ohne großen Aufwand, aber mit großem Effekt. Und glaub mir, das ist möglich
2. Mein Ziel ist es zu sagen "Verwendet PHP nur, wenn ihr wisst, was ihr tut". Alles andere ist, verdammt noch mal, leichtsinnig!
Mir ist zugegeben klar, dass man Sprachen nur durch Ausprobieren lernt. Aber man muss noch lange nicht alles, was man gerade lernt, ins Internet stellen. PHP kann man leicht auf zb XAMPP testen und ausprobieren. Da kann euch niemand angreifen und ihr könnt alles tun. Wenn es dann halbwegs funktioniert, und ihr nen Überblick habt, was ihr tut ... dann kann man es auch grob gegen Angriffe schützen.
__________________
|
|
|
19.06.2009 13:19 |
|
|
Isabel
» in love with flow
Dabei seit: 09.05.2005
Beiträge: 6.745
|
|
reicht es dann nicht bei der IP abfrage "strip_tags" zu verwenden?
__________________
|
|
|
19.06.2009 14:13 |
|
|
1Sm!le
Mitglied
Dabei seit: 05.03.2005
Beiträge: 441
Herkunft: Berlin
Themenstarter
|
|
| Zitat: |
Original von Isabel
reicht es dann nicht bei der IP abfrage "strip_tags" zu verwenden? |
Ich nehme an, du meinst ID? Und nein, in meinem Beispielfall würde es nicht tun, auch wenn die Idee dahinter schon richtig ist ... mit solchen Funktionen kann man sich gut und effektiv schützen.
__________________
|
|
|
19.06.2009 14:43 |
|
|
Nanni
Mitglied
Dabei seit: 25.01.2007
Beiträge: 11.260
Herkunft: Wien
Name: nennt mich Nanni
|
|
Interessant ist es wirklich und gut, dass es einmal angesprochen wurde.
Trotzdem werde ich jetzt nicht alles mögliche unternehmen, um die Daten zu schützen
- Ein VRH ist ein Pferdespiel, viele der Mitglieder wissen ohnehin nicht, was denn HTML geschweige denn PHP bedeutet.
- Mitglieder und Besucher haben keinen Grund, die Daten zu löschen
- Fremde, die nichts mit der Seite zu tun haben, werden wohl kaum an meinen Daten herumhacken.
- Und wer hat Grund, die Daten zu löschen? Andere Hofbesitzer aus Eifersucht? Dafür muss man es allerdings auch erst lernen, um gezielt etwas anrichten zu können.
Für den Notfall habe ich die Daten der Pferde natürlich trotzdem gespeichert - das wieder raufzuladen, dauert ja notfalls auch nicht sehr lange, kommt ja nicht täglich vor.
Wenn diese Methoden unter Hofbesitzern bekannter werden, steigt natürlich auch die Gefahr dafür!
Heißt also im Endeffekt, dass Mitglieder per URL-Aufrufen die Daten ihrer Pferde ändern können? Daran hatte ich wirklich noch nie gedacht =D
LG Nanni
__________________
|
|
|
19.06.2009 14:46 |
|
|
1Sm!le
Mitglied
Dabei seit: 05.03.2005
Beiträge: 441
Herkunft: Berlin
Themenstarter
|
|
Ja, auch das heißt es, das ist auch problemlos machbar 
Wer Grund hat anzugreifen sind
* Leute, die mit dir nix zu tun haben, aber den Server für ihre Zwecke nutzen wollen
* Leute, die dich ärgern wollen
Ein einziger davon reicht ja auch.
__________________
|
|
|
19.06.2009 14:47 |
|
|
Nanni
Mitglied
Dabei seit: 25.01.2007
Beiträge: 11.260
Herkunft: Wien
Name: nennt mich Nanni
|
|
Wieso bitte sollte jemand meinen Server für seine Zwecke nutzen wollen? Es ist kostenlos und dauert keine fünf Minuten, einen eigenen Server einzurichten, und ist nebenbei einfacher und sicherer, als meinen Server mitzubenutzen, denn schließlich kann ich den ja jederzeit löschen und der entsprechende Hacker hat sich die Arbeit um sonst gemacht.
__________________
|
|
|
19.06.2009 14:53 |
|
|
Isabel
» in love with flow
Dabei seit: 09.05.2005
Beiträge: 6.745
|
|
ist natürlich auch klug solche funktionen hier jetzt darzustellen...
so hat man dann die neue Ebene des VRH-Terrorismus erreicht ^^
__________________
|
|
|
19.06.2009 15:09 |
|
|
Nessa82
Königin v. Passiv-Aggressivistan
Dabei seit: 13.03.2005
Beiträge: 6.254
|
|
lol,... nun hat mein Mann nen neuen Floh im Ohr. Der probiert jetzt an unseren Pferden rum. o.0
|
|
|
19.06.2009 15:24 |
|
|
Isabel
» in love with flow
Dabei seit: 09.05.2005
Beiträge: 6.745
|
|
ja ich bin auch mal gespannt, wer bald alles leere Datenbanken hat
bei meiner Beliebtheit bin ich da bestimmt drunter xD
__________________
|
|
|
19.06.2009 15:25 |
|
|
Nessa82
Königin v. Passiv-Aggressivistan
Dabei seit: 13.03.2005
Beiträge: 6.254
|
|
ja, aber wer weiß, evtl hats mein Mann mit dem kodieren aber auch nur nicht richtig gemacht. Wer weiß.
Auf jeden Fall sucht er nun intensiv nach Löchern aller Art.
|
|
|
19.06.2009 16:00 |
|
|
Ella*
Pell, du Lachs!
Dabei seit: 20.06.2008
Beiträge: 1.141
Herkunft: NRW
Name: Ella
|
|
| Zitat: |
Original von Nanni
Wieso bitte sollte jemand meinen Server für seine Zwecke nutzen wollen? Es ist kostenlos und dauert keine fünf Minuten, einen eigenen Server einzurichten, und ist nebenbei einfacher und sicherer, als meinen Server mitzubenutzen, denn schließlich kann ich den ja jederzeit löschen und der entsprechende Hacker hat sich die Arbeit um sonst gemacht.
|
Für was illegales vielleicht... i.was, was man besser nicht von einem eigenen Server aus macht? So genau weiß ichs auch nicht...
Oh man, hoffentlich wird es nicht wirklich bald so sein, dass die VRH Besitzer von hackenden Neidern geärgert werden, die Datenbanken löschen .__.
__________________
Illusion is the first of all pleasures.
Oscar Wilde
|
|
|
19.06.2009 16:38 |
|
|
Freak
unmotiviert.
Dabei seit: 15.10.2005
Beiträge: 2.590
|
|
Meint ihr wirklich, da muss jemand schlecht drauf sein, um sowas zu versuchen?
Jeden Hobby-Webbastler juckt es in den Fingern, wenn er solche Möglichkeiten liest. Hat er dann noch etwas kriminelle Energie... 
__________________
|
|
|
19.06.2009 16:47 |
|
|
sina91
<3
Dabei seit: 09.02.2007
Beiträge: 2.331
Herkunft: nähe Oldenburg
Name: Sina
|
|
Man kann sich aber auch verrückt machen
Ich meine, wenn wir darüber nachdenken, was theoretisch alles möglich ist, sollten wir dank der Impressumspflicht schon gar keine vRhs mehr aufbauen, das könnte ja Einbrecher etc. anlocken.
Bei einem vRh wird ein schlauer Hacker sicherlich einen Downloadserver einrichten, da bei Free Webspace Anbietern ja meist unendlich Traffic vorhanden ist.
__________________
|
|
|
19.06.2009 17:17 |
|
|
|
|
|
  |
Impressum
|
