+Ajax, Sicher machen

[SteBu]

Moin Forum,

mal eine Frage. Um Includes(PHP) vor dem direktem Aufruf zu schützen, nutze ich ich eine Konstante, die in der "äußeren" Datei definiert wird und demzufolge im Include abgefragt werden kann.
Aber wie macht ihr das bei den serverseitigen Scripten die über Ajax angesprochen werden? Gibs da eine schnelle und einfache Lösung(außer SESSION)?

Gruß aus dem Glutofen Berlin
SteBu

[dedlfix]

echo $begrüßung;

Um Includes(PHP) vor dem direktem Aufruf zu schützen, nutze ich ich eine Konstante, die in der "äußeren" Datei definiert wird und demzufolge im Include abgefragt werden kann.

Um Dateien vor einem dierekten Ausliefern durch den Webserver zu schützen lege ich sie außerhalb des DocumentRoots ab. Mein Provider gestattet es, das DocumentRoot für jede einzelne Domain in ein beliebiges Unterverzeichnis des mir zugewiesenen Verzeichnisses zu legen.

Aber wie macht ihr das bei den serverseitigen Scripten die über Ajax angesprochen werden? Gibs da eine schnelle und einfache Lösung(außer SESSION)?

Für den Server ist die AJAX-Geschichte irrelevant. Er bekommt lediglich einen Request und arbeitet diesen ab. Es gibt keinen relevanten Unterschied zwischen einem AJAX-Request und einem "normalen" Request.

echo "$verabschiedung $name";

[SteBu]

Für den Server ist die AJAX-Geschichte irrelevant. Er bekommt lediglich einen Request und arbeitet diesen ab. Es gibt keinen relevanten Unterschied zwischen einem AJAX-Request und einem "normalen" Request.

Für den Request mag das stimmen, doch ist die Problematik eine andere. Die includierte Datei kennt ja die Konstante. Ein File, welches da einfach nur "rumlungert" und den Request verarbeiten soll jedoch nicht. Daher greift die Methode da nicht.

SteBu

[wahsaga]

hi,

Für den Request mag das stimmen, doch ist die Problematik eine andere. Die includierte Datei kennt ja die Konstante. Ein File, welches da einfach nur "rumlungert" und den Request verarbeiten soll jedoch nicht. Daher greift die Methode da nicht.

Du redest wirr.

Ein per AJAX ausgeführter Request unterscheidet sich m.E. für deinen Server kein bisschen von einem "normalen".

Also entweder wirkt dein "Sicherungsmechanismus" generell, oder er ist generell für die Tonne.

gruß,
wahsaga

[SteBu]

Du redest wirr.

Nein, wir reden nur aneinander vorbei.

Bsp. zum Verständnis.

Datei a.php ist ein Include von index.php
In index.php steht "define('RUN', true);"
in a.php schaue ich dann nach:
if(defined('RUN'))
{
//mach was
}
else
{
//ne geht nicht
}

Datei b.php sei nun ein Script, welches einen Request von index.php verarbeiten soll(AJAX).
Wie hindere ich nun jemenden drann die Datei b.php direkt aufzurufen?

Ich hoffe es ist jetzt klarer.

Gruß
SteBu

[wahsaga]

hi,

Datei b.php sei nun ein Script, welches einen Request von index.php verarbeiten soll(AJAX).
Wie hindere ich nun jemenden drann die Datei b.php direkt aufzurufen?

OK, also hat das mit dem ganzen Konstanten-Kram gar nichts zu tun.

Womit wir wieder dabei wären, dass ein AJAX-Request sich durch nichts von einem "normalen" unterscheidet.

Entweder willst du also keinen von beiden zulassen, oder beide.

Du kannst natürlich beim AJAX-Request bspw. einen zusätzlichen GET-Parameter mitgeben, und in b.php auf diesen prüfen - aber der lässt sich natürlich auch bei jedem sonstigen Aufruf mitgeben, "Sicherheit" bringt das also keine.

Ebenfalls möglich wäre es, den AJAX-Request einen zusätzlichen HTTP-Request-Header generieren zu lassen (als selbstdefinierten natürlich mit "X-" beginnend), und auf diesen zu prüfen. Das habe ich mal erwogen, um AJAX-Requests von "normalen" halbwegs zuverlässig unterscheiden zu können. Habe es dann aber wieder verworfen, weil ich vermute, das zu viele "Personal Firewalls" und Proxies im Einsatz sind, die solche zusätzlichen Header auf Grund von Paranoia oder schlicht Blöd^WUnwissenheit blocken könnten.

