Vortrag „Relaunch mit Web-Agenturen: Spiel, Spaß und Spannung“

Ende April halte ich ein Vortrag unter dem Titel „Relaunch mit Web-Agenturen: Spiel, Spaß und Spannung“.

Ausnahmsweise soll es dabei nicht darum gehen, was passiert,wenn eineprofessionelle und seriöse Webagentur ein gutes Design abliefert, der Kunde es aber durch schlechte Bedienung und Nichteinhalten eines Redakteurshandbuch „versaut“. Diese Fälle sind ja oftmals bekannt. Mir geht es darum mal eine andere Sicht aufzuzeigen, die ebenfalls leider sehr häufig auftritt: Was passiert eigentlich, wenn Agenturen mehr versprechen als sie halten können, wenn Agenturen ungeprüft jeden technischen Begriff aus vielleicht unbedarften Auftraggebermund für bare Münze halten und umsetzen oder auch wenn Agenturen nach aussen mit Kompetenzen werben, diese aber bei den konkreten Kunden-Webprojekt garnicht anwenden.

Seit etwa 1999 bin ich an einer Universität quasi Provider für Webauftritte. Und als Provider liefern wir zwar Webspace, haben aber darauf was und wie die einzelnen Einrichtungen ihre Sites dann machen wenig Einfluß. (Allein schon wegen der Haftungsproblematik halten wir uns raus). Wir bieten es auf freiwilliger Basis an, daß wir unverbindlich und ergebnissoffen beraten. Diese Beratung wird allerdings oft erst in Anspruch genommen, wenn das Kind schon in den Brunnen gefallen ist: Wenn sich herausstellt, daß der Sohn des Bekannten doch nicht so recht hatte, als er sagte, daß heutzutage gute Websites nur in Flash gehen; Oder als der Webauftritt von der eine Agentur behauptete, sie sei barrierefrei schon bei einer einmaligen Schriftvergrößerung auseinanderfällt. Seit 1999 hab ich davon einige Beispiele sammeln dürfen.

Um den Vortrag aufzulockern möchte ich jedoch einige weitere Beispiele aufführen.

Daher stelle ich hier die Frage: Wer hat besonderes schöne Beispiele, Anekdoten oder Erfahrungen gesammelt und würde diese hier in den Kommentarbereich oder via E-Mail an mich teile, so daß ich daraus zitieren könnte? (Auf Wunsch gern mit oder auch ohne Namensnennung).

 

 

Flattr this!

Was Print-Designer für die Umsetzung eines Webdesigns liefern müssen

(Vorbemerkung: Dieser Artikel hat noch kein Endzustand erreicht und wird noch nach und nach durch das eingehende Feedback korrigiert und erweitert.)

Das Webseiten keine Gemälde sind und die Gestaltung für das Web anderen Regeln gehorcht als bei der Print- oder Screengestaltung wurde bereits in vielen Artikeln von Experten ausführlich und in nahezu epischer Breite beschrieben.
Stellvertretend für viele Artikel verweise ich auf den aktuellen Artikel von Marc Hinse, ein professioneller Webdesigner und Webentwickler, der in klaren und offensichtlichen Beispielen die wichtigsten Dinge aufzeigt: Web ≠ Print

Ein Rant zum Einstieg

Trotz der großen Zahl an Artikeln, Büchern und Studien (insbesondere solche die die Themen Usability und der Barrierefreiheit behandeln) gibt es immer noch sehr viele Agenturen und Screen/Print-Designer, die glauben mit der Erstellung einer Photoshop-Vorlage sei alles getan um ein Webdesign fertig zu stellen; Und nun müsse nur noch ein „Programmierer“ es einfach umsetzen.
Noch schlimmer: Es gibt sogar Studiengänge oder Kurse die damit werben, daß man in diesen die Erstellung von Webdesigns erlernt; bei denen allerdings nur Grundlagen von HTML 4.0 (!) gestreift werden, der Schwerpunkt aber nur daraus besteht, (zugegebenermaßen) schöne Grafiken mit Photoshop zu erstellen.

Doch genug geschimpft, kommen wir zur Sache.

Was braucht ein Webdesigner von einem Print-Designer?

Es gibt Situationen bei denen man nicht umhin kommt, doch die Vorlage eines Print-Designer umzusetzen.
Die Ausgangslage ist die folgende: Kunde hat sich von einer Print-Agentur beschwatzen lassen, ein Design von der Agentur zu nehmen. Ein Webdesigner soll dieses Design danach umsetzen. Was braucht er dazu?

Die Photoshop-Vorlage für die Startseite eines größeren Webangebotes ist allenfalls der allererste und einfachste Schritt. Marc Hinse beschreibt in seinem Artikel ausführlich woran es Print-Designs mangelt. Dies kann als Orientierung genutzt werden, was ein Screen-Designer zusätzlich liefern muss.
Die folgende Auflistung soll versuchen, dies zusammenzufassen.

Grundlegendes

Vor der Umsetzung sollte eine Prüfung der Vorlage stattfinden auf visuelle und logische Fehler, sowie anderer offensichtlicher Mängel in Bezug auf Usability und Barrierefreiheit.

  • Farbkontraste: Wenn unterschiedliche Farben verwendet werden für Texte und Hintergründe, ist zu prüfen ob die Kontraste ausreichend sind. Als Anhaltspunkt können hier die gängigen Formeln aus der barrierefreien Gestaltung von Webauftritten herangezogen werden.
  • Navigation und aktuelle Position auf der Website: Wie wird bei einzelnen Unterseiten die aktuelle Position innerhalb des Webauftritts dargestellt? Ist eine entsprechende Navigation enthalten? Gibt es eine Vorlage für eine Inhaltsübersicht in Baumform und einer in alphabetischer Ansicht?
  • Optische Bedienelemente: Gibt es rein optische Bedienelemente, die verlangen, daß Surfer sie auch optisch genauso wahrnehmen und nutzen können, wie der Design?
  • Scrolling: Welches Scrollverhalten für Inhaltsbereiche ist vorgesehen? Kann es etwa passieren, daß Texte aus dem Sichtbereich verschwinden, nur weil der Surfer eine größere Schriftart verwendet?
    Welches optische Verhalten ist für Überschriften oder Slogans im Kopf der Seite vorgesehen, sollten diese auf zwei oder mehr Zeilen umbrechen?
  • Formulare: Haben alle Formulare erkennbare Absendebuttons?

Vorlagen für unterschiedliche Seitentypen

