Fußgängerboykott

Vor einigen Tagen habe ich hier bereits über den Sinn bzw. den fahrlässigen Einsatz von Radfahrern als lebende Verkehrsbremsen berichtet. Seitdem ist kein Tag vergangen, an dem nicht von einem Radfahrer über einen Autofahrer lautstark geschimpft wurde ( glatte Untertreibung ).

Der Mittelweg wurde ja im Zuge des Umbaus von einem kombinierten Fuß- und Radweg beiderseits, auf schmalste Fußwege mit einem nicht getrennten Radweg auf der Straße umgebaut, damit in der Mitte Platz für unnötige Verkehrsinseln und eine optische und akustische Warnfläche ist. Letztere wird oft von LKW als illegaler Parkplatz benutzt.

Auf Höhe des ehemaligen Geländes der Braunschweiger Zeitung, ist direkt vor einem Briefkasten ein solcher Übergang mit Verkehrsinsel und Straßenlaternen hingebaut worden, um die Massen an die-Straße-querenden-Menschen sicher über den Mittelweg zu bringen. Das mit dem massenhaften Abbremsen der Autofahrer hat dann neulich auch tatsächlich geklappt. Allerdings anders als von den Stadt(un)planern vorgesehen.

Was war passiert ?

Ein älteres, bereits mit Gehhilfen ausgerüstetes Ehepaar ( Vermutung, so wie die sich angebrüllt haben ), querte die Straße und sorgte so für eine massenhafte Behinderung des Straßenverkehrs. Der ältere Herr stoppte den Straßenverkehr in grob widriger Form, in dem er sich einfach auf die Straße stellte, um seiner Frau ein sicheres hinübergehen zu ermöglichen. Anstatt die eigens dafür gebaute Überquerung ( die sonst auch niemand benutzt ) in Anspruch zu nehmen und so zügig und sicher hinüber zu kommen, lies er seine Frau an der breitesten Stelle, keine 5 Meter vor dem Überweg über die Straße „queren“.  „Queren“ ist hier auch falsch, denn statt quer zur Fahrtrichtung zu gehen, wurde die längstmögliche Strecke in Form einer Diagonalen gewählt. Der Vollzug der Diagonalung zog sich gefühlte 5 Minuten hin, inkl. vollständigem darniederliegens des Verkehrsflusses.

Als Konsequenz kann man hier eigentlich nur den Schluß ziehen, daß der Fußweg auch durch einen gemalten Streifen auf der Straße ersetzt werden müßte, damit statt Radfahrern mehr gehbehinderte Rentner den Verkehr „entschleunigen“ oder korrekter weise „ausbremsen“ bzw.  „ausdiagonalen“ .  Die Radfahrer werden von den Autofahrern im Bezug auf das Ausbremsen, trotz des Umstandes, daß Bremsen in doppelter Ausführung vorhanden sind, nicht für voll genommen. Gehbehinderte Rentner dagegen möchte wohl scheinbar niemand auf der Motorhaube liegen oder als Galionsfigur haben.

Fazit:  Nicht mal die Menschen, die sie dringend brauchen, wollen die überflüssigen Überquerungen benutzen. Wenn das kein Argument gegen diese schwachsinnige Baumaßnahme ist, was dann ?

P.S.: Das Fehlen jeglichen Beweismaterials dieser Story ist dem Umstand der mannigfaltig fehlerhaften Wiedererkennung von gehbehinderten Senioren und den schlechten Sichtverhältnissen meiner Kamera im Dunkeln geschuldet.

Java machts richtiger, aber leider auch komplizierter.

Vor einigen Monaten hatte Java bekanntlich ein schweres Problem in Sachen Sicherheit. Damals jagte eine Hiobsbotschaft die Nächste. Die Javaentwickler haben viel Häme über sich ergehen lassen müssen, haben aber daraus gelernt .

