Beiträge von kk

In v1.1.4 ist die Session-Verwaltung bereits abgesichert: jeder Nutzer erhält zusätzlich zu seiner Session-ID (in der URL) ein Cookie. Dieses ist wiederum Multi-Session-fähig, d.h. man kann in einem Browser mehrere verschiedene Sitzungen zu LiveConfig geöffnet haben; auch ein Logout aus einer der Sessions beeinflusst die anderen Sessions nicht.
Das Cookie wird nur serverseitig genutzt, dank "HttpOnly"-Flag ist es in den meisten Browsern vor JavaScript-Zugriff geschützt und bietet somit noch mehr Schutz gegen XSS.
Session-Hijacking sollte somit praktisch unmöglich sein.

Viele Grüße

Klaus Keppler

Hallo!

Erstmal vielen Dank für die ausführliche Beschreibung.
Die "öffentliche" IP-Adresse in einem VZ-Container wird offenbar "nur" per PPP bereitgestellt. Die Bibliothek, mit der wir die Interface-Daten auslesen, ignoriert (derzeit) PPP-Interfaces, und meldet nur "echte" Schnittstellen.
Da es aber prinzipiell immer Sinn machen kann, auch an eine PPP-Adresse einen Dienst zu binden, werden wir das entsprechend anpassen.
Im nächsten Release (v1.1.4, voraussichtlich übermorgen) wird das entsprechend korrigiert sein.

Viele Grüße

Klaus Keppler

Opera unterstützt offenbar selbst in der aktuellen Version 11 noch kein CORS (Cross Origin Resource Sharing), was für das Login über eine "fremde" URL benötigt wird. Das ist ziemlich merkwürdig, weil die entsprechende W3-Spezifikation sogar von einer Opera-Mitarbeiterin bearbeitet wird...

Wir werden die Anmeldefunktion so umbauen, dass in so einem Fall der Browser direkt auf das Anmeldeformular von LiveConfig weitergeleitet wird; geplant ist das bereits für die kommende Preview-Version (1.1.4).

Viele Grüße

Klaus Keppler

Zitat von killerbees19

Das sollte bei Datenbankdateien aber nicht passieren...

Ist bereits bekannt & erledigt, hat es nur noch nicht in dieses Release geschafft (ist dann in 1.1.4 erledigt). Aber trotzdem nochmal Danke für den Hinweis.

Hallo,

die Preview-Version 1.1.3 steht nun zum Download bereit. Neben Bugfixes und Optimierungen in den Installationsroutinen wurde nun vor allem der Bereich "Webserver-Verwaltung" aktiviert.
LiveConfig erkennt somit automatisch den installierten Webserver (aktuell: Apache httpd), und kann diesen dann auf Wunsch "übernehmen". Wer mag, kann das gerne mal auf einem Testsystem ausprobieren. Die zuständigen Lua-Scripte werden unter /usr/lib/liveconfig/lua/ installiert.

Durch ein Problem beim automatisierten Build der Gentoo-Pakete steht für 1.1.3 aktuell noch kein Overlay zur Verfügung; wir werden das kurzfristig nachreichen; die Binary-Pakete (.tgz) können aber schon heruntergeladen werden.

Viele Grüße

Klaus Keppler

Zitat von antondollmaier

- Proxy-Caches/Logs
- Internet-Cafes mit WLAN

Das erledigt eigentlich die SSL-Verschlüsselung (HTTPS). Und wer die abhorcht (da gibt es ja auch Möglichkeiten, manche Firewalls machen das mit zwischengeschobenen SSL-Zertifikaten), der kommt ohnehin an alle Daten.

Zitat

Allerdings war es etwas schockierend zu sehen, dass die simple Weitergabe der URL ("hier, schau mal!") plötzlich aus einem einfachen User einen Admin machte.

Mit "einfacher User" war aber nicht ein in LiveConfig eingeloggter User gemeint, oder? Denn die Session-ID ist immer an einen bestimmten Account innerhalb LiveConfig gebunden.

Viele Grüße

Klaus Keppler

Zitat von killerbees19

