GCI oder so... unter HTML5 > probleme beim Ausführen

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallo Leute,

    ich bin neu hier und steig auch noch nicht ganz durch, hoffe trotzdem das richtige Forum getroffen zu haben...

    Ich habe mit einen PI neu installiert, momentan ist das für mich Übung und ich habe noch viele Fragen und Probleme. Aber mit Google versuch ich mich "durchzubeißen". Gerade häng ich aber an einem "komischen" Problem.

    Ich möchte gerne meine GPIOs über HTML5 ( / Javascript) auslesen, ändern...
    Online findet man natürlich mehrere Wege die nach Rom füren, ich habe das ganze jetzt mit CGI angefangen (gerne bin ich für bessere Lösungen offen).

    nun ich habe einen Apache2 auf dem aktuellsten Raspbian Jessi Lite (Kernel 4.1). Ich habe auch PHP5 und divere CGI tools "ausprobiert" (z.B. php5-cgi)
    genau da ist auch mein Problem zuerst hieß es ich habe nicht die Berechtigungen um CGI auszufürhen

    Zitat

    AH01630: client denied by server configuration: /usr/lib/cgi-bin/w210.cgi


    nach etwas Googeln und herumprobieren, öffnet er mir nun meine CGIs als TEXT und führt diese nicht aus... sicherlich habe ich hier was "Peinliches" verbockt :@ .

    Hoffentlich kann mir jemand helfen.

    im meiner /etc/apache2/apache2.conf habe ich folgende Zeilen eingefügt:

    Code
    ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
    <Directory /usr/lib/cgi-bin>
           AllowOverride None
           Options FollowSymLinks
           Require all granted
    </Directory>

    Folgendes steht in meiner CGI /usr/lib/cgi-bin/w211.cgi:

    Bash
    #!/bin/bash
    
    
    gpio -g mode 21 out
    gpio -g write 21 1
    
    
    echo "Status: 204 No Content"
    echo "Content-type: text/plain"
    echo "1"


    Vielen Dank :danke_ATDE:
    gruß baer

  • GCI oder so... unter HTML5 > probleme beim Ausführen? Schau mal ob du hier fündig wirst!

  • Nein. Aber wozu ohne PHP?

    PHP wird Serverseitig ausgeführt, HTML ist nur eine Ausgabe die dem Client angezeigt wird, Javascript läuft Clientseitig.

    Die Anleitung ist doch sehr ausführlich und beschreibt sogar 2 verschiedene Wege - trotzdem nicht genug?

  • Hi,


    Vermeide so gut es geht CGI da das extrem unsicher ist!


    sorry meigrafd, aber das ist Unsinn. cgi ist genau so sicher oder unsicher wie anderer Webcontent.
    Es kommt immer darauf an, wie es umgesetzt ist ;)


    Nur um der Entstehung irgendwelcher Mythen vorzubeugen ...
    -ds-

  • CGI ist eines der unsichersten Möglichkeiten, Konsolen Befehle auszuführen da es einzig und alleine dem Anwender überlassen ist ob Er Schutzmaßnahmen einrichtet. Dahingegen bestehen für den PHP Interpreter vorgegebene Regeln (php.ini) die man nicht einfach so umgehen kann und bereits Standardmäßig Einschränkungen mitbringen woran der Anwender nicht selber denken muss. Anzunehmen das betroffene wüssten worauf zu achten ist, ist ein vertaler Trugschluss.
    CGI ist eine Technologie aus dem letzten Jahrhundert und ein Security-Albtraum.
    (fast-cgi oder php-cgi ist nicht cgi)

    Aber jeder wie er meint...

    Ich empfinde es mittlerweile zu lästig in jedem, in irgendeiner form relevanten, Thread immer wieder die selben Diskussionen zu führen - zuletzt einigte "man" sich eigentlich darauf; Anfängern von unsicheren Varianten abzuraten um nicht nur sich sondern auch andere nicht zu gefährden. Aber selbst verständlich kannst Du hier gerne den individuellen Fall von baeri detalliert beleuchten und ein entsprechendes Sicherheitskonzept ausarbeiten - wenns dir denn so viel Spaß macht....

  • Sorry meigrafd ... belege Deine Aussage und gut ist's ...
    Nur: Du wirst keine belastbare Quelle für Deine Aussage finden, denn: ob Du jetzt was in php sonstwas auf dem server ausführst, oder ein script/Programm in einer Sprache, das nicht serverseitig unterstützt wird aus /cgi-bin aufrufst ... wo bitte soll da der grosse Unterschied sein.

    btw: Viele (wenn nicht die meisten) Windows-Server nutzen cgi für den Aufruf der diversen .dlls.

    Deshalb: bitte eben keine Mythen verbreiten.
    danke,
    -ds-

  • *seufz* Ich sagte bereits das ich es langsam lästig finde. Eben so wie dass das was ich schreibe nicht wirklich gelesen wird.

    Wie gesagt reden wir hier von CGI, nicht von FCGI


    Aber nun denn:

    Zitat

    Die Zulassung der CGI-Skriptausführung auf dem Server ist ein Sicherheitsrisiko.


    http://www.mpipks-dresden.mpg.de/~mueller/docs/…pache2.cgi.html
    http://www.mpipks-dresden.mpg.de/~mueller/docs/…2.security.html

    Zitat

    Damit erfährt man über den Webserver-Rechner immerhin so einiges, etwa
    [...]
    in DOCUMENT_ROOT das Wurzelverzeichnis des Dokumentbaums dieses Webservers auf dem Server-Rechner (/export/one/d/produkt/apache/htdocs) - das ist einer der Gründe, weshalb CGI als Sicherheitsrisiko gilt, denn jedes CGI-Programm kann von dort aus mit Dateizugriffsfunktionen auf andere Dokumente zugreifen (falls dort kein zusätzlicher Schutzmechanismus eingerichtet wurde, etwa das CGI-Programm mit geringeren Berechtigungen als den Webserver laufen lassen etc.) und damit ggf. im Webserver vorgenommene Schutzmechanismen wie .htaccess überlisten,


    http://aktuell.de.selfhtml.org/artikel/cgiper…triebnahme/#a18

    Zitat


    Leider gibt es auf die Frage "Sind CGI-Skripts ein Sicherheitsrisiko?" nur eine Antwort: "Ja" - ohne wenn und aber.
    Mit einem CGI-Skript erlaubt man der ganzen Welt, ein Programm auf dem Webserver auszuführen. Natürlich erfüllt dieses Programm eine wohldefinierte Aufgabe und sollte daher nichts Böses anrichten können. Mit allen möglichen Tricks kann man aber viele Programme dazu bringen, Dinge zu tun, an die deren Autoren nicht im mindesten gedacht haben - oft mit katastrophalen Konsequenzen.


    http://comment.univie.ac.at/99-1/31/ => 9) Sicherheit

  • Mein Gott ... lass es doch gut sein ...
    Was Du da verlinkt hast sind einfach nur Aussagen, die für jegliche Art von scripts gelten ...
    Dynamische Inhalte, egal welcher Art, sind immer ein Risiko ...

    CGI - das "Common Gateway Interface" ( -> click <- ) ist nur eine Schnittstelle, über die Server-Informationen zwischen Anwendung und Server ausgetauscht werden, auf die man sonst mit einem Programm nicht zugreifen könnte.
    /cg-bin wurde mal als Standard-Verzeichnis für solche Anwendungen ( egal ob bash, C, Perl, ... ) festgelegt.
    Ein Programm das CGI nutzt führt, wie auch z.B. ein php-script, eine oder mehrere Aktionen gibt und gibt ggf. HTML-Code und/oder setzt entsprechende Server-Variablen.
    Falls es Dich interessiert, kannst Du beim -> W3.ORG <- was über CGI und Programme, die es nutzen, nachlesen. Alles was dort als "Risiko" eingestuft wird, gilt uneingeschränkt auch für jede andere Art von scripts.

    Also lass doch einfach mal diese unsäglichen Diskussionen mit Deinen Versuchen über Spitzfindigkeiten oder sonstwas unbedingt recht zu haben und halte Dich an die Tatsachen.
    Wie gesagt, viele, wenn nicht sogar alle, Windows-WWW-Server nutzen CGI ...

    Ich habe mich hier zwar schon das eine oder andere Mal eines besseren belehren lassen (zwar nicht unbedingt von Dir ;) ), aber hier liegst Du mit Deiner Aussage vollkommen daneben.

    //EDIT: btw: -> [url=http://www.geedot.de/vermeidung-sicherheitsrisiken-webseite-php,62.html]PHP als Sicherheitsrisiko[/url] <- ... wenn man will, kann man jede Aussage belegen :fies:

    Ich bin dann raus,
    -ds-

  • Hallo Baer,

    es gibt Alternativen zu php. Da du dich ja scheinbar mit Javascript auskennst, würde ich dir empfehlen, serverseitig ebenfalls Javascript zu verwenden. Ich habe gute Erfahrungen mit node.js gemacht. Damit kannst du mit einfachen Mitteln einen eigenen Webserver programmieren, über den du die GPIO's steuern kannst.
    Anleitungen gibt's im Internet.

    Dann brauchst du auch keinen Apache und kein CGI ;)

    Viele Grüße,
    Kai-Uwe

    Einmal editiert, zuletzt von kaiuwe (8. Februar 2016 um 11:22)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!