Ein Webauftritt besteht aus unterschiedlichen Typen von Seiten. Für alle diese Typen muss eine Vorlage geliefert werden, wenn diese Typen vorhanden sind:

  • Startseite
    Die Eingangsseite der Webpräsenz.
  • Doorway-Page
    Hinweis: Doorway-Pages sollten nur in Ausnahmefällen verwendet werden. Für normale Webauftritte, derren Schwerpuntk auf der Informationsverbreitung liegt, sollten Doorway-Pages nicht mehr zum Einsatz kommen. Am Besten verzichtet man auf dieses Relikt des letzten Jahrtausends!

  • Inhaltsübersichten / Inhaltsindex
    Bei komplexen Seiten reicht eine Navigation meist nicht aus, es muss auch eine Inhaltsübersicht und/oder ein alphabetischer Seitenindex geliefert werden. Dabei handelt es sich dann auch meist um eine umfangreiche Liste, derren optische Darstellung definiert sein sollte.
  • Fehlerseiten
    Falls ungültige Adressen auf der Webseite aufgerufen werden, der Zugriff fehl schlug oder es zu einer anderen Art von Fehler kam.
  • Ausgabeseiten für Suchergebnisse
    Falls der Webauftritt eine Suchmaske anbietet, muss definiert werden, wie das Ergebnis der Suche aussieht.
  • Seiten mit Formularen
    Sind Eingabeformulare auf dem Webauftritt vorhanden, müssen diese vollumfänglich dargestellt werden. Dabei müssen alle üblichen Eingabemasken und Bedienmöglichkeiten definiert sein: Eingabemasken für Texte (sowohl mit aktiven Cursor als auch ohne), Auswahllisten, Checkboxen, Radioboxen und Absendebuttons.
    Bei textuellen Eingabemasken, sowie bei Auswahllisten ist anzugeben, ob es ein Default-Element gibt, welches sichtbar ist, wenn die Eingabemaske oder Auswahlliste nicht aktiv ist.
  • Seiten mit viel Text, Seiten mit ganz wenig Text
    In der klassischen Vorlage eines Print-Designers ist Mustertext immer schön passend lang, damit die Seite optisch gut aussieht.
    In der Praxis allerdings gibt es unterschiedlich lange Texte. Die Länge des Textbereiches hat Einfluß auf das Scrollverhalten der Seite. Daher sind für beide Varianten Vorlagen zu liefern. Bei der Variante mit viel Text, muss dieser so lang sein, daß der gesamte Text nicht auf einer Bildschirmseite darstellbar ist. Nur so kann der Webdesigner erkennen, wie die Seite mit Scrollbalken auszusehen hat.
  • Seiten mit kleiner Schriftgröße, Seiten mit großer Schriftgröße
    Damit klar ist, wie sich das Webdesign verhält, wenn Surfer mit unterschiedlich eingestellten Schriftgrößen die Seite besuchen, sind mindestens 4 Beispielvorlagen für folgende Varianten zu liefern:

    1. Startseite mit Schriftvergrößerung auf 150%
    2. Startseite mit Schriftverkleinerung auf 75%
    3. Inhaltsseite mit Schriftvergrößerung auf 150%
    4. Inhaltsseite mit Schriftverkleinerung auf 75%
  • Seiten mit Bildern in den Textbereichen
    Verwendete Bilder in Textbereichen können in Größe und Position variieren. Zudem ist ihre Darstellung auch abhängig davon ob sie von Text umflossen werden sollen oder nicht. Daher muss eine Vorlage vorhanden sein, die zeigt, wie sowohl kleine Bilder (bis zu einer Größe von 300px in Höhe und Breite), als auch wie große Bilder (bis zu einer Größe von 1024px Breite und 800px in der Höhe) dargestellt werden sollen.
    (Diese Vorlage können ggf. mit der Vorlage der Seiten mit viel Text kombiniert werden.)

  • Sonstige spezielle Inhaltsobjekte und „Web 2.0“-Elemente
    Wenn die Seite verschiedene eingebettete Objekte enthält, wie beispielsweise YouTube-Videos, Werbebanner und Werbetextbereiche, diverse Web 2.0-Bookmarklets, Feeds aus Blogs oder anderen Medien, dann muss auch hier die Position und die Art der Darstellung definiert sein.

    Ausserdem gibt es oft einige textuelle Informationen, die ebenfalls gesondert dargestellt werden sollten. Beispielsweise die „Personen-Visitenkarten“ bei einer Wir über uns-Seite oder die Kontaktdaten in einem Impressum.

Vorlagen für verschiedene Ausgabeformate

Neben der Vorlage für die Darstellung mit Webbrowsern müssen ebenso Vorlagen geliefert werden für die Darstellung derselben Seite mit folgenden Medien:

  • Print
  • Handheld
  • Screenreader

Bei den unterschiedlichen Ausgabemedien sollte zudem bedacht werden, daß Bereiche der Webseite bei diesen gegebenfalls obsolet sind oder aber ob welche zusätzlich definiert werden müssen, die in der Monitordarstellung jedoch fehlen:

  • Bei der Print-Darstellung ist die optische Darstellung von Links und Menüs zu hinterfragen. Einige Links machen bei der Print-Ausgabe keinen Sinn mehr und sollten daher dann unsichtbar sein.
  • Bei der Print-Darstellung könnte möglicherweise eine für Print-Publikationen andere Corporate Design-Vorgabe für den Kopfteil der Seite gelten.
  • Bei der Handheld- und Screenreader-Darstellung sind etwaige vorher unsichtbare Skiplinks sichtbar zu machen.

Unterstützung verschiedener Fensterauflösungen

Wenn ein Print-Designer anhand der obigen Anforderungen noch nicht verzweifelte und laut über diese unangemessenen Nachfragen des unwürdigen Code-Sklavens geflucht haben, wird er gleich möglicherweise völlig aus der Haut fahren. Denn nun wird sich heraus stellen, ob das ganze Design überhaupt was wert ist: Wie soll das Design denn bei verschiedenen Fensterauflösungen reagieren?

Folgende Vorlagen sind zu liefern:

  • Startseite mit Auflösungen von
    1. 1600×900 Pixel (neuer 16:9 Bildschirm)
    2. 1024×800 Pixel
    3. 950×500 Pixel
    4. 600×320 Pixel und 320x600Pixel (für diverse ältere Handhelds)
  • Textseite, die auch Bilder enthält mit Auflösungen von
    1. 1600×900 Pixel (neuer 16:9 Bildschirm)
    2. 1024×800 Pixel
    3. 950×500 Pixel
    4. 600×320 Pixel und 320×600 Pixel (für diverse ältere Handhelds)

Ein Anhaltspunkt und Hintergrundinformationen liefert u.a. die Seite Browser Size von Google.

Verwendete Bilder

Alle für die Vorlage verwendeten Bilder (insbesondere bei Hintergründen zu Bereichen der Webseite) müssen einzelnt geliefert werden. Die Bilddateien sollten dabei möglichst im Orginal und in einem der gängigen Bildformate JPG, GIF, PNG, TIFF geliefert werden. Keinesfalls sollten Bilder vom Print-Designer selbst verkleinert werden. Bilder, welche in einem Word- oder PDF-Dokument embedded werden, sind nicht nutzbar.
Ausserdem müssen alle verwendeten Logos, die auf der Webseite dargestellt werden sollen, geliefert werden.
Für den Fall, daß Hintergrundbilder in einer oder zwei Dimensionen wiederholbar sein sollen, muss die Vorlage des Bildes entsprechende Ränder haben, die einen fließenden Übergang erlauben.

