Newsletter

Email:


Name (optional):


Archiv (ab 2010)

Nächste Veranstaltung

Sommerpause

Nächster Vortrag voraussichtlich im August

Anmeldung

Anmeldung mit Xing

Anmeldung ohne Xing

Alle Veranstaltungen kostenlos

Verlosung nur an angemeldete Gäste

Silber-Sponsoren

Don't get lost in data, get information

ABIT GmbH - Beratung - Software -  Seminare - Veranstaltungen - News

Creating digital success. | ecx.io

Veranstaltungen

Sommerpause

Nächster Vortrag voraussichtlich im August

Kalender als XML und iCal

Wir unterstützen...

Elterninitiative Kinderkrebsklinik e.V

Kinderkrebsklinik e.V

Sponsoren

Wir danken unseren Sponsoren:

Permanente Sponsoren

Uni Düsseldorf
(Raum und Beamer)


(Preise)


(Organisation und Marketing)


(Preise)


(Preise)

Mitgliedschaften

java.net Member

Events

Nachlese: Unkaputtbar - Muster für Resilient Software
Written by Philip Höfges   
Friday, 12 June 2015 14:12

>> Video

Es ist schönes Frühsommerwetter. Was unternimmt man am Besten? Klar, den Rheinjug-Vortrag von Uwe Friedrichsen besuchen. Das dachten sich auch die etwa 75 Zuhörer, die sich dafür interessiert haben, was Uwe zum Thema Resilent Software Design zu erzählen hat. Uwe Friedrichsen ist Mitarbeiter bei codecendric und hat seinen Schwerpunkt auf verteilte Systeme gelegt.

Zunächst fragt Uwe, wie lange es das Publikum wohl aushalten würde. Die vollen 90 Minuten, so das Meinungsbild. Und damit legt Uwe los. Am Anfang des Vortrags wird geklärt, was Resilence überhaupt ist. Im Bereich der Softwareentwicklung bedeutet dies, das Systeme sich in Produktion befinden und verfügbar sein sollen. Aber wie definiert man dann Verfügbarkeit? Für den Redner gibt es zwei wesentliche Werte, die dies ausdrücken: Mean Time to Failure (MTTF) und Mean Time to Recovery (MTTR). Mit der Formel MTTF / (MTTF + MTTR) kann man Verfügbarkeit gut angeben. Wie erreicht man nun sein Ziel möglichst hoher Verfügbarkeit? Im ersten Ansatz wird versucht, die durchschnittliche Zeit, in der das System fehlerfrei läuft (MTTF) zu maximieren. Dazu wird noch angemerkt, dass nahezu jedes System ein verteiltes System ist. Es existieren oftmals andere Systeme, von denen der Benutzer keine Kenntnis hat. Dies kann zu Fehlern führen. Fehler sind heutzutage leider keine Seltenheit mehr, sondern gehören dazu. Uwe fasst dies sehr schön in einem Mantra zusammen: „Versuche nicht, Fehler zu vermeiden, sondern akzeptiere deren Existenz.“. Das bedeutet, man kann auf Fehler nicht unbedingt einwirken, was den Ansatz, die MTTF zu maximieren sehr schwierig macht. Der andere Ansatz liegt in der Minimierung der MTTR, als möglichst wenig Zeit verstreichen zu lassen für die Wiederherstellung des Systems. Dazu gibt es zwei Möglichkeiten: Im besten Fall, bekommt der Benutzer gar nicht mit, dass es einen Fehler gegeben hat, da er so schnell repariert worden ist. Im schlechten Fall ist diese Zeit zu kurz, so dass der Benutzer den Fehler zwar erkennt, ihm jedoch eine Teilmenge des Systems zur Verfügung gestellt wird, damit er erkennt, dass nicht alles fehlerhaft ist. Damit hat Uwe die Grundlagen des Themas abgearbeitet.

Im zweiten Teil des Vortrags gibt Uwe eine Mustersprache an, anhand derer man sehen wird, wie Resilient Software in der Realität ungefähr aussieht. Er spricht dabei sehr viele Unterpunkte an.