Java Applets werden nun nicht mehr direkt ausgeführt. Dazu kommen sehr restriktive Einstellungen unter denen Applets ausgeführt werden. Deswegen hier eine kurze Anleitung, wie Sie Applets wieder auf Webseiten aktivieren, denen Sie vertrauen können.

Windows:  „Startmenü“ -> „Einstellungen“ -> „Systemsteuerung“ -> „Java“

Sicherheitseinstellungen von Java unter Windows

Sicherheitseinstellungen von Java unter Windows

 

Um neue Webseiten einzutragen, klicken Sie auf „Siteliste bearbeiten“.

java-panel.windows-liste

Sicherheitseinstellungen Java: Domains freigeben

Einmal auf „Hinzufügen“ auswählen und dann einfach die Domain eingeben. Das wars schon.

Danach wird Java in der Webseite wieder korrekt ausgeführt. Wichtig ist das z.b. wenn Sie eine VNC Konsole benutzen wollen, da diese Anwendungen fast nur in Java zu haben sind.

„90 Prozent der Amerikaner zweifeln an Evolutionstheorie“

… die anderen haben in der Schule aufgepaßt 🙂

Update: 21.2.2014

So angebracht der Witz auch ist, leider sind wir Deutschen nicht vor solchen Problemen gefeit. In Baden-Würtemberg soll jetzt der Biologie Unterricht eingestellt werden und in einem Mix-Fach aus Technik und Biologie aufgehen. Da dort keine Biologen unterrichten würden, meinen Experten, daß dies von den Schülern ( zurecht ) nicht für „voll“ genommen wird. Um jeglicher Diskussion und ggf. Einmischung aus dem Weg zu gehen, wurden alle betroffenen Lehrer und Dozenten vom Ministerium mit einem Maulkorb versehen und Ihnen bei Zuwiderhandlung mit Kündigung gedroht. Zum Glück gibt es standhafte Menschen in allen Positionen, die sich so was in einer freien Gesellschaft nicht gefallen lassen.

Hier eine klare Ansage an alle Politiker: Wir wollen für unsere Kinder und uns keine amerikanischen Verhältnisse!

Java Swing und das Repainten von Komponenten

Von Zeit zu Zeit muß man Dinge tun, welche die Entwickler von Swing nicht vorgesehen hatten. Da wäre z.B. das Updaten einer JTextArea, während das Programm läuft.

Kleines Beispiel:

        for(int i=0;i<names.length;i++ ) {
            infotext = "Uploading file ... "+names[i];
            if ( infotext.length()> 55 ) 
                    infotext = infotext.substring(0, 55);
            updateInfo( infotext );
            String link = p.uploadFile(names[i].trim(),"/");
            result += "File: "+names[i].trim()+"\nShare: "+link+"\n";
        }
    JTextArea text = new JTextArea("");

    public void updateInfo(String text) {
            this.text.setText(text);
    }

Jetzt sollte man annehmen, daß die JTextArea jeweil nach dem setText() den neuen Text anzeigt. Tut sie aber nicht und das betrifft nicht nur JTextArea, sondern so ziemlich alle Komponenten von Swing.

Warum ist das so ?

Swing cacht quasi die ganzen Änderungen und führt diese erst durch, wenn Ruhe eingekehrt ist, d.b. wenn das Programm wartet. Das passiert z.b. wenn eine Dialogbox angezeigt wird. Die Verarbeitung des Programms ist dann eingestellt und es wartet z.B. auf das Drücken des OK Buttons in einem InfoRequester.

Solange das Programm aktiv läuft, gibt es keine Updates, weil das Rechenleistung kostet und sich mit der Zeit einige Inhalteänderungen ergeben haben können, die man dann gemeinsam durchführen kann. So spart das Guisystem Zeit und Resourcen.

Nun ist das Delay einer solchen Sparmaßnahme natürlich kontraproduktiv, wenn es um die kontinuierliche Anzeige neuer Inhalte geht, wie z.b. einem Progressbar oder eben einem textlichen Infofeld wie einer JTextArea.