Verwendete Schriften

Wenn die Webseite verschiedene Schriften verwendet, sind diese anzugeben. Zusätzlich müssen zu jeder Schrift mindestens 2 weitere Alternativschriften genannt werden, die dann verwendet werden, wenn die favorisierte Schrift nicht verfügbar ist.
Weiterhin muss für den Fall, daß keine der drei Schriften verfügbar ist, angegeben werden, ob es sich um eine Serifenschrift handelt oder nicht.

Schriftgrößen

Für alle Bereiche der Homepage in der Texte dargestelt werden, sind die exakten Schriftgrößen anzugeben. Allerdings sollte nur der Haupttextbereich (=Inhaltsbereich) in der Größenangabe Pixel oder Point fest definiert werden. Die Schriftgrößen aller anderen Textbereiche werden dagegen proportional zu der Größe des Haupttextbereiches definiert werden.

Schriftgrafiken

Werden Schriftgrafiken verwendet, sind die dafür verwendete Schriftarten und Schriftgrößen ebenso wie bei den normalen Textbereichen anzugeben. Handelt es sich bei den Schriftgrafiken um Grafiken, bei der es zu keinen besonderen grafischen Modifikationen kam, werden diese vorzugsweise vom Webdesigner verworfen und über normale Texte dargestellt, derren Optik mit Hilfe von CSS an die Vorlage angepasst wird.

Reaktion bei Maus- und Tastaturbedienung, sowie Hovereffekte

Der aktuelle Fokus des Cursors (sowohl bei Maus- oder Tastaturbedienung) von Links ist sichtbar zu machen. Dies gilt für:

  • Links in der Navigation
  • Links in Textbereichen
  • Links auf Grafiken
  • mit der Tastatur angesteuerte aktive Skiplinks
  • weitere mit Maus oder Tastatur angesteuerte reaktive Bereiche, die zu einer Aktion führen (Buttons, Ajax-Schaltflächen, usw.)

Zusätzlich muss definiert werden, wie ein selektierte Objekte (Texte und Bilder) in den jeweiligen Bereichen der Homepage aussieht.

Farben

Texte, Links, Hintergründe, Ränder und Bereiche haben unterschiedliche Farben. All diese müssen in RGB-Werten angegeben werden.
Zusätzlich sollte man bei Farbübergängen von Flächen die Start- und die Endfarbe angeben.

Verwendete Mustertexte

Wie oben bereits beschrieben, sollten die Vorlagen sowohl kurze, wie auch lange Texte beinhalten. Häufig wird dabei zurückgegriffen auf das bekannte Lorem Ipsum.
Leider fehlt es dem Lorem Ipsum-Text, wie auch meisten anderen Mustertexten, an unterschiedlichen Textarten. Beispielsweise Tabellen oder Zitate. Wenn der Webdesigner ein CSS entwerfen soll, muss dieser jedoch auch wissen, wie auszusehen haben.
Ein idealer Mustertext sollte daher folgende Elemente enthalten:

  • Tabellen (mit mindestens 3 Zeilen und Überschriftenzeile, sowie mindestens 3 Spalten und Bezeichnungsspalte)
  • Zitate (sowohl innerhalb eines Absatzes als auch in Form eigener Absatzzitate)
  • Akronyme und Abkürzungen
  • Listen (ungeordnete Listen, geordnete Listen; dabei auch Listen in Listen).
  • Zitate oder Absätze in anderen Sprachen

Postionen und Ausrichtung von Bereichen

Falls in der Vorlage verschiedene Bereiche definiert wurden (zum Beispiel zwei nebeneinander stehende Textblöcke), ist zu definieren, wie diese zueinander positioniert sind und welche Textausrichtung genutzt werden soll.
Über die oben genannte Vorlage für kleinere Bildschirmauflösungen soll dabei auch gezeigt werden, wie die Textbereiche dargestellt werden, wenn der zur Verfügung stehende Platz nicht ausreicht, diese nebeneinander zu positionieren.

Rechtliche Aspekte

Viele Print-Designer greifen zurück auf ein großes Archiv von Bildern verschiedener Quellen. Diese werden z.B. für Hintergründe, als Schmuckgrafiken oder zur emotionellen Ansprache benutzt.
Beispielsweise finden sich auch Fotos von Menschen dabei, die in der eine oder anderen Situation aufgenommen wurden und sich damit eignen eine werbende Botschaft zu überbringen.
Hier ist zu hinterfragen, ob die Bilder überhaupt für die Nutzung im Internet frei gegeben sind, ob diese entsprechende Lizenzen haben. Dies gilt ganz besonderes auch dann, wenn nur einzelne oder wenige Personen abgebildet sind.
Die Vorlage einer Nutzungslizenz für eine begrenzte Auflage von Print-Publikationen reicht nämlich keinesfalls aus um das Recht zu erlangen, selbige Bilder weltweit abrufbar im Internet zu verbreiten.

Alles da? Dann los

Erst nachdem all das obige geliefert wurde, kann ein Webdesigner daran gehen, das Design für einen Webauftritt umzusetzen.
Sollte etwas fehlen, wird es zwangsläufig zu Rückfragen kommen. Dies kann auch sehr schnell sehr teuer werden. Beispielsweise dann, wenn Teile bereits umgesetzt wurden, sich dann aber herausstellt, dass aufgrund von mangelhaften Vorlagen (z.B. das Verhalten der Seite beim Einsatz von großen Bildern im Inhaltsbereich) die grundlegende Gestaltung nochmals neu gemacht werden muss.

Fazit

Das der Aufwand, den ein Print-Designer leisten müsste um all die oben definierten Informationen zu liefern sehr hoch ist, dürfte offensichtlich sein.
Der Aufwand dürfte eher selten wirklich geleistet werden. Trotzdem hab ich bislang keine andere ausreichende Checkliste gefunden, die alles auflistet, was ein Webdesigner im Idealfall bekommen sollte. Daher sehe ich diese Auflistung als idealtypischen Orientierungsrahmen an.
In der täglichen Praxis erwarte ich jedoch nicht, daß dieses Ideal erfüllt wird. So schön es auch wäre. Denn wenn alls richtig laufen würde, dann bräuchte man sowas garnicht:

Denn besser und kostengünstiger ist es immer noch, ein Webdesign gleich von einem richtigen Webdesigner entwerfen zu lassen, der dann das Print-Design zusammen mit dem Handheld- und Screenreader-Design erstellt.

Wenn ich meine Wohnung streichen lassen will, werde ich auch zum Maler gehen. Und nicht zum Lackierer.

Eine ebenfalls gute Variante wäre noch, wenn Webdesigner und Print-Designer noch während der ersten Erstellungsphase einer Vorlage schon zusammen und Hand-in-Hand arbeiten.

Weitere Links zum Thema

Flattr this!

Komische IT-Agenturen

