jtb.blog - Java

Webtasks

nospam@example.com (Jtb) — Fri, 09 Feb 2007 22:34:11 +0100

Meine ehemalige Uni hat ein nettes System im Probebetrieb gestartet: Webtasks
Idee hinter dem System ist, dass angehende Stundenten kleine Programmieraufgaben und Wissenstests online lösen können. Zwar noch stellenweise recht buggy, aber vom Ansatz her wirklich geil.

Interessant für fortgeschrittene Programmierer ist hierbei die eingehende Analyse des System bzw der Absicherung
Viel Spaß beim Lesen der folgenden Seiten Bei den ersten Aufgaben bekommt man auf der Weboberfläche immer die Möglichkeit den Methodenrumpf einzugeben - Anfang und Ende der Methode ist vorgegeben.
Nachdem man also seinen Sourcecode eingeben hat, fällt schnell einiges auf:

Die Entwickler von Webtasks haben das Schlüsselwort System gesperrt. Somit fallen viele schädliche Funktionen wie beispielsweise exit(int) weg. Aber leider auch echt nützliche Funktionen wie arraycopy

Aber als erfahrener Sicherheitsspezialist sollte man wissen, dass ein Sperren von Usereingaben aufgrund einer Blacklist immer aufwändig und häufig fehlerhaft ist.

So bietet sich dank Reflection ein Weg trotzdem auf alle System-Funktionen zuzugreifen:

CODE:

try
{
Class c = Class.forName("java.lang.System");
}
catch (Exception e)
{
// Errorhandling
}

Aber es wurden so auch nette Klassen wie beispielsweise Runtime übersehen, vergessen oder ignoriert

Eine komplette Übernahme des Servers wird aber vom strikt eingestellten SecurityManager verhindert - jeglicher Zugriff auf Kommandos, Dateizugriffe allgemein sowie Sockets ist gesperrt.

Aber es gibt ja noch mehr Optionen zu "stören". Beispielsweise alle Rechenzeit durch eine Endlosschleife bzw Rekursion ohne Abbruchbedindung aufzubrauchen. Ein Verbrauch der Speicherressourcen ist erstmal nicht möglich da die Java-VM beim Starten feste Speichergrenzen übergeben bekommen hat.
Bei den ersten Versuchen zeigt sich, dass die eingesetzten Java-Unittests Zeitlimits gesetzt haben - eine Endlosschleife wird nach 30 Sekunden abgebrochen. Auch eine simple Rekursion wird entdeckt und verhindert: "Rekursiver Aufruf verboten!"

Da erstmal nicht klar ist, wie die Rekursion entdeckt wird (der gesamte Sourcecode liegt ja nicht vor - mehr dazu aber später), kann man einfach eine s.g. unchecked Exception werfen und sich über die Ausgabe des Compilers freuen:

CODE:

|*Append.java:53: unreachable statement*
semaphore = false;
^
1 error

Ah, eine Semaphore
Und wir wissen nun nicht nur den Dateinamen sondern auch noch den Variablenname der Semaphore sowie der Type

Also können wir die Rekursionssperre einfach außer Kraft setzen - vor dem rekursiven Aufruf setzt man einfach semaphore auf false. Der Wille wurde gezeigt, aber wirklich ernst muss man diese Sperre nicht nehmen

Aber viel besser wird es, wenn man bemerkt, dass die Eingabe nicht auf den Methodenrumpf eingeschränkt ist. Man kann die vorgegebene Methode einfach per geschweifte Klammer schließen und eine neue Methode anfangen. Somit ist die vorgegebene Rekursionssperre endgültig sinnlos - immerhin wirkt sie nur auf eine Methode

Da das System scheinbar noch im Beta-Status ist, gibt es einige Aufgaben die nicht korrekt funktionieren. Durch einen Glücksfall gibt es eine Aufgabe, die den Sourcecode ausspuckt:

CODE:

01 /**hide**/public class Rotate_Right {
02
03   private static boolean  semaphore  = false;
04
05   public static void main(String[] args) {
06     int[] input = { 0, 1, 2, 3, 4, 5 };
07     int steps = 2;
08
09     // Test
10     printArray("Input: ", input);
11     System.out.println("Input: " + steps);
12     printArray("Output: ", studentsMethod(input, steps));
13   }
14
15   public static int[] demoMethod(int[] array_in, final int steps) {
16     // sempahore lock
17     if (semaphore == false)
18       semaphore = true;
19     else {
20       System.out.println("Rekursiver Aufruf verboten!");
21       return null;
22     }
....

Hier erkennt man nochmal deutlich, dass die Semaphore nutzlos ist.

Aber dennoch bringt uns die Rekursion nicht weiter - das System verträgt das ohne weiteres. Aber die Spielkiste hat ja noch mehr zu bieten. Analysieren wir zuerst wie die Unittests nach 30 Sekunden abgebrochen werden und versuchen ein Thread.sleep(1000000);
Ergebnis:

CODE:

ZEITÜBERSCHREITUNG:
Der Test wurde nach 30 Sekunden automatisch abgebrochen, da seine Ausführung zu lange dauerte.

Ok, der Unittest holt sich also den Thread und beendet ihn einfach. Aber wie sieht es mit einem Thread aus? Dank anonymen Threads ist die schnelle Erzeugung kein Problem:

CODE:

new Thread(new Runnable() {
    public void run() {
      try {
int i = 0;
     while (true) {
i++;
        }
      }
      catch(Exception ex) {}
    }
  }).start();

Und schon wird nichts mehr abgebrochen und der Webbrowser lädt Ewigkeiten

Fazit: externen Java-Code zu kompilieren und auszuführen kann unschön werden. Nur ein sinnvoll gesetzer Sicherheitsmanager schützt dann den Server vor einem Angreifer. Wer böswillig Ressourcen verbrauchen will, schafft dieses wenn keine zusätzlichen Sicherheitsmaßnahmen getroffen werden. Ein Blacklisten der Benutzereingaben wird sehr wahrscheinlich leicht umgangen werden können bzw müsste sehr umfangreich sein.
Externer Benutzercode sollte in einer eigenen Klasse gesetzt werden. Ansonsten sind Sicherheitsmechanismen in derselben Klasse aufgrund fehlender Sicherheit nutzlos.

Seid freundlicher zu den Maschinen und auszulieferender heißer Kaffee

nospam@example.com (Jtb) — Sun, 24 Sep 2006 15:22:09 +0200

Sowas müssen sich die Leute gedacht haben, die sich die Konfigurationsstruktur von Tomcat ausgedacht haben.
Die ganze Konfiguration baut auf XML auf (solange eine Anwendung sich nicht denkt, weitere Einstellungen über eine Properties-Datei zu machen). Eigentlich eine nette Idee - so kann der Server die Datei leichter parsen. Nur für den Menschen wird die Datei sehr leicht kaum noch lesbar. Es gibt zwar eine Administrationsoberfläche, aber die erwies sich bei meinen Versuchen mit Tomcat dieses Wochenende als unbrauchbar. Ich wollte ja eigentlich mal jboss ausprobieren, aber jboss ist leider unter Gentoo stable gerade nicht installierbar und mir wurde von der Benutzung in Gentoo im #gentoo-java Channel abgeraten. Aber zurück zu Tomcat. Für die gerade erwähnte Administrationsoberfläche muss man sich erstmal von Hand einen User angelegen. Dessen Passwort steht dann erstmal im Klartext in der Datei. Gehashte Passwörter unterstützt Tomcat nicht in einer Passwortdatei - das klappt nur mit einer Datenbank (per jdbc) bzw Verzeichnisdienst wie LDAP. Ein nicht zu unterschätzender Aufwand. Denkt man sich nun, dass man ja die Passwortdatei nur vom Serveruser (also beispielsweise tomcat) lesbar/schreibbar machen kann, wird man von der Administrationsoberfläche sanft auf den Boden der Wirklichkeit zurückgeholt: ändert man einen User, wird die Datei wieder world-readable gemacht
Bei den verfügbaren Webanwendungen, die ich mir angeguckt habe, wurde in der Installationsdokumentation immer die Konfiguration in XML angegeben - also muss ich als Administrator meine Konfig jetzt in einem Format tippen, was eigentlich dafür gedacht ist, maschinenlesbar zu sein

Aber ansonsten hat die Adminoberfläche so einige Tücken. Ich finde es zwar schön, dass man sich mit ein paar Klicks einen Vhost anlegen kann, vermisse aber dann die Zuordnung von Prioritäten. Weiterhin kann man scheinbar keinen Alias mit einem Wildcard erstellen (also *.domain.tld um alle Subdomains abzufangen). Bzw der Alias wird ohne Fehler erstellt und zeigt keine Wirkung. Wenn schon kein Alias erlaubt ist, dann müsste eigentlich die fehlerhafte Eingabe abgefangen werden.

Gibt man einen Vhost im Browser ein, den es nicht gibt, wird der Browser nur eine leere Seite anzeigen - erst ein Blick in die Header der Antwort ergibt:

CODE:

HTTP/1.x 400 No Host matches server name www.domain.tld

Diese Fehlermeldung kommt übrigens auch, wenn man keinen Context für den Vhost eingerichtet hat - sehr angenehm zum testen
Wieso man in der Adminoberfläche weniger wesentlich weniger Attribute angeben kann als möglich, will ich garnicht wissen.

Sehr schamant fand ich auch folgenden "Bug": man lad eine WAR-Datei hoch, die dann vom Tomcat entpackt werden sollte. Dieser macht es nicht und äußert sich im Log nur, dass er das Verzeichnis WEB-INF nicht finden kann. Was irgendwie logisch ist, wenn nichts entpackt wurde.
Lösung: tomcat hatte nicht die Schreibrechte auf den Ordner, so dass die WAR-Datei nicht entpackt werden konnte. Es kam aber kein Fehler dazu, so dass ich lange rumsuchen musste
Ich vermute einfach mal, dass dort das Ich-Muss-Alle-Exceptions-Fangen Paradigma von Java zugeschlagen hat..

Bei meiner Installation einer anderen Java-Software kam es zu weiteren Fehlern. Für die Anwendung Roller muss man einen Context anlegen und in diesem die Datenbankverbindung konfigurieren. Das Problem: sobald man den Context anlegt, kommt man in der Administrationsoberfläche nicht weiter - es kam der Fehler "Document base does not exist or is not a readable directory.". In den Logfiles von Roller fand ich aber den Hinweis, dass die Anwendung schon versuchte, die Datenbankverbindung aufzubauen... Also die Konfigurationsdatei des Contexts von Hand editiert und schon funktionierte alles.. Aber zum Thema Logfiles lesen: wenn ich keinen Debugmodus angeschaltet habe, möchte ich keinen über 20-zeiligen Stacktrace bekommen. Da sieht man ja die Fehlermeldung vor lauter Methodenaufrufen nicht mehr!

Weiterhin hat die Adminoberfläche scheinbar Probleme mit einem Context, dessen Appbase manuell gelöscht wurde:

CODE:

HTTP Status 500 - Error retrieving attribute debug

Davon, dass ich in die Administrationsoberfläche nach einmaligen Anlegen weder Path noch Docbase ändern kann, will ich garnicht erst reden

Danke, mir reicht's erstmal mit Tomcat

CODE:

# emerge -C tomcat

Wann ist endlich Mono so weit, dass ich ASP.Net 2 unter Linux einsetzen kann?
Oder es endlich Dedicated Server Angebote mit genug RAM gibt, so dass man dank Virtualisierung sowohl Linux als auch Windows fahren kann?

Über die Verwendung von Interfaces

nospam@example.com (Jtb) — Tue, 18 Jul 2006 16:26:29 +0200

Mal wieder ein schönes Beispiel zum Thema Programmieren an der Uni. Aufgabe war die Implementierung einer HashTable in Java. Schon die Angabe der verschiedenen Modi der HashTable über Strings brachte mich arg zum stauen (wo es doch in Java 5 so schöne Enumerations gibt und man damit sich kostenlos Schutz durch den Compiler erkauft).
Aber das Beste war die Verwendung eines Interfaces. Man bekam ein Interface namens EntryInterface gestellt und musste nun eine Klasse namens Entry unter Verwendung dieses Interfaces implementieren.
Moment – Warum ist der Klassenname Entry vorgegeben?
Wir haben doch eine schön definierte Schnittstelle und die mitgelieferten Testcases können doch einfach diese nutzen. Dank Interface habe ich ja ein Abstraktionslayer, so dass die reelle Implementierung von EntryInterface niemanden außer dem Entwickler der HashTable-Interna interessieren sollte.
Beim näheren Anschauen der Testcases lief dann auf, dass diese eine Instanz von Entry benötigen:

CODE:

@Test
public void testHomeAdress_DivisionLinear() {
Entry testEntry1 = new Entry();
testEntry1.setKey("Z8IG4LDXS");
testEntry1.setData("OK");

Es hat schon einen guten Grund, warum die HashTable in Java anders implementiert ist. Dort muss man nicht ein Objekt übergeben, sondern direkt Key und Data. Eine Klasse weniger nötig zum Benutzen.
Ein Interface auf eine solche Art zu benutzen ist schon arg komisch. Da gibt es nun wirklich bessere Lösungen..

Webservices in der Praxis

nospam@example.com (Jtb) — Sun, 22 Jan 2006 13:57:37 +0100

Für einen kleinen Dienst auf der Arbeit habe ich einen Webservice gebaut (klar, die Vorteile sprechen für sich: eingebaute Verschlüsslung dank https und Zugriff von fast überall).
Da der Client auch in C# 2005 geschrieben werden sollte (man will ja mal die neuen Features ausprobieren), habe ich den Webservice natürlich auch gleich in dotNet geschrieben - geht ja auch schön leicht: ein paar Klicks und fertig ist das ganze im Visual Studio 2005.

Getestet und nun kommt das Problem des Deployments - auf dem passenden Server ist zwar nicht ein, nicht zwei sondern schon drei Webserver installiert (Apache2+Tomcat und Lotus Domino).. Upps, da fehlt IIS...
na ja, als Workaround schnell mal einen IIS installiert und eingerichet, aber wirklich toll ist es nicht.

Also der Plan: den Server-Teil neu in Java programmieren. In der Theorie kein Problem, in der Praxis aber schon. Das generierte WSDL vom dotnet-Webservice will die WTP-Extension von Eclipse nicht als korrekt validieren.

Also alles aus der WSDL-Datei entfernen (eigentlich nur SOAP12) - und die Validierung klappt.
Nun merkt man, dass es nicht (so einfach) wie bei dotNet möglich ist einen SoapHeader zu definieren und in Implementierung anzusprechen..

Nur mal als Beispiel wie einfach das mit dotNet 2.0 ist:

[WebService(Namespace = "http://mydomain.tld/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class TrackerWebservice : System.Web.Services.WebService
{
public SoapAuthenticationHeader authentication;

public TrackerWebservice()
{}

[WebMethod(Description = "Adds a trackerentry to the tracker", EnableSession = false)]
[SoapHeader("authentication")]
public void addEntry(Entry entry)
{
/* implementation */
}
// [..]

und

public class SoapAuthenticationHeader : SoapHeader
{
private NetworkCredential credentials;

public NetworkCredential Credentials
{
get { return credentials; }
set { credentials = value; }
}

}