Ich würde dabei soweit gehen, diverse Browsereinstellungen die im HTTP-Header mit übertragen werden immer mit den vorherigen zu vergleichen.

Eine Prüfung des "User-Agent:"-Headers ist in 1.1.3 bereits enthalten.

Zitat

Eine Option zur Überprüfung der IP wäre super, dann aber bitte je Benutzeraccount einzeln deaktivierbar machen, nicht nur für das ganze LC global

Selbstverständlich.

Über Twitter wurden wir darauf hingewiesen, dass LiveConfig anfällig für Session Hijacking sei, da keine Validierung der Session erfolge.

Da die Antwort nicht in einen Tweet passt, mache ich das hier etwas ausführlicher.

LiveConfig verwaltet seine Session-ID über die URL, da mehrere gleichzeitige Sessions mit dem selben Browser über Cookie-basierte Session-IDs nicht möglich sind.
Wenn ein Angreifer die Möglichkeit hat, im Browser die Session-ID aus der URL auszulesen, dann könnte er genauso auch ein Cookie auslesen - die URL-Variante ist daher prinzipiell nicht unsicherer. Um zu verhindern, dass die URL durch ein Klick auf einen externen Link über den Referrer nach außen gelangt, sind alle externen Links innerhalb von LiveConfig durch einen Dereferrer geschützt.

Da LiveConfig nicht anfällig für XSS (Cross Site Scripting) ist, besteht die einzige "Gefahr" also in einer bewußten oder unbewußten Weitergabe der URL mitsamt Session-ID (z.B. Screenshot, ...).
Um diesem vorzubeugen, werden wir in der nächsten Preview-Version (1.1.4) ein zusätzliches Cookie mit speichern, welches die Verwendung der Session-ID auf den jeweiligen Browser begrenzt.
Eine Begrenzung auf die IP-Adresse des Logins (bzw. einer /16 (IPv4) oder /64 (IPv6) Maske) macht unserer Erfahrung nicht immer Sinn; wir haben häufig den Fall erlebt, dass ein Nutzer mehrere verschiedene Internet-Uplinks gleichzeitig nutzt (Outbound Load Balancing), die in völlig verschiedenen Netzbereichen lagen.
Wir werden dies aber als zusätzliche Option mit integrieren (die meisten Anwender haben ja nur einen Uplink ;))

Weitere Vorschläge und Diskussionen sind herzlich willkommen.

Viele Grüße

Klaus Keppler

Super, das hat weiter geholfen. Unsere Testumgebung lief bisher nur auf englischer Umgebung; die Erkennung ob eine Funktion definiert ist (fn_exists) hat mit "grep" auch eine englische Antwort erwartet. Die dann definierte Funktion log_end_msg() ergab auf manchen LSB-Versionen eine Rekursion, die wohl zum SEGFAULT geführt hatte.
Ein neues Init-Script haben wir hier bereitgestellt: http://download.liveconfig.com/tmp/liveconfig
Das Update wird in V1.1.3 (kommender Donnerstag) enthalten sein. Mit dem nächsten Release aktivieren wir dann übrigens auch die Basiskonfiguration von Apache-vHosts.

Danke für die Info. Das ist ziemlich merkwürdig, weil wir diesen Fehler nicht reproduzieren können.
Ich habe ein Init-Script mit Debug-Meldungen vorbereitet; könnten Sie dieses bitte mal mit "./liveconfig.debug restart" aufrufen?

wget http://download.liveconfig.com/tmp/liveconfig.debug
chmod 755 liveconfig.debug
./liveconfig.debug restart

Welche Distribution kommt denn zum Einsatz?
Und auf welches Ziel verweist /bin/sh? (meistens auf "dash" oder "bash")

EDIT: mit Debian 6 (Squeeze) hatten wir das Upgrade hier auch getestet, und es lief anstandlos durch. Es scheint sich hier um ein Problem mit dem Init-Script zu handeln (das haben wir zur Version 1.1.2 LSB-"konformer" gemacht).
Da die verschiedenen Linux-Distributionen LSB (Linux Standard Base) jeweils in unterschiedlichen Versionen unterstützen, sollte das init-Script möglichst flexibel sein. Und genau hier scheint das aktuelle Problem zu liegen...