Die Swing API bietet für Komponenten nun eine Methode repaint() an, die Swing mitteilt, daß die Komponente sich geändert hat und neu gezeichnet werden muß. Soweit, so gut. Leider wird der Rendercall wie schon erwähnt irgendwann gemacht und damit kann man repaint() solange aufrufen, bis man schwarz wird.

Dies Problem haben viele Javaentwickler. Auf den diversen Hilfeseiten findet man die wildesten und vor allem komplett falschen Lösungen für das Problem, in dem Mantraähnlich repaint() oder validate() empfohlen wird.

Alles falsch Leute, die Lösung sieht so aus:

	
        public void updateInfo(String text) {
			this.text.setText(text);
			this.paintComponents( this.getGraphics() );
	}

this bezieht sich dabei auf den eigentlichen Frame z.B. das Panel in dem die Komponente untergebracht ist. paintComponents(g) zeichnet alles neu und damit auch den aktualisierten Text der Area. Der Grund wieso Swing mit Delays arbeitet zeigt sich deutlich, wenn man mehrfach pro Sekunde paintComponents(g) aufruft. Nicht nur daß man die Updates im Viewport sehen kann, es dauert auch so lange, daß man tatsächlich Performanceeinbrüche haben kann. Damit wäre geklärt, wieso es normalerweise delayed ist.

Fazit: Swing ist eindeutig zu langsam konstruiert.

Jersey, Pydio & the next Big thing – Part II

Ja, es hat länger gedauert als erwartet. Nicht nur Jersey steckt voller Ungereimtheiten, auch Pydio hat tolle Bugs auf Lager. Kombiniert man das, verschwendet man richtig viel Zeit.

Status: Es geht.

Update der verwendeten Tools: Jersey 1.18 ( jsr311-api-1.1.jar, asm-3.1.jar, jersey-bundle-1.18.jar, NEU: jersey-multipart-1.18.jar)

Der Fileupload:

Der FileUpload stellt sich in Jersey schwieriger dar, als man annehmen sollte, denn die spärlichen Beispiele sind einfach mal falsch, solange man nicht die Suchbegriffe benutzt,
die einen ohnehin schon auf die richtige Fährte gebracht haben : MultiPart.

Aber auch da gibt es Fallstricke die es zu umschiffen geht und weil das einfach nur nervt, gibts hier gleich die Lösung der Probleme:

Schritt 1:

                FormDataMultiPart form = new FormDataMultiPart();
                FormDataBodyPart p = new FormDataBodyPart(
                            FormDataContentDisposition
                                .name("userfile_0")
                                .fileName("Dateiname")
                                .build()
                            , new File("Dateiname")
                            , MediaType.MULTIPART_FORM_DATA_TYPE);
                form.bodyPart(p);

Damit man FormDataMultiPart benutzen kann, muß oben erwähntes JAR-File zum Projekt hinzugefügt werden. Danach ist es aber ganz einfach das File dann wirklich per REST hochzuladen. Wobei REST hier wohl der falsche Ausdruck ist, denn es ist ein simples MultiPart-Form, daß per POST hochgeladen wird. Das macht jeder Webbrowser genauso.

Schritt 2:

                response = resource.queryParam("get_action","upload")
                           .queryParam("dir","/")
                           .queryParam("secure_token", securetoken )
                           .header("Cookie", cookieheader )
                           .accept(MediaType.APPLICATION_XML)
                           .type(MediaType.MULTIPART_FORM_DATA)
                           .post(ClientResponse.class, form);

Jetzt muß man natürlich noch den Share Call per API iniziieren werden, damit ein Downloadlink für die Datei erzeugt wird. Das sagt sich jetzt so leicht, denn Pydio 5.2.0 und 5.2.1 sind an der Stelle einfach mal defekt. Da wir mit der REST API arbeiten, erwartet unser Client zurecht auch eine korrekt formulierte Antwort und dazu gehört auch die korrekte Länge der Antwort vom Server. Die Entwickler von Pydio haben es nun geschafft diesen Teil der API erfolgreich zu entschärfen. Statt der korrekten Länge des Links, kommt ein

