mediengestalter.info
FAQ :: Mitgliederliste :: MGi Team

Willkommen auf dem Portal für Mediengestalter

Aktuelles Datum und Uhrzeit: Do 28.03.2024 23:23 Benutzername: Passwort: Auto-Login

Thema: PHP - Dateien vor Aufruf schützen (+ Umfrage) vom 18.05.2010


Neues Thema eröffnen   Neue Antwort erstellen MGi Foren-Übersicht -> Programmierung -> PHP - Dateien vor Aufruf schützen (+ Umfrage)
Autor Nachricht
Wie schützt ihr relevante PHP Dateien vor ext. Zugriff (Name und ggf. Ort der Datei bekannt)
Mit define() einer Konstante in der Mutter, mit isset() in allen Töchtern
0%
 0%  [ 0 ]
Mit Setzen einer Variable in der Mutter, mit isset() in den Töchtern
0%
 0%  [ 0 ]
Mit setzen einer Variable in der Mutter, mit if Wert = in den Töchtern
0%
 0%  [ 0 ]
Mittels Include Ordnern die ausserhalb des public folders liegen
62%
 62%  [ 5 ]
Eine Andere Methode die ich ausgeheckt habe und demnach geheim ist
0%
 0%  [ 0 ]
Ich erkenne das Problem nicht bzw. habe mir darüber noch nie Gedanken gemacht.
37%
 37%  [ 3 ]
Mit einer anderen Methode die ich hier vorstelle (oder auch nicht)
0%
 0%  [ 0 ]
Stimmen insgesamt : 8

RNK
Threadersteller

Dabei seit: 06.06.2005
Ort: -
Alter: -
Geschlecht: Männlich
Verfasst Di 18.05.2010 21:19
Titel

PHP - Dateien vor Aufruf schützen (+ Umfrage)

Antworten mit Zitat Zum Seitenanfang

Hallo PHPler,

ich sinniere darüber was wohl die geeignetste Vorgehensweise ist, seine php-Dateien vor externem Aufruf zu schützen. Das betrifft includes, config-Dateien, postprocessing Dateien und Seiten allgemein etc. Um Verzeichnisschutz geht es hier nicht.