Gerade hab ich zufällig bei einer IT-Agentur etwas komisches im HTML-Text gefunden.
Dort steht wirklich folgende HTML Metatag-Angabe:

(Zeilenumbrüche von mir eingefügt)

Na, wer findet die beiden Worte auf die ich anspiele?

Hier nochmal als Screenshot, falls es geändert wird:
Screenshot des Source Codes einer IT-Agentur: Neben sehr viele IT-Fachbegriffen tauchen darin auch auf: Babysitter und Leihopa...

Ok, über eine IT-Agentur, die behauptet alle die genannten Fachbegriffe gleichzeitig kompetent vertreten zu können -und dies im Jahr 2010 noch auf einer Webseite tut, die in Tablelayout gestaltet ist und auf eine fixe 800x600px Bildschirmauflösung optimiert ist, darüber mag man denken was man will.

Aber zwei Dinge kann man festhalten:

  1. Das Buzzword SEO fehlt zu recht in den Keywords.
  2. Entweder laufen die Geschäfte doch mitunter nicht so gut, dass die Leute auch mal als Babysitter arbeiten, oder aber sie haben Humor. Und das wäre doch was positives.

Flattr this!

CGI Security / Sichere CGI-Skripten – Eine Einführung

1. Allgemeines

Die Programmierung von CGI-Skripten und -Programmen ist im Prinzip nicht schwerer als die von ganz normalen Programmen, die nicht das Common Gateway Interface benutzen. So ist die Wahl der Programmiersprache in der Regel nicht eingeschränkt (sieht man von den Einschränkungen bzgl. dem Betriebssystem und/oder den Provider ab) und wenn man nur etwas im Internet sucht, findet man zu quasi jeder Sprache Beispiele und Ressourcen.
Lange Zeit war die CGI-Programmierung die Aufgabe von wenigen Webmastern oder Systemadministratoren. Die Provider ließen in der Regel keine Benutzereigenen Skripten auf Ihren Server zu und wenn, dann gegen entsprechenden Aufpreis.

Heutzutage jedoch ist die Situation grundlegend verändert: Ein CGI-Verzeichnis gehört zum Standard von fast jedem kommerziellen Webspace-Angebot und die Zahl der Skript-Archive im Netz nimmt immer weiter zu.
Hiermit verbunden ist die Entwicklung, daß immer mehr Skripten auftauchen, welche zum Teil grobe Sicherheitslöcher haben. Dies nicht nur bei den kostenlosen, sondern auch bei den kommerziellen Skripten. Das Bulletin Board System der Infopop Corp. welches im März 2000 in der Security-Mailingliste BugTraq zu trauriger Berühmtheit gelangte, ist nur ein Beispiel von vielen. Dabei ist das Sicherheitsloch im UBB auch aus anderer Sicht ein interessantes Beispiel: Es zeigt auf, wie leicht viele Leute sich im Netz durch bekannte Namen oder große Dienste einlullen lassen; Selbst wenn der Code als Open Source vorliegt, schauen kaum Leute rein und prüfen diesen. So wurde ein Umfrageskript, welches auf dem bekannten CGI-Archiv The CGI Resource Index lag, über 750 mal von unterschiedlichen Personen im Ranking bewertet, aber nicht einer bemerkte das Sicherheitsloch, welches Hackern Tür und Tor öffnete.

In den meisten Fällen beruhen die Sicherheitslöcher auf folgende Aspekte:

  • Unsaubere Programmierung,
  • Unkenntnis der Sicherheitsprobleme,
  • eine ‚lachse‘ Grundhaltung („Wer sollte schon bei mir einhacken?“),
  • Geldgier von Archiv-Betreibern (Die große Anzahl der Skripten zählt. Alles andere ist unwichtig).

Was benötigt wird, ist eine Sensibilisierung der Webmaster und Sitebetreiber, die solche Skripten einsetzen in Bezug auf Sicherheitsaspekte. Dies erfordert aber auch eine Möglichkeit zur Einteilung der Sicherheitsaspekte, derren Gründe und Folgen.
Auf der folgenden Seite werden wir eine solche Einteilung vornehmen. Danach gehen wir anhand der Programmiersprache Perl ins Detail und zeigen anhand von Beispielen die typischen Fehler und Probleme.

2. Klassifikation von CGI-Programmen

Die folgende Auflistung definiert eine Klassifikation für CGI-Programme. Sie basiert auf die Auswirkungen, die eine möglicherweise vorhandene Sicherheitslücke haben kann und deren Gefährdungspotential.
Die Gefährdung des Webservers durch Prozessorlasten aufgrund von massenhaften Zugriffen werden nicht berücksichtigt, da dies nur indirekt ein Problem für CGI-Programme ist und den Server auch ohne ein solches Programm beeinträchtigt. Ebenso unberücksichtigt sind benutzerbezogene Sicherheitsprobleme, die auf mangelnde Kenntnisse des Systemadministrators oder des Benutzers auf einem Server zurückgehen. (Beispiel: Benutzer, die ihre Skripte global schreibbar machen, bzw. Provider, die dies empfehlen.)

Beschreibung Mögliche Folgen und Beispiele Gefährdungspotential
Sicher
Es liegen nur definierte Zustände vor; Das Programm fängt sowohl „gleichzeitige“ Zugriffe ab, als auch Brute-Force-Attacks.
Dateizugriffe beschränken sich auf festgelegte Dateinamen, die durch das Skript nicht geändert oder generiert werden.
Einzelne Benutzer werden als solche eindeutig identifiziert oder eindeutige Benutzer als Aufrufer werden nicht benötigt.
Keine Folgen. Diese CGI-Programme können als ’sicher‘ eingestuft werden.

Beispiel: Counter, die ‚atomare Zugriffe‘ erlauben, Banner- und Textrotatoren ohne Logfunktionen, …


keine Gefahr
Logische bzw. systematische Gefährdung
Es liegen nur definierte Zustände vor; Das Programm fängt sowohl „gleichzeitige“ Zugriffe ab, als auch Brute-Force-Attacks.
Diese Programme realisieren interaktive Abfragen, die auf einzelne Benutzer als ‚Kunden‘ abzielen, jedoch keine direkte Auswirkung auf allgemein wirksame Ergebnisse haben.
Durch die Begrenztheit der Environment-Variablen bzw. eines ungesicherten Zugangs zum betreffenden Skript (keine Passwort-Abfragen/SSL oder änliches) ist die Identifikation von Benutzern jedoch nicht garantiert. Eingeschlossen sind auch Skripte, die Cookies zur Identifikation heranziehen, da Cookies durch den Benutzer modifiziert oder abgelehnt werden können.
Benutzereingaben können unter Umständen mehrfach oder durch falsche Personen ausgeführt werden.

Beispiele: Gästebücher, die ansonsten sicher sind, Benutzerbasierte Zugriffsstatistiken

Prominentes Beispiel: -eigentlich jedes Gästebuch, auch das von xwolf-