Fazit: Wenn es der Sicherheit deiner Applikation einen Abbruch tut, wenn du nicht genau feststellen kannst, "woher" ein Request kommt, dann hast du m.E. beim Design etwas verkehrt gemacht.
Wenn lediglich die Befürchtung besteht, der Nutzer könnte für ihn unverständliche Daten geliefert bekommen, wenn eine Ressource anders als vorgesehen aufgerufen wird - nun, dass ist das Problem des Nutzers.

gruß,
wahsaga

[SteBu]

OK, also hat das mit dem ganzen Konstanten-Kram gar nichts zu tun.

So ist es. Das war nur am Rande bemerkt.

Fazit: Wenn es der Sicherheit deiner Applikation einen Abbruch tut, wenn du nicht genau feststellen kannst, "woher" ein Request kommt, dann hast du m.E. beim Design etwas verkehrt gemacht.

Das ist nicht so. Der Ajax-Teil soll nur einer leichteren Bedienbarkeit dienen. Die komplette Anwendung würde auch ohne laufen. Nur halt ein paar nette Features wären nicht da.

Wenn lediglich die Befürchtung besteht, der Nutzer könnte für ihn unverständliche Daten geliefert bekommen, wenn eine Ressource anders als vorgesehen aufgerufen wird - nun, dass ist das Problem des Nutzers.

So kann man es auch sehen. Werde ich dan mal für mich adaptieren die Einstellung.

Gruß
SteBu

[Michael S.]

Spätestens seit der PISA-Studie glauben wir doch alle dran, was uns früher schon beigebracht wurde: man soll immer mit der denkbar unintelligentesten Aktion des Benutzers rechnen.

Würdest dus auch in einem Programm mit GUI so machen?
"Tja.. wenn der Benutzer so blöd ist und nen Fehler verursacht isser selber Schuld. Schlimmstenfalls isses eben ein bluescreen..."

gruß
Micha

[wahsaga]

hi,

Würdest dus auch in einem Programm mit GUI so machen?
"Tja.. wenn der Benutzer so blöd ist und nen Fehler verursacht isser selber Schuld. Schlimmstenfalls isses eben ein bluescreen..."

URLs, die im Javascript-Code für AJAX-Requests benutzt werden, ruft m.E. kein Benutzer "zufällig" über die Adresszeile seines Browsers auf.

gruß,
wahsaga

[Michael S.]

s.o.
"die Wege des Anwenders sind unergründlich".

Nur weil du weisst, dass niemand freiwillig vom Balkon springt, heissts noch nicht, dass du das Geländer weglassen kannst...

mfg
Micha

[dedlfix]

echo $begrüßung;

Datei b.php sei nun ein Script, welches einen Request von index.php verarbeiten soll(AJAX).
Wie hindere ich nun jemenden drann die Datei b.php direkt aufzurufen?

Die Antwort auf diese Frage hast du, wenn du weißt, wie du einen sauberen, AJAX-gewaschenen Request von einem "normalen" Request unterscheidest.

Meines Wissens ist das praktisch nicht oder nicht zuverlässig möglich. Oder sendet ein AJAX-Request ein Identifikationsmerkmal mit? Vielleicht kannst du ihm ja etwas mitgeben (vielleicht eine Headerzeile), die ein "normaler" Request normalerweise nicht mitsendet.

Aber warum möchtest du das Direktaufrufen verhindern? Du lieferst ja die Daten an den Client aus, der damit machen kann, was er will. Warum soll man sich die Daten nicht auch "direkt" in der Form ansehen dürfen, in der sie dein Script ausliefert?

echo "$verabschiedung $name";

[SteBu]

Moin,

Aber warum möchtest du das Direktaufrufen verhindern? Du lieferst ja die Daten an den Client aus, der damit machen kann, was er will. Warum soll man sich die Daten nicht auch "direkt" in der Form ansehen dürfen, in der sie dein Script ausliefert?

Zum einen, weil einige davon sowieso nix ausliefern(diese Steuern nur einige Sessionvariablen) und zum anderen weil es die Sache natürlich einfacher machen würde.
Wenn ich davon ausgehen könnte, dass nur Daten an die serverseitigen Scripte kommen die ich "kenne/festlege"(im Sinne von DB-Abfragen) könnte ich mir etwas Prüfungsarbeit beim verarbeiten dieser sparen ;-).
Faulheit halt.

