3rdparty apps / Zugriff absichern

GNaschenweng

Benutzer
Mitglied seit
18. Jul 2008
Beiträge
7
Punkte für Reaktionen
0
Punkte
0
Ich habe mir nun ein paar der 3rd party-apps (cronjobs, vnstat) eingebunden, kann diese aber auch ohne angemeldet zu sein aufrufen:

Wenn ich z.b. Cronjobs unter /phpsrc/cronjobs/cronjobs.php anlege, kann ich die PHP datei ohne Anmledung ueber https://meine-ip-addresse/phpsrc/cronjobs/cronjobs.php aufrufen.

Gibt es da eine Moeglichkeit dies abzusichern? Ich habe auf der Synology website gelesen, dass man nur authenticate.cgi aufrufen muss um festzustellen ob ein Benutzer angemeldet ist oder nicht. Habe dies mit meinen rudimentaeren PHP-Kenntnissen versucht, konnte es aber nicht hinkriegen - hat dies schon jemand geschafft?
 

Martin.S

Benutzer
Mitglied seit
23. Jul 2008
Beiträge
7
Punkte für Reaktionen
0
Punkte
0
Vielleicht hilft Dir dieser Codeschnipsel

Oben am Anfang einfügen:


PHP:
$Login = 'Hallo'; 
$passwort = 'Welt'; 

if ($Login !='') 
{ 
// Zugriffskontrolle 
if($_SERVER['PHP_AUTH_USER']!=$Login || $_SERVER["PHP_AUTH_PW"]!=$passwort) 
   { 
      Header('HTTP/1.1 401 Unauthorized'); 
      Header('WWW-Authenticate: Basic realm="... Moment, ich kenne Dich doch gar nicht"'); 
      echo "Nein sorry, Du musst draussen bleiben \n"; 
      exit; 
   } 

}

Login und Passwort bitte anpassen.
Wenn Du $Login und $passwort leer lässt, kommst Du auch so rein.

Könnte eine Alternative zu dem sein, was Du suchst :)
Gruss
Martin
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
7
Punkte
0
Gibt es da eine Moeglichkeit dies abzusichern? Ich habe auf der Synology website gelesen, dass man nur authenticate.cgi aufrufen muss um festzustellen ob ein Benutzer angemeldet ist oder nicht.

Ja gibt es. Leider nicht ganz einfach, weil sich der vorinstallierte Apache mit seinem PHP ein wenig blöd anstellt. Aber wie dem auch sei. Du brauchst zwei Skripte:

auth.cgi:

Rich (BBCode):
#!/bin/ash
USR=$(/usr/syno/synoman/webman/modules/authenticate.cgi)
#[ "$USR" != "admin" ] && exit 1
echo "Content-type: text/html"
echo ""
echo $USR

Achte darauf, dass es bei den Zeilenenden keine ^M steht (mit dem vi gucken), sonst läuft das Skript nicht (also kein Windows-Zeilenende, sondern ein Linux-Zeilenende). Dieses Skripte wäre auch zugleich die Lösung für Shell.cgi-Skripte, wenn man die Zeile 2 entkommentiert (das haben wir schon irgendwo mal im Forum diskutiert - ist also nicht wirklich was neues).

Das zweite Skript (als PHP-Skript getarnt :D, könnte auch .html oder sonstwas sein - muss nur den AJAX-JavaSkript-Call können), liest nun den User-Namen via XMLHTTPRequest() ein:

test_auth.php:
PHP:
<input type="text" id="user" name="user" value=""/>
<script>
var myXMLHTTPRequest = (window.XMLHttpRequest)?
                        new XMLHttpRequest():
                        new ActiveXObject("Microsoft.XMLHTTP");
function LoadHTML(htmlfile){
  myXMLHTTPRequest.open("GET", htmlfile, false); myXMLHTTPRequest.send(null);
  return myXMLHTTPRequest.responseText;
}
ret=LoadHTML('https://syno:5001/phpsrc/systeminfo/auth.cgi');
alert(ret);
document.getElementById('user').value=ret;
</script>
<?php 
echo "php-Skript";
?>