Anmerkung: Man muß hier, wie auch bei der folgenden Stufe beachten, daß das Preis-Leistungs-Verhältnis eine große Rolle spielt. Niemand wird einen wirklich sicheren Server einrichten und die Benutzer zur eindeutigen Identifikation zwingen, nur um ein Gästebuch anzubieten.

Stufe I.
unwesentlich bis ärgerlich
Globale logische Gefährdungen
Es liegen nur definierte Zustände vor; Das Programm fängt sowohl „gleichzeitige“ Zugriffe ab, als auch Brute-Force-Attacks.
Diese Programme realisieren interaktive Abfragen, die auf einzelne Benutzer als ‚Kunden‘ abzielen und global wirksame Ergebnisse liefern.
Durch die Begrenztheit der Environment-Variablen bzw. eines ungesicherten Zugangs zum betreffenden Skript (keine Passwort-Abfragen/SSL oder änliches) ist die Identifikation von Benutzern jedoch nicht garantiert. Eingeschlossen sind auch Skripte, die Cookies zur Identifikation heranziehen, da Cookies durch den Benutzer modifiziert oder abgelehnt werden können.
Benutzereingaben können unter Umständen mehrfach oder durch falsche Personen ausgeführt werden. Globale Ergebnisse können somit von außen beeinflußt werden.

Beispiele: Umfragen / Polls, Seiten- und Linkratings

Prominentes Beispiel: Die Online-Zeitschrift Internet World benutzte ein Skript für aktuelle Umfragen. Die Personen, welche an den Umfragen teilnahmen wurden durch die Environment-Variablen für die Adresse und den User-Agenten für einen fest definierten Zeitraum unterhalb 5 Minuten identifiziert.
Folge: Wer nach 5 Minuten wiederkam, oder die Seite mit einem neuen Browser und/oder von einer anderen Adresse aus, aufrief, konnte nochmal abstimmen.

Anmerkung: Bitte beachten Sie hierzu auch den obigen Hinweis.

Stufe II.
mittel bis bedenklich
Nichtatomare schreibende Dateizugriffe
Das Programm bzw. das Betriebssystem ist nicht in der Lage mehrere Prozesse und Dateizugriffe gleichzeitig zu verwalten ohne das es zu Konflikten kommt.
Inhalte von Dateien können zerstört werden ohne das der Grund eine Hackerattacke sein muß; Stattdessen kann es irgentwann im ‚Normalbetrieb‘ zum Ausfall kommen, sobald nur 2 Benutzer zur selben Zeit das Skript aufrufen.
Je nach Sinn und Zweck des Programmes und der betroffenen Daten kann dies fatale Folgen für den Anbieter haben.

Beispiele: Alle Arten von CGI-Skripten, die ohne Locking auf Dateien schreibend zugreifen

Prominentes Beispiel: Das WWWBoard von Matt Wright benutzt keine Mechanismen zur Vermeidung des gegenseitigen Dateizugriffs.

Anmerkung: Dieser Fehler tritt bei allen Programmen und Betriebssystemen auf, die keine atomare Zugriffskontrolle für Dateien nutzen. (Ca. 90% aller kostenlosen Programme sind betroffen.)

Stufe III.
bedenklich
Ungeprüfte Dateizugriffe durch Benutzer
Das Skript greift über ungeprüfte Benutzereingaben auf vorhandene Dateien zu (Dateinamen sind jedoch fest codiert.). Benutzer haben die Möglichkeit den Inhalt von programmspezifischen Dateien zu ändern, obwohl dies den vordefinierten Strukturen dieser Dateien wiederspricht.
Inhalte von Dateien können zerstört oder unbrauchbar gemacht werden. Die zukünftige Ausführung des Programmes kann somit von außen unterbunden werden.
Je nach Sinn und Zweck des Programmes und der betroffenen Daten kann dies fatale Folgen für den Anbieter haben.

Beispiele: Alle Programme, welche Schreibend auf strukturierte Dateien zugreifen, wobei der neue Inhalt nicht nach seiner Syntax überprüft wird.

Prominentes Beispiel: Das Gästebuch von Matt Wright hat per Default HTML-Tags zugelassen und schreibt in eine HTML-Datei die neuen Einträge jeweils an der Stelle, wo in einer Zeile der String <–begin–> steht.
Dummerweise wird aber nicht verhindert, das ein Benutzer in seinem neuen Eintrag ebenfalls einen oder mehrere dieser Strings einbauen kann…

Anmerkung: Die Gefährdung ist abhängig von der Art des Skriptes.

Stufe IV.
bedenklich bis hoch
„Denial of Service“-Attacken
Das Programm ermöglicht z.B. einen Dateiupload oder eine Benutzereingabe über <textarea>, bzw. <input>, hat dabei aber keine Beschränkung in der Länge des übergebenen Strings. Im Gegensatz zu einer normalen DoS-Attacke, die durch die gleichzeitige Anforderung mehrerer Tausend Einzelabfragen abläuft, kann hier schon ein einziger Auftrag zu Problemen führen.
Ein Beispiel: Das Programm ist dafür gedacht die Eingabe eines Benutzernamens mit Hilfe eines regulären Ausdrucks nach Umlauten zu durchsuchen und diese zu ersetzen. Wird jedoch anstelle eines kurzen Namens ein String mit der Länge von mehreren MB übergeben, dann kann dies zu einem Lag führen.
Durch diese Attacken kann die CPU-Last steigen und der Server auch durch vergleichbar wenige Requests an seine Leistungsgrenze geführt werden.

Beispiele: Diverse Datei-Upload-Skripten

Stufe IV.
bedenklich bis hoch
Ungeprüfte Systemzugriffe durch fremde Benutzer
Das Skript ermöglicht über ungeprüfte Variablen den Zugriff auf Dateien und/oder Systemprogramme.
Dies tritt am häfigsten dann auf, wenn auf Dateien oder andere Programme (wie sendmail) zusammen mit ungeprüften Benutzereingaben aufgerufen oder geöffnet werden.
Beliebige Dateien, auf die der Web-User Zugriff hat, können im Bestfall zerstört oder unbrauchbar gemacht werden.
Im Worst Case erhält ein Hacker Zugriff zum Webserver und darüber auf alle Webseiten und Programme.

Beispiele: sendmail.cgi V2.0, nph-test.cgi, FormMail V1.0, ..

Prominentes Beispiel: Das Ultimate Bulletin Boardsystem hatte bis zur Version 5.43 (März 2000) ein bis dahin öffentlich unbekanntes Sicherheitsloch, bei dem es möglich war, Einfluß auf die Bennennung von Dateien zu nehmen, ohne das dabei Sonderzeichen entfernt wurden.
Durch das geschickte Ausnutzen von Sonderzeichen war es dann möglich Programme auf dem Server aufzurufen und sich somit ggf. Zugang zu diesem zu verschaffen.

Anmerkung: Skripte, welche dieser Fehler aufweisen, sollten sofort gelöscht werden und der Autor verständigt werden.

