Da reden wir aber wieder aneinander vorbei. Die Art der Prüfung kommt ja dann auch im lokalen Netz. Da brauche ich die Sicherheit nicht!
Ahh, so meinst Du das - da habe ich Dich missverstanden - Danke!
Da gebe ich dir zu 100% Recht. Diesbezüglich sehe ich die Modulentwickler in der Pflicht. Oder aber auch den Hersteller, solche Module dann ggf. gar nicht freizugeben? Oder nur mit rotem Sicherheitshinweis?
Ach nee, als Fanboy muss ich ja schreiben: Symcon macht alles richtig und alles ist toll und der Anwender ist doch selbst Schuld, wenn er nichts versteht.
Ich gebe zu, ich war auch gerade richtig erschrocken. HomeConnect läuft über OAuth. Heißt das so? Das hat mit WebHook nichts zu tun. Das ist auch in der Instanz “WebOAuth” zu sehen.
Sehe ich anders, siehe oben. Also ja, es ist okay, dass du das nicht brauchst. Schaden wird es aber nicht. Oder? Und eine andere Möglichkeit der Absicherung gibt es ja momentan nicht.
Das ist ein guter Hinweis da muss ich doch gleich mal prüfen ob ich das WebOAuth mit einer eigen Domain und Reversproxy nutzen kann dann brauche ich den Connect Dienst nicht mehr zu Aktivieren.
Und genau das ist des Pudels Kern, jedenfalls war das der Titel bzw. der Einstieg in dieses Thema ![]()
Muss ich mir mal in einer ruhigen Minute durchdenken wie ich das für mich lösen werde.
Heiko
Spontan würde ich sagen: Geht nicht. Aber zugegebenerweise bin ich da kein Fachmann.
Denke das hängt stark davon ab was von dem OAuth prozess alles auf symcon servern läuft und was auf meiner Symcon Instanz, und ob man in dem die URL manipulieren kann die an den Exteren Diesnt übergeben wird.
Nur mal so aus der Hüfte geschossen - könnte man dem Hook nicht eine Info mitgeben, welchen Weg er genommen hat? Also remote oder lokal?!
Dann könnte man als Modulentwickler ein Setting machen - Zugriff von Außen erlauben ja/nein!
Es bringt ja auch nichts wenn der Modulentwickler irgendein Magic macht und man sich wundert - einmal geht die Funktion und einmal nicht. Manche coolen Features gehen im Moment halt auch nur per WebHook.
Gruß HEiko
Denke das sollte schon im WebHoock modul entschieden werden bovor die ProcessHookData() des Moduls mit den Danten aufgerufen wird.
War zu optimistisch, das ist kein PHP modul in dem mal mal schnell ne url ausstauscht.
[Edit]
Hier mal ein neuer Thread zu den überlegungen.
Du kannst ja glaube ich in der $_IPS Variable sehen woher du kommst und könntest darauf reagieren.
Grüße,
Kai
Ne, wenn schon dann in $_SERVER
Ich dachte das war der Key. ![]()
Hast du ja wieder recht!
Grüße,
Kai
Welche Features wären das bei dir?
Ich überschlage gerade mal, wo und wie ich Webhooks in den Modulen nutze.
Alles was eine Aktion auslösen kann, habe ich mit Tokens, welche nur aus einem Frontend (HTMLBox) kommen können, abgesichert.
→ Wobei ich aktuell vieles auf das HTML-SDK umstelle, hier tritt das Problem nicht auf, da es keinen Hook benötigt. Dafür ist das WebFront dann außen vor.
Dort wo es für die Anbindung eines externen Dienstes (wie uPnP-Events, ONVIF Events etc..) genutzt wird, kann eigentlich nichts passieren. Dazu müsste man das Payload kennen und wissen wie man es vergiften kann. Mit viel Pech wird dann eine Variable auf einen falschen Wert gesetzt → hier könnte man natürlich mit $_SERVER[‚REMOTE_ADDR‘] noch mal gegensteuern. Auch wenn dies natürlich keine 100% Lösung ist.
Zusammenfassend braucht man für einen erfolgreichen Angriff also:
- Die ipmagic Adresse
- Den Namen des Hook + Instanz ID (alle meine Module hängen die immer an den Namen vom Hook)
- Die erwartete URL hinter dem Hook
- Die HTTP Methode ob die GET, POST, NOTIFY oder sonstwas erwartet wird
- Den genauen Aufbau des Payload und was eine Änderung bewirkt
- Eventuell noch den Token (sofern das Modul einen nutzt)
Das sind alles korrekte Aussagen aber Sie treffen ja leider nicht meine Punkte.
-
ich muss dem Entwickler vertrauen oder selber prüfen das ein Schutz Mechanismus implantiert ist.
-
Warum etwas zum Internet öffnen was technisch nicht benötigt wird. Bei der Härtung von Systemen ist das eine Kernbestandteil alles zu deaktivieren, was nicht gebraucht wird um die Angriffs Fläche möglichst klein zu halten.
Sind das nicht öffentliche Informationen? Das sollte sich ja beim Studium des PHP Codes heraus finden lassen.
Der Name ist auch bekannt da im PHP Code enthalten und bei dem zweiten Teil sind wir wieder bei Punkt 1 man muss prüfen ob der Entwickler ein Schutz Mechanismus implementiert hat.
@Nall-chan oder @paresy wie ist das eigentlich gibt es einen Mechanismus der zu viele fehl Anfragen auf eine ipmacig Adresse unterbindet?
Gruß Max
Da ich nicht auf deine Beitrag geantwortet habe und einfach nur meine Überlegungen niedergeschrieben habe, ist mir das egal.
Korrekt.
Ja. Dann weiß man auch was (nicht) passieren wird oder kann.
Schutz ist die ID ja nicht. security by obscurity ist keine Sicherheit. Es erschwert (manueller) oder verlangsamt (automatisierter) nur den Angriff.
Weitere Maßnahmen, wie Tokens o.ä. sind da schon sinnvoll.
Die Frage ist eher, wie wahrscheinlich ist es um so einen Aufwand zu betreiben um was zu erreichen.
Also meine Haustür werde ich bestimmt nicht über einen Hook öffnen.
Aber wenn mal eben eine Variable -1 anzeigt anstatt 23Watt, weil der Hook der ESPCam ‚gefunden‘ wurde, geht davon bei mir die Welt nicht unter.
Da fragt du den falschen… Bin auch „nur“ User der Software.
Ah ok da hatte ich was falsch verstanden, bzw hätte ja sein könne das du das weist, hast ja ne ganze Menge Module geschrieben und bist hier im Forum sehr aktive auch ich durfte von deine Antworten ja schon profitieren.
Okay, ich berichtige mich - ein „cooles“ Feature
und das ist das Speichern/Schreiben von Daten/Infos/Bildern in ein lokales File. Sehr hilfreich um Backups usw. zu machen! Einlesen von Files wird ja direkt unterstützt, leider nicht das schreiben!
Gruß HEiko
Ah, das ist natürlich etwas was ich bisher gar nicht so auf dem Schirm hatte, danke.
Auch Daten eines Formulars per Post aus eine Frontend an einen Hook senden fiel mir eben noch ein.
Glaube da das habe ich beides noch nie genutzt ![]()