Einer der Wichtigsten ist die Isolation. Es darf niemals soweit kommen, dass das gesamte System ausfällt. Dazu wird das Gesamtsystem aufgeteilt und kleine Untersysteme. Sollte eines von diesen ausfallen, läuft das Gesamtsystem jedoch weiter, weil die Untersystem unabhängig voneinander agieren können. Ebenfalls wichtig ist die Vermeidung von kaskadierenden Abbrüchen. Als wenn an Punkt A etwas schief geht, geht auch an Punkt B etwas schief usw. Dazu gibt es die sogenannten „Bulkheads“, zu deutsch Abschottungen. Die einzelnen Teilsysteme sollen möglichst disjunkt voneinander arbeiten. Und es sollte besser klappen als bei den Flutungsrräumen der Titanic, da diese nur im unteren Bereich angebracht worden sind. Diese kleine Anekdote sorgt für Heiterkeit im Publikum. Zuletzt möchte ich noch den Punkt der Relaxed Temporal Contraints erwähnen. Jeder Rechner mag vielleicht eine hohe Einzelverfügbarkeit haben, jedoch sinkt die Gesamtverfügbarkeit des System mit jedem Rechner im System ab. Dies bedeutet, dass die Konsistenz eines Systems nicht immer sofort geregelt werden muss, also alle System gleichzeitig online sind, sondern dass dies nach und nach geschehen sollte. Als Beispiel nennt Uwe eine Überweisung bei einer Bank. Das Geld ist vom eigenen Konto schneller verschwunden, als man „Überweisung“ sagen kann. Dies bedeutet aber definitiv nicht, dass es auch genau so schnell auf dem Konto des Empfängers liegt. Dies kann Tage dauern. Aber davon bekommt der Benutzer unmittelbar nichts mit. Das ACID Prinzip gilt heutzutage nicht mehr.

Zum Abschluss liefert Uwe Friedrichsen eine Zusammenfassung des Vortrags in drei Stichpunkten:

  • Systeme sind verteilt und es wird noch schlimmer
  • Fehler sind normal
  • Resilence ist notwendig

Mit diesen Worten beendet Uwe den Vortrag. Anschließend wird wie immer heiß über das Thema diskutiert, was aber vielleicht auch am Wetter liegt.

 
Nachlese: SmartHome und IoT: Warum, Was und Wie?
Written by Philip Höfges   
Thursday, 28 May 2015 07:24

Nach einer etwas längeren Pause, präsentiert die Rheinjug diesmal einen Vortrag zum Thema „Internet der Dinge“. Zu diesem interessanten Thema finden sich wieder viele Menschen in der Heinrich-Heine-Universität ein. Der Redner ist Sascha Wolter, ein Experte für Connected Home sowie ein erfahrener Sprecher.

Sascha beginnt seinen Vortrag mit einer kleinen Anekdote. Er erzählt, wie oftmals der Mensch nicht den Nutzen eines Geschäfts in den Vordergrund stellt, sondern vor allem aufs Geschäft achtet. Man verkauft Produkte und Dienstleistungen, von denen man selbst keine Ahnung hat. Stellt sich die Frage, ob man diese Produkte wirklich selbst benutzen würde. Aber darüber denkt der Verkäufer nicht nach. Er will verkaufen. Daraus resultierend stellt der Redner die zentrale Behauptung dieses Vortrags: Man soll nur Dinge entwickeln, die man auch selbst benutzen würde!

Man muss sich immer Fragen: Wer hat einen Nutzen davon? Wer würde dieses und jenes tatsächlich sinnvoll gebrauchen? Anhand eines kleinen Beispiels zeigt Sascha, dass dieser Gedanke nicht immer von Wichtigkeit ist: In einem Video wird gezeigt, wie man mit einer Geste des Smartphone die Tür öffnet. Aber warum denn mit einer Geste? In wie fern ersetzt diese den Prozess des Schlüsselherauskramens? Antwort: Gar nicht! Warum keine Näherungssensoren, so dass die Tür sich automatisch öffnet, wenn man vor ihr steht?! Hier stellt Sascha den Nutzen in Frage und erklärt, was sich in den letzten Jahren verändert hat.

Zur Zeit des Fernsehens, war der Samstag Abend ein Familientreffen. Man setzt sich gemeinsam vor das Gerät und sieht fern. Viele Menschen also auf einem Fleck („many-to-one“). Aber dies ist heutzutage nicht mehr üblich. Inzwischen haben sehr viele Menschen ein Smartphone. Damit kann man direkt mit anderen Menschen interagieren („one-to-one“). Aber nicht nur Smartphones sind vernetzt. Die Entwicklung zeigt, dass bald pro Quadratmeter drei Geräte vernetzt sein werden. Dies sei gar nicht mal so abwegig, behauptet Sascha und zählt auf: Smartphones, Smart TV, Spielekonsolen, Autos. Alles vernetzt. Da kommen schon jetzt sehr viele Geräte eines Haushalts zusammen. Selbst die Zahnbürste ist schon vernetzt. Wenn die Entwicklung so fortgeführt wird, erscheint diese etwas utopische Zahl von drei Geräten pro qm nicht mehr so utopisch. Damit wäre ein neuer Status erreicht: „one-to-many“.