Stufe V.
hoch

Analyse fremder Programme

Um sicher programmieren zu können, muß man wissen, was unsicher ist und was nicht, und man sollte mindestens halbwegs eine Ahnung haben, wie jemand versuchen könnte, das Skript auszutricksen und für die eigenen Zwecke zu mißbrauchen.
Anstelle jetzt die üblichen Phrasen zu zitieren, wie man programmieren sollte und was zu beachten ist, gehen wir das Problem von der anderen Richtung her an: Wie stelle ich Sicherheitslücken in einem CGI-Programm fest?
Im Folgendem werd ich anhand dieses Ansatzes und von Beispielen beschreiben, wie vorzugehen ist. Ich möchte aber betonen, das dies keine Anleitung zum Hacken sein soll. Vielmehr ist es so, daß niemand sich wirklich Systemadministrator oder Webmaster nennen sollte, der/die nicht diese grundsätzlichen und einfachen Möglichkeiten kennt und entsprechend berücksichtigt.
Gehen Sie immer von dem Grundsatz aus, daß wenn es Lücken im Sicherheitskonzept gibt, diese früher oder später auch gefunden werden. Als SysAdmin haben Sie deswegen nur 2 Möglichkeiten: Entweder Sie beseitigen alle Sicherheitslücken, inklusive derer, die Sie noch garnicht kennen, oder Sie hacken Ihr eigenes Skript bevor es jemand anders tut.

Oberflächlicher Check

Als SysAdmin eines Hosts mit mehreren Benutzern kann man nicht immer wissen, was diese gerade mal wieder programmiert haben und wo sie es ggf. hingetan haben. Wenn einer der Benutzer oder ein Seitenbesucher ein Problem hat, dann wird in der Regel nur die URL als Info gegeben. Bevor man also dran geht und lokal ins Skript reinschaut, kann man schonmal ueber die URL schauen, was los ist.
Angenommen auf der betreffenden Seite findet sich ein Formular mit folgendem HTML-Code:

Durch den Kontext des Formulares erfahren wir außerdem, daß der Autor der Webseite hier eine Feedback-Seite aufgebaut hat und einfach um ein kurzes einzeiliges Kommentar bittet.
Ohne das wir erst versuchen uns das Skript zu besorgen und zu wissen was es macht, sehen wir, das in den Eingabefeldern email und telefon erwartet wird, daß dort zum einen eine gültige E-Mail-Adresse, zum anderen eine gültige Telefonnummer mit den entsprechenden Syntaxi eingegeben wird.
Bei name und kommentar wird lediglich ein String erwartet, der sieht man vom Namen ab, eine beliebige Syntax haben könnte. Da nicht zu erwarten ist, daß jemand bei einem einfachen Feedback-Kommentar Namen und Kommentar nutzt um irgentwelche Operationen auszuführen, ignorieren wir diese Felder erstmal.
Weiterhin ist anzunehmen, daß das Skript richtig funktioniert, wenn es nur Werte bekam, wie sie vom Programmierer erwartet wurden. (Wenn dem nicht so ist, ist das Skript einfach falsch und unsere Aufgabe als SysAdmin besteht darin, daß Programm zu sperren und den Programmierer zurück zur Werkbank zu schicken.)
Nachdem wir das Skript einmal mit richtigen Werten getestet haben, sehen wir, daß das Skript uns eine E-Mail zusendete, worin sich für den Feedback bedankt wurde.
Was haben wir erfahren? -Das das Skript zumindest die von uns eingegebene E-Mail-Adresse benutzte um damit eine Systemoperation zu starten!

Eine gültige E-Mail sieht aus wie eines der folgenden Beispiele:

Eine E-Mail-Adresse kann aus den Zeichen [a-zA-Z0-9\.\\@] aufgebaut sein und muß einen gültigen Servernamen hinter dem @ aufweisen. Mehrere Punkte oder Bindestriche dürfen nicht aufeinander folgen und das @ darf nur einmal vorkommen. (Siehe auch: RFC821)
Das obige Programm wird im schlechtesten Fall die E-Mail-Adresse überhaupt nicht auf ihre Syntax überprüfen. Aber nehmen wir ruhig an, der Programmierer hat folgenden in Perl häufig verwendeten Ausdruck zur Syntaxprüfung eingebaut:

Hier, wie bei den meisten Formmail-Programmen, wird aber nur geprüft, ob in dem als E-Mail-Adresse übergebenen String auch vom Format her eine solche vorhanden ist. Es wird nicht geprüft, ob dort nicht Sachen drin sind, die da nichts zu suchen habe.
Was passiert also wenn wir z.B. folgendes als E-Mail-Adresse angeben:

nospam@fasel.com| mail bla@fasel.com < /etc/passwd

Die obige Syntaxprüfung würde feststellen, daß im String eine gültige E-Mailadresse auftaucht und danach dann die Dankesmail schicken. Nur: Wenn der Programmierer keinen weiteren Schutz eingebaut hat, der Code also folgendermaßen ausschaut

dann passiert folgendes: Das Skript wird zuerst die nette Dankesmail schicken und dann das Systemkommando ausführen, welches wir mitgegeben haben, nämlich uns die Passwort-Datei schicken. Natürlich ist dies noch ein harmloses Beispiel, auch wenn es meiner Meinung nach schon den Straftatbestand der Erschleichung von fremden Daten erfüllt (Paragraph 202a StGB). Weit kritischer wird es, wenn jemand Systemkommandos wie rm -Rf oder /usr/bin/term -display irgentwo:0.0 ausführen kann. In diesem Fall können und sollen die Paragraphen 303a StGB (Datenveränderung) und/oder Paragraph 303b StGB (Computersabotage) greifen.

Glauben Sie nicht, niemand würde über diese oder andere bekannte Sicherheitslücken versuchen auf Ihr System zuzugreifen! Überzeugen Sie sich selbst, indem Sie ein grep zum Beispiel nach dem String /etc/passwd auf Ihre access.log-Datei machen. Hier ein kleiner Auszug, was Sie möglicherweise auch bei sich finden werden:

(Bei dem von mir betreuten Server bewirkt übrigens jeder Versuch dieser Art eine sofortige automatische Mail an den Sicherheitsverantwortlichen. Nebenbei waren obige Versuche das rumspielen von Skript-Kiddies, die nichtmal in der Lage waren, ihre Dialins zu maskieren. Bei einem schlechtgelaunten Sicherheitsverantwortlichen hätten diese Versuche zu einer Anzeige geführt und dies wiederum zu einer Beschlagnahme des PC’s durch die Polizei zur Untersuchung der Festplatte…)

Torture-Skripten

Eine andere, wenn auch etwas brutale, Methode unsichere Parameter herauszubekommen, ist der Einsatz eines Torture-Skriptes. Dabei handelt es sich um ein Skript, das dem zu prüfenden Programm mehrere Hundert Anfragen mit unterschiedlichen zufällig erzeugten Strings übergibt und die Reaktion des Programmes speichert.