Dies betrifft handgeschriebenen Code, also kein Framework a la Zend. Gerade post processing PHP Dateien (also form targets, per AJAX targets usw. die u.a. SQL Zugriffe haben, dürfen nicht von extern aufgerufen werden können.

Eine Recherche ergibt mehrere Varianten. Welche guten Varianten fehlen hier ggf., welche Varianten bevorzugt ihr?
Die Bennung mittels .inc. als alleinigen Schutz zähle ich garnicht erst auf.

Weiterhin würde mich interessieren, wie ihr die Sicherheitslage hierbei bewertet: Ein Ajax-Request mit einem Post target ist Bestandteil einer function. Diese steht ja in Klartext beim Client. Wie lässt sich denn der Aufruff einer externen PHP Datei (die z.B. SQL Manipulation hat) verhindern wenn doch das javascript vom client aus genau dies tun muss?


ps. Den Schutz der Mutter, z.B. index.php lässt sich ja gut realiseren durch die $_SERVER Variablen.


Zuletzt bearbeitet von RNK am Di 18.05.2010 21:20, insgesamt 1-mal bearbeitet
  View user's profile Private Nachricht senden
safer-print

Dabei seit: 11.03.2010
Ort: -
Alter: -
Geschlecht: Männlich
Verfasst Di 18.05.2010 22:40
Titel

Antworten mit Zitat Zum Seitenanfang

Zitat:
Ein Ajax-Request mit einem Post target ist Bestandteil einer function. Diese steht ja in Klartext beim Client. Wie lässt sich denn der Aufruff einer externen PHP Datei (die z.B. SQL Manipulation hat) verhindern wenn doch das javascript vom client aus genau dies tun muss?

Wie wäre mit mod_rewrite bei der zusätzliche GET-Parameter übergeben werden. Sind diese nicht vorhanden bricht das Skript ab. z.B so:
Code:
RewriteEngine On
RewriteRule ^meinskript$ ../anderer_ordner/meinskript.php?secure=langespasswort  [NC,QSA,L]

Im Skript wird dann $_GET['secure'] auf 'langespasswort' geprüft. 'anderer_ordner' darf allerdings nicht mit htaccess lesegeschützt sein, sonst funktioniert das nicht. Ein direkter Aufruf kann dadurch zuverlässig verhindert werden.
  View user's profile Private Nachricht senden Website dieses Benutzers besuchen
Anzeige
Anzeige
RNK
Threadersteller

Dabei seit: 06.06.2005
Ort: -
Alter: -
Geschlecht: Männlich
Verfasst Di 18.05.2010 23:06
Titel

Antworten mit Zitat Zum Seitenanfang

(Betreff: unsicherer Ajax-Call vs. mod_rewrite) Das wird nicht funktionieren. Wenn ein Angreifer sich meinen AJAX Call anschaut (der liegt ja quasi beim Angreifer im Browser) .. baut er sich einfach einen eigenen Call von seiner Domain aus. mod_rewrite wird dann auch diesem Call die get-Variable anhängen, der Zugriff wäre damit erlaubt.

Ich glaube langsam, das ist allgemein ein riesengroßes Sicherheitsproblem von Ajax.
  View user's profile Private Nachricht senden
safer-print

Dabei seit: 11.03.2010
Ort: -
Alter: -
Geschlecht: Männlich
Verfasst Di 18.05.2010 23:14
Titel

Antworten mit Zitat Zum Seitenanfang

Verstehe ich das richtig: du willst sicherstellen, das ein Aufruf ausschließlich per Ajax gemacht werden kann? Dann musst du mir erklären warum? Vom Benutzer übergebene Parameter müssen immer überprüft werden – egal woher sie kommen.
  View user's profile Private Nachricht senden Website dieses Benutzers besuchen
RNK
Threadersteller

Dabei seit: 06.06.2005
Ort: -
Alter: -
Geschlecht: Männlich
Verfasst Mi 19.05.2010 00:02
Titel

Antworten mit Zitat Zum Seitenanfang

Ich möchte u.a. sicherstellen können, dass keiner Missbrauch betreibt mit einer sqldelete.php?id=4 (stark vereinfachtes Beispiel) ...was so recht einfach vom ajax call abzulesen ist. Auch <form target="sqldelete.php"> (entsprechend) ist doch total unsicher.
  View user's profile Private Nachricht senden
Eistee
Administrator

Dabei seit: 31.10.2001
Ort: Grimma
Alter: 45
Geschlecht: Männlich
Verfasst Mi 19.05.2010 06:04
Titel

Antworten mit Zitat Zum Seitenanfang

RNK hat geschrieben:
Ich möchte u.a. sicherstellen können, dass keiner Missbrauch betreibt mit einer sqldelete.php?id=4 (stark vereinfachtes Beispiel) ...was so recht einfach vom ajax call abzulesen ist. Auch <form target="sqldelete.php"> (entsprechend) ist doch total unsicher.


Hä? Hä? Hä?

Dafür hat man doch IN der sqldelete.php einen entsprechenden Authentifizierung-Modus (Session+Rechteprüfung o.ä.). dann ist es völlig egal wie das Script von aussen aufgerufen wird.
  View user's profile Private Nachricht senden Website dieses Benutzers besuchen
pRiMUS

Dabei seit: 09.09.2003
Ort: Vienna
Alter: 48
Geschlecht: Männlich
Verfasst Mi 19.05.2010 08:52
Titel

Antworten mit Zitat Zum Seitenanfang

Eistee hat geschrieben:
RNK hat geschrieben:
Ich möchte u.a. sicherstellen können, dass keiner Missbrauch betreibt mit einer sqldelete.php?id=4 (stark vereinfachtes Beispiel) ...was so recht einfach vom ajax call abzulesen ist. Auch <form target="sqldelete.php"> (entsprechend) ist doch total unsicher.


Hä? Hä? Hä?

Dafür hat man doch IN der sqldelete.php einen entsprechenden Authentifizierung-Modus (Session+Rechteprüfung o.ä.). dann ist es völlig egal wie das Script von aussen aufgerufen wird.


ich verstehe das problem auch nicht. für mich siehts nach einem designfehler aus.
  View user's profile Private Nachricht senden Website dieses Benutzers besuchen
bacon

Dabei seit: 24.10.2007
Ort: -
Alter: -
Geschlecht: -
Verfasst Mi 19.05.2010 10:24
Titel

Antworten mit Zitat Zum Seitenanfang

Zitat:
Ein Ajax-Request mit einem Post target ist Bestandteil einer function. Diese steht ja in Klartext beim Client. Wie lässt sich denn der Aufruff einer externen PHP Datei (die z.B. SQL Manipulation hat) verhindern wenn doch das javascript vom client aus genau dies tun muss?


Die meisten MVC-Frameworks stellen eine Methode RequestObject::isXmlHttpRequest() zur Verfügung. Guck' da mal rein Lächel Im Grunde wird nur ein Custom-HTTP-Header mitgeschickt. Per Konvention benutzen die meisten Javascript-Frameworks denselben, nämlich "X-Requested-With: XMLHttpRequest".

Zend sagt:
Zitat:
Die meisten AJAX Bibliotheken erlauben das Senden von eigenen HTTP Anfrageheadern; wenn die eigene Bibliothek diesen Header nicht sendet, muß dieser einfach beim Anfrageheader hinzugefügt werden um sicherzustellen das die isXmlHttpRequest() Methode funktioniert.


Trotzdem sollte man niemals Clientseitig schützen, denn Http-Header können ja nach Gusto manipuliert werden. Man verwendet diese Krücke aber gerne, um Front-Controller bspw. je nach "Art" des Requests mit oder ohne Layout auszuliefern (Sprich mit <html><head>... oder ohne).

Der beste Schutz gegen Sql-Manipulation in diversen PHP-Dateien ist, nur eine PHP-Datei als Front-Controller pro Anwendung zu verwenden. Diese ist dann die einzige, die den (parametrisierten) Request entgegen nimmt und delegiert). Und seinen Code ansonsten in PHP-Klassen zu kapseln.

