Welcome to MSDN Blogs Sign in | Join | Help

Ein kleiner Menüpunkt, zufällig entdeckt in Visual Web Developer Express Beta 2 ließ mir heute das Herz aufgehen. Für dieselbe Funktionalität hatte ich vor langer Zeit mal ein Makro geschrieben, welches jedoch Visual Studio regelmäßig zum Absturz brachte. Irgendwann gab ich auf. Jetzt hat die Produktgruppe meine Gebete erhört: CLOSE ALL BUT THIS!

Close All But This

Wie ich immer mal wieder auf Techie-Parties betone, habe ich Geisteswissenschaften studiert. Das kommt bei den Frauen gut an. Leider sind auf diesen Parties keine Frauen, aber egal, es geht um's Prinzip. Auf was ich eigentlich hinaus will: Durch intensives Studium der englischen Sprache habe ich die Erkenntnis gewonnen, daß die meisten Begriffe wörtlich gemeint sind. Gedichte und Songtexte sind zwar Ausnahmen, aber meistens ist die Primärbedeutung die primäre Bedeutung (Hähä! Linguistenwitz!)

Beispiel Nr. 1: Das Programme-Verzeichnis
Ja genau - das ist das zu da, um Programme abzuspeichern. Wäre es dazu da, Einstellungen, Logfiles oder Datenbanken aufzunehmen, dann hieße es ja Programm-, Einstellungs-, Logfiles- oder Datenbankverzeichnis. Das wäre viel zu lang. Kommen wir zu dem Grund, warum in diesem Verzeichnis nur ausführbare Programmdateien stehen dürfen: Für normale Benutzer ist der Schreibzugriff auf dieses Verzeichnis nicht gestattet. Im Normalbetrieb muß nämlich niemand schreibend auf Programmdateien zugreifen. Außer natürlich Viren. Und die greifen dankend zu. Dennoch handeln die meisten Anwendungen nach dem Motto "My directory is my castle"  und speichern alle möglichen Logs und Daten in ihrem eigenen Programmverzeichnis – von dem kann man ja schließlich sicher sein, daß es existiert.  Als ich neulich eine DSL-Zugangssoftware eines großen Telekommunikations-Konzerns installieren musste, sah ich diese krankhafte Logik wieder einmal live in action: Weil das Programm eine kleine, unwichtige Logdatei partout im Programm-Verzeichnis anlegen wollte, lief die gesamte Software nur unter dem Admin-Acount. Ein wahrhaft brauchbarer Beitrag zum Thema "mehr Sicherheit im Internet".
Ein weiterer Grund, das Programme-Verzeichnis nicht zu mißbrauchen ist nicht sicherheitsrelevant, aber genauso wichtig: Will man den Rechner neu aufsetzen, ohne alle Einstellungen zu verlieren, darf man sich die entsprechenden Files einzeln aus den verschiedenen Applikationsverzeichnissen zusammensammeln – ein praktisch unmögliches Unterfangen. Der arme „Files and Settings Transfer Wizard“, der Einstellungen von einem Rechner zum anderen migrieren kann, ist völlig hilflos.  Also: Alles, was keine EXE oder DLL ist, gehört in den Dokumente und Einstellungen-Ordner! Und das meine ich wörtlich...

Beispiel Nr. 2: Der Full Trust-Modus unter ASP.NET
Bei einer Sicherheitskonferenz beschwerte sich ein selbsternannter Webhosting-Sicherheitsexperte über die "unsichere Software" von Microsoft. Die Begründung: Im Full Trust-Modus sei es möglich, das User unter bestimmten Umständen "zuviel Rechte" bekommen. Nun frage ich mich: Was ist wohl von einem Modus zu halten, der wörtlich "volles-Vetrauen-Modus" heißt? Genau! Daß wir dem betreffenden User (oder dessen Code) voll vertrauen! Und wenn ein Webhoster seinen Usern voll vertraut, dann hat er den Beruf verfehlt. Für diese Gruppe sollte man den Modus in Do-not-use-this-really-we-mean-it-Modus umbenennen.

