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 ] |
Mit Setzen einer Variable in der Mutter, mit isset() in den Töchtern |
|
0% |
[ 0 ] |
Mit setzen einer Variable in der Mutter, mit if Wert = in den Töchtern |
|
0% |
[ 0 ] |
Mittels Include Ordnern die ausserhalb des public folders liegen |
|
62% |
[ 5 ] |
Eine Andere Methode die ich ausgeheckt habe und demnach geheim ist |
|
0% |
[ 0 ] |
Ich erkenne das Problem nicht bzw. habe mir darüber noch nie Gedanken gemacht. |
|
37% |
[ 3 ] |
Mit einer anderen Methode die ich hier vorstelle (oder auch nicht) |
|
0% |
[ 0 ] |
|
Stimmen insgesamt : 8 |
|
RNK
Threadersteller
Dabei seit: 06.06.2005
Ort: -
Alter: -
Geschlecht:
|
Verfasst Di 18.05.2010 21:19
Titel PHP - Dateien vor Aufruf schützen (+ Umfrage) |
|
|
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
|
|
|
|
|
safer-print
Dabei seit: 11.03.2010
Ort: -
Alter: -
Geschlecht:
|
Verfasst Di 18.05.2010 22:40
Titel
|
|
|
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.
|
|
|
|
|
Anzeige
|
|
|
RNK
Threadersteller
Dabei seit: 06.06.2005
Ort: -
Alter: -
Geschlecht:
|
Verfasst Di 18.05.2010 23:06
Titel
|
|
|
(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.
|
|
|
|
|
safer-print
Dabei seit: 11.03.2010
Ort: -
Alter: -
Geschlecht:
|
Verfasst Di 18.05.2010 23:14
Titel
|
|
|
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.
|
|
|
|
|
RNK
Threadersteller
Dabei seit: 06.06.2005
Ort: -
Alter: -
Geschlecht:
|
Verfasst Mi 19.05.2010 00:02
Titel
|
|
|
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.
|
|
|
|
|
Eistee
Administrator
Dabei seit: 31.10.2001
Ort: Grimma
Alter: 45
Geschlecht:
|
Verfasst Mi 19.05.2010 06:04
Titel
|
|
|
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. |
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.
|
|
|
|
|
pRiMUS
Dabei seit: 09.09.2003
Ort: Vienna
Alter: 48
Geschlecht:
|
Verfasst Mi 19.05.2010 08:52
Titel
|
|
|
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. |
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.
|
|
|
|
|
bacon
Dabei seit: 24.10.2007
Ort: -
Alter: -
Geschlecht: -
|
Verfasst Mi 19.05.2010 10:24
Titel
|
|
|
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 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
|
|
|
|
|
|
|
|
Ä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
|
|