In seinem Buch „Web Security“ gibt Lincoln Stein ein Beispiel wie ein Torture-Skript aussehen kann. Im Prinzip ist die Erstellung eines solchen Skriptes für einen guten Perlprogrammierer eine Sache von wenigen Minuten. Und anstelle das man wie bei Stein das Skript mit rein zufälligen Strings traktiert, wäre es auch nicht sonderlich schwer, das Skript so zu modifizieren, daß es ausgewählte Parameter benutzt, die dann nur Zufallsstrings aus einer bestimmten Familie an Zeichenkombinationen ergeben.
So würde man bei obigem Skript angeben, das die Parameter name, email, kommentar, telefonnummer nutzbar sind, wobei der Parameter email vom Typ einer E-Mail ist und telefon vom Typ einer Zahl, zzgl. den Zeichen „+“, „-“ und „/“.
Das Skript würde dann gezielt versuchen, die ihm nun bekannten Daten zu nutzen und die üblichen Sicherheitsprobleme auszuspielen, es würde nicht seine Zeit mit dem Senden von zufääligen Strings vom Typ [a-zA-z0-9] verschwenden bei einem Parameter, wo klar ist, daß dort der Teststring als E-Mail-Adresse getarnt werden muß.

Bisher waren wir nur beim Analysieren ohne das wir wirklich den Programmcode gesehen haben. Wenn wir der SysAdmin sind, sollte es auch keine Probleme machen, wenn wir die obigen Beispiele durchtesten um zu sehen, ob wir wirklich Zugriff zum System erhalten. Sind wir jedoch nicht der SysAdmin des betroffenen Systems sollten wir das Testen entweder ganz unlassen, wurden wir nicht dazu aufgefordert, oder nur so vorgehen, daß der Fehler aufgedeckt wird, ohne das wir einen Schaden anrichten.
Im folgenden Kapitel werden wir versuchen, Informationen über das bisher unbekannte Skript über das Netz zu erhalten.

Informationen aus dem Netz holen

Programmierer sind faule Menschen. Wenn es keinen -für den Programmierer!- guten Grund gibt, wird er/sie in der Regel kein Programm neu schreiben, welches es schon gibt. Scott Adams, der Autor von Dilbert drückt es seiner kurzgefassten Evolutionstheorie so aus:

We’re a planet of nearly six billion ninnies living in a civilization that was designed by a few thousand amazingly smart deviants.

Nicht anders läßt es sich erklären, daß die meisten CGI-Skripten kostenlose Kopien sind, die man aus irgenteinem Archiv heruntergeladen hat.

Wenn man nach Informationen zu einem CGI-Skript sucht, dann gibt es mehrere Möglichkeiten. Zum einen kann man die besagten Archive, wie z.B. The CGI-Resource Archiv durchsuchen. Zum anderen tut es auch eine normale Suchmaschine, jedoch hat dies meist den Nachteil, daß man dort oft nur von Links zu anderen Seiten, die das CGI auch einsetzen, erschlagen wird, jedoch den Download-Link leicht übersieht. Eine andere gute Quelle betreffend Sicherheitsprobleme bzgl. CGI-Skripten sind diverse Security-Listen, wie z.B. BugTraq.
Für das oben angegebene Skript, dessen Namen wir aus dem Wert von <form action=““> erhielten, findet sich dann auch über The CGI-Resource Archiv ein entsprechender Eintrag der zum Autor und zu einem Download des Skriptes führt.
Wenn wir zudem auch noch Informationen über die Unsicherheit des Skripten finden, dann sind wir als SysAdmins aus dem Schneider: Wir brauchen selbst nichts mehr zu machen (außer ggf. die Versionsnummer zu kontrollieren) als das Skript zu löschen und denjenigen der es auf dem Server installierte den Kopf abzureißen…
(Anmerkung: Sollte es Ihr Vorgesetzter oder Ihr Ehepartner gewesen sein, überlegen Sie sich was anderes!)

Finden sich keine Hinweise bzgl. der Sicherheit, sondern nur das Skript, dann sollten Sie es sich ggf. nun laden und dann lokal analysieren, indem Sie sich den Code anschauen. In dem folgenden Kapitel 4 gehen wir darauf genauer ein.

4. Analyse lokaler Programme

Im folgendem beschreiben wir die Bug-Suche in einem bestehenden Programm von dem wir wissen wollen, ob es sicher ist, oder nicht. Ausgegangen wird dabei von einem UNIX-System, da nur unter solchen Systemen ein Mindestmaß an Sicherheit gewährleistet ist und die Mehrzahl aller professionellen Webserver unter dem Apache/Unix-Mix arbeiten.

Oberflächliche Analyse

Bei der ersten, oberflächlichen Analyse schauen wir uns gezielt die Funktionen im Programm an, wo ein Sicherheitsloch auftreten könnte. Diese sind bei Perl:

  • Systemaufrufe mit open, system, eval, exec,
  • Eingebundene Systemaufrufe durch fremde Perlmodule
  • Benutzerspezifische eingebundene Routinen

Angenommen, wir durchsuchen das oben bereits genutzt Feedback-Programm, so kann die Analyse folgendermßen aussehen:


Zuallererst schauen wir uns die erste Zeile des Programmes an:

Wie wir sehen, wird der Interpreter Perl ohne Argumente aufgerufen. Das Programm wird also die Variablen so nehmen wie sie kommen und nicht, wie im Tainted Mode diese als rohe Eier behandeln.
Durchsuchen wir nun nach open(), da dieser Aufruf am häufigsten verwendet wird:


Wir haben 3 Zeilen mit 4 Variablen gefunden. Schauen wir mal, was sich dahinter verbirgt:

Hinter $mail steckt also das sendmail-Programm. Ausserdem sehen wir, daß sendmail hier ohne Parameter, insbesondere ohne den Tainted-Modus -t, aufgerufen wird. Spätestens aus diesem Grund sollten wir nun die Alarmglocken läuten hören!
Schauen wir, was hinter den anderen Variablen steckt. Besonders interessant wird dabei sein, was hinter $in{‚email‘} steckt, da dies als Argument zu $mail benutzt wird.


Wir sehen, daß $send_reply_file eine feste Variable ist, die nicht von außen geändert wird. Wir können diese Variable somit im Folgenden ignorieren.
Jetzt fehlt noch die 4. Variable $in{‚email‘}, welche aus einem Hash genommen wird. Wir schauen also zunächst, was mit dieser Variable passiert:


Die Variable kommt so also nur in dem open()-Aufruf vor. Das heißt, daß sie nirgends selbst verändert wurde, es sei denn der Hash wurde als ganzes geändert. Deswegen suchen wir nun nach dem Hash:

Wir erfahren, daß der Hash %in durch die Subroutine getcgi erstellt wurde. Wir müssen uns also diese Routine genauer unter die Lupe nehmen!