Ich hab mal 2 Möglichkeiten gezeigt, mit dem Usernamen umzugehen. Kannst dir nun eine passende Möglichkeit überlegen, wie du das Skript bei falschen Usern beendest.

Anmerkung: Die Lösungen mit dem Request auf autheniticate.cgi (so wie ihn Synology vorschlägt) haben einen Nachteil. Sie basieren darauf, dass das Session-Cookie noch nicht verfallen ist. Also es kann sein, dass man sich immer neu anmelden muss, wenn man es abfragt, weil man wiedermal zu lange vor der Screen gesessen hat. :rolleyes:

itari
 

drago

Benutzer
Mitglied seit
17. Jun 2008
Beiträge
308
Punkte für Reaktionen
0
Punkte
0
hi,

schön erklärt.

und wo werden diese scripte eingebunden?
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
7
Punkte
0

drago

Benutzer
Mitglied seit
17. Jun 2008
Beiträge
308
Punkte für Reaktionen
0
Punkte
0
also direkt in die php der endsprechenden apps...?
 

wizjos

Benutzer
Mitglied seit
03. Sep 2008
Beiträge
30
Punkte für Reaktionen
0
Punkte
0
Absichern mittels PHP

GNaschenweng schrieb:
Gibt es da eine Moeglichkeit dies abzusichern? Ich habe auf der Synology website gelesen, dass man nur authenticate.cgi aufrufen muss um festzustellen ob ein Benutzer angemeldet ist oder nicht. Habe dies mit meinen rudimentaeren PHP-Kenntnissen versucht, konnte es aber nicht hinkriegen - hat dies schon jemand geschafft?

Im Niederländischen forum hat user Merty folgende PHP-Skript gepostet:

PHP:
<html>
<head>
<title>PHP Test</title>
</head>
<body>

<?php
putenv('HTTP_COOKIE=' .$_SERVER['HTTP_COOKIE']);
putenv('REMOTE_ADDR=' .$_SERVER['REMOTE_ADDR']);
$user=exec('/usr/syno/synoman/webman/modules/authenticate.cgi');
if ($user=="admin") {
    echo "gefeliciteerd!";
} else {
    echo "nope!";
}
?>

</body>
</html>

Wenn man angemeldet ist gibt diese kode 'gefeliciteerd' zurück; wenn man nicht angemeldet ist 'nope'...

Wie es es funktioniert weis ich nicht, aber es funktioniert! :D

Grüss,

Wizjos
 

jahlives

Moderator
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
2
Punkte
0
Ich würde auf jeden Fall die Lösung vorziehen ohne AJAX Call. Weil beim AJAX Call überlässt man die Auswertung des Resultats dem Client. Das gehört aber auf den Server. Mit PHP kann man dann z.B. eine spezifische Fehlerseite anzeigen lassen.
Ich habe obigen Code mal ausprobiert und der funzt 1A. Habe ihn noch ein bisserl angepasst und binde ihn nun via htaccess Datei in synoman via php_value auto_prepend_file /path/to/file.php ein. Das sort dafür dass dieser Code allen php Dateien unterhalb von synoman vorangestellt wird (erspart einiges an manueller Änderung)
PHP:
<?php
putenv('HTTP_COOKIE='.$_SERVER['HTTP_COOKIE']);
putenv('REMOTE_ADDR='.$_SERVER['REMOTE_ADDR']);
$user=exec('/usr/syno/synoman/webman/modules/authenticate.cgi');
if($user !== 'admin'){
  header("HTTP/1.0 403 Forbidden");
  exit;
}
?>
Sobald ich mich im DS-Manager auslogge und eine 3rd Party Appl direkt aufrufen will bekomme ich sauber einen 403-er Fehler (so soll es sein). Trotzdem habe ich in der htaccess Datei auch eine Prüfung der IP Adressen. Wenn die anfragende IP Adresse nicht erlaubt ist, dann wird geblocked unabhängig vom Resultat der authenticate.cgi Prüfung

Gruss
tobi
 

wizjos

