Sicherheitslücken im Web

Sicherheit bei Webseiten ist ein fortlaufender Prozess. Das Internet und die Techniken schreiten immer weiter voran, so dass auch Überprüfungen regelmäßig durchgeführt werden sollten.
Sicherheitslücken sind nicht immer gleich kritisch, es gibt durchaus auch Sicherheitsprobleme, die verhältnismäßg ungefährlich sind. Expertise ist in diesem Bereich unabdingbar für eine differenzierte Sicht.

Welche Sicherheitslücken gibt es?

Im folgenden Text geben wir Einsicht auf die verschiedenen Sicherheitslücken. Diese ist Liste ist aber keineswegs vollständig, sondern soll lediglich dazu dienen Einsicht in die Vielschichtigkeit zu bekommen.

Version Disclosure

Bei der "Version Disclosure" handelt es sich um eine Sicherheitslücke, welche als solche nur im seltensten Falle erkannt wird. Ihr Websever, welche Ihre Webseite nach außen präsentiert, liefert standardmäßgdi Version nach außen.
Das ist in sofern problematisch, dass Hacker nach öffentlichen Exploits suchen können um sich Zugang zu Ihren Webserver zu verschaffen.

Public Error Messages

Wie der Name schon hergibt, geht es hierbei darum, dass Fehlermeldungen unbedingt abgehandelt werden sollten. Je nach dem an welcher Stelle ein Fehler auftritt, können gefährliche Informationen preisgegeben werden.

Doch es geht auch noch schlimmer..

Im folgenden Fall gibt der IIS sogar noch deutlich mehr Informationen..

Fehler, die aus dem System generiert werden, sind nicht für das Auge des Besuchers gedacht und sollten unbedingt durch entsprechende Fehlerseiten behandelt werden. Sollte Ihre Webseite ähnliche Fehler nach außen tragen, raten wir Ihnen sich schnellstens mit uns in Verbindung zu setzen um schlimmeres zu verhindern.

SessionId Disclosure

Tomcat ist ein typisches Beispiel für dieses Problem. Zumindest in älteren Versionen wurde die SessionId einfach als Parameter an die URL gehangen. Die Bearbeitung im Client ohne weitere Hilfsmittel erleichtert natürlich den Diebstahl einer Session und kann im schlimmsten Fall dazu führen, dass sich ein normaler Benutzer als Administrator anmeldet.

Cookies httponly

Sollten Cookies nicht per Javascript verwaltet werden, so kann man den parameter httponly ohne Bedacht setzen - wozu wir auch raten.
Falls Ihre Webseite zudem per HTTPS ausgeliefert wird, dann sollten Sie ebenfalls das Secure-Flag setzen.

Directory Listing

Vorranging in Frameworks wie XAMPP oder LAMPP ein Problem. Falls Sie keinen Grund haben Ihre Dateien im Ornder darzustellen, sollten Sie diese verstecken. Folgendes Beispiel gibt übersicht über Dateien, die für einen Benutzer nicht zugängig sein sollten.

Adminbereich

Administrationsbereiche sollten natürlich nur einem Administrator zugängig sein. Baut Ihr System zum Beispiel auf Wordpress auf und Ihre Admincenter ist über http://adresse/wp-admin/ erreichbar, so können Sie davon ausgehen, dass kein Wert auf die Sicherheit Ihrer Webseite gelegt wurde. Die Standardadresse /wp-admin/ sollte unbedingt geändert werden. Das spart nicht nur Traffic, sondern erschwert eine Attacke erheblich.
Kontaktieren Sie uns gerne, wenn Sie Hilfe benötigen.

Fehlernachrichten beim Anmelden

Auch hier wieder ein Fehler, der gerne gemacht wird.
Ein Benutzer meldet sich mit dem Namen "Admin" und dem Passwort "pass" an.
Bekommt dieser nun die Nachricht: "Das Passwort passt nicht zu dem Benutzer Admin", so weiß dieser, dass zumindest ein Benutzer mit dem Namen "Admin" exisiert und muss sich nur noch darauf konzentrieren das Passwort zu knacken.

Http Method Swapping

Ebenfalls ein Fehler, der öfter gemacht wird, insbesondere bei Schnittstellen. Adressen, die nur per POST angesprochen werden sollten keinesfalls andere Request-Methoden, wie zum Beispiel GET, akzeptieren.

Passwort ändern

Mittlerweile nicht mehr so häufig anzutreffen, dennoch ein ernstzunehmender Punkt um mögliche Arbeitszeit einzusparen. Möchte ein Benutzer sein aktuelles Passwort ändern, sollten Sie diesen dazu zwingen sein altes Passwort einzugeben um sicher zu gehen, dass es sich auch wirklich um diesen Benutzer handelt und nicht um eine gestohlene Session.

SQL Injections

Ganz klar der König der Sicherheitslücken. Bei SQL Injections werden SQL Statements in das Zielsystem eingeschleust und vom SQL-System verarbeitet. In moderner Entwicklung werden diese in der Abstraktionsschicht abgefangen und durch Prepared Statements escaped oder bestenfalls durch ORMs behandelt, so dass Entwickler nicht mehr in die Bredouille kommen an dieser Stelle Fehler zu machen. Dennoch eine der häufigsten Gründe, warum Websysteme gekapert werden. Fehlendes Wissen trägt ebenso oft dazu bei wie miserables Codeverständnis.

(Distributed) Denial of Service

DoS-Attacken sind realativ einfach abzuhandeln, da die Angriffe immer von einer IP stammen. Iptables genügen da in der Regel. DDoS-Attacken sind allerdings deutlich kritischer. Auch wenn man kleine Attacken oft mittigieren kann, sind manche Angriffe je nach Stärke tatsächlich unaufhaltbar. Um sich rudimentär abzusichern gibt es mittlerweile Services wie zum Beispiel Cloudflare.

Cross-site Scripting (XSS/RXSS/PXSS)

Sämtliche XSS-Attacken sind Resultate von nachlässiger Arbeit. Salopp wurde eine Ausgabe nach außen getragen ohne sicher zu gehen, dass diese escaped wurde. So werden Javascripts in Clients ins Zielsystem eingespielt und bei anderen Clients ausgeführt.

File Inclusion (RFI/LFI)

File Inclusion steht oft im Zusammenhang mit der Skriptsprache PHP, trifft jedoch auch auf andere Serverseitigen Sprachen zu, die ähnliche Fähigkeiten wie PHP bieten. Hier werden Dateien auf dem Server aufgerufen, die dem normalen Anwender eigentlich nicht zur Verfügung stehen.