Nach der Suche nach open(), müssten wir nun eigentlich auch nach den anderen Systemaufrufen suchen. Da wir aber in dem Aufruf open(SM, „|$mail $in{‚email‘}“); einen Anfangsverdacht haben, schauen wir uns zuerstmal an, wie der Hash %in gebildet wird.
Sollten wir feststellen, daß in der Subroutine getcgi kein Parsing nach gefährlichen Sonderzeichen geschieht, haben wir eine Sicherheitslücke dingfest gemacht und wir brauchen uns nicht mehr um den Rest zu kümmern, sondern das Programm gleich sperren.

Code-Analyse

Wenn wir das Programm mit einem Editor/Viewer öffnen finden wir folgenden Code für die Subroutine getcgi:

Beim obigen Code handelt es sich um eine Standard-Routine für das Einlesen von Parametern, die über das Netz kommend, dem Programm übergeben werden. Die erste if()-Abfrage dient lediglich dazu, die Parameter in eine Variable $in zu schieben, egal ob als Übertragungsmethode GET oder POST verwendet wurde.
Danach wird diese Variable aufgesplittet und Sonderzeichen, die durch die Übertragung codiert waren, wieder hergestellt. Im Ende der foreach-Schleife wird der jeweilige Parameter in das Hash geschoben.
Was wir in dem Code nicht sehen ist eine Schleife oder ein regulärer Ausdruck, in der etwaige Sonderzeichen gelöscht werden. In anderen Worten: Eine beliebige Hash-Variable, wie z.B. $in{‚email‘} hat genau den Inhalt, welcher im Eingabeformular (oder bei der GET-Methode in der URL-Zeile) eingegeben wurde, inklusive aller Sonderzeichen.
Wie wir also im Kapitel 3. Analyse fremder Programme bereits angetestet haben, erfährt nun seine Bestätigung: Sollte jemand als E-Mail-Adresse einen Ausdruck wie

eingeben, würde dies zum Erfolg führen, die Passwortdatei würde frei Haus und ohne Trinkgeld geliefert werden.

Korrektur

Als SysAdmin ist man leider nicht so häufig in der Rolle eines B.O.f.H., wo man unsichere Programme von Nutzern einfach löschen kann. Viel eher wird es so kommen, daß man den Benutzer erklären muß wie der entsprechende Code zu reparieren sei oder man muß es selbst tun (-vielleicht auch deswegen weil man selbst der Schuldige war).
Oft, wie in diesem Fall auch, sind es nur wenige Zeilen die geändert werden müssen um das Programm sicher zu machen. Wir kommen damit wieder zurück zu den gleichen -hoffentlich bekannten- Hinweisen für die Programmierung sicherer CGI-Skripts:

  • Aufruf von Perl bzw. von Perlvariablen im Tainted Modus Behandeln Sie grundsätzlich jede Variable die in irgenteiner Form von einem Benutzer übers Netz gesteuert ist wie ein rohes Ei, gefüllt mit einer Mischung aus Nitro und Flußwassercola.
  • Halten Sie sich auf den laufenden was Meldungen von Sicherheitsbugs betrifft und bewahren bleiben Sie selbstkritisch: Jeder, inklusive mir selbst, macht mal Fehler, ist mal abgelenkt oder übersieht mal etwas. Ein gesundes Maß an Selbstüberschätzung ist mitunter gut -hier ist es tödlich.
  • Kommentieren Sie ihr Skript so aus, daß jemand anders sich auch darin zurecht findet und erfährt was das Skript an dieser oder jener Stelle macht. Seien Sie jedoch auch nicht zu genau. Programme, bei denen durchweg auf 1 Zeile Programmcode mehr als 3 Zeilen Erklärung kommen, sind ebensoschlimm (für einen Profi sogar schlimmer), wie eines, welches keine Kommentare enthält.
  • Sollten Sie einmal ein Skript aus dem Netz holen wollen, lassen Sie die Finger von Skriptarchiven, wo nur ein Downloadlink ohne weitere Informationen, insbesondere ohne Link zum Autor und/oder Versionnummer, zum Skript vorhanden sind. Solche billigen CGI-Archive, die meistens nur der Werbebannerabzocke dienen, sind einer der Hauptgründe, warum unsichere Skripten noch nach Jahren vorhanden sind und genutzt werden.
  • Aufruf von von sendmail nur im Modus „-t“, da dieser Argumente in der Argumentliste unterdrückt.
  • Soweit möglich, bauen Sie ein CGI-Wrapper ein.
  • Falls Dateinamen übers Netz gegeben werden müssen und diese Dateien dann geöffnet werden sollen, dann nur in unterhalb ausgewählter Verzeichnisse, aber niemals so, daß ein Verzeichniswechsel möglich ist oder die Dateien gar auf das Root-Verzeichnis zugreifen können. Bei einem Dateinamen sollten Sie nur die Zeichen [a-zA-Z0-9\\._] erlauben.
  • Parsen aller Variablen, die an Systemaufrufen beteiligt sind. In dem obrigen Fall von der Variable $in{‚email‘} mit: $in{‚email‘} =~ s/[^a-zA-Z0-9\-\@\.]//g;. Der Nachteil hiervon besteht allerdings, daß man durch diese Methode zwar eine gültige E-Mailsyntax hat, jedoch nicht feststellt, ob wirklich Sonderzeichen in der E-Mailangabe vorhanden waren.

Zum letzten Punkt: Da wir gern wissen wollen, wenn jemand etwas Böses versucht, sollten wir uns ggf. die E-Mailadresse einer neuen Variable zuweisen, aus dieser dann alle Sonderzeichen löschen, die nichts in einer E-Mail zu suchen haben und dann beiden Strings vergleichen.
Folgendes kleines Perl-Beispiel zeigt wie man vorgehen könnte:

Ruft man das Skript nun auf mit perl test.pl „bkla@jkhxf.com|/bla/fasel“ wird in der letzten Zeile der Unterschied gemerkt und darauf hingewiesen, wärend eine korrekte E-Mail-Adresse auch als solche durchgeht.

Bemerkung

Bei dem herangezogenen Skriptbeispiel für das unsichere Feedback-Programm handelt es sich um ein reales Beispiel. Das Skript konnte bei der Erstellung dieses Artikels so wie es hier teilweise angegeben wurde über dessen Homepage und vom CGI-Resource Archiv geladen werden.
Da das Skript laut Download-Rating der Homepage bereits mehrere Hundert Male geladen und möglicherweise eingesetzt wurde, und wird, hab ich mich entschloßen aus naheliegenden Gründen den wahren Namen bis auf weiteres zu maskieren.

5. Referenzen

Bücher und Online-Referenzen

Folgende Links und Buchreferenzen halfen besonders bei der Erstellung dieses Artikels. Bitte beachten Sie, daß ich mich bei den Online-Referenzen auf den Seiteninhalt von April/Mai 2000 beziehe und keinen Einfluß über etwaige Seitenänderungen habe.

Dank

Besonderen Dank für die Mithilfe bei der Erstellung des Artikels geht an die folgenden Personen:

Flattr this!