Benutzer
Mitglied seit
03. Sep 2008
Beiträge
30
Punkte für Reaktionen
0
Punkte
0
Tobi,

Sehr schön! Aber stimmt die Zeile:
PHP:
if($user !== 'admin'){
wohl?

Gruss
Wizjos
 

jahlives

Moderator
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
2
Punkte
0
Wieso ned?
 

wizjos

Benutzer
Mitglied seit
03. Sep 2008
Beiträge
30
Punkte für Reaktionen
0
Punkte
0
Ich dacht es sollte nur '!=' oder '==' sein; nicht '!=='. Oder bin ich falsch informiert?
 

jahlives

Moderator
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
2
Punkte
0
Du bist falsch infomiert! ;)
PHP kennt kein strikte Typisierung von Variabeln. Bei Vergleichen mittels == oder != kann es vorkommen, dass eine Prüfung erfolgreich verläuft obwohl sie das nicht sollte z.B.
Die Funktion strpos() gibt das erste Vorkommen von needle (ich) in haystack (ich bin ein test string) zurück. Wenn du jetzt also folgendes machen willst
PHP:
if(strpos('ich bin ein test string','ich') == false){
  echo 'Wurde ned gefunden';
}else{
  echo 'Wurde gefunden';
Dreimal darfst du raten, aber der Code wird so niemals in den else-Zweig hineingkommen. Denn PHP ermittelt die Pos von 'ich' mit 0 (Integer). Damit PHP einen Integer mit einem Boolean Wert (false) vergleichen kann muss einer der beiden Werte gecasted werden (d.h. den gleichen Datentyp wie die andere Var erhalten), Problem hierbei ist dass Integer 0 == Boolean false gewertet wird. Die Bedingung trifft also zu.
Damit solche Vergleiche korrekt gemacht werden können gibt es den !== und === Operator. Dieser erzwingt neben der Prüfung auf den Wert auch eine Prüfung Datentyp. Damit wird PHP gezwungen keine Casts vorzunehmen.
In meinem Beispiel wäre das nicht nötig gewesen, aber ich habe mir angewöhnt das immer so zu schreiben um Problemen aus dem Weg zu gehen.

Gruss

tobi
 

jahlives

Moderator
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
2
Punkte
0
Also ich denke die folgenden zwei Dinge im Zusammenspiel funzen am Besten um den DS-Manager und die 3rd Party Applications abzusichern.

.htaccess
Je nachdem was man auf der DS mit der Datei schützen will gibt es verschiedene Orte, um die .htaccess Datei zu platzieren. Diese Datei beinhaltet dann eine White List von IP Adressen, die zugreifen dürfen. Der Rest kriegt einen 403-er (Forbidden).
Ich habe bei mir zu Hause die .htaccess Datei in /usr/syno/synoman angelegt, weil damit die IP Kontrolle auch den Login zum DS-Manager und zur Photostation (auch Audio und File) "überwachen" kann. Wenn es nur um den Schutz der 3rd Party geht, dann kann man die Datei auch unter /usr/syno/synoman/phpsrc erstellen.
Damit die .htaccess korrekt funzen kann sind zwei zusätzliche Module nötig: mod_rewrite und mod_headers. Zumindest mod_rewrite ist die Minimalvoraussetzung. Diese beiden Module wurden mit dem Apache geliefert und müssen "nur" in den Config aktiviert werden.
Code:
$ nano -w /usr/syno/apache/conf/httpd.conf-sys
ziemlich am Ende des Files wird php5_module geladen. Davor sollten die Aufrufe für die beiden Module erfolgen (am besten nach dem schliessenden </IfModule>)
Code:
LoadModule headers_module modules/mod_headers.so
LoadModule rewrite_module modules/mod_rewrite.so
Danach die Datei speichern und den Webserver neustarten
Code:
$ sh /usr/syno/etc.defaults/rc.d/S97apache-sys.sh restart
Achtet euch beim Restart des Servers auf allfällige Fehlermeldungen auf der Konsole.
Wenn alles geklappt hat dann kann man die Datei anlegen
Code:
$ nano /usr/syno/synoman/.htaccess
und mit folgendem Inhalt füllen
Code:
ErrorDocument 403 "Meldung die beim Forbidden angezeigt werden soll"
RewriteEngine on

RewriteCond %{REMOTE_ADDR} !^192.168.*$
RewriteCond %{REMOTE_ADDR} !^1.2.3.4$

RewriteRule ^.*$ - [forbidden]
Die erlaubten IP Adressen müsst ihr natürlich nach euren Bedürfnissen anpassen.

php Code
Der Code
Code:
[COLOR=#000000] [COLOR=#0000bb]<?php
putenv[/COLOR][COLOR=#007700]([/COLOR][COLOR=#dd0000]'HTTP_COOKIE='[/COLOR][COLOR=#007700].[/COLOR][COLOR=#0000bb]$_SERVER[/COLOR][COLOR=#007700][[/COLOR][COLOR=#dd0000]'HTTP_COOKIE'[/COLOR][COLOR=#007700]]);
[/COLOR][COLOR=#0000bb]putenv[/COLOR][COLOR=#007700]([/COLOR][COLOR=#dd0000]'REMOTE_ADDR='[/COLOR][COLOR=#007700].[/COLOR][COLOR=#0000bb]$_SERVER[/COLOR][COLOR=#007700][[/COLOR][COLOR=#dd0000]'REMOTE_ADDR'[/COLOR][COLOR=#007700]]);
[/COLOR][COLOR=#0000bb]$user[/COLOR][COLOR=#007700]=[/COLOR][COLOR=#0000bb]exec[/COLOR][COLOR=#007700]([/COLOR][COLOR=#dd0000]'/usr/syno/synoman/webman/modules/authenticate.cgi'[/COLOR][COLOR=#007700]);
if([/COLOR][COLOR=#0000bb]$user [/COLOR][COLOR=#007700]!== [/COLOR][COLOR=#dd0000]'admin'[/COLOR][COLOR=#007700]){
  [/COLOR][COLOR=#0000bb]header[/COLOR][COLOR=#007700]([/COLOR][COLOR=#dd0000]"HTTP/1.0 403 Forbidden"[/COLOR][COLOR=#007700]);
  exit;
}
[/COLOR][COLOR=#0000bb]?>[/COLOR] [/COLOR]
sollte nicht in die .htaccess Datei direkt unter /usr/syno/synoman
geschrieben werden, weil davon auch die Photostation betroffen wäre, die ja auch auf PHP basiert.
Dann wären keine Zugriffe mehr möglich!
Also braucht man eine zweite .htaccess Datei direkt im Verzeichnis phpsrc

Diese lädt dann den Code in jedes php File das auf dem Server ausgeführt wird und sich im phpsrc-Verzeichnis befindet. Diese Version ist dem Eintrag in das php.ini File vorzuziehen, weil php.ini alle php Files betrifft und nicht nur die 3rd Party Appl
Code:
php_value auto_prepend_file /usr/syno/synoman/phpsrc/checkuser.php
die obige Zeile ist der einzig nötige Eintrag in dieser .htaccess Datei. checkuser.php ist den Name unter dem ihr obigen PHP Code abgespeichert habt. Ihr könnt aber einen beliebigen Namen und ein beliebiges Verzeichnis für die Datei wählen, da der Server unter root läuft und somit auf alle Dateien/Verzeichnisse zugreifen darf.

Ich denke diese Kombi ist die bestmögliche Absicherung der 3rd Party Appl, zusammen mit einem starken root Passwort natürlich :D

Gruss

tobi
 
Zuletzt bearbeitet:
  AdBlocker gefunden!

Du bist nicht hier, um Support für Adblocker zu erhalten, denn dein Adblocker funktioniert bereits ;-)

Klar machen Adblocker einen guten Job, aber sie blockieren auch nützliche Funktionen.

Das Forum wird mit einem hohen technischen, zeitlichen und finanziellen Aufwand kostenfrei zur Verfügung gestellt. Wir zeigen keine offensive oder Themen fremde Werbung. Bitte unterstütze dieses Forum, in dem du deinen Adblocker für diese Seite deaktivierst.