Die folgenden Hinweise richten sich an alle Website- / Diensteanbieter an der TUM, welche einen Login anbieten. Dabei ist unerheblich, ob es sich um einen zentralen Login (z.B. mit TUM-Kennung oder ZV-Kennung) oder lokalen Login (mit lokalen Accounts des jeweiligen Systems) handelt.

Die Hinweise sind zum Großteil allgemeine Best-Practice bezüglich IT-Sicherheit nach aktuellem Stand der Technik. Sie können in der Regel unabhängig von der konkret eingesetzten Software-Lösung umgesetzt werden.

Mitglieder der TUM sind leider immer wieder auch gezielt Opfer von Hacking- / Phishing-Angriffen. Aus diesem Grund ist es wichtig, einen hohen Standard beim Umgang mit insbesondere sensiblen Zugangsdaten zu halten.

Verschlüsselte Verbindung

Websites mit Login müssen verschlüsselt bereitgestellt werden. Der Einsatz von https:// ist nicht nur bei Logins, sondern schon bei der Erfassung personenbezogener Daten (z.B. Formulare) erforderlich.

Dabei ist es nicht ausreichend, dass nur die Seiten mit Login / Formularen verschlüsselt (https://) angeboten werden, während weitere Seiten weiterhin unverschlüsselt erreichbar sind. Hintergrund ist, dass durch einen Mischbetrieb eine Angriffsfläche für einen Downgrade-Angriff geboten wird. 

Sie sollten daher dafür sorgen, dass alle über die selbe Domain angebotenen Seiten verschlüsselt erreichbar sind. Aufrufe per http:// sollten, ohne weitere Verarbeitung, auf https:// umgeleitet werden.

Zur Verschlüsselung notwendige Server-Zertifikate erhalten Sie über die TUM bzw. das DFN kostenfrei (siehe https://www.it.tum.de/faq/it-dienste/zertifikate/ ).

Wenn Sie von der TUM bzw. dem LRZ bereitgestellte Webserver nutzen, ist ein DFN Zertifikat in der Regel bereits enthalten.

Die Verwendung von DFN Zertifikaten ist keine Pflicht, Sie können auch Dienste wie https://letsencrypt.org/ in Anspruch nehmen.

Als TLS Versionen dürfen nur noch TLS 1.2 mit Perfect-Forward-Secrecy Cipher (PFS) und TLS 1.3 zum Einsatz kommen. Eine aktuelle Konfiguration der relevanten Ciphers für gängige Server-Software finden Sie unter https://ssl-config.mozilla.org/.

Einen ausführlichen Test Ihrer Verschlüsselung können Sie über https://www.ssllabs.com/ssltest/ anstoßen.

Einsatz von "HTTP Strict Transport Security"

Wenn Ihre Website vollständig über https:// erreichbar ist, sollte dies durch den Einsatz von "HTTP Strict Transport Security" ( https://de.wikipedia.org/wiki/HTTP_Strict_Transport_Security ) bekanntgegeben werden. Dabei handelt es sich um einen HTTP-Header, welcher dem Browser des Nutzers mitteilt, dass die gerade aufgerufene Website vollständig per https:// erreichbar ist und daher aus Sicherheitsgründen nicht mehr per http:// aufgerufen werden soll. Dies verhindert den oben angesprochenen Downgrade-Angriff, da nun der Browser weiß, dass die Seite nur per https:// aufgerufen werden soll.

Bei HSTS wird angegeben, wie lange sich der Browser merken soll, dass die Seite nur per https:// aufrufbar ist. Zu Beginn der Implementierung sollte dieser Zeitraum recht kurz gewählt werden, sollte sich herausstellen dass doch noch Seiten nur per http:// abrufbar sind und somit für Nutzer dann nicht mehr erreichbar sind. Anschließend ist ein Erhöhung des Zeitraums auf mindestens mehrere Monate sinnvoll.

Zusätzlich können Browser auch direkt so vorkonfiguriert werden, dass Ihre Seite nur per https:// erreichbar ist. Mehr hierzu finden Sie auf https://hstspreload.org/

Hinweis: Seit Januar 2023 wird die Domain *.tum.de mit HSTS Preload gekennzeichnet. Das heißt dass Websites unter der Domain *.tum.de in Browsern nicht mehr unverschlüsselt aufgerufen werden können.

"Secure", "HTTP only" und "SameSite" Session-Cookies

Websites mit Logins verwenden üblicherweise Cookies zur Aufrechterhaltung einer Nutzer-Session. Bei den meisten Anwendungen wird das Session-Cookie ausschließlich serverseitig ausgewertet und muss daher nur bei HTTP-Aufrufen übertragen werden.

Normale Cookies können mittels JavaScript ausgelesen werden. Dies kann und sollte verhindert werden, wenn dies nicht technisch notwendig ist.

Cookies können hierzu mit den Optionen "secure" sowie "HTTP only" versehen werden.

Die Option "secure" weist den Browser an, das Cookie nicht über eine unverschlüsselte Verbindung zu senden. "HTTP only" verhindert, dass das Cookie mittels JavaScript ausgelesen werden kann.

Mittels "SameSite" kann verhindert werden, dass Cookies übermittelt werden, wenn die Seite von einer anderen Seite aus eingebettet (Frame) bzw. aufgerufen wird. Dies ist unter Anderem ein sinnvoller Schutz gegen Cross-Site Request Forgery.

Weitere Einschränkungen sind möglich, siehe hierzu https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Cookies

Verwendung der "Content-Security-Policy"

Um Ihre Website zusätzlich vor Cross-Site-Scripting-Angriffen zu schützen, sollten Sie Content-Security-Policy (kurz "CSP") einsetzen, wenn Ihre Website dies unterstützt. Durch entsprechende CSP-Header geben Sie dem Browser des Nutzers vor, von welchen Quellen die Website JavaScript und weitere Ressourcen laden darf. Sie verhindern so im Falle eines möglichen Cross-Site-Scripting-Angriffs, dass schädliches JavaScript im Kontext Ihrer Website ausgeführt und z.B. Nutzerdaten entwenden kann.

Mehr zu CSP finden Sie hier: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

Prüfen Sie die Sicherheitsmaßnahmen Ihrer Anwendung z.B. mit Online-Scannern wie https://observatory.mozilla.org/ 

security.txt hinterlegen (RFC 9116)

Pflegen Sie eine /.well-known/security.txt auf ihrer Website um Kontaktinformationen bzgl. sicherheitsrelevanten Themen nach RFC 9116 bekannt zu geben. Mehr dazu finden Sie auch auf https://securitytxt.org/

Art der Nutzerkennung und Nutzergruppe benennen

Viele Dienste präsentieren den Nutzern als Login schlicht Eingabefelder für Benutzername und Passwort und nehmen an, dass die Nutzer selbst wissen, welche Daten einzugeben sind. Dies ist in einem Umfeld mit zentralen Logins, wie es an der TUM herrscht, allerdings keinesfalls der Fall.

Viele Dienste ermöglichen den Zugang mit den zentralen Zugangsdaten, der "TUM-Kennung". Daher wird seitens der Nutzer oft einfach angenommen, dass ein Dienst der TUM mit Login auch mit der TUM-Kennung oder anderen zentralen Logins genutzt werden kann.

Diese Annahme ist oft nicht richtig, gleichzeitig führt aber das Fehlen eines konkreten Hinweises oft dazu, dass Nutzer geradezu dazu erzogen werden, ihre TUM-Kennung als Login einfach auszuprobieren, was extrem kontraproduktiv ist.

Login-Seiten müssen daher auf die Art der genutzten Kennung hinweisen, sowie angeben, welche Zielgruppe für den Login berechtigt ist, sofern es hier Einschränkungen gibt (z.B. für interne Dienste einer einzelnen Einrichtung).

Dienste, die zentrale Kennungen als Login akzeptieren, sollten dies explizit erwähnen. Werden lokale Logins des Systems verwendet, ist auch darauf entsprechend hinzuweisen.

Verantwortlichkeit zeigen

Logins sind in der Regel immer mit der Verarbeitung von personenbezogenen Daten gekoppelt. Achten Sie darauf, dass von Ihrer Login-Seite aus eine entsprechende Datenschutz-Erklärung sowie ein Impressum verfügbar ist. Bei lokalen Systemen nennen Sie, wenn möglich, bitte immer auch einen technischen Ansprechpartner für die Systembetreuung. 

Software aktuell halten

Wenn Sie Drittsoftware einsetzen (z.B. Wordpress, Typo3, Gitlab, Wikimedia), achten Sie bitte darauf, diese aktuell zu halten. Gerade bekanntere Software-Anbieter veröffentlichen regelmäßig Sicherheits-Updates, welche dann auch zeitnah eingespielt werden müssen. Registrieren Sie sich hier bitte für entsprechende Newsletter. Vergessen Sie allerdings dabei auch nicht, Ihre Infrastruktur (Webserver, Datenbanken, ...) aktuell zu halten.

Moderne Authentifizierung (SAML/OIDC/OAuth/Shibboleth) / TUM-Login nutzen

Wenn Ihre Website einen TUM Login untersützt, verwenden Sie dafür bitte noderne föderierte SSO Verfahren wie SAML, OIDC, OAuth oder Shibboleth. Durch deren Verwendung werden keine Zugangsdaten der Nutzer über Ihren Server übertragen und Sie müssen keine Passwörter speichern. Dadurch mindern Sie automatisch das Risiko für Sie und Ihre Nutzer, sollte es doch einmal zu einem erfolgreichen Angriff kommen. Dies ist auch im Zuge der Datenschutz-Folge-/Risikoabschätzung im Rahmen der EU DSGVO, die für Ihre Systeme zu dokumentieren ist, relevant. Die Verwendung von LDAP Authentifizierung ist für neue Systeme prinzipiell untersagt, da diese Methode aus Datenschutz- und IT-Sicherheits-Aspekten mit dem Stand der Technik nicht vereinbar ist. Bestandssysteme sollten zeitnah migrieren.

Links zu externen Seiten prüfen

Beachten Sie, dass wenn Ihre Website Links zu externen Seiten via target="_blank" öffnet, die externe Seite beschränkt in der Lage ist, Ihre Website (den "opener") zu manipulieren. Um dieses Risiko zu unterbinden, ergänzen Sie bitte an alle Links die sich mit target="_blank" öffnen ein rel="noopener".

Weitere Informationen hierzu: https://mathiasbynens.github.io/rel-noopener/ sowie https://www.christoph-freyer.at/blog/links-absichern-mit-rel-noopener/ 

Haftungsausschluss

Die hier aufgeführten Maßnahmen haben keinen Anspruch auf Vollständigkeit. Zum sicheren Betrieb eines Dienstes müssen weit mehr Aspekte beachtet werden. Es liegt in der Verantwortung des Betreibers, einen sicheren Betrieb zu gewährleisten. Die hier genannten Maßnahmen sind lediglich eine Hilfe, um wichtige Aspekte nicht zu übersehen. Gerne nehmen wir weitere Aspekte mit in die Liste auf.

Checkliste

• Alle Seiten der Domain sind per https:// erreichbar, http:// Aufrufe werden umgeleitet
• HSTS wird eingesetzt
• Session-Cookies sind "secure" und "http only" markiert
• CSP ist auf den strengst möglichen Grad eingestellt
• Art der Nutzerkennung und Zielgruppe eines Logins sind klar kommuniziert
• Der Systembetreiber ist erkennbar
• Prozesse zur Softwareaktualisierung sind definiert
• Alternativen, wie Shibboleth, wurden geprüft
• Externe Links wurden ggf. überprüft
• Ihnen ist bewusst, dass diese Checkliste nicht hinreichend einen sicheren Betrieb abprüfen kann