Content-Length:  0

und damit kann Jersey nicht umgehen. Daher darf man nun erstmal das Pydio Quickfixen.Von der Isolation des Fehlers bis zum funktionierenden Fix der PHP Anwendung, vergingen rund 80 Minuten.

Ich hege ja die Hoffnung, daß mein Bugreport gelesen und bearbeitet wird. Zur Sicherheitslücke die ich letzte Woche an das Team von Charles geschickt habe, kam nur ein : „Wir schicken Dir Deine Mail zurück-kam also an“ Nachricht zurück. Ein Umgang mit Securityproblemen muß sich wohl erst noch entwickeln. Was übrigens für den an sich sicheren Code von Pydio spricht. „Gut“ ist allerdings was anderes. Kommentare fehlen da fast vollständig 🙂

Nachdem nun diese Klippen umschifft sind, kann die eigentliche Arbeit an der Anwendung beginnen.

JAXB XML Parsing kann man übrigens getrost vergessen, der XML Code der von Pydio kommt überfordert den Parser, so daß Elemente einfach verloren gehen. Ob da der Fehler bei Pydio liegt, oder der Parser Bugs hat, mag ich nicht beurteilen. Ich habe mir dann flugs einen eigenen SimpleXML-Parser mit XML-zu-Objekt Komponente geschrieben. Reflektion ist ne schöne Sache in Java.

Wenn Sie also vorhaben sollten, für Pydio in Java zu entwickeln, kommt einiges auf Sie zu. Sie dürfen sich aber gern melden, wenn Sie Fragen haben. Aufgrund der Bots die mein Blog zum Abladen von Schrott missbrauchen wollen, kann ich leider keine Kommentarfunktion freischalten 🙁

 

Jersey, Pydio & the next Big thing

Wer schon immer Pydio(formerly known as AjaXplorer) über Jersey in Java per API ansprechen wollte sollte nun weiterlesen, für alle Anderen die Kurzform: Tun Sie es nicht, niemals, nie, nicht, auf keinen Fall!

Wenn man alleine zum Coden des Logins 6 Stunden braucht, kann es nicht gut enden. Für alle Wagemutigen hier ein paar Tips wie es klappt. Ja, „klappt“, nicht klappen könnte. Ich werde allerdings keine konkrete Implementierung vorstellen, dafür hat mich das einfach zuviel Geld gekostet 😉

verwendete Tools: Jersey 1.18 ( jsr311-api-1.1.jar, asm-3.1.jar, jersey-bundle-1.18.jar )

Schritt 1: Client mit DefaultClientConfig erstellen.

DefaultClientConfig clientConfig = new DefaultClientConfig();
Client client = Client.create(clientConfig);

WebResource resource = client.resource("http://Ihre.domain/pathtopydio/index.php");

Schritt 2: Session Cookie besorgen

String cookieheader = getSession( response );

Schritt 3: LoginSeed besorgen

String seed = resource.queryParam("action", "get_seed")
 .header("Cookie", cookieheader )
 .accept(MediaType.APPLICATION_XML).post(String.class);

Schritt 4: Einloggen

response = resource.queryParam("userid", loginname )
 .queryParam("password", loginpasswort)
 .queryParam("login_seed", seed )
 .queryParam("action", "login")
 .header("Cookie", cookieheader )
 .accept(MediaType.APPLICATION_XML).post(ClientResponse.class);

Schritt 5: SecureToken auslesen

String secureToken = getSecureToken( response );

Schritt 6: offen … Was auch immer Sie jetzt machen wollen :

result = resource.queryParam("get_action","ls")
 .queryParam("dir","/")
 .queryParam("secure_token", secureToken )
 .header("Cookie", cookieheader )
 .accept(MediaType.APPLICATION_XML).post(String.class);