Nächste Woche: Das "Unsafe"-Keyword in C#...

Normalerweise sind meine Argumentationen ja so zwingend, daß sie keinen Widerspruch hervorrufen. (Vielleicht liest aber auch nur keiner mein Blog :-)

Dennoch regt sich manchmal Widerstand, zum Beispiel als Reaktion auf den Artikel "My, ist das geil":  Golo Haas, der Besitzer des äußerst lesenswerten, intelligenten und oft überraschenden Eisbärenblogs findet das My-Objekt gar nicht geil. Der Vorwurf lautet: "Jetzt haben wir so ein schönes, einheitliches Framework, und jetzt geht Ihr VB-Schnullis wieder getrennte Wege? Warum nur?". Das ist freilich von mir sehr ungerecht zusammengefasst: Golos wirklich gute und faire Argumentation kann man hier nachlesen.

Unter anderem schreibt er: "[...] My ist nicht geil. Nicht einmal ansatzweise. Denn My untergräbt die klare Struktur von .NET, die viele Entwickler so lieben, wie es bei PHP auch geschieht. Unter dem Motto "Alles soll einfacher werden" wird ein zusätzlicher Namensraum eingeführt, der Abkürzungen bietet. Diese aber mit eingeschränkter Funktionalität, und nicht mehr nach den klassischen Namensräumen sortiert, es wird also neben der Einführung einer zweiten Schreibweise auch noch die Beschäftigung mit den klassischen Namensräumen vermindert. Letztlich führt das meiner Meinung nach zum gleichen Ziel wie in PHP, nämlich, dass Einsteiger sich auf My stürzen werden, dann aber irgendwann an die Grenzen stoßen oder fremden Code bearbeiten müssen, und sich dann doch mit den klassischen Strukturen auseinander setzen müssen. Letztlich wird so wieder ein Parallelweg eingeführt, der eigentlich überflüssig ist, und am Ende die Produktivität eher senkt als steigert, da redundante Abläufe erlernt werden müssen. [...]"

Dazu habe ich einige Thesen:

Wir müssen uns mit der harten Realität abfinden: Es gibt eine große Bandbreite von Programmierern da draußen - von der (oft selbsternannten) Elite bis zum Hobby- oder Gelegenheitsprogrammierer. Nirgends ist zudem die Bandbreite so hoch wie bei der klassischen VB-Gemeinde – hier gibt es wirklich alle Schattierungen.

Und mindestens drei davon sind die Zielgruppe des My-Objekts. Wo wir schon bei (Mynungs-)freiheit sind:

  • Nehmen wir den vorkenntnisfreien Anfänger. Visual Basic 6 war auch deshalb ein Erfolg, weil dieses Framework eine steile Lernkurve hat und ein Einsteiger gleich loslegen konnte. Dieses gute Gefühl ist mit VB.NET weg – das höre ich jeden Tag von Leuten, die VB.NET als zu komplex empfinden. Wer gleich am Anfang eine große Wand vor sich sieht, wird in vielen Fällen erst einmal die Flucht ergreifen. Ein Neueinsteiger braucht schnelle Erfolgserlebnisse. Meine These: Wer irgendwann später an die Grenzen stößt, hat dann (aber erst dann) die Motivation, sich weiter einzuarbeiten und Techniken und Werkzeuge zu benutzen, die mehr Lernaufwand, aber auch mehr Möglichkeiten bieten. Vom Dreirad auf das Fahrrad umsteigen ist etwas stressig - aber nötig.
  • Dann gibt es da den theoriefreien Praktiker. Der ist typischerweise Ingenieur und will eben mal schnell eine Applikation zum Auslesen von Messwerten über den seriellen Port schreiben. Die Schönheit und Konsistenz des Frameworks ist ihm herzlich egal. Er will Ergebnisse, denn morgen muß er die Werkzeugmaschine beim Kunden abliefern und braucht die Messwerte für ein Freigabedokument. Seine Aufgabe ist es nicht, schönen wartbaren Code für die Ewigkeit zu schreiben. Sein Chef würde ihn entlassen, wenn er erstmal zwei Wochen irgendein Framework erlernen muß. Er will nicht irgendwann in anderen Sprachen programmieren und den Code anderer Leute lesen. Der theoriefreie Praktiker wird übrigens immer übersehen und meistens mit dem vorkenntnisfreien Anfänger in einen Topf geworfen.
  • Ich persönlich gehöre zur Gruppe der ideologiefreien Pragmatiker. Gibt es eine Möglichkeit, irgendwas schneller zu erledigen, dann nutze ich diese. Ich habe kein Problem damit, daß es mehrere Möglichkeiten und  gibt, dasselbe Problem zu lösen – und jedes der verwendbaren Werkzeuge spezifische Vor- und Nachteile hat. That’s Life – jeder Handwerker kann das bestätigen! Will ich schnell sein? Gib mir mehr Namespaces von vom Schlage "My"! Will ich genaue Kontrolle über meine Arbeit? Do it yourself with System.IO and friends! Ich habe die Wahl der Waffen. Das ist für mich keine "Redundanz" sondern Flexibilität – bei VB6 hatte ich die nicht, da musste ich nehmen, was die VB-Runtime auftischte und mir notfalls mit C++ behelfen (schauder). Die Wahl zwischen RAD und klassischem Frameworkcode steigert hingegen noch meine Produktivität.

