• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Webinar: Online Security
 

Webinar: Online Security

on

  • 350 views

Wer sind die Angreifer im Netz, was sind Ihre Ziele und gegen welche Arten von Attacken muss ich mich wappnen? ...

Wer sind die Angreifer im Netz, was sind Ihre Ziele und gegen welche Arten von Attacken muss ich mich wappnen?


Es gilt immensen Schaden abzuwenden und das Vertrauen der Nutzer in Ihre Plattform zu gewinnen und zu bewahren.

Statistics

Views

Total Views
350
Views on SlideShare
350
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Webinar: Online Security Webinar: Online Security Presentation Transcript

    • Online SecurityWer, was,wie?
    • Agenda1. WER SIND DIE ANGREIFER2. DIE TOP 10 GEFAHREN UND WAS ICH DAGEGEN UNTERNEHMEN KANN
    • „ Privacy is implied. Privacy is not up for discussion.(Mikko Hypponen)
    • HTTPS://
    • Top 10 Online Gefahren Injection Cross Site Scripting (XSS) Broken Authentication and Session Management Insecure Direct Object References Cross Site Request Forgery (CSRF) Security Misconfiguration Insecure Cryptographic Storage Failure to Restrict URL Access Insufficient Transport Layer Protection Unvalidated Redirects and Forwards
    • 10) Unvalidated Redirects and Forwards  In Webapplikationen kommt es h aufig zu Weiterleitungen zu anderen Webseiten. Oft werden hierbei uber die Url mitgegebene Parameter genommen um die Zieladresse zu ermitteln.  Gefahr:  Angreifer kann dadurch das Opfer auf Malware- oder Phishing-Seiten weiterleiten  Umgehung von Authorisierungsmaßnahmen  http://example.org/redirect.php?url=http://evil.org  Maßnahmen:  Möglichst keine Urls aus User Parametern übernehmen  Input Validierug / White-Listing
    • 9) Insufficient Transport Layer Protection Bei Web Applikationen wird der Netzwerkverkehr nicht mittels Verschlüsselung geschützt, auch wenn sensible Daten übertragen werden. Gefahr:  Angreifer kann vertrauliche Informationen mitlesen oder verändern (Gesundheitsdaten, Kreditkartennummern, Passwörter, geheime Firmendaten...) Maßnahmen:  SSL  Verschlüsseln und Signieren der Daten vor der Übertragung
    • 8) Failure to Restrict URL Access Typische Fehler:  Es werden nur bestimmte Links und Menü-Punkte angezeigt, die anderen werden versteckt (Security by Obscurity)  Presentation Layer Access Control: Keine Überprüfung am Server Gefahr:  Angreifer kann Funktionen aufrufen, für die er nicht berechtigt ist  http://www.the-online-bank.com/user/getAccountData  http://www.the-online-bank.com/admin/getAccountData Maßnahmen:  Für jede Url sicherstellen, dass der User für den Zugriff authorisiert ist  Auf bestimmten Seiten ist überhaupt kein Zugriff möglich (Config-Files, Log-Files, etc.)
    • 7) Insecure Cryptographic Storage Das Problem liegt oft darin festzustellen, was sensible Daten sind und wo diese überall gespeichert sind (Logfiles, Backups...) Gefahr:  Angreifer hat Zugriff auf sensible Daten und kann diese verändern Maßnahmen:  Verschlüsselung (Datenbanken, Files ...) mit Standardalgorithmen  Schlüssel schützen
    • 6) Security Misconfiguration Die Sicherheit der Web Applikation hängt von den darunterliegenden Schichten ab. Wichtig ist hierbei die Installation der aktuellen Patches. Gefahr:  Sicherheitslücken ausnutzen, da keine Patches installiert wurden  Standard Passwörter zu Default Accounts  Unautorisierten Zugriff auf Funktionalität durch schlechte  Server Konfiguration# Maßnahmen:  Hardening Prozess definieren
    • 5) Cross Site Request Forgery (CSRF)1. Angreifer sendet präparierte URL an Benutzer durch zusätzlichen Kanal (z.B. E-Mail)2. Benutzer ruft Seite im Browser auf. Server führt Aktion direkt aus3. Dieser Punkt ist je nach Angriff optional. Zum Beispiel bei Passwortänderungen greift der Angreifer mit dieser Information auf den Server zu. Bei Aktionen ohne weiteren Zugriff des Angreifers (z.B. Überweisungen) ist dieser Punkt nicht mehr notwendig
    • 5) Cross Site Request Forgery (CSRF) CSRF: Missbrauch des Vertrauens der Applikation gegen uber Benutzer Durch untergeschobene präparierte URL kann ein Angreifer einen Benutzer zu einer Aktion am Server missbrauchen – die Daten für die Authentisierung (Session Cookie, IP Adresse, SSL Zertifikate des Clients, etc.) werden automatisch mitgeschickt Gefahr:  Der Angreifer kann alles machen, das der Benutzer auch kann. (Account löschen, Logout, Überweisung machen etc.)  http://server/changePassword.php?newPassword=angreifer“ Maßnahmen  Ein (zufälliger) geheimer Token, der nicht automatisch übertragen wird, zu allen kritischen Requests hinzufügen. Dieser Token (SharedSecret) ist nur dem Client und dem Server bekannt. Bei jeder Anfrage vom Client wird dieser Token dem Server übermittelt. <i n p u t name=”token ” v a l u e=”134 awe r i o a s d f 1 2 ” type=”hidden ”/>  Bei unverschlüsselter Kommunikation kann ein Angreifer diesen Token stehlen  Verifizierung der Aktion durch Benutzer anfordern  “Möchten Sie wirklich Ihr ...?”
    • 4) Insecure Direct Object References Ähnlich zu “Failure to Restrict URL Access” Typische Fehler:  Es werden nur bestimmte Objekte angezeigt, die anderen werden versteckt  Presentation Layer Access Control: Keine Überprüfung auf Server-Seite Gefahr:  Angreifer wird ähnliche Nummern ausprobieren:  www.example-bank.com?account=100  www.example-bank.com?account=102  www.example-bank.com?account=104 Maßnahmen:  Keine direkte Referenz auf Objekte - nur ein zufälliger,  Temporärer Mapping-Value  Statt ?account=100 – ?account=8w9e9fgi  Statt ?file=accounting.xls – ?file=119347  Überprüfung der Objekt Referenzen: Formatierung, ob der User die Berechtigung hat zuzugreifen, etc.
    • 3) Broken Authentication and Session Management Zur Erinnerung: HTTP ist ein stateless Protokoll Die SessionID wird verwendet um den Status des Users festzuhalten Gefahr:  Session Hijacking – Beispiel: Firesheep  User Accounts übernehmen  Aber auch die Funktionen: Passwort ändern, Sicherheitsfrage, Passwort vergessen, etc. Maßnahmen:  Verwendung von SSL und Sicherstellung, dass die SessionID immer durch SSL geschützt ist  Sicherstellen, dass ein logout wirklich die Session zerstört
    • 2) Cross-Site Scripting (XSS) Unvalidierter Benutzerinput wird genommen und ausgegeben <s c r i p t >a l e r t (” x s s ”);</ s c r i p t > Ausführung des Codes durch vertrauenswürdigen Server. Zertifikate und Verschlüsselung der Kommunikation zwischen Server und Benutzer bieten keinen Schutz. Der eingeschleuste Code wird direkt von der vertrauten Domäne ausgeführt. Arten:  Reflected XSS  Stored XSS
    • 2) Cross Site Scripting (XSS)”Reflected“ HEISE Security - News vom 22.3.2012 XSS Angriff durchgeführt auf https://www.paypal.com
    • 2) Cross-Site Scripting (XSS) Gefahr:  Session Hijacking  Teile der Web Page überschreiben und User zu anderer Seite weiterleiten Maßnahmen:  Keinen Input des Users auf der Webseite anzeigen.  Falls das nicht geht: Encoding!  Validierung des User-Inputs; White-Lists
    • 1) Injection Injection bedeutet, dass an einen Interpreter Commandos geschickt und diese ausgeführt werden in einer Art und Weise wie es eigentlich nicht vorgesehen ist. Sql-Injection, OS Shell Injection, Buffer Overflows etc. Gefahr:  Datenbankeinträge können manipuliert, ausgelesen oder gelöscht werden  Betriebssystem Zugriffe  …
    • 1) Injection - SQL Injection Jede Eingabe MUSS validiert werden. Es ist nicht ausreichend nur Formularfelder zu validieren. Injection ist auch zum Beispiel durch HTTP Header-Felder möglich. Ausfiltern von speziellen Datenbankzeichen wie zum Beispiel einfache Hochkomma -> Blacklist Filtering Zu bevorzugen ist eine Prüfung der Eingaben auf gültige Zeichen -> Whitelist Filtering Precompiled Statements verwenden. Das Statement wird in der Datenbank mit Platzhaltern kompiliert. Spätere Manipulation des Statements durch Eingaben nicht mehr möglich. Minimierung der notwendigen Rechte in der Datenbank -> Principle of „Least Privilege“. Verhindert SQL Injection nicht, verkleinert jedoch den Schaden durch einen Angriff.
    • 1) Injection - Command Injection - Maßnahmen Validierung der Eingaben (siehe auch SQL Injection) Verwenden der Funktionen von Programmiersprachen zum Lesen von Dateien Beschränken der Zugriffsrechte auf Dateien durch Rechtevergabe oder Verwendung von chroot Umgebungen Minimieren der möglichen ausführbaren Dateien Berücksichtigen der System-Konfigurationen (z.B. sichere PHP Konfiguration)
    • …und immer an sichere Passworte denken! Wie schnell kann Ihres gehackt werden? Sample Passwords Class of Attack Pwd Combinations Dual Core PC darren 308.9 Million Instant Land3rz 3.5 Trillion 58 Mins B33r&Mug 7.2 Quadrillion 83½ Days
    • Literaturhinweise/LinksOpen Web Application Security Project www.owasp.org OWASP Top 10 Project OWASP Testing Guide OWASP Web Goat Project
    • Zertifizierungen kuehlhaus Web-Developer sind zertifiziert in Development allen wichtigen Basis-Technologien und Frameworks  Die zertifizierten kuehlhaus Experten sichern  Gesteigerte Budgetzuverlässigkeit*  Effizienteres Zeitmanagement und gesteigerte Produktivität durch den sicheren Umgang mit Produkten und Technologien*  Detaillierte Security Tests  Entwicklung unter Security-Gesichtspunkten  … und die Zertifizierung belegt, dass das Entwicklerteam in Bezug auf diese Technologien auf dem neuesten Stand ist* Quelle: Burlington Consultants, Value of Training and Certification study 2003
    • kuehlhaus AGN7 5-6D-68161 MannheimDr. Nico BerndtHead of DevelopmentTelefon +49.621.496083-0E-Mail info@kuehlhaus.comInternet www.kuehlhaus.comDie Inhalte dieser Präsentation sind das geistige Eigentum unseresUnternehmens. Jede weitere Verwendung sowie Weitergabe an Dritte imOriginal, als Kopie, in Auszügen, elektronischer Form oder durchinhaltsähnliche Darstellung bedürfen der Zustimmung der kuehlhaus AG.