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.