Das Monster im WP7-Clipboard

Es ist keine besonders wichtige Geschichte, die ich heute erzähle, aber loswerden will ich sie trotzdem, denn ich finde sie einigermassen süss:

Ich wollte für meine im Bau begriffene WP7 App eine Funktion programmieren, die einen im Clipboard vorhandenen Text nimmt, ihn analysiert und dann dem Benutzer auf eine intelligente Weise zur Verfügung stellt: Die App würde eine Liste erstellen aller spezieller „Dinge“ im Text wie URLs, Mail-Adressen und Telefonnummern, und der Benutzer könnte anschliessend diese Dinge durch einfaches Antippen verwenden. Eben eine verallgemeinerte Variante der WP7-Standard-Funktionalität, die in SMS-Texten (aber nur solchen) aus Dingen antippbare Links macht.

Dabei musste ich feststellen, dass es einer WP7-Applikation nicht erlaubt ist, den Clipboard-Inhalt auszulesen. Das ist nur interaktiv durch den Benutzer ausgelöst möglich. Siehe entsprechende Info im MSDN. Es nützt überhaupt nichts, dass die entsprechende Methode Clipboard.GetText da ist und man sie ohne Probleme in seinen Code aufnehmen kann – der Versuch, sie auszuführen, ergibt knallhart stets eine SecurityException.

Gegenüber anderen Einschränkungen des WP7-API ist das ein kleiner Fisch, aber trotzdem: Was soll das mit Sicherheit zu tun haben? Was haben sich die Microsoft-Programmierer dabei gedacht, als sie diese Einschränkung einführten, gegen welches Bedrohungs-Szenario richtet sie sich?

Es kann eigentlich kaum daran liegen, dass im WP7-Clipboard irgendein Monster sitzen könnte, gegen das man Programme schützen müsste, welche den Clipboard-Inhalt auslesen. Das Clipboard kann sowieso nur Text enthalten (eine weitere Einschränkung, bei der man nicht so recht weiss, was man davon halten soll), und auch wenn man mit Hilfe von Unicode einigen Blödsinn anstellen kann, eine Bedrohung kriegt man so wohl kaum zustande.

Soll die Limitation ein Schutz sein gegen bösartige Programme, welche den Benutzer über den Inhalt des Clipboards ausspionieren? Programm wartet im Hintergrund, bis der Anwender das hochgeheime Passwort per Copy&Paste von einer App in die nächste transportiert, schnappt sich dieses, während es im Clipboard sitzt, sendet es zum Server der Verbrecher, und das Unheil nimmt seinen Lauf?

Aber sicher doch.

Vor allem, da ja in WP7 das Multitasking von Apps so toll ausgebaut ist, dass man überhaupt im Hintergrund warten könnte, bis etwas Interessantes im Clipboard auftaucht.

Meine Vermutung ist, dass die Jungs und Mädels bei Microsoft schlicht über’s Ziel hinausgeschossen sind. Gebrannt durch die lange Leidensgeschichte von Windows auf dem PC, was Sicherheit bzw. die ziemliche Abwesenheit derselben betrifft, will man wohl jetzt unter allen Umständen vermeiden, dass WP7 mit irgendeiner Sicherheitslücke Negativ-Schlagzeilen macht.

Wenn man also nicht zu 100% sicher sein kann, dass nichts aus dem Ruder läuft, wenn man den Apps Clipboard-Lese-Zugriff einräumt, lässt man lieber die Finger davon: Better safe than sorry.

Veröffentlicht in Allgemein. Schlagwörter: . 1 Comment »

Eine Antwort to “Das Monster im WP7-Clipboard”

  1. Anheledir Says:

    Unabhängig davon, wie ernst die Bedrohung tatsächlich ist (im Moment nur Text, aber vlt. später ja auch Bilder & co.?), habe ich ein gewisses Verständnis für solche Sicherheitsbedenken. Wenn ich teilweise in Foren und anderen Communities lese, was Entwickler gerne alles „heimlich“, „automatisiert“ und im Hintergrund auf meinem Smartphone machen möchten, läuft es mir oft eiskalt den Rücken herunter. Nun mag das Multitasking auf der Windows Phone Plattform noch eingeschränkt funktionieren, aber das reine Einfügen des Inhalts aus der Zwischenablage leert diese ja nicht auch. Also kann eine App die ich vielleicht deutlich später starte – wenn ich mein Passwort, Link oder sonstige private Nachricht schon längst im Clipboard vergessen habe – immer noch darauf zugreifen. Und dann natürlich auch noch die Hintergrunddienste, die unabhängig von den gestarteten Apps agieren können.

    Wie gesagt, das Bedrohungspotential ist möglicherweise gering im Moment, aber dennoch vorhanden und bietet auch eine gewisse Angriffsfläche. Vielleicht sind deshalb die gleichen Sicherheitsbedenken aufgetreten, nach dem die API-Funktion GetText() fertig war – und um das Problem bis zum Ende logisch fertig zu analysieren und vlt. mit einem neuen Flag in der Manifest-Datei zu lösen, wurde es halt sicherheitshalber erst einmal gesperrt. Es mag übervorsichtig wirken, aber wie du schon geschrieben hast ist gerade Microsoft mit einer in der Vergangenheit eher laschen Sicherheitspolitik bekannt geworden (was sich in den letzten Jahren aber schon deutlich geändert / verbessert hat!), und auch das Sicherheitsbewusstsein für Dinge, die Programmierer ohne Einverständnis des Nutzers automatisch und intransparent mit dem Smartphone machen können ist größer geworden dank der zahlreichen Zwischenfälle und der Malware auf den konkurrenzplattformen.

    Just my two cents🙂


Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: