Frustrierendes Publishing, mit Sicherheit

Veröffentlicht am Montag, 7. November 2016 07:00 in Tools

Vor kurzem stieß ich auf einen recht krassen Bug in der von mir verwendeten Bibliothek CommonMark.NET, bei dem die Eingabe einzelner Tilden-Symbole (~) zum Absturz des gesamten Prozesses führte (per StackOverflow-Exception). Der Fehler ist ab Version 0.14 behoben, weshalb ich jedem, der noch eine ältere Version benutzt, das Update wärmstens empfehlen würde. Die Situation entbehrte nicht einer gewissen Komik, da...

Principle of Most Astonishment

Veröffentlicht am Montag, 7. November 2016 05:00 in Satire & Code Review

Manch Entwickler hätte sich längst in der Unfallstatistik verewigt, sähe er im Straßenverkehr ebenso selten nach links oder rechts wie beim Programmieren. Dabei ist grade das Abgucken bei anderen doch eines der wichtigsten Hilfsmittel zum Lernen und zur Weiterentwicklung. Mit Scheuklappen fällt es aber schwer, Muster zu erkennen und für sich selbst zu adaptieren.

Good guy DHL

Veröffentlicht am Samstag, 22. Oktober 2016 06:00 in Satire

Bei DHL kennt man die Redewendung "doppelt dreifach fünffach genäht hält besser" wohl auch. Jedenfalls wollte jemand sichergehen, dass ich auch wirklich mitbekomme, wann ein Paket bei mir ankommt.

wann-es-kommt.png

Windows ist dafür nicht sicher genug

Veröffentlicht am Montag, 10. Oktober 2016 05:00 in Satire & Security

Ich muss gestehen, dass ich bis vor kurzem - und zwar viele Jahre lang - mit einem absolut mangelhaften und fahrlässigen Sicherheitsverständnis beim Thema Online-Banking unterwegs war: per iTAN. In meiner grenzenlosen Arroganz dachte ich, dass mit einem eigenen System, dediziertem Browser inklusive aktiviertem NoScript zusammen mit der Unterstützung meiner Bank, die Überweisungen lediglich vormerkt, damit sie (auch auf anderen Geräten) nochmals kontrolliert und ggfs. storniert werden können, auf der sicheren Seite beim Online-Banking sei. Weit gefehlt! Anscheinend ist die gängige Expertenmeinung, dass das bloße Vorhandensein einer iTAN-Liste in der eigenen Schreibtisch-Schublade automatisch dazu führt, dass monatlich Beträge im unteren einstelligen Millionenbereich von meinem Konto an Betrüger abgedrückt werden. Außerdem seien die Phising-Mails heutzutage so clever, dass ich jederzeit und beliebig oft dazu überredet werden könnte, auf Links zu klicken, um dort bereitwillig hunderte TAN-Nummern einzutippen. Scho-ckie-rend! Kurz, so teilte mir meine Bank jedenfalls mit, sei es alternativlos, das Verfahren zum Ende des Jahres einzustellen. Ich solle mich doch gefälligst für eine der Alternativen anmelden.

Web Security für alle: Content-Security-Policy

Veröffentlicht am Mittwoch, 28. September 2016 04:00 in Programmieren & Security

Der Content-Security-Policy-Header ist so ein bisschen der Schweizer-Armee-Header der Sicherheitseinstellungen. Er kann sehr fein granuliert steuern, was der eigenen Seite erlaubt sein soll: wohin man sich verbinden darf, woher Skripte, Styles und Schriftarten geladen werden, was an Inhalten eingebettet werden kann und wo die eigenen Inhalte eingebettet werden dürfen, von wo Bilder, Objekte und andere Inhalte stammen müssen. Damit verhindert er - zumindest mit den strengsten Einstellungen - so gut wie alle XSS-Angriffe. In gewisser Weise löst dieser Header auch die bereits vorgestellten Funktionen von X-Frame-Options und X-XSS-Protection ab, weil man mit ihm dasselbe und noch mehr erreichen kann. Warum ich das erst jetzt erzähle? Nun, der Content-Security-Policy-Header ist relativ neu und gut für moderne Browser geeignet, während die eben genannten Header zwar im direkten Vergleich weniger bieten, dafür aber auch mit älteren Browsern funktionieren. Zumindest momentan haben also noch alle ihre Daseinsberechtigung.

Web Security für alle: X-XSS-Protection