Im nächsten Teil geht Sascha Wolter sogar noch einen Schritt weiter: Die Intelligenz der Gegenstände. Viele Gegenstände haben das Potenzial, in Zukunft vernetzt zu sein. Dies bietet sehr viele Möglichkeiten und natürlich auch Gefahren. Sicherheit von Wertgegenständen, Information und vielem mehr steht auf dem Spiel. Den Dingen fehlt „Weltwissen“, wie Sascha es nennt. Als Beispiel erzählt er eine Geschichte über eine geplante Bombendetonation im Weltraum in einem Film. Die Sensoren der Bomber zeigten an, sie sei am Zielort angelangt und begann den Countdown. Dummerweise war dies ein Fehler. Sie war nicht am Zielort. Das Resultat: Fatale Explosion. Daran kann man sehr gut ablesen, dass die Gegenstände zwar in der Lage sein werden, Analyse von Daten zu betreiben und vielleicht eigenständige Entscheidungen zu treffen, aber es fehlt ihnen immer ein wichtiger Aspekt: die Menschlichkeit. Und diese ist zum jetzigen Zeitpunkt wohl noch sehr wichtig.

In einem kleinen Beispiel zeigt Sascha, wie Gedankenkontrolle mit Hilfe eines Gerätes um den Kopf bereits möglich ist. Dies wird zu medizinischen Zwecken bei körperlich eingeschränkten Menschen eingesetzt. Dies hat aber auch Potenzial in anderen Bereichen. Sascha erzählt, dass damit die Reaktionsgeschwindigkeit des Menschen erhöht werden kann. Weil die Impulse an das Nervensystem ohne Nachdenken zu müssen sofort geschickt werden. Tolle Sache, aber natürlich noch nicht salonfähig.

Am Ende seines Vortrags zeigt Sascha noch einige kleine Demonstrationen. Mit Hilfe eines LEGO-Roboters zeigt er, dass bereits Fernsteuerung mit dem Smartphone möglich ist. Über Eingabe auf dem Touchscreen und sogar über Sprache. Dieses Spielzeug wird sogar dafür eingesetzt, um potenziellen Kunden spielerisch zu zeigen, was man sich als Entwickler vorstellt. Um sehr schnell beginnen diese Kunden zu spielen und auszuprobieren. Schöne Sache. Dazu zeigt Sascha ein Beispiel mit einer Sensorleiste. Hier wird deutlich, wie leicht es ist, Gestik und Sprache als Eingabe zu kombinieren und Dinge zu bewirken. Zum Schluss demonstriert er, wie man sogar die elektrischen Impulse des Nervensystems benutzen kann, um Eingaben an ein Interface zu übertragen. Eine Banane, eine Hand. Beides kann dies bewirken. Vielleicht ist damit der Schritt zu Eingabemethoden möglich, wie sie bisher nur in Science-Fiction-Filmen zeigt wird. Damit endet ein, wie ich finde, un-, aber auch außergewöhnlicher Rheinjug-Vortrag. Im Anschluss wird sehr angeregt über diese angesprochenen Themen diskutiert.

 
Für einen guten Zweck: Java Performance Survey
Written by Lukas Ladenberger   
Tuesday, 07 April 2015 08:14

Liebe rheinjug Freunde,

ein JUG Kollege hat uns gebeten, euch auf eine Umfrage zum Thema "Java Performance" aufmerksam zu machen. Die Umfrage dauert ca. 3 Minuten und hat auch einen guten Zweck: Für jede Teilnahme wird $0,50 an eine Charity Organisation gespendet.

Hier ist der Link: https://rebellabs.typeform.com/to/yhPzjG.

Danke vorab!

 
Nachlese: Sicherheitslücken in Webanwendungen
Written by Philip Höfges   
Monday, 23 March 2015 11:00
>> Video

Nachdem der letzte Vortrag krankheitsbedingt abgesagt werden musste, nimmt Philipp Hagemeister einen neuen Anlauf. Zu seinem Vortrag zum Thema „Sicherheitslücken in Webanwendungen“ finden sich etwa 100 interessierte Menschen im Hörsaal 5C ein. Philipp Hagemeister ist Promotionsstudent an der HHU und beschäftigt sich vorrangig mit Netzwerksicherheit.

Philipp beginnt seinen Vortrag mit einigen rechtlichen Hinweisen. Schließlich sollen wir das wissen ja dafür verwenden, uns gegen Angriffe zu schützen und nicht, um Angriffe zu starten. Der Redner nennt zunächst eine Liste möglicher Angriffsziele. Man ist erstaunt, wie vielfältig so ein Angriff auf die Webanwendung doch sein kann: Sicherheit des Passworts, Sicherheit der Firewall, Vertrauenswürdigkeit usw.

Für die Demonstration zeigt Philipp eine kleine, selbst geschriebene Anwendung einer Bank mit dem Namen „Ganz&Sicher“. Diese soll nachher auch dem Publikum für eigene Tests und Experimente zur Verfügung gestellt werden.

Zunächst zeigt Philipp, wie leicht man eine URL manipulieren kann, wenn nicht korrekt damit gearbeitet wird. Bei Datenübertragung mit GET werden die Parameter im Klartext mit übertragen. Leichte Angriffsfläche. Um dies zu vermeiden, sollte POST verwendet werden, sobald Daten im Spiel sind. Ist das alleine schon sicher? Nein, natürlich nicht!

Viele Webanwendungen stützen sich auf Datenbanken. Warum auch nicht? Ist ja sicher. Falsch! Die sogenannte „SQL Injection“ erlaubt es, beispielsweise in Textfelder auch schädliche Befehle einzugeben, die dann von der Anwendung ausgeführt werden. Im Extremfall können solche Befehle sogar Auswirkungen auf das System haben. Man kann damit Daten ohne Kenntnis des Admins verändern, hinzufügen oder löschen. Sehr schlecht! Als mögliche Gegenmaßnahme rät Philipp Hagemeister dazu, die Felder genau vorzugeben und zufällige Ids zu verwenden.

Moderne Browser nutzen alle die sogenannte „Same Origin Policy“. Dies bedeutet, dass nur Inhalten vertraut wird, die direkt von jeder jeweiligen Webseite stammen. Inhalte anderer Webseiten werden sofort ausgeschlossen. Dieses Konzept sei ein guter Anfang, meint der Redner, aber noch nicht der Weisheit letzter Schluss.

Weiterhin nennt Philipp Enkodierung als mögliche Schwachstelle. Man muss in der Anwendung durchgehend darauf achten, die Enkodierung zu überprüfen. Einmal vergessen, erlaubt dies bereits Vollzugriff auf die Webanwendung durch den Angreifer. Als Lösung rät der Redner dazu, eine Template-Sprache zu verwenden.

Außerdem gibt es ein Problem mit XSS: Es ist nicht wirklich zuverlässig, XSS zu filtern und kann sogar Schwachstellen verursachen.

Mit Hilfe der Token-Generierung versucht Philipp, eine Schwachstelle zu lösen: Schlechte Passwörter der Benutzer. Dabei weist er ausdrücklich darauf hin, dass die Bibliothek java.util.random nicht zu benutzen ist. Sie würde zwei Benutzer, die zur selben Zeit ein zufälliges Passwort anfragen, das Selbe geben. Schlecht! Weiterhin ist es oftmals nicht sonderlich schwer, Passwörter schlicht und ergreifend zu knacken. Es gibt die „Rainbow Tables“. In ihnen werden beliebte Passwort-Hash gespeichert. Das macht es für einen Angreifer sehr viel leichter, viele mögliche Passwörter auszutesten. Schlecht!

Wichtig dabei ist in jedem Fall: Niemals im Klartext speichern! Zu dem sollten Hashs verwendet werden: Passwörter sollten in Kombination mit einem „salt“ gespeichert werden. Dieser salt sollte mit Hilfe von einem der von Philipp vorgeschlagenen Programme erzeugt werden (PBKDF“, bcrypt oder scrypt). Diese Kombination macht es dem Angreifer zumindest sehr schwer, das Passwort zu knacken. Sicher ist so ein Passwort natürlich nie, aber man kommt immerhin sehr nah heran.

Abschließend fordert Philipp das Publikum auf, dass das Publikum die eigenen Anwendungen mit den hier vorgestellten Tricks überprüft. Mit Hilfe diese einfachen Tricks macht man es Angreifern sehr schwer und sorgt dafür, dass die Anwendung nicht so schnell geknackt werden können.

Nach dem Vortrag findet wie immer die abschließende Diskussion statt, bei der angeregt über das Thema diskutiert wird.