Schlagwort: Code injection

Da ist PHP plötzlich wieder in allen Medien

Programmieren mit PHP - Einstieg in die serverseitige WebprogrammierungAls ich letztes Jahr ein neues Buch zu PHP geschrieben habe, war das Thema nicht mehr wirklich angesagt. Zumindest nicht in der öffentlichen Wahrnehmung. Aber jenseits des allgemeinen und sehr kurzlebigen Aufmerksamkeitshorizonts hatte und hat PHP unverändert im Web riesige Bedeutung, was mich auch zu dem Entschluss für das neue Buch bewogen hatte.

Die Woche ist PHP plötzlich wieder in allen Medien aufgetaucht, wobei witziger Weise viele Meldungen dazu selbst mit PHP veröffentlicht werden, denn fast alle populären Content Management Systemen (CMS) wie WordPress oder Joomla! als auch viele andere Webseiten basieren unverändert auf PHP, was eben dessen unveränderte Bedeutung belegt.

Tja – und jetzt gibt es mal wieder eine Sicherheitslücke in PHP. Solche Sicherheitslücken begleiten eigentlich die gesamte Historie der Sprache und haben meist keine Aufmerksamkeit auf sich gezogen. Vielfach blieben sie über zig Jahre einfach unbehandelt oder sie wurden irgendwann still und leise bereinigt, was nur Experten überhaupt mitbekamen.

Aber diese Sicherheitslücke wird als hochkritisch gewertet und führt zu massiven Konsequenzen. In der php2shell erlauben die Sicherheitslücken Codeeinschleusung. In klassischer C-Tradition ist wohl ein Speicherüberlauf machbar und das Error-Handling hat zudem einen Bug. Zig Webseiten von Behörden und Einrichtungen sind im Moment abgeschaltet.

Mittlerweile sind Patches zum Fixen veröffentlicht und ich muss selbst meine Seiten zeitnah angehen. Aber für mich ist es als Randeffekt bemerkenswert, dass eben PHP wieder in der Wahrnehmung auftaucht und vielleicht Interesse an meinem Buch zu PHP weckt.

Aus Heise.de: „Da ist PHP plötzlich wieder in allen Medien“ weiterlesen

Log4shell oder warum angeblich das Internet brennt

Die Medien berichten mal wieder über einen Hacker-Angriff. Oder genauer – eine Schwachstelle in Log4J, über die wohl im Moment ziemlich viele Angriffe auf Server gefahren werden. Log4J bezeichnet eine sehr oft eingesetzte Java-Bibliothek zum Protokollieren von Serverzugriffen.

Schon eigenartig, aber es sieht so aus, als hätte ich etwas von Nostradamus. Denn gerade halte ich zwei Schulung zu JavaScript und in der Einleitung zu solchen Schulungen erzähle ich immer davon, wie stark JavaScript in der Vergangenheit unterschätzt wurde. Und dass man immer mehr Projekte finden kann, bei denen JavaScript zum Einsatz kommt und sogar teils Java verdrängt, da JavaScript schlanker und vor allen Dingen einfacher und wartbarer ist. M.W. steigt etwa Paypal seit Jahren Server-seitig immer mehr von Java auf JavaScript um.

Das zweite eigenartige Phänomen ist, das ich bei JavaScript immer die Build-In-Funktion eval vorstelle – mit dem Merksatz „Eval ist evil“. Denn damit ist Code injection ein Kinderspiel – wenn freie Daten eingegeben werden können. Auch beim Server.

Und Punkt Nummero 3 ist, dass ich mit Node.js letzte Woche in der Schulung ein kleines Protokollier-Skript für einen Webserver unter Node.js vorgestellt habe. Also so etwas wie Log4J-Light mit JavaScript.

Als hätte ich es geahnt, dass die Sache am Wochenende nach meinen Schulungen ein großes Thema wird. Oder haben die Hacker sich bei meiner Schulung die Anregung geholt? Muss mal meine Schulungsteilnehmer befragen, ob die eine Praxisübung machen wollten und die aus dem Ruder gelaufen ist ;-).

Ach nein – Log4J ist ja Java – und kein JavaScript.

Es tut gut, wenn man seit Jahrzehnten Fan des lange verlachten JavaScript ist und nun JavaScript sich als sicherer und vor allen Dingen schlanker und wartbarer erweist als die hochgelobten, schwergewichtigen Konkurrenten. Bei denen kann man oft in den Unmengen an Code einfach nicht mehr erkennen, wie die Geschichte wirklich abläuft. Und daraus resultieren eben Schwachstellen und Sicherheitslücken, die in einem schlankeren System viel schneller aufgedeckt und beseitigt werden können.

Aschenbrödel hat sich durchgesetzt.