Wie mache ich meine Webanwendung sichererer?
Browser Beschreibungssprachen wie HTML und CSS,
sowie auch Clientbasierte Scriptsprachen wie JavaScript, JQuery und Co
und auch Serverseitiges Programmieren ist ja nicht wirkich eine große Kunst.
Und es gibt sicherlich viele unter euch, die ein paar schöne Zeilen Code zaubern können,
sei es in PHP, C#. NET , Java oder sonstiger Programmiersprache.
Beim diesem Thema über Secure Code Programming
beschränke ich mich wirklich nur auf's wesentliche im Programmcode
und gehe nicht weiter auf andere Sicherheitsmaßnahmen wie
WAF (Web Application Firewall)
oder Datenbankverschlüsselung oder Data Encryption Standard (DES) ein.
HTTP und HTTPS der erste Schritt - die SSL/TLS Umstellung ist der erst Schritt
Alles was zwischen dem Client und dem WebServer geschieht,
wird über das www (mit dem HTTP Protokoll) gesendet und kann theoretisch,
von anderen unerwünschten Personen/Maschinen mitgelesen werden.
Sensible Daten, die wir tag-täglich im Browser eingeben,
wie zum Beispiel ein Anmelde-Formular für den Webseiten-Login,
können so abgefangen werden und missbraucht werden.
Der erste Schritt eine Webapplikation noch sicherer zu machen,
beginnt also damit, den Webserver von HTTP auf HTTPS-Protokoll umzustellen.
Der Programmcode bleibt davon unberührt,
vielmehr muss auf dem Webserver SSL/TLS (Secure Socket Layer/Transport Layer Security) Verschlüsselung eingerichtet werden.
Die meisten Provider bieten solchen Services an und es nicht wirklich kompliziert.
Und dem Websitenbesucher wird dann das Schloss im Browser für einen vertrauenswürdige Website anzeigt.
Das SSL-Protokoll verwendet für die Verschlüsselung eine Kombination aus öffentlichen und symmetrischen Schlüsseln.
(zum Glück ist der symmetrische Schlüssel bei der Verschlüsselung schneller als der öffentliche Schlüssel...)
Besucht nun ein Client mit seinem Browser eine HTTPS Webseite
wird ein sogenannter SSL-Handshake ausgeführt.
Dabei werden die nötigen Information zwischen Client und Server ausgetauscht,
der eine verschlüsselte SSL-Verbindung aufbaut und ermöglicht.
Damit können nun alle über das HTTP-Protokoll gesendeten Daten
jeweils nur von beiden Seiten ver- und entschlüsselt (encrypt & decrypt) werden kann.
Implementieren von Sicherheitscode - mehr als einfach nur Programmieren!
Statische Webseiten, die nur aus HTML und CSS bestehen bedürfen nicht unbedingt großer Beachtung.
Jedoch alle dynamischen Webanwendungen, wo Scripte,
Programiersprachen und auch Datenbanken im Backend zur Anwendung kommen,
sollten vom Entwickler auch mal kritisch in Hinblick auch Sicherheit betrachtet werden.
Schlagwörter wie XSS Cross Site Scripting, Session Hijacking, XSRF, CSRF, SQL-Injection, ...
sollte man als Programmierer zumindst schon mal gehört haben.
Und wer hier schon erste Ansätze implentieren kann,
um seine Website vor diesen Art von Hackerangriffen zu schützen,
ist zumindest den möchtegern Häcker oder Programmierer schon mal einen Schritt vorraus.
Zunächst muss eines klar sein:
Eine Webseite 100% sicher zu machen geht kaum,
irgend ein Hintertürchen gibt es immer irgendwie ... irgendwo.
Da es auch immer noch den unkalkulierbaren Faktor "Mensch" gibt...
Hacken ist eine Kunst!
und man benötigt viel Kreativität und natürlich etwas technisches Know-How.
Daher soltle man schon beim programmieren gewisse Sicherheits-Standards implementieren,
die sicherlich schon eine große Bariere für einen durchschnits-Häcker darstellt.
Zu dieser Art secure-code-programming zählt zum Beispiel,
das validieren von Benutzereingaben.
Im Grunde müssen
alle Input und Output variablen/daten gefiltert werden.
- Encoding von Eingaben (escape inputs)
- Sonderzeichen Filter
- CSRF protections
die man über seine Webappliaktion laufen lassen kann
und so die ersten Schwächen aufdecken kann
und dann entsprechende Lösungsansätze im Programmcode implemmentieren kann.
Security Guideline for Programmer
Im allgemeinen sollten sich Web-Application-Developer folgenden Grundsatz für alle Applikationen einprägen:
"... never trust all data, which comes from browser..."
r>
Um XSS (Cross-Site-Scripting), session hijacking und andere Angriffsvarianten auf Webseiten und online Portale
zu verhindern, oder zumindest gut-möglich einzuschränken,
muss sämtlicher Traffic der vom Browser (Client) zum Server geht
und auch der Traffic der vom Server zum Client geht!
gefiltert werden.
Kurzum kann man dies auch so beschreiben:
- validate input
- + and +
- encode output
"...Data pre-validation at Client-Side,
but better in Server side...
do always final input-validation on Server-Side..."
Beispiel input-validation on Server-Side (convert prohibited signs) mit JAVA
String contentsHtml = changeUtil.addHtmlTag(Bean.getContents());
setAttribute (request,"contentsHtml",contentsHtml.replaceAll("<","<").replaceAll(">",">").replaceAll("&","&").replaceAll("'","'").replaceAll(""","\""));
Beispiel output-validation mit escapeToHTML in JSP (Java Server Pages)
<%@ page import="com.sapportals.portal.prt.util.StringUtils" %>
<jsp:useBean id="MyParameterFromServer" scope="request" class="java.lang.String" />
MyParameterFromServer = StringUtils.escapeToHTML(MyParameterFromServer);
<input type="text" name="mytext" value="<%=MyParameterFromServer%>">
Be carefull at indirect object reference
of werden requestes einfach an die Datenbank geschickt ohne diese wirklich zu prüfen
Zum Beispiel "Delete File ID = 34"
Aber hat man den jemals geprüft:
- ob den Benutzer auch wirklich authorisiert ist diese file-Id zu löschen?
- war er der Ersteller der Datei?
- oder wenigstens in der Gruppe der Ersteller?
use Token (HASH value) in all FORMS to protect XRSF-Attacks
Eine Form von website-hacking sind so genannte XRSF-Attacks (Cross-Site Request Forgery, XSRF, CSRF).
Diese unauthorisierte Angriffe und Datenmanipulationen lassen sich schon durch ein TOKEN verhinden.
Das Token sollte in diesem Falle ein HASH Value sein,
welche jedes mal neu generiert wird, wenn man eine Seite (Unterseite) besucht.
Im JAVA java.util gibt es die Class StringTokenizer
welche noch weitere Methoden für die Token implementierung anbietet.
Bei der Verwendung von Token in Form eines HASH values
gilt immer der Grundsatz,
dass es nur für die eine FORM-Session gültig ist und eine valid-period hat.
Also, so bald man die Page refreshed, muss das Token erneuert werden
und das alte TOKEN verliert die Gültigkeit (expired).
Durch diese Security-Code implementierung bleibt die Session dort wo sie ist,
und man macht XRSF-Attacken (Cross-Site Request Forgery, XSRF, CSRF) fast unmöglich.
Die erweiterte Form von TOKEN
Man könnte noch weiter gehen und einen "jump-over verhindern"
also es müssen die Business Process Stepps eingehalten werden,
um auf der nächsten Seite etwas machen zu können.
Also nur wenn Schritt 1 und 2 gemacht wurden (natürlich mit einem valid-token),
kann Schritt 3 ausgeführt werden.
Mit etwas kreativität
kann man als die Token-Prozedur so aufbauen,
dass viele Angriffe, besonders die Cross-Site Request Forgery verhindert werden können.