Denn: Hast du nur einen Front-Controller, hast du weniger zu überwachen. Und wenn jemand eine Datei mit einer PHP-Klasse direkt aufruft, sieht er erstmal nichts. Und kann damit auch keinen Schaden anrichten. Der Tod der Anwendung ist eben prozeduraler Mistcode - daher mache ich auch jedes CMS und jede Blogsoftware o.Ä., die auch nur im Ansatz irgend einen Mist wie if( ! defined('SUPERCMS_DATEI')) die('Access denied') irgendwo stehen hat, direkt wieder zu - denn dann weiß ich, dass ich es eben mit prozeduralem Mistcode zu tun habe, dem die eigenen Entwickler augenscheinlich nicht trauen.


Zuletzt bearbeitet von bacon am Mi 19.05.2010 10:25, insgesamt 1-mal bearbeitet
  View user's profile Private Nachricht senden
 
Ähnliche Themen Direktor Aufruf abwarten, aber wie erstelle ich einen Aufruf
Dateien in CGI-bin per Passwort schützen?
Umfrage-Tool für PDF-Dateien
Seitenaktualisierung bei Aufruf
Fomular: unerwünschter Aufruf der Bestätigungsseite
Browserfenster bei url aufruf automatisch breite anpassen
Neues Thema eröffnen   Neue Antwort erstellen
MGi Foren-Übersicht -> Programmierung


Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst an Umfragen in diesem Forum nicht mitmachen.