• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Cronjob für PHP Script absichern

  • Thread starter Deleted member 13046
  • Start date
D

Deleted member 13046

Guest
Hallo
ich hab ein Session basierendes Script, welches ich bisher manuell (via login) ausführe. Nun möchte ich dieses aber per Cronjob erledigen lassen.
Da ich das Script per Session abgesichert gab müsste ich diese Session ja dazu wegnehmen um es als Cronjob laufen zu lassen. Dann könnte das aber jeder ausführen was ich natürlich nicht möchte.

Welche Mechanismen gibt es dazu, um ein CronJob auf ein php Script etwas sicher zu gestalten? Übergabe von Parametern? Oder was gibts da so?

Vielleicht hat auch einer ein Beispiel oder ein URL zu einem Beispiel.

Besten Dank
Gruß Haxley
 
Ich nehme an du meinst mit Cronjob ein wget-Aufruf des Skriptes. Es gäbe mehrere Möglichkeiten zur Realisierung

a) das Skript direkt über die PHP Kommandozeile aufrufen und im Skript überprüfen ob dies der Fall ist und dann die Sicherheitsprüfung deaktivieren.

b) dem Skript einen festen Token vergeben welcher für Cronjobs als GET-Parameter übergeben wird. Über if/else bei Angabe des Tokens die Session-Validierung überspringen oder fälschen (je nachdem was einfacher ist)

c) Das Loginsystem abändern so dass jede Seite Benutzername und Passwort akzeptiert und dann im Cronjob die Zugangsdaten mit angeben.

d) (Nicht empfohlen) Mittels curl eine korrekte Login-Session aufbauen und dann die Aktion als eingeloggter User durchführen.
 
b) dem Skript einen festen Token vergeben welcher für Cronjobs als GET-Parameter übergeben wird. Über if/else bei Angabe des Tokens die Session-Validierung überspringen oder fälschen (je nachdem was einfacher ist)

Ich würde b) nehmen. In der WebApp im Admininterface einen Tokengenerator einbauen. Nur die benötigten Aktionen via Token zulassen. Am besten via REST-API vernünftig mit GET, POST, CREATE, UPDATE, ... usw. realisieren.

Sollte das Script auf einem anderen Server laufen, dann sollte die Kommunikation ausschließlich via https stattfinden. Das verringert die statistische Wahrscheinlichkeit eines mitm Angriffs.

Durch das Konzept ist es auch möglich dem Script mal eben im Webinterface durch eine neue Token den Zugriff zu entziehen.

Einfach mal bei Google, Facebook und co nachschauen. Die nutzen alle das Verfahren für API-Zugriffe. Was anderes machst du ja auch nicht. Auf eine API zugreifen, um zu einem bestimmten Zeitpunkt eine bestimmte Aufgabe zu erledigen. Userlogins + Passwörter sollte man bei API-Zugriffen tunlichst vermeiden.
 
Last edited by a moderator:
Ich hätte noch ein:

e) In der Session-Prüfung eine Ausnahme für Requests von Localhost (127.0.0.1 || ::1) hinzufügen.


Ich bin prinzipiell ein Fan von a) und nutze i.d.R. ein eigenes CLI-Starter-Script, welches ausserhalb vom DocumentRoot liegt.

huschi.
 
Back
Top