Was auch immer Sie im Pydio Forum dazu lesen, vergessen Sie es einfach:

– die rest.php geht nicht und wenn nur für einen hartgecodeten User ( :facepalm: )
– Irgendwelche Force-Header sind völlig überflüssig
– Jersey brauchen Sie auch nicht, wenn Sie gleich einen eigenen HTTP-Request nebst Parser bauen, haben Sie mehr Spaß und sind schneller. Sie müssen eh das Gleiche machen wie mit Jersey: Cookies und Securetoken auslesen.
– JSON ? … per Api ? … muharhar !
Mit anderen Worten, da kommt XML, selbst wenn Sie APPLICATION_JSON als Medientyp schicken ( Pydio 5.2 )

Vorteile von Jersey: bis auf die etwas übersichtlichere Schreibweise .. keine 🙂

Eigentlich hat es nur Nachteile. Es ist schlecht dokumentiert, keine Eclipseunterstützung, verbraucht unnötig Platz, keine Beispiele im Netz usw. usw.
Da muß man ergänzen, Beispiele gibt es schon, aber fast nur für die Serverseite, wenn man in JavaEE einen netten WebService auf Rest aufbauen möchte.

Also das geht bestimmt besser.

Eins muß ich entschuldigend für Jersey sagen, ich habe die 1.x Release verwendet, weil dies auf einer Webseite so mit Links erklärt wurde. Jersey selbst meint allerdings auch, wer Maven nicht will/kann, soll 1.18 nehmen. Tja, dann…

Morgen gehts weiter mit Fileupload per Pydio API.

OwnCloud 6 und Pydio 5 angreifbar für XSS Attacken

Im Dezember 2013 wurde in OwnCloud eine Schwachstelle entdeckt, die Benutzer für XSS Attacken angreifbar macht.

XSS Attacken bestehen aus dem Einschleusen von Javascriptcode in bestehende Webseiten, deren Inhalt dann im Context eines Benutzers ausgeführt wird. Ziel dieses Angriffs ist entweder der Zugang des Benutzers, oder das Umleiten auf eine andere Seite, welche dann Daten abgreift oder einen Exploit gegen den Besucher PC/Browser ausführt.

James Sibley von blog.noobroot.com hat nun am 12.12.2013 so eine Schwachstelle über einen sehr ungewöhnlichen Angriffsvektor geschafft, nämlich dem Filesystem. Dieser Angriff funktioniert auch bei Pydio(ehemals AjaXplorer).

Zunächst erzeugt man erstmal auf einem x beliebigen Linux/Unix System eine Datei, die wie ein HTML-Tag benannt ist :

echo "" > "<img src=x onerror=alert(window.document.cookie);>.txt"

Klingt unglaubwürdig, funktioniert aber wirklich. Solange keine weiteren ‚“‚ im Namen sind, kann man auf diese Weise leicht alle beliebigen Anweisungen unterbringen, da Filenamen in modernen Dateisystem auch länger als 64 Zeichen sein können. Möchte man ‚“‚ drin haben, muß man sich nur etwas mehr anstrengen bei der Eingabe. Für dieses Demo belassen wir es mal dabei.

OwnCloud und Pydio erlauben es Benutzern solche Dateien zu teilen. Passiert dies, wird der betreffende Benutzer die von einem anderen Benutzer geteilte Datei in seinem Zugangsfenster sehen. In dem Augenblick wird vom Browser der Tag <img … > ausgewertet, weil er im Sourcecode der Seite steht. Weil das Bild nicht angzeigt werden kann, wird das onError-Script ausgeführt, welches der Angreifer in den Dateinamen geschrieben hat.

Wie wird da jetzt ein Angriff draus, denn erzeugen kann man die Datei über Pydio und OwnCloud nicht?