Wir planen durchaus die in der Roadmap angekündigten Termine einzuhalten.
In wenigen Stunden stellen wir die Preview 1.1.2 bereit, in welcher dann u.a. auch der SQLite-Fehler beseitigt ist. Mit der nächsten Preview 1.1.3 (nächste Woche) schalten wir die Apache-vHost-Verwaltung dazu - so kann Schritt für Schritt jedes Feature auf Stabilität geprüft werden.
Das Upgrade zwischen den einzelnen Versionen sollte zudem reibungslos möglich sein.

Mit Version 1.1.1 (steht zum Download bereit) wurde ein Fehler im Zusammenhang mit SQLite beseitigt (die Kontakte- und Kunden-Tabellen wurde nicht vollständig initialisiert). Das Problem mit dem "SQL Logic Error" bei SQLite wird auch schon bearbeitet, das wird im nächsten Update (1.1.2, ca. Ende dieser Woche) beseitigt sein.

Ich verstehe den Unmut, insbesondere wenn die einzelnen Erwartungen sehr hoch sind. Grundsätzlich bitte keine Angst - wir "klopfen" nicht gerade mal schnell die Masken zusammen. Der schrittweise Roll-Out war schon immer so geplant, und wir möchten diesen auch möglichst transparent gestalten. Auf der Roadmap-Seite ist genau aufgelistet, welches Feature wann kommen wird.
Die "komplizierten" Sachen sind alle bereits grundsätzlich programmiert (wir arbeiten da sehr modular) und müssen nun schrittweise in eine stabile Produktlinie integriert werden. Und die allererste Version, die unsere eigene Entwicklungs- und Testumgebung verlässt, überrascht nunmal naturgemäß noch mit Eigenheiten, die wir natürlich auch möglichst früh beseitigen möchten.

Grundsätzlich stehen wir für Rückfragen jeglicher Art gerne zur Verfügung; wir möchten offen mit dem Stand der Entwicklung umgehen, und auch belastbare Termine und Zusagen abgeben (-> Roadmap).

Ich persönlich stehe ab morgen (MI-FR) auch auf den WorldHostingDays für direkte Gespräche gerne zur Verfügung; bitte ggf. einfach per PN für eine Terminvereinbarung melden.

Viele Grüße

Klaus Keppler

Problem gelöst - die neuere glibc verhält sich da etwas anders als ältere Versionen... wir haben eben LiveConfig 1.1.1 veröffentlicht, welches nun auch auf Debian 6 die Interfaces korrekt anbindet.

Hmm, schade (wäre ja zu einfach gewesen
Wie sieht die Konfigurationsdatei (liveconfig.conf) aus - kommt der "http_ssl_socket"-Befehl mehrfach vor?

Dieser Ausgabe nach zu urteilen bindet LiveConfig an kein IPv6-Interface. Ist IPv6 aktiviert (modprobe ipv6)? Klappt z.B. ein "ping6 ipv6.google.com"?
In der Server-Detailansicht zeigt LiveConfig, welche Interfaces mit welchen IP-Adressen erkannt wurden; ich vermute mal daß da auch keine v6-Adressen aufgelistet werden.

Was zeigt denn "netstat -anp | grep liveconfig" an? Und um welche Distribution handelt es sich?

Nein, die Preview-Einschränkungen bringen nur "normale" Fehlermeldungen.
Es handelt sich hier um ein Problem mit dem SQLite-Schema. Vor dem Release haben wir alle möglichen Standard-Passwörter und Testdaten entfernt - vermutlich stammt es daher. Wir prüfen das gerade, mehr Infos dann in Kürze.

Ok, Debian 32bit wird relativ kurzfristig nachgeliefert.

Zum Umfang: so eine Software ist ziemlich komplex, wir starten daher schrittweise. Alle 1-2 Wochen gibt es in der aktuellen Startphase weitere Updates mit weiteren Funktionen; einfach "dran bleiben" (z.B. via Newsletter/Twitter).
Ein paar weitere Infos gibt's auch noch in den Release Notes: http://download.liveconfig.com/v1.1/RELEASE_NOTES.txt