Veröffentlicht am Dienstag, 27. September 2016 04:00 in Programmieren & Security

Genau begründen kann ich es gar nicht, aber in meinem Kopf sortiere ich den X-XSS-Protection-Header immer in ein persönliches Gruselkabinett ein. Es widerstrebt mir fast, ihn zu implementieren. Vielleicht liegt es daran, dass die Funktionsweise zunächst proprietär und kaum durchschaubar war, oder dass es durchaus false positives geben kann? Oder auch daran, dass der vor XSS-Attacken schützende Header dazu genutzt werden konnte, eigentlich sichere Seiten für XSS-Attacken verwundbar zu machen, was Microsoft 2010 den Pwnie-Award für den Most Epic FAIL eingebracht hat. Dennoch verhindert der Header durchaus gewisse Angriffsszenarien, also los!

Web Security für alle: X-Content-Type-Options

Veröffentlicht am Montag, 26. September 2016 04:00 in Programmieren & Security

Der Header X-Content-Type-Options ist recht trivial zu implementieren, da er nur einen einzigen Wert annehmen kann: nosniff. Auch was er bewirkt, ist schnell erklärt: er untersagt dem Browser, schwarze Magie zur automatischen Erkennung des Inhalts von Serverantworten anzuwenden. Stattdessen soll er sich strikt an den übermittelten MIME-Type halten. Microsoft erläutert das an einem Beispiel anschaulich: auch wenn eine Serverantwort als Content Type "Text" signalisiert, interpretierte der Internet Explorer den Inhalt eigenständig als HTML, wenn entsprechende Tags vorhanden waren. Dieses Verhalten bietet Potenzial für Angriffsvektoren (XSS), etwa wenn ein Browser Inhalte als Skripte interpretiert und ausführt, die nicht ausgeführt werden sollten. Der genannte Header unterdrückt dies und führt beispielsweise nur aus, was der Server explizit als Skript ausliefert.

Web Security für alle: X-Frame-Options

Veröffentlicht am Freitag, 23. September 2016 04:00 in Programmieren & Security

Ich erinnere mich an eine Zeit, in der es ein Katz- und Maus-Spiel gab zwischen Seitenbetreibern und fragwürdigen "Diensten" im Internet, die fremde Seiten in iFrames eingebettet angezeigt haben - man sprach von "frame busting"-Techniken, um dieses ungebetene Einbetten der eigenen Inhalte loszuwerden. Irgendwann wurde erkannt, dass dieses Einbetten nicht nur inhaltliche Aspekte hat, sondern auch ein ernsthaftes Sicherheitsproblem darstellt: Clickjacking kann dazu genutzt werden, Mausklicks und Tastatureingaben unbemerkt und ungewollt umzuleiten, etwa um Passwörter und ähnliche sensible Daten zu stehlen. Vorhandene Cheat-Sheets zu dem Thema zeigen schon, wie komplex dieses scheinbar einfache Thema ist, und wie wirkungslos viele Versuche, sich dagegen zu wehren.

Web Security für alle: HSTS

Veröffentlicht am Donnerstag, 22. September 2016 04:00 in Programmieren & Security

Neben der eigentlichen Funktionalität für den Redirect zu https aus dem letzten Post gibt es eine ganze Reihe sicherheitsrelevanter Header, die man für seine Webseite umsetzen muss sollte kann. Die konkreten Maßnahmen hängen ganz von den persönlichen Ansprüchen, der Rolle der eigenen Seite und natürlich den verfügbaren Ressourcen und Fähigkeiten ab. Mozilla gibt in seinen Guidlines ein Cheat Sheet vor, das nicht nur eine sinnvolle Reihenfolge für die Umsetzung von Maßnahmen vorzugeben versucht, sondern auch den zu erwartenden Benefit aufführt. Ich beginne bei der Umsetzung mit dem http strict transport security-Header, oder kurz und einfach von der Zuge gehend: HSTS.

Web Security für alle: Redirect to https

Veröffentlicht am Mittwoch, 21. September 2016 04:00 in Programmieren & Security

Da wir nun ein glitzerndes Hochglanz-Zertifikat für den SSL-Betrieb der Webseite haben, mit dem die eigene Seite per https angesteuert werden kann und von den Browsern mit mehr oder weniger grünen Vorhängeschlössern präsentiert wird, ist ja alles in bester Ordnung - oder? Hmm..., mal sehen, was der Sicherheits-Check von Mozilla dazu sagt.

Blättern: 1 2 3 ... 26