AskSinAnalyzer - Eigenbau HM Funktelegramm-Dekodierer mit 2.8" TFT LCD

[MadMax-FHEM]

https weiß ich nicht, habe aber im Kopf, dass ESP sich da schwer tut...

Ja, du musst csrfToken beachten...
Also ich hab einen extra Webzugang mit fixem Token...

Kein Token würde ich nicht machen...

Die Sub in myUtils hast du angelegt!?

Gruß, Joachim

[tndx]

Ja, die Sub ist da und liefert direkt in FHEM aufgerufen die erwünschte Ausgabe.

Bringt denn ein fixes Token irgendeinen Mehrwert gegenüber keinem Token? Ist dann doch nur mehr oder weniger ein weiterer statischer Bestandteil der URL?

Immerhin kann der ESP mit einigen schwächeren/älteren Varianten von https umgehen, und das ist ja besser als gar kein https? @Psi: was ist denn der größte gemeinsame Nenner von https und dem Analyzer?

[Psi]

Die DeviceList wird wird vom ESP von FHEM geholt weshalb httpS erst mal nicht geht:
https://github.com/jp112sdl/AskSinAnalyzer/blob/master/AskSinAnalyzerESP32/Helper.h#L87

An dieser Stelle könnte man aber wahrscheinlich auch die Unterstützung für WiFiClientSecure einbauen, ohne Cert (-Authority) check.
Hierfür würde ich empfehlen ein Issue auf Github auf zu machen, ggf. baut das dann Jerome ein.

Ein fixen Token bringt einen geringes Sicherheits-Plus da dieses erst gesnifft werden müsste. Meiner Meinung nach braucht es aber gar keins, ins lokale Netz zu kommen ist hoffentlich aufwändig genug und mit der reinen Device-List kann man jetzt auch nicht die Welt anfangen.

Alternativ gäbe es noch den Analyzer-XS, da hier ne Node-Anwendung zugrunde liegt wäre https kein Problem.
Hier geht halt der Luxus des Displays verloren.

[MadMax-FHEM]

Man muss nicht ins Netz kommen...

Auch nicht sniffen...

Bevor sowas hier geschrieben wird bitte nachlesen was csrf ist und warum selbst ein fixer Token hilft und gar kein Token einfach nur "dumm" ist...

Du bekommst eine Mail mit einem "veränderten/verteckten" Link, der aber "zufällig" auf dein fhem passt.
Dann wird genau das was da drin steht ausgeführt...
Wenn dann fhem auch noch sudo ohne PW hätte kann nicht nur in fhem sondern auf dem System so einiges passieren...

Mit einem Token gesetzt muss neben "zufälligem" passenden IP/Link eben auch der Token passen...

Also deutlich mehr Schutz als ganz ohne Token...


Und: ein fixer Token ist quasi fast so gut wie der dynamische von fhem...
Weil der ja auch "nur" bei fhem Neustart generiert wird...
Und wenn fhem lang läuft eben auch fast statisch ist...

EDIT: eher ist https im eigenen Netz naja, nicht viel Not da... Weil WLAN ja verschlüsselt ist und wenn jemand im LAN mitsniffen kann, dann naja...

Gruß, Joachim

[Psi]

Nun, ich bin kein FHEM Nutzer aber wie ich es verstanden habe gilt dieser Token für die Abfrage der DevList, also den fhem?cmd={printHMDevs()} command.
Das ist eine lesende Operation und angenommen an dieser Stelle sind keine weiteren Lücken vorhanden bringt ein CSRF-Angriff nichts. Welche Parameter sollte ich hier von außen verändern? Zudem muss jemand erst mal auf die Idee kommen dir nen Link zu schicken mit einer lokalen FHEM-IP / Hostname.

Aber ja, Paranoia is applied security.

[MadMax-FHEM]

Das mit der Mail ist ja nur ein mögliches Szenario...
Genauso kann es ein Link auf einer (fake) Internetseite etc. sein...

Und ja bei deinem Aufruf "einfach nur ein weiterer Parameter"...
Für dich leicht, weil du ihn kennst...
Ein "Angreifer" müsste ihn ja wissen/erraten...

Und ja in diesem Fall "nur" lesend...
...aber was wenn der Angreifer einen "sudo rm -r /" absetzt...
Oder schlimmeres (für andere) z.B. Software/Malware "installiert"...

Tja wenn du meinst...

Dein System...

Ende OT

Gruß, Joachim

[Psi]

Also sorry wenn ich über nen HTTP Request nen "rm -rf" (oder seis auch nur was "harmloses") injecten kann dann hat fhem an sich n Problem.
Sicherlich läuft fhem auch nicht als root oder kann ohne weiteres root privs ausnutzen.

Ich finde deinen Einwand gut aber übertreiben muss mans auch nicht. Zeig uns nen praktischen Exploit und wir werden sicher anders agieren.

[MadMax-FHEM]

Dann halt noch mal OT und dann isses mir egal: jedem sein System...

Ich will niemanden "zwingen"...
...nur vermeiden, dass "hier" verbreitet wird, dass der Token (selbst ein fixer) unfug/unnötig ist...

Weil es faktisch eben NICHT so ist!

Lies halt einfach was csrf ist...
Und es ist KEIN fhem spezifisches Problem...
Der Token ist eine fhem spezifische Lösung dafür...

EDIT: z.B. hier https://de.m.wikipedia.org/wiki/Cross-Site-Request-Forgery

Und du glaubst nicht wieviele fhem entweder direkt als root betreiben oder großzügig sudo ermöglichen (was im Endeffekt dasselbe ist)...

Gruß, Joachim

[ucm73]

Hallo,
obwohl die Frage bereits einmal gestellt wurde (leider ohne Antwort): Hat jemand ein passendes Gehäuse zum Druck am 3D Drucker?
Für die Version von stan23 https://www.thingiverse.com/thing:3788587 scheint es ja eines zu geben, ich bekomme das leider nicht hin, ein passendes Gehäuse "zu bauen".
Gruß, Alexander

[trebron106]

Hallo Alexander,

ich habe auf die schnelle ein Gehäuse für den 3D Druck gezeichnet und angehängt.

Gruß
Klaus

[locutus]

Bitte beachtet, dass es zwei Varianten der Platine gibt:

- das erste Modell mit 3-pol. DIP-Kodierschalter
- die aktualisierte Ausgabe mit 4-pol. DIP-Kodierschalter und geänderten Abständen zwischen den Tastern.

Klaus, für welche Variante ist die Bodenplatte?

[trebron106]

Hallo,

ich habe die Variante mit 4 Dip Schaltern.

Gruß
Klaus

[ucm73]

Hallo Klaus, danke für die Mühe, werde ich heute noch drucken.
Könntest du eventuell mit den Daten von locutus die Rückwand für die 1. Version noch erstellen?
Beim ersten Modell mit 3-pol. DIP-Kodierschalter sind ja auch die Taster für den ESP leicht versetzt.
Danke!

[trebron106]

Hallo,

anbei der Boden für die Dip3 Version.

Ich hoffe das die Masse der Bohrungen passen.

Gruß
Klaus

[ucm73]

Hallo Klaus, die mittleren Aussparungen für den DIP und den Umschalter passen für die Dip3 Version.
Der äußerste der 3 "Taster" links des DIP-Kodierschalters ist auch korrekt abgebildet, die anderen teils mehr oder weniger versetzt.
Ist das sehr aufwendig, wenn du dir das noch einmal anschaust?