nicht angemeldet
Camping_RIDER
tk
Der Martin
MudGuard
Matthias Apsel
Auge
Matthias Apsel
Matthias Apsel
Camping_RIDER
Camping_RIDER
Camping_RIDER
Aloha,
die Überschrift deutet es an - ich verstehe das php-Script nicht, das ich für die Verwaltung der Datenbanken auf meiner HP benutze: phpDVD 1.0.4
Es funktioniert alles hervorragend, auch wenn ich selber nicht so wirklich php spreche, komme ich damit klar und kann alles so anpassen, dass es so aussieht und funktioniert, wie ich es für mich brauche. Im Grunde geht es mir auch nur um eines: wenn ich eine DB-Seite meiner HP nun validiere, kommt immer eine Fehlermeldung, seitdem ich auf HTML5 umgestellt habe, z.B. bei meiner Amiga-Software-Datenbank.
Wenn ich diese validieren lasse (einfach mal auf den HTML5-Link oben klicken), kommt immer folgende Meldung:
Line 69, Column 29: Bad value for attribute action on element form: Must be non-empty.
<form method="get" action="">
Okay, ich verstehe schon was da steht.
Schau ich mir nun aber die Stelle in meinem Code an, steht dort folgendes:
<form method="get" action="<?php echo $REQUEST_URI; ?>">
Schau ich mir den Quelltext der ausgegebenen Datei an, findet sich folgendes:
<form method="get" action="">
Offensichtlich ergibt <?php echo $REQUEST_URI; ?> "nichts" als Rückgabewert und HTML5 verlangt dort eine Angabe.
Doch warum ist das so?
Wenn ich diesen php-Befehl weglasse, und gleich
<form method="get" action="">
angebe, funktioniert die Suchmaske bei Druck auf den "Go"-Knopf auch.
Gebe ich (als Beispiel):
<form method="get" action="http://wiki.selfhtml.org/wiki/Startseite">
ein, läd bei Klick auf den Go-Knopf die SelfHTML-Wiki.
Lasse ich die action-Angabe ganz weg:
<form method="get">
funktioniert das Script auf den ersten Blick genauso.
Was ich jetzt nicht verstehe: was könnte der ursprüngliche Autor mit dieser offensichtlich überflüssigen Angabe bezweckt haben?
MfG
JPL
Offensichtlich ergibt
<?php echo $REQUEST_URI; ?>"nichts" als Rückgabewert und HTML5 verlangt dort eine Angabe.
Du musst es auch richtig schreiben <?php echo $_SERVER['REQUEST_URI'];?>
HTML5 erwartet, dass in action="" etwas steht auch wenn die gleiche Seite wieder aufgerufen wird. Warum kann ich dir nicht sagen, selber halte ich dieses für Schwachsinn. Aber ich habe mich damit abgefunden :)
Vielleicht kann mal jemand genau erklären warum action="" nicht leer sein darf.
Aloha
Offensichtlich ergibt
<?php echo $REQUEST_URI; ?>"nichts" als Rückgabewert und HTML5 verlangt dort eine Angabe.Du musst es auch richtig schreiben
<?php echo $_SERVER['REQUEST_URI'];?>
Danke!
:)
(Hab ja gesagt, ich spreche kein PHP, auch wenn ich durch meine anderen Programmierkenntnisse durchaus verstehe, was ein Code macht... aber wenn es darum geht zu erkennen, welcher Befehl falsch notiert ist... :D )
Gruß
JPL
(Hab ja gesagt, ich spreche kein PHP, auch wenn ich durch meine anderen Programmierkenntnisse durchaus verstehe, was ein Code macht... aber wenn es darum geht zu erkennen, welcher Befehl falsch notiert ist... :D )
$REQUEST_URI ist nicht wirklich falsch notiert ... erfordert aber so, wie Dein Skript es benutzt, aktiviertes register globals. Und das ist ein Problem.
Das würde ich auch nicht aktivieren, weil schon vor 12(!) Jahren (PHP 4.2.0) register globals aus Sicherheitsgründen ENDLICH per default deaktiviert wurde. Seit PHP 5.3 ist es sogar "deprecaded", dass bedeutet, dass es bald (in neuen PHP-Versionen) auch nicht mehr aktivierbar ist.
Das lässt mich für Dein Skript das Schlimmste befürchten. Es ist offenbar "asbach-uralt" und dürfte ziemlich verbugt und unsicher sein - und es wird offenbar auch nicht gepflegt (der Server, von dem der Download stattfinden soll wird nichtmal mehr gefunden).
Du solltest Dir was Neues suchen.
Jörg Reinholz
Aloha ;)
(Hab ja gesagt, ich spreche kein PHP, auch wenn ich durch meine anderen Programmierkenntnisse durchaus verstehe, was ein Code macht... aber wenn es darum geht zu erkennen, welcher Befehl falsch notiert ist... :D )
$REQUEST_URI ist nicht wirklich falsch notiert ... erfordert aber so, wie Dein Skript es benutzt, aktiviertes register globals. Und das ist ein Problem.
Du und Melina, ihr vergesst beide eine noch viel einfachere Möglichkeit: Was, wenn $REQUEST_URI eine benutzerdefinierte globale Variable ist, die nur in irgendeiner Form aus $_SERVER['REQUEST_URI'] abgeleitet wird? Das ist für mich nicht per se ausgeschlossen. Zumindest nicht entscheidbar aus den Daten, die uns hier vorliegen.
Ansonsten natürlich full ACK.
Grüße,
RIDER
$REQUEST_URI ist nicht wirklich falsch notiert ... erfordert aber so, wie Dein Skript es benutzt, aktiviertes register globals. Und das ist ein Problem.
Was, wenn $REQUEST_URI eine benutzerdefinierte globale Variable ist, die nur in irgendeiner Form aus $_SERVER['REQUEST_URI'] abgeleitet wird?
Naja. Das habe ich bedacht. Laut diesem Zweig sollte es dann nämlich gefüllt sein.
Jörg Reinholz
Aloha ;)
Okay, ich gebe dir ja Recht. Es ist extrem unwahrscheinlich, dass $REQUEST_URI benutzerdefiniert ist, da ('software.php') leer sein soll und woanders mit ominösem Inhalt gefüllt. Gänzlich unmöglich ist es dennoch nicht...
Was mich einfach stutzig macht: Wenn da tatsächlich $_SERVER['REQUEST_URI'] stehen sollte, dann macht es eigentlich keinen Sinn, das action-Attribut überhaupt zu füllen - denn auf den aktuellen REQUEST_URI wird ja auch mit leerem action-Attribut (in HTML5-Sprech: ohne action-Attribut) verwiesen...
Es kann natürlich sein, dass der Entwickler damals 1. mit register_globals und 2. redundant gearbeitet hab. Ich will aber nicht grundsätzlich davon ausgehen. Auch wenn ich dir Recht gebe, die Bezeichnung der Variable als $REQUEST_URI macht die Annahme schon zur naheliegendsten.
Grüße,
RIDER
Was mich einfach stutzig macht: Wenn da tatsächlich $_SERVER['REQUEST_URI'] stehen sollte, dann macht es eigentlich keinen Sinn, das action-Attribut überhaupt zu füllen - denn auf den aktuellen REQUEST_URI wird ja auch mit leerem action-Attribut (in HTML5-Sprech: ohne action-Attribut) verwiesen...
Tja. Was wissen wir denn, was der Programmierer sich vor 12 Jahren mal dachte. Vielleicht dachte er einfach, <http://de.selfhtml.org/html/referenz/attribute.htm#form@title=wenn das action-Attribut laut selfhtml da sein soll>, dann muss auch was drin stehen?
Jörg Reinholz
Hallo,
Das lässt mich für Dein Skript das Schlimmste befürchten. Es ist offenbar "asbach-uralt" und dürfte ziemlich verbugt und unsicher sein - und es wird offenbar auch nicht gepflegt (der Server, von dem der Download stattfinden soll wird nichtmal mehr gefunden).
ich hab das Script "damals" gefunden und es hat genau das getan (bzw. tut es immer noch), was ich benötige. Ist ja nix großes, wie man auf dem verlinkten Beispiel sehen kann (die anderen Datenbanken sind nicht öffentlich).
Habe hier mal den Hauptteil vom Script als Textdatei hochgeladen:
Es wird etwas mit "register_globals" gemacht, aber inwiefern dass ein Sicherheitsproblem ist, kann ich nicht erkennen (mangels Kenntnissen auf dem Gebiet).
Du solltest Dir was Neues suchen.
Hach, nur ungern, ehrlich gesagt, nach all den vielen Jahren komme ich mit diesem Script ganz gut klar und es war wirklich ne Heidenarbeit meine Datenbanken (es ist ja nur die verlinkte Amiga-Softwaresammlung öffentlich, weil das außer einigen anderen Retro-Computer-/Amigafans eh keinen interessiert, alle anderen sind nicht frei zugänglich) an die Seite anzupassen...
Gruß
JPL
Hallo Jörg,
Das würde ich auch nicht aktivieren, weil schon vor 12(!) Jahren (PHP 4.2.0) register globals aus Sicherheitsgründen ENDLICH per default deaktiviert wurde. Seit PHP 5.3 ist es sogar "deprecaded", dass bedeutet, dass es bald (in neuen PHP-Versionen) auch nicht mehr aktivierbar ist.
Nicht "bald". register_globals wurde mit PHP 5.4.0 (also vor über 2,5 Jahren) entfernt, es kann in aktuellen Versionen nicht mehr aktiviert werden.
Du solltest Dir was Neues suchen.
+1
Gruß,
Tobias
Aloha,
Du solltest Dir was Neues suchen.
+1
seitdem das hier so thematisiert wurde - und mein jetziges Script nur unter PHP 5.3 läuft und wenn ich auf PHP 5.4 aktualisiere (bei meinem Anbieter) nicht mehr, suche ich schon nach einem neuen Script.
Aber scheinbar gibt es sowas nicht (oder ich bin zu doof zu suchen :) )...
Kann doch nicht sein, daß ich der einzige bin, der über PHP eine SQL-Datenbank auswerten will?!
:)
Gruß
JPL
Hallo
Du solltest Dir was Neues suchen.
seitdem das hier so thematisiert wurde - und mein jetziges Script nur unter PHP 5.3 läuft und wenn ich auf PHP 5.4 aktualisiere (bei meinem Anbieter) nicht mehr, suche ich schon nach einem neuen Script.
Aber scheinbar gibt es sowas nicht (oder ich bin zu doof zu suchen :) )...Kann doch nicht sein, daß ich der einzige bin, der über PHP eine SQL-Datenbank auswerten will?!
Oh, das machen viele. Viele machen das aber nicht mit einem offensichtlich seit Jahren nicht gepflegten Script. Es gibt dafür drei mögliche Lösungen.
1. Du suchst dir ein neues Skript. Es ist aber nicht sehr wahrscheinlich, dass du eines findest, das deine vorhandenen Datenstrukturen nutzen kann.
2. Du suchst dir jemanden, der PHP-Skripte lesen und überarbeiten kann. Das kann evtl. Geld kosten, Zeit sowieso.
3. Du schaffst dir die notwendigen PHP-Kenntnisse drauf. Das dauerst erfahrungsgemäß am längsten. Etwas dazuzulernen hat aber noch nie geschadet, auch wenn es nicht einfach ist. Wenn du das willst, wird dir hier gerne geholfen dir selbst zu helfen. Die Aufgabenstellung, mit dem abgeschalteten register_globals umzugehen, ist überschaubar. Das heißt nicht, dass das Skript nicht hunderte Fallen bereithalten kann und vermutlich auch wird.
Tschö, Auge
Hi,
- Du suchst dir ein neues Skript. Es ist aber nicht sehr wahrscheinlich, dass du eines findest, das deine vorhandenen Datenstrukturen nutzen kann.
naja, ich habe ja nicht wirklich eine exotische Datenbank.
4-6 Spalten, nach denen man sortieren können sollte.
Das Script an sich läuft ja perfekt, nur die globalen Variablen sind das Problem. Eigentlich müßte man "nur" die entsprechenden Bereiche, in denen globale Variablen verwendet werden, entsprechend ersetzt:
if(!ini_get('register_globals')){
$__am = array('COOKIE','POST','GET');
while(list(,$__m) = each($__am)){
$__ah = &${"HTTP_".$__m."_VARS"};
if(!is_array($__ah)) continue;
while(list($__n, $__v) = each ($__ah)) $$__n = $__v;
}
}
function edit_db($edit_flag)
{
global $datenbank_entry, $datenbank_field, $datenbank_mysql_host, $datenbank_mysql_username, $datenbank_mysql_password, $datenbank_mysql_db, $datenbank_mysql_table;
global $phpdatenbank_version, $phpdatenbank_pwd_1, $SCRIPT_NAME;
if ($edit_flag == "edit")
{
//MySQL query: connect and retrieve datenbank count
$datenbank_connect_string = @mysql_connect($datenbank_mysql_host, $datenbank_mysql_username, $datenbank_mysql_password) or die ("Could not connect to the database.");
$datenbank_query_string = "SELECT " . $datenbank_field[2][1] . ", " . $datenbank_field[2][2] . ", " . $datenbank_field[2][3] . ", " . $datenbank_field[2][4] . ", " . $datenbank_field[2][5] . ", " . $datenbank_field[2][6] . " FROM " . $datenbank_mysql_table . " WHERE " . $datenbank_field[2][2] . "=\"" . $datenbank_entry . "\" LIMIT 1";
$datenbank_result = @mysql_db_query($datenbank_mysql_db, $datenbank_query_string) or die ("Invalid query (result)");
$datenbank_row = @mysql_fetch_array($datenbank_result);
}
function update_db($update_flag)
{
global $datenbank_field, $datenbank_entry, $datenbank_mysql_host, $datenbank_mysql_username, $datenbank_mysql_password, $datenbank_mysql_db, $datenbank_mysql_table;
global $datenbank_index_url, $SCRIPT_NAME, $phpdatenbank_version, $datenbank_edit_password, $datenbank_form_password;
global $edit_field1, $edit_field2, $edit_field3, $edit_field4, $edit_field5, $edit_field6;
// Verify password
if ($datenbank_form_password == $datenbank_edit_password)
{
// Password is ok, save it in a cookie and authorize
setcookie("phpdatenbank_pwd_1", $datenbank_form_password, time()+31539000);
$datenbank_auth = 1;
}
else
{
// Wrong password, clear the cookie and do not authorize
setcookie("phpdatenbank_pwd_1");
$datenbank_auth = 0;
}
Hm....
Gruß
JPL
Hallo,
Das Script an sich läuft ja perfekt, nur die globalen Variablen sind das Problem.
Das Script mag den Anschein machen zu laufen - aber früher oder später wird es dir wieder um die Ohren fliegen (spätestens wenn die mysql_*-Funktionen weg sind). Wirf es weg und schreib es neu, ein korrigieren der Fehler kommt einem Neuschreiben gleich. Und unterlass Crosspostings.
Gruß,
Tobias
Hakuna matata!
Vielleicht kann mal jemand genau erklären warum
action=""nicht leer sein darf.
Welche Bedeutung sollte der leere String denn haben? Wenn das Formular an die selbe Addresse geschickt werden soll, dann kann man das action-Attribut weglassen.
Welche Bedeutung sollte der leere String denn haben? Wenn das Formular an die selbe Addresse geschickt werden soll, dann kann man das action-Attribut weglassen.
Sorry ich wusste nicht, dass man es auch so schreiben darf
<form name="form1" method="post">
<input type="submit" name="hallo" value="Senden">
</form>
Laut http://validator.w3.org/check ist es aber valid.
Hallo,
Vielleicht kann mal jemand genau erklären warum
action=""nicht leer sein darf.
Welche Bedeutung sollte der leere String denn haben? Wenn das Formular an die selbe Addresse geschickt werden soll, dann kann man das action-Attribut weglassen.
genau das war AFAIK bis HTML 4.x nicht erlaubt - action war ein Pflichtattribut, durfte aber leer sein. Ein Leerstring galt als URL des aktuellen Dokuments.
Jetzt in HTML 5 ist das gerade andersrum festgelegt - das action-Attribut darf fehlen, aber wenn es angegeben ist, darf es nicht leer sein.
Okay, kann man akzeptieren; der Sinn hinter dieser 180°-Kehrtwende erschließt sich mir aber nicht.
Ciao,
Martin
Hakuna matata!
Wenn das Formular an die selbe Addresse geschickt werden soll, dann kann man das action-Attribut weglassen.
genau das war AFAIK bis HTML 4.x nicht erlaubt - action war ein Pflichtattribut, durfte aber leer sein. Ein Leerstring galt als URL des aktuellen Dokuments.
Aber nur, wenn mit <base> keine andere Adresse angegeben wurde. Wenn man trotz abweichender <base>-Adresse das Formular an die Adresse des aktuellen Dokuments senden wollte, musste man selbige vollständig notieren. (RFC 2396 4.2)
Vielleicht ist das der Grund für die Wende.
Hi,
Vielleicht kann mal jemand genau erklären warum
action=""nicht leer sein darf.Welche Bedeutung sollte der leere String denn haben?
Die Url, an die gesendet wird. Da das Ding weder mit Protokoll, noch mit // für den Server noch mit / für serverrelative Adresse beginnt, eine relative URL (relativ zur aktuellen URL).
Und da keine "Relation" angegeben ist, also genau die aktuelle URL.
Wenn das Formular an die selbe Addresse geschickt werden soll, dann kann man das action-Attribut weglassen.
Das "kann" ist bei HTML5 ein "muß". Warum auch immer man hier die Abwärts-Kompatibilität aufgegeben hat.
cu,
Andreas
Om nah hoo pez nyeetz, MudGuard!
Wenn das Formular an die selbe Addresse geschickt werden soll, dann kann man das action-Attribut weglassen.
Das "kann" ist bei HTML5 ein "muß". Warum auch immer man hier die Abwärts-Kompatibilität aufgegeben hat.
Es funktioniert aber dennoch. Vielleicht hat auch 1UnitedPower den Finger in der Wunde.
Matthias
Hallo
Wenn das Formular an die selbe Addresse geschickt werden soll, dann kann man das action-Attribut weglassen.
Das "kann" ist bei HTML5 ein "muß". Warum auch immer man hier die Abwärts-Kompatibilität aufgegeben hat.
Es funktioniert aber dennoch. Vielleicht hat auch 1UnitedPower den Finger in der Wunde.
Vielleicht tolerieren ja auch die Browserhersteller in ihren Programmen den seit Urzeiten üblichen Fehler, um von Bugmeldungen verschont zu bleiben.
Tschö, Auge
Vielleicht kann mal jemand genau erklären warum
action=""nicht leer sein darf.
Ich habe das irgendwann mal recherchiert. Aber „genau“ ist so eine Sache. :)
In HTML 4.01 ist action="" gültig, weil der Leerstring ein gültiger URI ist. (Hat glaube ich hier auch schon jemand gesagt.)
RFC 2396:
4.2. Same-document References
A URI reference that does not contain a URI is a reference to the
current document. In other words, an empty URI reference within a
document is interpreted as a reference to the start of that document,
and a reference containing only a fragment identifier is a reference
to the identified fragment of that document. Traversal of such a
reference should not result in an additional retrieval action.
However, if the URI reference occurs in a context that is always
intended to result in a new request, as in the case of HTML's FORM
element, then an empty URI reference represents the base URI of the
current document and should be replaced by that URI when transformed
into a request.
Warum ist der Leerstring in HTML5 ungültig?
Ian Hickson:
Because browsers do weird things with an empty action="" attribute.
Zum Beispiel?
Thomas Broyer-2:
Yes, because they're violating the spec too. HTML5 defines the form
submission to violate the RFC 3986 to make it work like IE, FF and
Opera:
http://www.w3.org/TR/html5/forms.html#form-submission-algorithm (step 9)
The comments there (an HTML comment, look at the source of the page) says:
<!-- Don't ask me why. But that's what IE does. It even treats
action="" differently from action=" " or action="#" (the latter
two resolve to the base URL, the first one resolves to the doc
URL). And other browsers concur. It is even required, see e.g.
http://bugs.webkit.org/show_bug.cgi?id=7763
https://bugzilla.mozilla.org/show_bug.cgi?id=297761
-->
Die base URL ist wahrscheinlich das hier:
The document base URL of a Document object is the absolute URL obtained by running these substeps:
If there is no base element that has an href attribute in the Document, then the document base URL is the Document's fallback base URL; abort these steps.
Otherwise, the document base URL is the frozen base URL of the first base element in the Document that has an href attribute, in tree order.
Leute, die diese Spezifikationen entwickeln, haben den besten Job.
Aloha ;)
Danke für die Zusammenfassung!
Das heißt, dass das Verhalten in HTML5 letztendlich deshalb geändert wurde, weil die Browser "mit den Füßen abgestimmt" haben? Nett :D
Wenn wir's grad davon haben - gibt's in HTML5 eigentlich überhaupt noch Pflichtattribute?
Grüße,
RIDER
Om nah hoo pez nyeetz, JPL!
Was ich jetzt nicht verstehe: was könnte der ursprüngliche Autor mit dieser offensichtlich überflüssigen Angabe bezweckt haben?
Du verwendest das DB-Script direkt in der Ressource, die auch aufgerufen wird. Das ist sicherheitstechnisch nicht unbedenklich.
Du solltest es in eine "index.html" o.ä. einbinden und dann ist request_uri nicht leer und liefert dir die Seite, von der aus dein Script aufgerufen wird. Auf dieser möchtest du wieder landen, weil deine PHP-Ressource nicht direkt über den Browser erreichbar sein sollte. Zum Beispiel stehen in einem solchen Script für gewöhnlich Zugangsdaten. Deshalb sollten solche Scripte grundsätzlich außerhalb des document-root liegen.
Zudem hast du so den Vorteil, dass du dasselbe Script von mehreren Seiten aus einbinden kannst, ohne dass es tatsächlich mehrfach vorhanden sein muss. Änderungen brauchst du dann auch nur ein einziges Mal vorzunehmen.
Matthias
Aloha,
Du verwendest das DB-Script direkt in der Ressource, die auch aufgerufen wird. Das ist sicherheitstechnisch nicht unbedenklich.
Du solltest es in eine "index.html" o.ä. einbinden und dann ist request_uri nicht leer und liefert dir die Seite, von der aus dein Script aufgerufen wird. Auf dieser möchtest du wieder landen, weil deine PHP-Ressource nicht direkt über den Browser erreichbar sein sollte. Zum Beispiel stehen in einem solchen Script für gewöhnlich Zugangsdaten. Deshalb sollten solche Scripte grundsätzlich außerhalb des document-root liegen.
das verstehe ich jetzt nicht ganz.
Aktuell rufe ich das Script in einer (im konkreten Beispiel) "software.php" auf - was ist der Unterschied dazu, wenn ich das jetzt in einer "software.html" machen würde?
Gruß,
JPL
Om nah hoo pez nyeetz, JPL!
das verstehe ich jetzt nicht ganz.
Aktuell rufe ich das Script in einer (im konkreten Beispiel) "software.php" auf - was ist der Unterschied dazu, wenn ich das jetzt in einer "software.html" machen würde?
Es ist ein Unterschied, ob die software.php das Skript _ist_ oder ob eine andere Datei das Skript lediglich _aufruft_.
Matthias
Es ist ein Unterschied, ob die software.php das Skript _ist_ oder ob eine andere Datei das Skript lediglich _aufruft_.
Hi,
also direkt in der PHP steht das, was ich weiter unten verlinkt habe. Die Datenbankeinstellungen, also Adresse, Benutzername, Passwort... wird in dieser PHP durch ein "include config.php" eingefügt.
Ist das jetzt Sicher genug - oder sollte ich eine neue Seite machen, in der dann auch das DB-Script durch "include" eingebunden wird?
Gruß
JPL
Aloha ;)
Es ist ein Unterschied, ob die software.php das Skript _ist_ oder ob eine andere Datei das Skript lediglich _aufruft_.
Im Fall, dass beide innerhalb des DocumentRoot liegen ist dieser Unterschied imho aber ziemlich marginal. Wer das Skript zu Gesicht bekommen kann, kann auch das aufrufende Dokument zu Gesicht bekommen und damit die Addresse des Skripts.
Grüße,
RIDER
Om nah hoo pez nyeetz, Camping_RIDER!
Im Fall, dass beide innerhalb des DocumentRoot liegen ist dieser Unterschied imho aber ziemlich marginal.
Ja, quasi null.
Matthias
Hi,
hm, also was bedeutet das denn nun konkret?
Was könnte jemand machen, der direkten Zugriff auf den Ordner hat und die Dateien direkt anschauen kann?
Wenn ich die im Browser ausführe, sieht man ja nur immer das Resultat und abgesehen von der Endung der Seite würde man ja gar nicht wissen, daß dahinter ein PHP-Script steckt...
Gruß
JPL
Om nah hoo pez nyeetz, JPL!
hm, also was bedeutet das denn nun konkret?
Was könnte jemand machen, der direkten Zugriff auf den Ordner hat und die Dateien direkt anschauen kann?
Dein Passwort für deine Datenbank lesen.
Wenn ich die im Browser ausführe, sieht man ja nur immer das Resultat und abgesehen von der Endung der Seite würde man ja gar nicht wissen, daß dahinter ein PHP-Script steckt...
Dein Server liefert für http://www.jochen-lipps.de/amiga/software/config.php einen Status 200. Also weiß ein Angreifer, dass es diese Seite gibt. Hingegen kommt für http://www.jochen-lipps.de/amiga/software/config-x.php ein 404 zurück.
Wenn jetzt aufgrund irgendeines dummen Zufalls der Webserver falsch konfiguriert ist, zum Beispiel weil das jemand ohne ausreichend Ahnung getan hat, liefert der Webserver den Text des php-Skriptes aus. Und in diesem steht möglicherweise dein Datenbankpasswort.
Matthias
Dein Server liefert für http://www.jochen-lipps.de/amiga/software/config.php einen Status 200. Also weiß ein Angreifer, dass es diese Seite gibt. Hingegen kommt für http://www.jochen-lipps.de/amiga/software/config-x.php ein 404 zurück.
Wenn jetzt aufgrund irgendeines dummen Zufalls der Webserver falsch konfiguriert ist, zum Beispiel weil das jemand ohne ausreichend Ahnung getan hat, liefert der Webserver den Text des php-Skriptes aus. Und in diesem steht möglicherweise dein Datenbankpasswort.
Hi,
danke für die Erklärung.
Gruß
JPL
Aloha ;)
hm, also was bedeutet das denn nun konkret?
Konkret heist das imho, dass du im Rahmen des hier Besprochenen schon ausreichend gesichert bist, zumal du ja die Logindaten schon nur includierst.
Imho kein konkreter Handlungsbedarf.
Grüße,
RIDER
Aloha :-)
Konkret heist das imho, dass du im Rahmen des hier Besprochenen schon ausreichend gesichert bist, zumal du ja die Logindaten schon nur includierst.
Imho kein konkreter Handlungsbedarf.
Danke für die Beruhigung :)
Gruß
Jochen
Aloha ;)
Deshalb sollten solche Scripte grundsätzlich außerhalb des document-root liegen.
Sollten, ja. Viele Hoster bieten diese Möglichkeit aber nicht. Und sofern diese Möglichkeit nicht gegeben ist, ist es sicherheitstechnisch ziemlich unrelevant, ob direkt auf das PHP-Skript verlinkt wird, oder nicht. Wenn der Hacker den Server dazu bringen kann, PHP im Klartext auszuliefern, dann ist so oder so einiges im Argen, da ist es dann imho ziemlich egal ob der Hacker die Addresse des Skripts zuvor kannte oder nicht.
Grüße,
RIDER
Aloha ;)
Meine Lösung für dein Problem:
Schau ich mir nun aber die Stelle in meinem Code an, steht dort folgendes:
<form method="get" action="<?php echo $REQUEST_URI; ?>">
Mach daraus:
<form method="get" <?php if ($REQUEST_URI != ''): ?> action="<?php echo $REQUEST_URI; ?>" <?php endif ?> >
Das führt dazu, dass das action-Attribut nur dann überhaupt ausgegeben wird, wenn $REQUEST_URI kein Leerstring ist.
Vorausgesetzt natürlich (wie von Melina angedeutet), $REQUEST_URI ist überhaupt definiert, also irgendwo vorher bspw. durch $REQUEST_URI = $_SERVER['REQUEST_URI']; oder eine ähnliche Anweisung ins Leben gerufen worden...
Falls du letzteres nicht absehen kannst - dann alternativ auch gerne
... <?php if (isset($REQUEST_URI) AND $REQUEST_URI != ''): ?> ...
Lasse ich die action-Angabe ganz weg:
<form method="get">funktioniert das Script auf den ersten Blick genauso.
Ich weiß aber nicht, ob das nicht nur Zufall ist. Von meiner Warte her ist nicht ganz abzusehen, was exakt in $REQUEST_URI drinsteht. An deiner Stelle (da du das PHP-Skript nicht selbst geschrieben hast und daher auch nicht genau weist, was da warum und wie stattfinden soll) würde ich vermeiden, potentiell sinnverändernde Operationen vorzunehmen, indem du $REQUEST_URI austauschst oder gar action generell weglässt. Nimm lieber eine sinnerhaltende wie meine oben gepostete, die trotzdem für deine Zwecke genügt ;)
Was ich jetzt nicht verstehe: was könnte der ursprüngliche Autor mit dieser offensichtlich überflüssigen Angabe bezweckt haben?
Schwierig, das vorherzusagen :D Aber auch schwierig anzunehmen, dass die Angabe tatsächlich in allen Fällen überflüssig ist.
Grüße,
RIDER
Aloha,
danke - mal wieder.
:)
Guß
JPL
Hallo,
als ich mich vorhin mal bei meinem Anbieter eingeloggt habe um zu gucken, ob man PHP-Scripte vielleicht "auslagern" kann, dass die nicht im gleichen Ordner wie die aufgerufene Datei liegen, habe ich gesehen, dass aktuell die PHP-Version 5.3 aktiv war und man wahlweise bis zu PHP 5.6 "updaten" kann.
Habe das auch mal gemacht, PHP 5.6 - mit dem Resultat, dass mein DB-Script nicht mehr funktionert hat. Ich konnte zwar noch auf die Spaltenüberschriften klicken, mit denen man normalerweise ja die Spalten anders sortieren kann, und die Seite wurde auch neu geladen und in der Adresszeile waren auch die ganzen angefügten Adressbestandteile zu sehen:
http://www.jochen-lipps.de/amiga/software/software.php?amiga_search=&amiga_search_type=&amiga_max_results=all&amiga_sort=1a&amiga_search_results=
Aber das Resultat war gleich null, es wurde nichts sortiert, ich konnte auch nicht mehr nach Begriffen suchen etc.
Erst als ich jetzt wieder auf PHP 5.3 zurückgestellt habe, ging es wieder.
Gibt es zwischen 5.3 und 5.6 wirklich so ein Unterschied, dass es andere Befehle gibt?
Oder was könnte dafür der Grund sein?
Gruß
JPL
Hakuna matata!
Gibt es zwischen 5.3 und 5.6 wirklich so ein Unterschied, dass es andere Befehle gibt?
Oder was könnte dafür der Grund sein?
Aber sicher, sonst wäre ein Versionssprung ja zimelich witzlos. Im PHP Manual wird zu jeder PHP-Version immer auch ein Update-Guide zur Verfügung gestellt. Darin befindet sich immer eine Sektion "Backwards incompatible changes".
Weil du gleich drei Versionssprünge machst, sind für dich diese drei Abschnitte besonders relevant:
http://php.net/manual/en/migration54.incompatible.php
http://php.net/manual/en/migration55.incompatible.php
http://php.net/manual/en/migration56.incompatible.php
Eine Gesamtübersicht gibt es auch:
http://php.net/manual/en/appendices.php
Hi,
Weil du gleich drei Versionssprünge machst, sind für dich diese drei Abschnitte besonders relevant:
http://php.net/manual/en/migration54.incompatible.php
http://php.net/manual/en/migration55.incompatible.php
http://php.net/manual/en/migration56.incompatible.phpEine Gesamtübersicht gibt es auch:
http://php.net/manual/en/appendices.php
danke für die Info.
Ich versteh zwar nicht viel von PHP, aber ich werde mir das mal antun und gucken, ob Befehle betroffen sind, die "mein" Script verwendet.
Gruß
JPL