SteBu

[wahsaga]

hi,

Wenn ich davon ausgehen könnte, dass nur Daten an die serverseitigen Scripte kommen die ich "kenne/festlege"(im Sinne von DB-Abfragen) könnte ich mir etwas Prüfungsarbeit beim verarbeiten dieser sparen ;-).

Welche Unterschied macht es dabei, ob der Request "per AJAX" oder "normal per Adresszeile" reinkommt?

Beides kann am Client beliebig manipuliert worden sein - die Prüfung der Eingabedaten ist also in jedem Fall unerlässlich.

gruß,
wahsaga

[Siechfred]

Hell-O!

Es gibt keinen relevanten Unterschied zwischen einem AJAX-Request und einem "normalen" Request.

Doch, der AJAX-Request ist mit Abstand der sauberste.

Siech*SCNR*fred

[Cybaer]

Hi,

Um Includes(PHP) vor dem direktem Aufruf zu schützen, nutze ich ich eine Konstante, die in der "äußeren" Datei definiert wird und demzufolge im Include abgefragt werden kann.

Und ich verlgeiche __FILE__ mit $_SERVER['SCRIPT_FILENAME'] - da muß dann nichts definiert werden.

Gruß, Cybaer

[dedlfix]

echo $begrüßung;

Und ich verlgeiche __FILE__ mit $_SERVER['SCRIPT_FILENAME'] - da muß dann nichts definiert werden.

Für einen nicht sicherheitsrelevanten Zweck hatte ich das auch mal so verwendet. Bis der Provider meinte, seine Verzeichnisstruktur ändern zu müssen, und um rückwärtskompatibel zu sein, einen Symlink verwendete. Ungefähr so:
/kunden/homepages/... war dann das physische Verzeichnis.
/homepages war ein Symlink auf /kunden/homepages
PHP bekam den /homepages-Pfad mit auf den Weg und $_SERVER['SCRIPT_FILENAME'] zeigte brav /homepages/... an. Aber __FILE__ löste den Symlink auf und verwies auf /kunden/homepages/...

Doch das nur als kleine Episode am Rande.

echo "$verabschiedung $name";

[wahsaga]

hi,

PHP bekam den /homepages-Pfad mit auf den Weg und $_SERVER['SCRIPT_FILENAME'] zeigte brav /homepages/... an. Aber __FILE__ löste den Symlink auf und verwies auf /kunden/homepages/...

realpath() hätte den Symlink auflösen können ;-)

gruß,
wahsaga

[Cybaer]

Hi,

realpath() hätte den Symlink auflösen können ;-)

Yep! Das ist auch wichtig, wenn das Script auf einem Windows-Server läuft, um die unterschiedlichen Pfadtrenner anzupassen!

Meine Funktion, die ich benutze, wenn ich meine Basis-Lib eingebunden habe (was de facto immer der Fall ist ;-)):

/* Script eingebunden oder selbst aufgerufen? 060112 */
function is_inc($FILE) {
 // Als Parameter ist __FILE__ zu uebergeben!
 return realpath($_SERVER['SCRIPT_FILENAME'])!=realpath($FILE);
}

Und dann, wo auch immer, z.B. ein: if(!is_inc(__FILE__)) { echo 'Not standalone!'; die; }

Gruß, Cybaer

[Cybaer]

Hi,

Bis der Provider meinte, seine Verzeichnisstruktur ändern zu müssen, und um rückwärtskompatibel zu sein, einen Symlink verwendete.

Ach, du meinst 1&1? ;-)

Gruß, Cybaer

[wahsaga]

hi,

Bis der Provider meinte, seine Verzeichnisstruktur ändern zu müssen, und um rückwärtskompatibel zu sein, einen Symlink verwendete.

Ach, du meinst 1&1? ;-)

<wort class="gefluegelt">
1und1 ergibt nicht zwei - sondern nur Probleme ...
</wort>

gruß,
wahsaga

[Cybaer]

Hi,

<wort class="gefluegelt">
1und1 ergibt nicht zwei - sondern nur Probleme ...
</wort>

Das kommt mir vor, wie ein Verleumdung aus dem Schlund des Partners (schenkelklopf ;-))!

Gruß, Cybaer