Und wo liegt das Problem?

 

Die Problemkandidat Nummer eins ist der erkenntnisfreie "Fortgeschrittene", der nach 10 Jahren Berufserfahrung als Codeklopfer immer noch glaubt, Datenbankcode gehöre in den Click-Event des OK-Buttons. Der keine Wahl treffen kann zwischen RAD und "reiner Lehre", weil er nur ersteres kennt- und keine Lust hat irgend etwas Neues zu lernen – schließlich könnte da jeder kommen, das war schon immer so, wo kommen wir denn da hin, dBase konnte doch schon alles was man so braucht. Der erkenntnisfreie Fortgeschrittene begründet den schlechten Ruf von RAD-orientierten Features. Aber auch diese Gruppe kauft Compiler. Das ist ein Fakt, den ich mit Zahlen untermauern kann...

 

Sorry, Golo: My ist geil!

 

P.S: Myner Mynung nach kann es außerdem niemand geben, der My-Code nicht versteht, auch wenn er gerade vom Planeten Cobol angekommen ist oder den Gott des Semikolons verehrt ;-)

 

P.P.S: Ich habe gerade gemerkt, daß die Buchstabenkombination "ei" in der deutschen Sprache ygentlich überflüssig ist!

 

Ich verschone Sie ja gänzlich mit persönlichen Details, aber jetzt möchte ich einmal eine Ausnahme machen. Einige Leser haben mir Mails mit nettem Feedback über mein Blog geschrieben: Vielen Dank dafür! Vereinzelt klang auch der Wunsch nach häufigeren Posts an (eine leicht getarnte Version der Frage "Lebst Du eigentlich noch? :-)

<Rechtfertigung>Ja, ich lebe noch, und war in letzter Zeit zugegebenerweise etwas beschäftigt mit dem Release meiner Tochter Theresa (noch im Alphastadium, sehr viel Maintenance nötig, Soundfunktion aber voll funktionsfähig), diversen Reisen nach Vaubekien und neuerdings mit der Aktion "Deutschland sicher im Netz" - hier plane ich Events für Entwickler zum Thema sichere Programmierung.</Rechtfertigung>

Aber ich gelobe Besserung. Wiederbelebungsmaßnahmen für mein Blog sind in vollem Gange, vor allem seit ich mein vergessenes Passwort für die Blogging-Engine auf einem PostIt-Zettel unter meiner Tastatur wiedergefunden habe (kleiner Scherz. Den PostIt-Zettel habe ich natürlich sicher in meiner Geldbörse verwahrt. Schließlich hat man einen Security-Ruf zu verlieren.)

Ja my! Mystens gibt es ja Diskussionen zwischen VB.NETlern und C#-Anhängern, welches denn jetzt die bessere Programmiersprache ist. Die offizielle Aussage von Mycrosoft war ja immer: Beide sind gleichgut. Myne Mynung zu diesem Thema ist ja hinlänglich bekannt und wird jetzt noch durch das neue, geile My-Template untermauert. Das gibt's nämlich nur für VB.NET!

Genug gekalauert. Das My-Template bietet eine Abkürzung zu den meisten, täglich anfallenden Aufgaben bei der Programmierung. Beispiel gefällig?

Aus:

Dim File As New System.IO.StreamReader("c:\test.txt")
Dim Words As String = File.ReadToEnd()
File.Close()

Wird:

Dim Words As String = _
 My.Computer.FileSystem.ReadAllText("c:\test.txt")

Gut, was? Folgendes war schon immer üble Steinzeit:

Private Declare Auto Function PlaySound Lib "winmm.dll" _
 (ByVal lpszSoundName As String, ByVal hModule As Integer, _
      ByVal dwFlags As Integer) As Integer
Private Const SND_FILENAME As Integer = &H20000

Dim bAns As Boolean, iRet As Integer = 0
Try
 iRet = PlaySound("C:\sound.wav", 0, SND_FILENAME)
Catch
End Try

Dieser wunderschöne Code wird jetzt aufgeräumt zu:

My.Computer.Audio.Play ("C:\sound.wav")

Im My-Namespace finden sich sieben sogenannte Rootobjekte, die jewils selbstbeschreibend Zugriff auf bestimmte Funktionalitäten und Tools geben:

  • My.Application liefert Infos über das aktuell laufende Programm: Applikationstitel, -version, -beschreibung, Logfiles uvm.
  • My.Computer bietet Zugriff auf Ressourcen des Rechners: Registry, Audio, Dateisystem, serielle Schnittstellen, usw.
  • My.User informiert über den aktuell angemeldeten Besitzer (Name, Domain, Gruppen etc.)
  • My.Ressources erlaubt den Zugriff auf alle eingebetteten Ressourcen - mit Intellisense anstatt dem RessourceManager aus der Hölle
  • My.Settings macht das abspeichern von Benutzer- und Applikationseinstellungen zum Kinderspiel
  • My.Webservices und My.Forms bieten per Intellisense blitzschnellen Zugriff auf alle im Projekt definierten Webservices bzw. Fensterklassen.

Aber das kann man natürlich woanders nachlesen. Mein Tip: Das My-Objekt läßt sich auch prima erweitern. Das betrifft sowohl die Erweiterung der Rootobjekte selbst als auch das Hinzufügen neuer Rootobjekte.

Ein Beispiel: Firma VB-Trans, eine Spedition, muß sehr viele Programme schreiben, die einen an den Computer angeschlossenen Barcodescanner benutzen.  Kann man das My.Computer-Objekt, das ja Zugriff auf solche Dinge wie Schnittstellen und Geräte bietet, um Barcodescanner-Funktionen erweitern, die dann über  My.Computer.Barcode ansprechbar sind? Ja man kann. Und so geht's:

Namespace My

    Public Class BarcodeReader

        Public Function Scan() As String
            Return "Ein toller Barcode"
        End Function

    End Class

    Partial Class MyComputer

        Private _BarcodeReader As BarcodeReader

        Public ReadOnly Property BarCodeReader() As BarcodeReader
            Get
                If _BarcodeReader Is Nothing Then
                    _BarcodeReader = New BarcodeReader
                End If
                Return _BarcodeReader
            End Get
        End Property

    End Class

End Namespace

Hier ist bemerkenswert, daß nicht die Klasse Computer im Namespace My erweitert wird, sondern (aufpassen!) die Klasse MyComputer im Namespace My. Trotzdem wird die Funktion Scan nachher über

My.Computer.BarcodeReader.Scan()

angesprochen? Wie kann das sein? Ganz einfach: Der  VB.NET-Compiler übersetzt die Aufrufe entsprechend: In Wirklichkeit ist Computer eine nämlich öffentliche Eigenschaft der MyComputer-Klasse - dies verheimlicht uns VB.NET durch fiese Tricks aber vollständig. Mit ildasm kommt man dem Spuk aber auf die Schliche.

Das Erweitern der MyComputer-Klasse ist aber durch die neuen partiellen Klassen sehr einfach: Unsere eigene Barcode-Funktionalität wird beim Kompilieren mit der "eingebauten" MyComputer-Klasse zusammengefügt und in eine einzige kompilierte Klasse gepackt.

Analog funktioniert das Erstellen eigener Rootobjekte. Als alter Philosoph wünschte ich mir, jeden Tag einen neuen Sinnspruch beim Start meiner Applikation anzeigen zu können - Zeit für ein My.ThoughtOfTheDay-Objekt. Kein Problem. Einfach eine Bibliothek zur Philosophiegenerierung (PhilosophyLib) samt Funktion GetDeepTought() geschrieben und folgendermaßen als Rootobjekt in den My-Namespace integriert:

Imports PhilosophyLib

Namespace My

    Friend Module My_ThoughtOfTheDay

        Private _ThoughtOfTheDay As ThoughtOfTheDay

        Public ReadOnly Property ThoughtOfTheDay() As ThoughtOfTheDay
            Get
                If _ThoughtOfTheDay Is Nothing Then _ThoughtOfTheDay = New ThoughtOfTheDay
                Return _ThoughtOfTheDay
            End Get
        End Property

    End Module

End Namespace

So entsteht ein neues Rootobjekt:

My.ThoughtOfTheDay.GetDeepTought()

Ich habe zu beiden Vorgehensweisen zwei kleine Beispielprojekte gestrickt, die hier zu finden sind. Da diese Projekte jedoch mit einem Microsoft-internen  Build der Beta 2 von VB.NET Express erstellt wurden können My-Fans (bzw. my fans :-) das Ganze erst ausprobieren, wenn demnächst endlich die finale, öffentliche Beta 2 erscheint. Bis dahin kann man die Beispiele natürlich mit einem handelsüblichen Texteditor betrachten und sich in Vorfreude üben - ist ja bekannlich die schönste Freude (meines Erachtens ist dieses Sprichwort Schwachsinn. Ich will alles, und zwar jetzt. Aber das gehört ja nicht zum Thema.)

Viel Spaß also mit dem My-Template und selbstgebastelten Funktionen wie My.Computer.Needs.More.Memory etc...

So, ich bin wieder beim Bloggen und wünsche natürlich zunächst mal allen Lesern ein glückliches neues Jahr! Machen Sie nichts, was ich nicht auch machen würde!

Falls der Neujahrsvorsatz "mehr Sport" war, hätte ich da einen Tip: Die ASP.NET-Experten und -MVPs Christof Wille und Alex Zeitler spielen wieder Golf - und Sie können mitmachen! Allerdings handelt sich es hier um eine ganz spezielle Art von Programmierer-Golf... ich zitiere: "[...] die Idee ist simpel aber bestechend: beim „klassischen“ Golf gewinnt derjenige, der die geringste Anzahl Schläge benötigt um einzulochen. Und diese Idee haben wir auf das Programmieren übertragen: derjenige, der am wenigsten Zeichen zur Lösung einer vorgegebenen Aufgabe benötigt, der gewinnt das Turnier. Geschwindigkeit und Schönheit der Lösung sind keine Kriterien."

Also nix wie hin zu: http://www.codefairway.net/de/default.aspx.

Nachdem ich zwischen Weihnachten und Neujahr (wer braucht schon Urlaub) die Community-Seite für den msdn Techtalk auf mehr Browserkompatibilität getrimmt habe (ja, der Feuerfuchs darf jetzt auch drauf! ;-), und zwar im harten Kampf "Mann-gegen-tag", war ich reif für etwas Selbstfindung - und damit für den göttlichen CSS Zen Garden. Diese gar nicht esoterische Seite demonstriert wunderbar, was man mit CSS so machen kann. Unter "CSS ressources" sind einige unverzichtbare Infos für Webdesigner zu finden, z.B. die Tutorials von Maxdesign aus Australien, welche endlich mal das Mysterien von "float" und "clear" klären. Ommmmmm!

Tja, und wer schon Anfang des Jahres genug von allem hat, dem hilft nur noch die hoffentlich mittlerweile bekannte endgültige Nostalgieseite!

Zusammen mit meinem Kollegen Dirk Primbs war ich neulich bei GIGA TV zu Besuch - Anlaß war der GIGA Homepage Award. Unser persönlicher Biograph Frank Fischer, der eigentlich gerne Kameramann bei Steven Spielberg geworden wäre, hat ein Video daraus gebastelt, das hier zu bestaunen ist. Der Soundtrack ist übrigens hausgemacht von unserem Eventmanager Roberto Winckler, der schon einmal einen Nummer-eins-Hit in Neuseeland hatte (echt!). Viel Spaß!

Portalframeworks sind klasse: Alles, was man für eine Standard-Webseite braucht (Userverwaltung, Content Management, Listenankündigungendowloadbereichefotoalben und der ganze restliche Krams) als offener Sourcecode, erweiterbar durch eigene Module und mit eigenem Webdesign. Eins der beliebtesten Portalframeworks ist DotNetNuke (DNN)- leider ein durch und durch amerikanisches Projekt. DNN läßt sich in der aktuellen Version 2.x nämlich nur von Hand durch Eingriff in den Core-Sourcecode (argh!) lokalisieren. Mit Search & Replace wühlt man sich durch zehntausende Zeilen Sourcecode, um eigenhändig Stringliterale zu übersetzen und Datumsformate in die richtige Form zu trimmen. Und kommt die nächste Version raus, war dann alles für die Katz'. Das ist (hier stand ein zensiertes Wort)!

Aber Hoffnung naht: DotNetNuke 3.0 wird am 1. November released, und laut Aussage von DNN-Teamchef Shaun Walker gegenüber gut informierten Kreisen (mir ;-) kommt das Portal-Framework jetzt mit einer voll lokalisierbaren Engine inklusive bereits fertiger deutscher Lokalisierung! Ob das Ganze brauchbar ist, wird sich herausstellen.

Die Konkurenz vom Rainbow Portal ist offenbar schon weiter: Sie biet ihr Framework in 14 Sprachen an und hat auch sonst interessante Features wie z.B. einen 2-stufigen Abnick-Prozeß für Inhalte des Content Management-Systems. Leider kam ich persönlich noch nicht dazu, mir die DNN-Konkurrenz richtig anzusehen, aber vielleicht hat jemand schon Feedback zu diesem Thema? Sobald ich schlauer bin, was das Regenbogenportal betrifft, werde ich an dieser Stelle meine Erkenntnisse veröffentlichen.

Okay, als jemand, der sich öfters mit Security in ASP.NET befaßt ist es schon bitter zu schlucken, daß auch meine liebstes Web-Frameowork nicht gegen klassische Security-Fehltritte gefeit ist: ASP.NET hat ein Problem mit der Kanonisierung von URLs. Das hat nichts mit Musik zu tun, sondern beschreibt folgenden Sachverhalt:

Die Schreibweisen c:\dir\test.dat, test.dat, und ..\..\test.dat beziehen sich unter Umständen genau ein einziges File namens test.dat, es kommt, wie so oft, nur auf den momentanen Kontext an. Der Prozeß, wie ein Parser diese verschiedenen Schreibweisen einer identischen Angabe in eine einzige, maßgebliche Form umwandelt heißt Kanonisierung. Macht er dabei einen Fehler, hat man ein Sicherheitsproblem. Durch kreative Verwendung der Schreibweisen wird es dann nämlich einem Angreifer möglich, Schutzmechanismen zu umgehen - denn unter Umständen prüft der Parser auf eine Schreibweise und läßt keinen Zugriff auf das entprechende File zu, aber verwendet man eine andere Schreibweise, tja: dann kommt man damit durch.

Beispiel: Im Web ist Hallo Welt und Hallo%20Welt effektiv fast immer der gleiche String, da %20 eine alternative Kodierung eines Leerzeichens darstellt. Gehen wir jetzt davon aus, jemand darf nicht "Hallo Welt" eingeben. Unsere Strategie, dem Bösewicht auf die Finger zu hauen, sieht so aus:

If Eingabe="Hallo Welt" then Error

Und schon haben wir ein Problem: "Hallo%20Welt" fällt durch unser Raster, wird aber später im Programm vermutlich irgendwo zu "Hallo Welt" umgewandelt - und weiterverarbeitet. Bingo. Hätten wir die Umwandlung aller möglichen Schreibweisen schon vor der Prüfung durchgeführt (und dabei keine Fehler gemacht) dann wäre unsere Prüfung wasserdicht. Leider ist das Ganze nicht so einfach wie es aussieht. Denn manchmal ist es gar nicht so einfach, zu erkennen wieviele alternative Darstellungsmöglichkeiten es eigentlich gibt, besonders wenn vor- und nachgeschalteter Programmcode, oft gar nicht unter eigener Kontrolle, böse dazwischenfunkt.

Also: Wer selber ohne Kanonisierungsprobleme ist, der werfe den ersten Stein. Statt Steinewerfen empfiehlt es sich aber meistens sowieso, sofort Gegenmaßnahmen einzuleiten.

 

Tja, Ralf Westphal hat mir das Buch "Getting Things Done" empfohlen. Ich will dieses Werk jetzt schon seit 2 Tagen bestellen, aber ich komme einfach nicht dazu...

Erste Erkennis meines mir und der Welt gegenüber gnadenlosen Selbstversuchs:* Blogging verleitet zum Predigen.

*Ist das wirklich Grammatik?

Ich lese das Interview mit Michael Kofler in der Süddeutschen über Linux und Open Source und frage mich, wie immer bei solchen Diskussionen: Warum soll ich die Früchte meiner Arbeit herschenken? Warum beschwert sich keiner, daß es für andere technische Produkte Patente und Lizenzen gibt? Warum ist das bei Software plötzlich ein Problem? Wäre es nicht besser für die Menschheit, wenn KIA einfach einen Porsche kopieren dürfte? Das würde dafür sorgen, daß es weniger Innovation gibt - weil niemand mehr in aufwendige Entwicklungen investieren wollte, wenn andere die Früchte ernten. Ich kapier's einfach nicht, und das liegt - so hoffe ich - nicht daran, daß ich bei Microsoft arbeite.

Auf Konferenzen erklären viele Leute mir erstmal, daß Sie für Open Source sind, um dann sofort danach zu fragen, wie sie ihren eigenen Code per Obfuscator besser gegen den Ideenklau anderer absichern können. Da ist plötzlich das Problem, daß .NET-Code "zu offen" ist?  "Ich will die Eier und das Mehl gratis, aber den Kuchen möchte ich verkaufen".

Ich vermute: Die erwähnten großen Beiträge von anderen kommerziellen Firmen zu Open Source beruhen darauf, daß diese nicht am Kuchen verdienen, sondern beim Backen helfen - und sich dafür bezahlen lassen. Und deren Werbung erklärt dann, der Kuchen wäre gratis. Clever.

Neulich  bei einer großen Entwicklungskonferenz: Zwei Programmierer, verantwortlich für Intranet-Webapplikationen in einer großen Firma, stellen eine harmlose Frage am Microsoft-Stand: "Wie kann man eigentlich aus einer ASP.NET Webapplikation eine Prozeß mit bestimmten Benutzerrrechten starten?". Meine Antwort: "Äh, mit CreateProcessAsUser oder so, glaube ich ... äh, ich denke das war doch LogonUser... also jedenfalls gibt's in Windows dafür eine Funktion, die können Sie aufrufen, äh --- warum brauchen Sie diese Funktion?". Die Antwort läßt mir das Blut in den Adern gefrieren: "Ja, wir müssen auf dem Server eine Applikation starten, die unter den Benutzerrechten des jeweiligen eingeloggten Users läuft. Und da dachten wir, der Benutzer kann seine Domänen-Anmeldedaten einfach in unsere Webapplikation eingeben und wir starten dann auf dem Server mit diesem Account die entsprechende Applikation". Vorsichtige Frage von mir: "Verwenden Sie HTTPS?". Antwort: "Nein, wieso?".

Wenn das so online geht, sendet diese Firma völlig unverschlüsselte Domänen-Usernamen mit passendem, ebenfalls unverschlüsselten Paßwörtern quer durch's Intranet. Jeder, der den Netzwerkeverkehr irgendwie mitprotokolliert, hat die Chance auf unlimierterten Zugriff auf geheimste Daten. Ich weise die Zwei darauf hin.

"Ach, das macht nix, ist ja alles nur innerhalb unserer Firma, und deshalb sicher".

Bitte nicht falsch verstehen: Ich möchte die Zwei nicht schlecht machen, oder über irgend jemand herziehen. Aber diese kleine Geschichte ist der Beweis, daß Security kein Thema ist, welches "die von Microsoft" oder "die von Sun" oder "die von IBM" durch "bessere Sicherheitsfeatures" lösen können. Keine IT-Sicherheit ohne Sicherheitsbewußtsein und Kenntnis der Grundlagen der Technologien, mit denen man arbeitet.

Fingerzeigen bringt uns auch nicht weiter: "Microsoft" ist nicht "unsicher", "Sun" ist nicht "unsicher", "IBM" ist nicht "unsicher". Unsicher ist, Ausbildung und Aufklärung zu vernachlässigen, oder sich nicht für Security zu interessieren.

Die Entwickler und Entscheider wiegen sich in falscher Sicherheit: "Wird schon niemand abhören". Falsch: Jemand wird sich finden. Jemand der gerade Streit mit seinem Chef hatte und zufällig in der IT-Abteilung arbeitet. Wenn das passiert, sind  Existenzen bedroht - von einzelnen Sündenböcken (wahrscheinlich die Entwickler oder ihr Chef) oder ganzen Firmen.Und wer gibt den Programmierern Zeit, sich mit sichereitsrelevanten Fragen zu befassen? Sind die ökonomischen Zwänge so groß, daß für relevantes Training keine Zeit bleibt?

Da muß sich die Industrie an der eigenen Nase fassen: Wir brauchen viel mehr verständliche Informationen über Sicherheit, wir müssen klarmachen das Security kein Feature ist (wie ein großer Datenbankhersteller unermüdlich behauptet). Microsofts Security Whitepapers sind ein erster Schritt, und die Security-Vorträge auf Konferenzen sind in letzter Zeit auch gut besucht.

Ach ja, was ist die Lösung für das Problem der Beiden? Eine zweite Webapplikation, die über Windows Authentication authentifiziert und den Benutzer impersoniert, dann die Applikation startet. Kein Passwort wird ausgetauscht, und das Ganze ist auch bequemer, weil der Benutzer nichts eingeben muß.

Security: Mach's nie ohne!

Hmm... gute Frage. Oft finde ich Blogs ein Instrument zur gnadenlosen Selbstbeweihräucherung (mit Tendenzen zum Exhibitionismus), frei nach dem Motto: "Was ich der Welt schon immer mal sagen wollte." Aber da das Ganze immer mehr zum Phänomen wird und ich nie abgeneigt bin, gefährliche (aber legale) Dinge im Selbstversuch auszuprobieren werde ich jetzt mutig in die Welt der Blogger eintreten. Ok, jetzt muß ich nur noch den Post-Button finden... ah hier ... also los ...

 
Page view tracker