Ganz einfach: Man erzeugt die Datei auf einem externen Server und bindet diesen über die unzähligen Methoden als neues Repository (Begriff von Pydio) z.b. via Samba, FTP, AmazoneS3 oder DropBox-Anbindung ein. Dann kann man die Datei freigeben.

Das Opfer kann dagegen nichts machen, da bspw. in Pydio dazu keine Interaktion zwischen den beiden Benutzern nötig ist. Man kann dort eine Datei für x-beliebige Benutzer freigeben, oder gleich komplett für alle. Der angegriffene Benutzer sieht den Angriff erst, wenn es zuspät ist, er also die Seite mit dem geänderten Dateinamen anzeigt. Ohne sie anzuzeigen, kann man sie nicht sehen, also kommt es für ihn überraschend und damit zu spät. In dem Augenblick wird der Browser zum Helfershelfer der Angreifer.

Pydio und OwnCloud Exploit

Pydio und OwnCloud Exploit

Gegen diesen Angriff gibt es derzeit noch keinen Patch.

Unser Rat an der Stelle kann nur lauten, daß nur vertrauenswürdige Personen Benutzerzugänge auf Ihre OwnCloud und Pydio Installation bekommen und natürlich diese natürlich keine externen Repositories einbinden dürfen. Dies kann in Pydio über das Rechtemanagement verhindert werden.

ownCloud und Pydio wurden natürlich bereits informiert.

und wieder die UNO aus Nigeria..

Es ist sehr ruhig geworden in unserer Spamfalle. Lange ist es her, daß mich eine dieser „419“ Emails erreicht hat. „419“ stammt übrigens vom Paragraphen im Nigerianischen Recht, der solche Verbrechen unter Strafe stellt. Nicht, daß es jemanden groß kümmern würde.

Return-path: <kawashima@arukikata.co.jp>
Delivery-date: Sat, 01 Feb 2014 14:23:27 +0100
Received: from XXXXXXXXXXXXXX ([XXXXXXXXXXXXX])
	by XXXXXXXXXXXXXXXXXXXXXXXX with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128)
	(Exim 4.80.1)
	(envelope-from <kawashima@arukikata.co.jp>)
	id 1W9aXe-0007E9-NM
	for XXXXXXXXXXXXXXXXXXXXXXXXXXX1 Feb 2014 14:23:26 +0100
Received: from elias.avalonia.dk ([62.243.190.19]) by XXXXXXXXXXXXX (XXXXXXXXX)
 with ESMTP (Nemesis) id 0LqzuR-1VfShV0zhr-00efhq for ;
 Sat, 01 Feb 2014 16:21:26 +0100
Received: from [184.82.171.225] (account mr@cosmo.dk HELO User)
  by elias.avalonia.dk (CommuniGate Pro SMTP 6.0.8)
  with ESMTPA id 44454438; Sat, 01 Feb 2014 16:55:43 +0100
Reply-To: <atmunit1001@yahoo.co.jp>
From: "UNITED NATIONS ORGANIZATION"<kawashima@arukikata.co.jp>
Date: Sat, 1 Feb 2014 06:54:31 -0500
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <auto-000044454438@elias.avalonia.dk>
Subject:   

UNITED NATIONS.
United Nations House, 617/618.
Diplomatic Zone,
Central Area District,
Federal Capital Territory,
Abuja, Nigeria.
atmunit1001@yahoo.co.jp

Our Ref: YBNGWB/UN/2014.

Attention: Dear Beneficiary,

Natürlich haben hier wieder das übliche UNO.PDF als Anhang, was entweder ein Exploit ist, oder den gleichen Text nochmal hübsch aufbereitet zeigt. Vermutlich beides 🙂

Absender, Empfänger, Reply-To: und Server über die das geschickt wurden, passen natürlich nicht zusammen. Das auch gleich mal kein Subject Header in der Email drin war, bedeutet natürlich nichts gutes.

Wie immer, einfach in die Tonne die Mail hauen.