Sie wissen jetzt, wie man Bedrohungen in Bedrohungsbäumen darstellt. Nehmen Sie sich das Konzept Ihrer nächsten App, und erstellen Sie alle Bedrohungsbäume, die Ihnen einfallen. Wenn Sie jetzt zu den 99 % aller Menschen gehören, denen mit Mühe ein oder zwei Bedrohungen einfallen, dann sind Sie in guter Gesellschaft. Ohne weiteres Hilfsmittel aus dem Blauen heraus Bedrohungen identifizieren zu wollen, ist ähnlich schwierig, wie auf Befehl hin lustig zu sein – auch wenn Karnevalisten es Jahr für Jahr vergeblich versuchen und ihre Trauer über den sich nicht einstellenden Humor mit Alkohol ertränken.\nUm dem Problem der Einfallslosigkeit zu begegnen, könnten Sie es den Karnevalisten gleichtun und sich volllaufen lassen. Das erhöht zwar nicht das Sicherheitsniveau Ihrer App, beschert Ihnen aber zumindest einen kurzweiligen Abend – und einen dicken Kopf am Tag danach.\nWir raten Ihnen allerdings, sich entweder einen Security-Experten einzukaufen oder sich einer Methodik zu bedienen, die Sie strukturiert durch den Prozess der Bedrohungsanalyse führt. Diese Methode nennt sich Threat Modeling – das Modellieren von Bedrohungen. Bekannt gemacht hat diese Methode die Firma Microsoft, indem sie Threat Modeling als integralen Bestandteil des Secure Development Lifecycle implementiert hat.\nUrsprünglich stammt das Threat Modeling wie viele große Erfindungen der Menschheit aus dem militärischen Bereich. Ende der 1990er Jahre wurde es von der US-Army und der britischen Armee entwickelt. Mittlerweile ist es als Methodik zur Risikoanalyse in die Norm AS/NZS 4360 integriert, seit 2005 ist es Bestandteil des CVSS (Common Vulnerability Scoring System), und obendrein ist es Bestandteil von OCTAVE, der Operationally Critical Threat, Asset, and Vulnerability Evaluation, einem Ansatz zum Management von Informationssicherheitsrisiken des Software Engineering Institute der Carnegie Mellon University.\nDer von Microsoft verwendete Ansatz beim Threat Modeling basiert auf der Idee, eine Applikation (ein System, eine Infrastruktur etc.) anhand eines Datenflussdiagramms (DFD) zu modellieren. Der Gedanke dahinter ist, dass Angriffe nur dort möglich sind, wo Daten in ein System gelangen oder ein System verlassen. Modelliert man den Fluss der Daten durch eine Anwendung, muss man »lediglich« an allen relevanten Stellen überlegen, welche Bedrohungen dort wirken können.\nDas Threat Model wird erstmalig in der Designphase der Entwicklung erstellt, also bevor überhaupt eine einzige Zeile Code programmiert wird. Die Überlegung dahinter ist, dass es wesentlich günstiger ist, Sicherheitslücken so früh wie möglich im Entwicklungsprozess zu identifizieren. Denn je später eine Sicherheitslücke gefunden wird, desto teurer ist es, sie zu schließen.\nInsbesondere ist das Threat Modeling auch dazu geeignet, Designfehler zu finden, eine Fehlerklasse, die sich mit automatischen Tools zur Codeanalyse nicht identifizieren lassen. Und eine auf einem Designfehler beruhende Sicherheitslücke zu schließen, kann extrem teuer oder gar unmöglich sein.\nDer Nichtmathematiker der beiden Autoren dieses Buches bekam vor einigen Jahren den Auftrag eines Kunden – nennen wir ihn der Einfachheit halber »Backup-Monster« –, dessen bereits im Betrieb befindliche Software für Online-Backups auf Sicherheitslücken hin zu untersuchen.\nIn einer Zeit, als jeder beim Begriff Cloud noch in den Himmel guckte, wollte Backup-Monster seinen Kunden mit der Software die Möglichkeit geben, automatisiert Backups von ihren Rechnern auf einen Server von Backup-Monster im Internet zu spielen. Natürlich wurde mit AES-256-Verschlüsselung geworben und damit, dass die Daten der Kunden absolut sicher seien und selbst von Backup-Monster nicht entschlüsselbar abgelegt würden.\nZum Zeitpunkt der Untersuchung hatte Backup-Monster einige Hundert bis tausend Kunden, die den Service fleißig nutzten und bereits mehrere Terabyte auf dem Server gesichert hatten. Beim Audit der Software kam dann heraus, dass Architekten und Programmierer gegen alle kryptografischen Regeln verstoßen hatten und die Software schlichtweg so offen wie ein Scheunentor war. Die Verstöße waren allesamt im Design angesiedelt (falscher Algorithmus, falsche Verschlüsselungsart, falsche Authentisierung).\nDa die Änderungen nicht nur Interna der Software betrafen, sondern auch die Kommunikation mit dem Server und insbesondere die Ablage der Backup-Daten auf dem Server, wurden mit dem Update auf einen Schlag alle auf dem Server liegenden Backups unbrauchbar. Backup-Monster hatte neben der Erstellung einer neuen Software also auch noch die unangenehme Aufgabe, allen Kunden mitzuteilen, dass ihre Backups sich in kleine Logikwölkchen aufgelöst hatten – und dass nicht ausgeschlossen werden konnte, dass irgendwer unbefugt auf diese Daten zugegriffen hatte.\nNeben diesem Image-Schaden, der Backup-Monster viele Kunden kostete, verdoppelten sich die Kosten für die Erstellung der Software nahezu, da das komplette Design neu erstellt und anschließend implementiert werden musste.\nAbbildung 7.2 Die Kosten für die Fehlerbehebung in Software steigen umso mehr, je später der Fehler entdeckt wird.\nNeben der vorstehenden Anekdote veranschaulicht der NIST-Report »The Economic Impacts of Inadequate Infrastructure for Software Testing« aus dem Jahr 2002 sehr deutlich den Zusammenhang zwischen dem Zeitpunkt, zu dem ein Fehler gefunden wird, und den Kosten, um ihn zu beheben, wie Abbildung 7.2 zeigt (das NIST ist das US-amerikanische Institut für Standardisierung: das National Institute of Standards and Technology).\n7.3.1Erstellen eines Datenflussdiagramms\nAbbildung 7.3 zeigt ein einfaches Datenflussdiagramm (DFD) für eine Banking-App, eine App also, die für den Zugriff auf Kontodaten bei einer Bank gedacht ist. Dieses Diagramm zeigt die App und ihre Kommunikationsbeziehungen. Es enthält noch keine näheren Informationen darüber, wie die App intern strukturiert ist. Ein Datenflussdiagramm dieser Detailtiefe bezeichnet man als Kontextdiagramm, und ein Kontextdiagramm ist die Grundlage eines Threat Models.\nAbbildung 7.3 Kontextdiagramm einer Banking-App\nDie nächste Ebene des Datenflussdiagramms, Ebene 1, zeigt die einzelnen Module der App (siehe Abbildung 7.4). Je nach Komplexität von Architektur oder App lässt sich das Datenflussdiagramm in weiteren Ebenen immer mehr verfeinern. Für die meisten Fälle genügen die Ebenen 0 und 1 aber vollkommen, denn wie Sie gleich sehen werden, lassen sich aus Abbildung 7.3 und Abbildung 7.4 schon alle für den Programmierer relevanten Bedrohungen ermitteln, die gegen die Banking-App wirken können.\nAbbildung 7.4 Ebene 1 der Banking-Applikation im Datenflussdiagramm\nEin Datenflussdiagramm (DFD) kann aus den folgenden Elementen bestehen:\nAbbildung 7.5 Entität im DFD\nLord Knut Knillenhauer\nIm Gegensatz zu einer Entität ist ein Prozess dadurch gekennzeichnet, dass er Daten verarbeitet. Das bedeutet, dass ein Prozess mindestens einen Dateneingang (Entry Point) und mindestens einen Datenausgang (Exit Point) besitzen muss. Ein Prozess kann niemals Quelle oder Senke in einem DFD sein. Die Daten, die ein Prozess verarbeiten soll, müssen von einem anderen Objekt zugeführt werden, und die verarbeiteten Daten müssen an ein anderes Objekt abgegeben werden.\nAbbildung 7.6 Prozess im DFD\nEine Prozessgruppe ist nichts anderes als das, was der Name suggeriert: eine Gruppe von Prozessen, die der Übersichtlichkeit halber im DFD zu einer Gruppe zusammengefasst sind. Im Regelfall löst sich diese Gruppe in weiteren Ebenen des DFD auf. Eine komplexe App würde man beispielsweise in Ebene 0 als Prozessgruppe zeichnen und in den folgenden Ebenen dann in Module aufteilen.\nAbbildung 7.7 Prozessgruppe im DFD\nUm mit Gertrude Stein zu sprechen: Ein Datenspeicher ist ein Datenspeicher ist ein Datenspeicher. Der Wortsinn steht für die Bedeutung im DFD. Jeder Ort, an dem Daten gespeichert werden, ist im DFD ein Datenspeicher. Im Gegensatz zu einem Prozess, der möglicherweise auch Daten speichert – und sei es nur temporär –, verarbeitet der Datenspeicher aber keine Daten, ist also ein rein passives Element und somit ausschließlich Quelle und/oder Senke von Informationen.\nAbbildung 7.8 Datenspeicher im DFD\nDer Datenfluss symbolisiert den eigentlichen Sinn des DFD, nämlich den Weg der Daten durch das modellierte System. Dabei stellt der Pfeil die Richtung des Datenverlaufes von einer Quelle zu einer Senke dar. Ein bidirektionaler Datenfluss kann entweder durch zwei gegenläufige Pfeile oder einen Doppelpfeil dargestellt werden.\nAbbildung 7.9 Datenfluss im DFD\nDie Vertrauensgrenze oder Trust Boundary ist eine Erweiterung des ursprünglichen DFD für den Anwendungsfall des Threat Modelings. Eine Vertrauensgrenze trennt Bereiche unterschiedlicher Sicherheitsniveaus. Diese sind beim Threat Modeling von besonderem Interesse, da sich dort in der Regel die meisten Angriffsvektoren dadurch ergeben, dass Daten von einem unsicheren Bereich kommen und somit per se als nicht vertrauenswürdig gelten.\nAbbildung 7.10 Vertrauensgrenze (Trust Boundary) im DFD\nMit den Informationen aus den vorstehenden Absätzen können Sie nun die in Abbildung 7.3 und Abbildung 7.4 modellierte App analysieren. Das Kontextdiagramm zeigt, dass es zwei Entitäten gibt, die die App mit Daten beliefern. Der Benutzer gibt Daten über das GUI ein, und die Bank liefert Daten über das Netzwerk. Die App speichert die Zugangsdaten für das Online-Banking sowie die Bewegungs- und Transaktionsdaten in jeweils einem Datenspeicher. Zusätzlich ist zu beachten, dass Daten der App beim automatischen Backup über iTunes auf den Rechner des Benutzers gelangen können.\nEbene 1 teilt die App in ihre Hauptmodule auf, so dass der Datenfluss innerhalb der App sichtbar wird. Die Schnittstelle zum iTunes-Backup ist in dieser Ebene entfallen, da sie zur Darstellung im Kontextdiagramm keiner weiteren Detaillierung mehr bedarf.\nMit diesen beiden Diagrammen können Sie nun beginnen, spezifische Bedrohungen für die App zu ermitteln. Dazu ist es sinnvoll, eine Tabelle mit allen Elementen der Datenflussdiagramme zu erstellen, diese Tabelle Zeile für Zeile zu durchlaufen und für jedes Element zu überlegen, welche Bedrohung wirken kann. Entitäten, Prozesse und Datenspeicher lassen sich aufgrund der geringen Anzahl leicht in einer Tabelle wiederfinden. Um die vielen Datenflüsse sinnvoll in eine Tabelle überführen zu können, sollten Sie die Datenflüsse – wie in den beiden Abbildungen – mit Nummern versehen. Es hat sich in der Praxis als hilfreich herauskristallisiert, die Nummern aus der jeweiligen Ebene des DFD, gefolgt von einem Punkt und einer fortlaufenden Nummer, zusammenzusetzen. Damit ist sofort klar, in welcher Ebene sich der Datenfluss befindet, was bei komplexen Diagrammen mit vielen Ebenen extrem hilfreich ist.\nEin Datenflussdiagramm allein nützt natürlich nicht besonders viel, denn nur dadurch, dass Sie Ihre App schön aufgemalt haben, fallen Ihnen keine Bedrohungen ein. Es fehlen noch eine Methode und Quellen für beispielhafte oder häufig vorkommende Sicherheitslücken, die Sie als Hilfestellung verwenden können.\nInformationsquellen zu Sicherheitslücken\nEs gibt drei wichtige Quellen, die Informationen über Sicherheitslücken in IT-Systemen sammeln. Die erste und bei Programmierern wohl bekannteste ist das Open Web Application Security Project (OWASP) [Anm.: http://www.owasp.org] . OWASP ist ein freies, aus der Community heraus entstandenes Projekt, das sich ursprünglich nur mit der Sicherheit von Web-Applikationen beschäftigte. Daraus ist in der Zwischenzeit aber wesentlich mehr geworden: Es gibt mittlerweile sogar ein OWASP Mobile Security Project, das aber noch sehr in den Kinderschuhen steckt und daher keine Relevanz für die Praxis besitzt.\nOWASP, das im Übrigen durch eine gemeinnützige Organisation gleichen Namens getragen wird, veröffentlicht regelmäßig eine Liste der 10 häufigsten Sicherheitslücken in Web-Applikationen, die OWASP Top 10. Neben einigen rein web-bezogenen Sicherheitslücken sind die OWASP Top 10 auch für iOS-Programmierer ein wichtiger Ratgeber, denn kaum eine App kommt heutzutage ohne Kommunikation mit dem Internet aus, und obwohl das Frontend eine App und kein Browser ist, lauern dieselben Gefahren, die in einer Web-Applikation lauern können, auch bei der Programmierung einer App, die mit Servern im Internet kommuniziert. Das ist Grund genug, einen kurzen Blick auf die OWASP Top 10 zu werfen (Version 2010).\nEine detaillierte Erläuterung der OWASP Top 10 und der darin aufgeführten Sicherheitslücken würde locker ein eigenes Buch füllen, daher möchten wir Sie an dieser Stelle auf das sehr ausführliche OWASP-Dokument verweisen. [Anm.: https://www.owasp.org/images/b/b8/OWASPTop10_DE_Version_1_0.pdf] Wir werden aber im weiteren Verlauf des Kapitels bei der Ausarbeitung des Threat Models auf einzelne Sicherheitslücken aus der Top 10 zu sprechen kommen, insbesondere auf A1, A7 und A9.\nTabelle 7.1 Die OWASP Top 10\nID Thema Bedrohung\nEin Angreifer kann Befehle in einen dafür nicht vorgesehenen Datenstrom injizieren.\nEin Server leitet schädliche Eingaben (Scripte) eines Angreifers ungefiltert an einen Benutzer weiter.\nAuthentisierung und Session Management\nEin Angreifer kann Anmelde- oder Session-Mechanismen umgehen oder manipulieren und so auf Daten anderer Benutzer zugreifen.\nEin Angreifer kann auf ungesicherte Objekte zugreifen (Dateien, URL etc.).\nEin Angreifer kann Aktionen im Benutzerkontext anderer Benutzer ausführen lassen.\nFehler in Konfiguration und Betrieb der Betriebsplattform führen zu Sicherheitslücken.\nEin Angreifer kann auf nicht oder fehlerhaft verschlüsselte Daten zugreifen.\nEin Angreifer kann einen nur auf Verbergen von URLs basierenden Zugriffsschutz umgehen.\nDie Kommunikation zwischen den Netzwerkteilnehmern ist nicht ausreichend abgesichert und kann von einem Angreifer abgehört werden.\nEin Angreifer kann das Ziel von URL-Weiterleitungen manipulieren und damit Opfer auf falsche Seiten locken (z. B. Phishing-Angriffe).\nEine weitere gute Informationsquelle ist die Liste der 25 gefährlichsten und häufigsten Softwarefehler, die Top 25 Most Dangerous Software Errors [Anm.: http://cwe.mitre.org/top25] . Herausgeber ist die MITRE Cooperation in Zusammenarbeit mit dem SANS Institute. MITRE ist eine US?amerikanische Forschungsorganisation, und das SANS Institute (SANS steht für SysAdmin, Audit, Networking, Security) ist ein genossenschaftlicher Zusammenschluss von IT-Fachleuten mit Fokus auf IT-Sicherheit.\nDie MITRE Cooperation pflegt seit vielen Jahren eine öffentlich verfügbare Liste von Sicherheitslücken in IT-Systemen. Diese Liste mit dem Namen CVE (was für Common Vulnerabilities and Exposures steht) ist ein Industriestandard für die eindeutige Bezeichnung von Sicherheitslücken. Aus der CVE-Liste und den Erfahrungen des SANS (und weiterer IT-Sicherheitsunternehmen und -fachleute) entsteht jährlich die besagte Liste der 25 schlimmsten Software-Sicherheitslücken. Im Gegensatz zu den OWASP Top 10 ist diese Liste nicht primär auf die Sicherheit von Web-Anwendungen fokussiert, sondern auf IT-Systeme im Allgemeinen. Die meisten Elemente der OWASP Top 10 finden sich daher auch in dieser Liste wieder, wobei aus Konfigurationsfehlern resultierende Sicherheitslücken (OWASP A6) kein Bestandteil der Top 25 sind.\nMITRE und die Hacker\nDie MITRE Cooperation war nicht immer ein Aushängeschild für IT-Sicherheit. Ganz im Gegenteil. Der bekannte KGB-Hack [Anm.: https://secure.wikimedia.org/wikipedia/de/wiki/KGB-Hack] Ende der 1980er Jahre lief zu großen Teilen über ungesicherte Systeme der MITRE Cooperation. Und wie es auch heute noch typisch für Institutionen ist, die man auf die Sicherheit ihrer IT-Systeme anspricht, stritt auch die MITRE Cooperation damals lange ab, ein Problem zu haben – so lange, bis es sich nicht mehr leugnen ließ.\nUm Ihnen für den weiteren Verlauf des Kapitels weitere potenzielle Sicherheitslücken aufzuzeigen, finden Sie nachfolgend die Top 25 von MITRE und SANS aus dem Jahr 2011 samt einer kurzen Erläuterung, denn die Grundlage eines erfolgreichen Threat Models und der sicheren Programmierung ist die Kenntnis der wichtigsten Sicherheitslücken. Wo es dem Verständnis und der Wahrheitsfindung dient, sind einige Code-Beispiele eingefügt. Da alle aufgeführten Sicherheitslücken in Internet und Literatur bereits vielfach in epischer Breite und beliebiger Detailtiefe beschrieben sind, haben wir die folgenden Erläuterungen so kurz wie möglich gehalten, denn Sie möchten ja iOS-Apps programmieren und kein Fachmann für IT-Sicherheit werden.\nTop 1: SQL Injection\nEin Angreifer schleust SQL-Befehle mit einer Eingabe in die Kommunikation ein und bringt diese Befehle somit auf der Datenbank zur Ausführung. Das Einschleusen erfolgt über die Benutzerschnittstelle, nicht über die Manipulation des Netzwerkverkehrs. SQL Injection ist daher ein Problem der Eingabevalidierung. Benutzereingaben müssen grundsätzlich auf schädliche Sonderzeichen hin untersucht werden, und diese Sonderzeichen müssen anschließend entfernt werden.\nEine beispielhafte SQL-Abfrage, die die Existenz eines Benutzers und die Richtigkeit seines Passwortes abfragt, ist die folgende:\nselect * from tbl.user where user='foo' and pw='bar';\nGibt es eine Zeile in der Tabelle tbl.user, bei der die Spalte user den Wert foo und die Spalte pw den Wert bar hat, ist der Benutzer vorhanden, das Passwort korrekt und die Anmeldung somit erlaubt.\nDas SQL-Statement selbst steht fest, und die Werte für die Spalten user und pw kommen aus Benutzereingaben. In Objective-C abgebildet, sähe das Ganze wie folgt aus (die beiden NSString-Objekte user und pass simulieren in dem Beispiel die Benutzereingaben):\nNSString *user = @"foo";\nNSString *pass = @"bar";\n@"select * from tbl.user where user='%@'\nand pass='%@'", user, pass];\nNSLog(@"query: %@", query);\nListing 7.1 SQL-Befehl zur Autorisierung eines Benutzers\nDas Ergebnis in der Konsole ist eine gültige SQL-Abfrage:\nquery: select * from tbl.user where user='foo' and pass='bar'\nGibt ein böswilliger oder neugieriger Benutzer statt seines regulären Passwortes aber einen simplen SQL-Befehl ein ...\nNSString *pass = @"' or 1=1--";\n... hat die ganze Abfrage jetzt eine ganz andere Bedeutung:\nquery: select * from tbl.user where user='foo'\nand pass='' or 1=1--'\nDiese Abfrage gibt als Ergebnis die Zeile der Tabelle tbl.user zurück, bei der die Spalte user den Wert foo hat, das Passwort leer ist oder die Bedingung 1=1 erfüllt ist. Und die letzte Bedingung ist immer erfüllt, denn 1 ist grundsätzlich immer 1! Ein Angreifer kann sich auf diese Weise also ohne Kenntnis des Passwortes am System anmelden. Der Grund dafür ist, dass der Programmcode die Eingabe des Benutzers ungefiltert in SQL-Befehle integriert und an die Datenbank schickt.\nDie erste Maßnahme gegen SQL Injection ist daher die Validierung der Benutzereingabe auf schädliche Sonderzeichen – besonders auf das einfache Hochkomma, das Minuszeichen und das Semikolon.\nDie zweite Maßnahme ist die Verwendung von Prepared Statements, sofern die jeweilige Datenbank dies unterstützt. Außerdem verfügen die meisten Datenbank-Bibliotheken über Abfragemethoden, die den Input-String direkt auf schädliche Sonderzeichen filtern.\nWenn Sie die iOS-eigene Datenbank SQLite verwenden, können Sie problemlos Prepared Statements [Anm.: https://www.sqlite.org/c3ref/stmt.html] verwenden, genauso wie bei vielen anderen gängigen Datenbanksystemen.\nZur Validierung von Eingabedaten gibt es zwei grundlegende Ansätze. Das Whitelisting definiert explizit die Zeichen, die erlaubt sind. Alle anderen Zeichen werden verworfen. Das Blacklisting definiert explizit die Zeichen, die verboten sind.\nSie sollten grundsätzlich bei allen sicherheitsrelevanten Auswahlverfahren das Whitelisting verwenden. Denn nur damit stellen Sie sicher, dass Sie nicht durch eigene Nachlässigkeit etwas übersehen oder von einem findigen Angreifer ausgetrickst werden.\nTop 2: OS Injection\nAnalog zur SQL Injection kann ein Angreifer Betriebssystem-Befehle in eine Benutzereingabe schleusen und diese Befehle auf dem System zur Ausführung bringen, wenn die Benutzereingabe ungefiltert verarbeitet wird. Darüber hinaus gibt es gängige Injection-Angriffe gegen LDAP-Systeme und XML-Parser.\nDie Maßnahme gegen diese Art von Angriffen sind analog zur SQL Injection die strikte Filterung von Benutzereingaben und, sofern möglich, die Einrichtung weiterer Filtermöglichkeiten auf dem Weg zum Backend.\nTop 3: Buffer Overflow\nEin Angreifer kann die fehlende Längenüberprüfung einer Funktion ausnutzen und Speicherüberläufe provozieren, um z. B. eigenen Code zur Ausführung zu bringen. Besonders bekannt sind Angriffe gegen stackbasierte Buffer Overflows, die durch die Verwendung unsicherer C-Funktionen die Rücksprungadresse einer Funktion manipulieren und den Programmfluss dadurch auf Code umleiten, der vom Angreifer gesteuert wird.\nEin simples Beispiel für einen Angriff dieser Art zeigt der folgende C-Code:\nListing 7.2 Simpler Buffer Overflow\nDas Problem bei Listing 7.2 besteht darin, dass die Funktion strcpy die Länge ihrer Parameter nicht überprüft. So führt die Zuweisung von zehn Zeichen an ein nur vier Zeichen großes Array zu keiner Fehlermeldung während der Übersetzung. Zur Laufzeit überschreibt diese Zuweisung dann aber gnadenlos den Stack-Speicher – das Programm stürzt ab. Das Problem liegt also sowohl in der fehlenden Überprüfung durch die Sprache als auch in der falschen Verwendung der Funktion durch den Programmierer.\nNeben stackbasierten Buffer Overflows gibt es solche, die auf dem Heap stattfinden. Grundsätzlich bezeichnet der Begriff Buffer Overflow aber alle Fehler, bei denen zu viele Daten in einen Puffer geschrieben werden.\nEine generische Maßnahme gegen Buffer Overflows gibt es nicht. Wenn Sie sich in der iOS-Programmierung nur auf der Ebene von Cocoa Touch bewegen, haben Sie keine Probleme mit Buffer Overflows. Sobald Sie aber in die C-Welt hinabtauchen, stehen Ihnen all die schönen Sicherheitslücken zur Verfügung, die C und seine Implementierung bietet. Apple hält zu diesem Thema den Secure Coding Guide bereit, der auf die Grundlagen der sicheren C-Programmierung eingeht. Werfen Sie im Bedarfsfall einen Blick dort hinein; sie finden das Dokument in der Xcode-Dokumentation. Grundsätzlich aber gilt, insbesondere für Programmierer ohne C-Erfahrung: Verwenden Sie in erster Linie den höchstmöglichen API-Level für Ihre Programmierung.\nTop 4: Cross Site Scripting\nAbhilfe gegen XSS schafft das sogenannte Escapen von Sonderzeichen. Damit wandeln Sie die Sonderzeichen in der Benutzereingabe in unschädliche Varianten um, die vom Browser nicht als Code-Tags interpretiert werden. Allerdings ist beim XSS nicht nur die Eingabe-, sondern auch die Ausgabeseite relevant, denn Sie sollten nie davon ausgehen, dass alle Daten, die an den Benutzer gehen, aus vertrauenswürdiger Quelle stammen. Wenn Sie, um beim Beispiel des Forums zu bleiben, zwar alle Benutzereingaben auf schädliche Zeichen hin prüfen, sich aber über importierte RSS-Feeds XSS-Angriffe einhandeln, hilft Ihnen nur die Validierung der Ausgabedaten.\nDas Escapen von Sonderzeichen ist mit Cocoa Touch praktischerweise ganz einfach, wie der folgende Code-Schnipsel zeigt:\nNSString *evilString = @"c:\_foobar<script>alert(23)</script>";\nNSLog(@"evilString: %@", evilString);\nNSString *sanitizedString =[evilString\nNSLog(@"sanitizedString: %@", sanitizedString);\nListing 7.3 Escapen von Sonderzeichen\nDer NSString evilString enthält neben sonstigen Sonderzeichen eckige Klammern, die dazu verwendet werden, Code für den Browser zu kennzeichnen. In der NSLog-Ausgabe sehen Sie, dass obendrein der Backslash zu einem Umbruch geführt hat, da er eine Formatierungsanweisung enthält:\n2012-08-01 20:00:37.938 Top25Foo[32685:c07] evilString:\nDer über die Methode stringByAddingPercentEscapesUsingEncoding ins UTF8-Format konvertierte NSString sanitizedString enthält hingegen nur noch sogenannte escapte Zeichen. Die stellt ein Browser zwar als die ursprünglichen Zeichen dar, interpretiert sie aber nicht mehr als Code-Tags:\n2012-08-01 20:00:37.939 Top25Foo[32685:c07] sanitizedString:\nAuf Ein- und Ausgabe angewendet, sorgt die Funktion also dadurch für Sicherheit, dass über sie keine XSS-Schwachstelle entstehen kann.\nTop 5: Fehlende Authentisierung für sicherheitsrelevante Funktionen\nBei diesem Fehler handelt es sich weniger um einen Implementierungs- als vielmehr um einen Designfehler. Er besteht darin, dass der Zugriff auf sicherheitsrelevante Funktionen ohne wirksame Authentisierung möglich ist. Denken Sie bei der Implementierung sicherheitsrelevanter Funktionen daher immer daran, diese gut zu schützen. Wenn Ihre App beispielsweise einen Uploadservice für Dateien anbietet, dann wäre es ein typischer Fehler dieser Art, wenn die Uploadfunktion immer aktiviert wäre und jeder ohne Authentisierung die bereits hochgeladenen Dateien wieder herunterladen könnte. Damit fänden Sie in jedem öffentlichen Hotspot viele Freunde.\nTop 6: Fehlende Autorisierung\nDieser Fehler liegt vor, wenn es entweder keine Autorisierungsfunktion gibt oder wenn eine vorhandene Autorisierungsfunktion fehlerhaft arbeitet. Wenn Ihre App beispielsweise im Kontext einer Client-Server-Architektur ein Rollenmodell verlangt, um verschiedene Benutzer und Benutzer unterschiedlicher Privilegierungsstufen zu unterscheiden, dann muss dieses Rollenmodell zum einen vorhanden, zum anderen sicher sein. Wenn ein Angreifer durch die Änderung eines Parameters Administratorrechte erlangt und auf die Daten aller Benutzer zugreifen kann, liegt ein Fehler dieser Art vor.\nTop 7: Verwendung fest kodierter Geheimnisse\nEs kommt ständig vor, dass eine App Geheimnisse speichern muss. Ein Geheimnis kann das Passwort für den Datenbankzugriff im Backend sein, ein Geheimnis kann ein Zertifikat sein, eine Seriennummer etc.\nGanz schlechter Stil – und ebendieser Fehler – ist das feste Einkodieren von Geheimnissen in die App, z. B. als NSString im Quelltext. Zum einen lässt sich ein String ohne weiteres aus der App wieder auslesen und ist somit allen zugänglich, die diese App in die Hände bekommen. Zum anderen lässt sich ein auf diese Weise gespeichertes Geheimnis nicht ändern – Sie müssten eine neue App übersetzen und verteilen.\niOS bietet zum Speichern von Geheimnissen die Keychain (siehe Abschnitt 7.4.2), daher gibt es zum Glück keine Ausrede dafür, Geheimnisse im Quelltext oder an vergleichbar unglücklicher Stelle zu speichern.\nTop 8: Fehlende Verschlüsselung sensibler Daten\nDie Überschrift beschreibt die Sicherheitslücke bereits sehr treffend. Gemeint sind damit alle Stellen, an denen personenbezogene oder andere sensible Daten nicht durch wirksame Verschlüsselung vor unbefugtem Zugriff geschützt werden. Das kann die Ablage im Dateisystem betreffen, die Übertragung im Netzwerk, Einträge in der Keychain etc. In Abschnitt 7.4.4, »Verzeichnisse und Datenattribute«, werden Sie die iOS-eigenen Mechanismen für die Verschlüsselung von Daten kennenlernen, so dass Ihnen dieser Fehler (hoffentlich) nicht unterlaufen wird.\nTop 9: Unsichere Uploadfunktion\nBeim Upload von Dateien auf Server kann es passieren, dass die fehlende Überprüfung der hochgeladenen Dateien dazu führt, dass ein Angreifer darüber Schadcode einschleust. Auf einem Webserver könnte beispielsweise ein Angreifer aktiven Code hochladen (z. B. Java oder PHP) und der Webserver den Code beim Abruf der hochgeladenen Datei ausführen. Damit stünde dem Angreifer der Webserver offen.\nAuf eine App bezogen, könnte der Fall eintreten, dass eine App eine Server-Schnittstelle öffnet, um den Upload von Dokumenten auf ein iDevice zu ermöglichen. Gelingt es einem Angreifer, über diese Schnittstelle Dateien hochzuladen, die Schadcode oder sonstige Schadroutinen enthalten, öffnet diese App eine veritable Sicherheitslücke. Solch ein Schadcode kann z. B. ein Konfigurationsprofil für iOS sein, das der Angreifer mit dem iPhone Configuration Utility [Anm.: http://support.apple.com/kb/DL1465?viewlocale=de_DE] erstellt und ahnungslosen Nutzern in öffentlichen Hotspots über die Uploadfunktion der betreffenden App auf ihre iDevices lädt. Öffnet ein Benutzer dann die Datei, installiert sich das Profil, und je nachdem, welche Einstellungen der Angreifer vorgenommen hat, können diese die komplette Funktionsuntüchtigkeit des Gerätes bewirken.\nEine App sollte daher bei der Verwendung einer Uploadfunktion die hochgeladenen Dateien auf Typ und Inhalt hin prüfen.\nTop 10: Sicherheitsrelevante Entscheidungen aufgrund unsicherer Eingaben\nDiese Art von Fehler kommt häufig in einer Client-Server-Kommunikation vor. Rufen Sie sich die App aus dem Beispiel der SQL Injection noch einmal ins Gedächtnis. Diese App authentisiert einen Benutzer gegen eine Datenbank. Das heißt, dass der Benutzer nur Zugriff auf die Daten erhält, wenn seine Anmeldedaten in der Datenbank vorhanden sind. Die App validiert die Benutzereingaben, um zu verhindern, dass sich ein Angreifer über eine SQL Injection unbefugten Zugriff auf die Daten verschafft.\nNun ist die App auf dem iDevice aus Sicht des Datenbankservers, der sicher verwahrt in einem Rechenzentrum steht, ein unsicheres System. Daher sollte sich der Server nicht darauf verlassen, dass die Daten, die von der App kommen, vertrauenswürdig sind. Der Angreifer kann die Daten ja auch auf dem Weg von der App zum Server manipulieren, einfach indem er sich mit einem Proxyserver in die Mitte setzt. Wenn er dann dort eine SQL Injection in den Datenstrom einfügt, kann er die Datenbank kompromittieren. Der Server muss seinerseits also auch Maßnahmen gegen SQL Injection treffen.\nDies entspricht zum einen dem Prinzip Defense in Depth (siehe Abschnitt 7.3.3, »Generische Designgrundsätze«), vermeidet aber den Fehler, dass Daten aus unsicherer Quelle ungeprüft für sicherheitsrelevante Aktionen (in diesem Fall die Authentisierung des Benutzers) herangezogen werden.\nTop 11: Ausführung mit nicht benötigten Rechten\nDieser Punkt subsumiert alle Sicherheitslücken, die daraus entstehen, dass Funktionen mit mehr Berechtigungen ausgeführt werden als nötig. Das betrifft bei der App-Entwicklung nicht die App selbst, denn diese bekommt Ihre Berechtigungen von iOS zugewiesen. Um beim Beispiel der SQL Injection zu bleiben, wären nicht benötigte Rechte dann vorhanden, wenn der Datenbankbenutzer, mit dem die App auf die Datenbank zugreift, über Administratorrechte auf der Datenbank verfügt (DB-Admin). Ist dies der Fall, wäre eine SQL Injection fatal, denn dann könnte ein Angreifer auf alle Daten in der Datenbank zugreifen.\nVerwendet die App aber einen Datenbankbenutzer, der nur über so viele Rechte verfügt, wie notwendig sind – z. B. ausschließlich über lesenden Zugriff auf die Benutzertabelle –, dann hält sich der Schaden in Grenzen.\nTop 12: Cross Site Request Forgery\nCross-Site Request Forgery (XSRF) ist eine web-spezifische Sicherheitslücke, die bei der App-Programmierung selbst nicht auftritt, sondern nur innerhalb einer Web-Applikation. Detaillierte Informationen dazu finden Sie in der Dokumentation des OWASP-Projekts [Anm.: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)] .\nTop 13: Path Traversal\nBeim Path Traversal wird der Zugriff auf eine Ressource über Benutzereingaben manipuliert. Ein klassischer Fall ist eine Downloadfunktion, bei der ein Angreifer durch geschickte Manipulation von Parametern beliebige Dateien herunterladen kann. Wenn der Zugriff auf Ressourcen schon dynamisch erfolgen muss, sollte er nicht über Benutzereingaben manipulierbar sein. Überdies müssen Pfadelemente wie Punkte (.), Slashes (/) und Backslashes (\_) aus Benutzereingaben herausgefiltert werden.\nTop 14: Download ohne Integritätsprüfung\nEine Sicherheitslücke dieser Art entsteht, wenn eine App Code aus unsicherer Quelle nachlädt (also z. B. aus dem Internet) und diesen Code nicht auf Integrität hin prüft. Manipuliert ein Angreifer den Code, kann er darüber beliebigen Schadcode einschleusen.\nBei der Programmierung von Apps für den Apple App Store kann dieser Fehler nicht auftreten, da die Apple-Richtlinien das Nachladen von Code verbieten. Eine App mit so einer Funktion käme (falls Apple dies bei der Überprüfung der App bemerkt) daher nicht in den Store.\nProgrammierer im Enterprise-Umfeld müssen sich aber nicht an die Apple-Richtlinien halten, so dass eine App beliebigen Code nachladen kann. Denken Sie in diesem Fall immer daran, eine Integritätsprüfung zu implementieren, um sicherzustellen, dass der Code auch der ist, den Sie haben wollen.\nTop 15: Fehlerhafte Autorisierung\nDie fehlerhafte Autorisierung von Benutzern oder Rollen führt immer wieder zu schweren Sicherheitslücken, die den unbefugten Zugriff auf Ressourcen erlauben. Wenn Ihre App Trust- und Rollenmodelle verwendet, um Benutzer oder Rollen zu autorisieren, müssen Sie darauf achten, dass ein Angreifer den Autorisierungsmechanismus nicht umgehen kann.\nTop 16: Verwendung von Funktionen in unsicheren Bereichen\nSicherheitslücken dieser Art entsprechen denen von Punkt 10, nur dass sie nicht aus der Verwendung von Informationen aus unsicherer Quelle resultieren, sondern aus der Verwendung von Funktionalität aus unsicherer Quelle, z. B. aus der Verwendung eines Frameworks, das Schadroutinen enthält.\nEs ist schwierig, Sicherheitslücken dieser Art zu erkennen. Sie haben in Kapitel 2, »Die Reise nach iOS«, Kategorien kennengelernt. Es ist z. B. möglich, dass ein Framework über Kategorien die Methode einer Cocoa-Touch-Klasse überschreibt und mit unerwünschten Funktionen anreichert. Wenn Sie dieses Framework in den eigenen Code einbinden, ist diese Kategorie bei allen Klassen vorhanden, die über Importanweisungen mit dem Framework verbunden sind.\nEin anderer Fall ist das Auslagern von Funktionalität an einen Dienst, z. B. eine Cloud. Wenn Sie nicht zufällig Betreiber dieses Dienstes sind und eine belastbare Aussage über die Sicherheit desselben treffen können, sollten Sie den Dienst als grundsätzlich unsicher betrachten und die entsprechenden Vorkehrungen treffen, um die Gefahren zu minimieren, die aus dieser Annahme resultieren.\nTop 17: Fehlerhafte Berechtigungen\nEine Sicherheitslücke dieser Art liegt vor, wenn eine wichtige Ressource nicht ausreichend vor unbefugtem Zugriff geschützt ist. Ein Klassiker sind falsche Dateisystemberechtigungen für sicherheitsrelevante Dateien. Wenn ein Angreifer lesend auf die Datei /etc/shadow in einem Linux-System zugreifen kann, hat er Zugriff auf die Passwort-Hashes aller Benutzer.\nMit solchen Feinheiten haben Sie dank der restriktiven Sandbox von iOS bei der App-Programmierung nicht zu kämpfen, trotzdem sollten Sie sich als App-Programmierer immer die Frage stellen, wer Zugriff auf eine Ressource bekommen muss, und den Zugriff grundsätzlich so restriktiv wie möglich gestalten.\nTop 18: Verwendung potenziell unsicherer Funktionen\nIn der Beschreibung von Buffer Overflow (Top 3) haben Sie bereits die C-Funktion strcpy kennengelernt, die aufgrund der fehlenden Überprüfung der Pufferlänge grundsätzlich unsicher ist. Funktionen solcher Art gibt es einige, und die Verwendung dieser Funktionen führt immer wieder zu schweren Sicherheitslücken.\nDarüber hinaus gehört die falsche Verwendung kryptografischer Funktionen bzw. die Verwendung unsicherer kryptografischer Funktionen zu dieser Fehlerklasse. So weist die API CCCryptor in iOS eine Sicherheitslücke auf, da es zwar standardmäßig den CBC-Modus [Anm.: https://secure.wikimedia.org/wikipedia/de/wiki/Cipher_Block_Chaining_Mode] für symmetrische Algorithmen verwendet, als Initialisierungsvektor aber nur Nullen verwendet. Das führt zu einer unsicheren Verschlüsselung. Die Verwendung von CCCryptor im Standardmodus ist daher ein Beispiel für die Verwendung einer potenziell unsicheren Funktion.\nTop 19: Verwendung unsicherer kryptografischer Algorithmen\nNeben der Verwendung unsicherer Funktionen ist die Verwendung unsicherer kryptografischer Algorithmen eine weitere typische Quelle von Sicherheitslücken. Sie müssen als Programmierer daher immer prüfen, dass die von Ihnen verwendeten Algorithmen noch als sicher gelten.\nDie Verwendung sicherer Algorithmen allein ist noch kein Garant für Sicherheit. Sie müssen darüber hinaus auf die korrekte Verwendung achten. Dazu zählen insbesondere die folgenden Punkte:\nausreichend lange und starke Schlüssel\nsichere Ablage von Schlüsselmaterial\nVerwendung hinreichend zufälliger Zufallszahlen-Generatoren\nTop 20: Falsche Berechnung von Puffergrößen\nDieser Punkt entspricht Punkt 3. Warum der falsche Umgang mit Puffergrößen zweimal in der Top 25 auftaucht ... Gute Frage.\nTop 21: Fehlende Begrenzung von Anmeldeversuchen\nEin Weg, unbefugten Zugang zu Systemen zu erlangen, ist das Durchprobieren von Anmeldedaten, der sogenannte Brute-Force-Angriff. Hat eine App oder ein System keinen Mechanismus implementiert, um Brute-Force-Angriffe zu erkennen und zu unterbinden, kann ein Angreifer beliebig viel Zeit damit verbringen, sich Zugang zu verschaffen.\nImplementieren Sie daher stets Mechanismen gegen Brute-Force-Angriffe, wenn Sie Authentisierungsfunktionen in Ihrer App haben. Ein gutes Beispiel ist das iPhone selbst. Mit aktiviertem Benutzercode haben Sie in der Standardkonfiguration sechs Anmeldeversuche, bevor das Gerät für eine Minute gesperrt wird. Ein angemessen starkes Passwort vorausgesetzt, braucht ein Angreifer schon sehr viel Glück, um dieses in sechs Versuchen zu erraten. Nach weiteren Fehlversuchen sperrt sich das iPhone am Ende für 60 Minuten, bis es sich nach 10 Anmeldeversuchen selbst löscht. Die gestaffelte Sperrung ist ein gutes Mittel, automatisierte Angriffe auszubremsen.\nTop 22: Unsichere URL-Weiterleitung\nDas Problem unsicherer URL-Weiterleitungen betrifft ausschließlich Web-Anwendungen und ist daher für die App-Programmierung nicht von Interesse. Grundsätzlich erlauben unsichere URL-Weiterleitungen einem Angreifer, Opfern Links von vertrauensvollen Institutionen zu schicken, die dann aufgrund einer fehlerhaft implementierten URL-Weiterleitungsfunktion an eine vom Angreifer kontrollierte Webseite weiterleiten, wo den Opfern dann Schadcode untergeschoben wird oder sie Opfer eines Phishing-Angriffs werden.\nTop 23: Formatstring-Fehler\nFormatstring-Fehler sind eine Erblast aus der C-Programmierung. Sie haben Formatstrings bereits in Kapitel 2, »Die Reise nach iOS«, kennengelernt und im weiteren Verlauf des Buches an zahlreichen Stellen verwendet. Formatstrings stellen aufgrund ihrer Natur eine grundsätzliche Gefahr dar: Ein Angreifer kann einen Formatstring, zu dem er die Eingabe liefern kann, durch eigene, eingeschleuste Formatierungsanweisungen dazu bringen, etwas anderes zu tun als vorgesehen – namentlich, unbefugt auf Speicher zuzugreifen. Bei der Verwendung von Formatstrings sollten Sie daher stets darauf achten, dass die Anzahl der Platzhalter der Anzahl der Argumente entspricht und dass Eingaben außerhalb ihres eigenen Kontrollbereichs nicht ungeprüft in einem Formatstring landen.\nTop 24: Integer Overflow oder Wraparound\nComputer sind folgsame Gesellen, denn sie machen genau das, was man ihnen sagt. Betrachten Sie die folgenden Code-Zeilen:\nNSLog(@"foo vorher: %i", foo);\nNSLog(@"foo nachher: %i", foo);\nListing 7.4 Addition von 1 und 127 im Datentyp »char«\nint bar = 4294967295;\nNSLog(@"bar vorher: %u", bar);\nNSLog(@"bar nachher: %u", bar);\nListing 7.5 Addition von 1 und 4.294.967.295 im Datentyp »Integer«\nNSLog(@"bar vorher: %u", fooBar);\nNSLog(@"bar nachher: %u", fooBar);\nListing 7.6 Subtraktion von 0 und 1 im Datentyp »Integer«\nDie Konsolenausgabe von Listing 7.4 ist die folgende:\n2012-08-02 21:06:38.514 Top25Foo[76237:c07] foo vorher: 127\n2012-08-02 21:06:38.516 Top25Foo[76237:c07] foo nachher: –128\nWas ist passiert? Der Datentyp char ist 8 Bit groß und kann daher 256 verschiedene Werte annehmen. Da es sich hier um ein char mit Vorzeichen handelt (signed), wird ein Bit für das Vorzeichen verbraucht: daher hat char einen Wertebereich von –128 bis 127. Die Addition von 1 und 127 führt also nicht etwa dazu, dass ein Laufzeitfehler auftritt, sondern der Computer schiebt die Bits einfach weiter: Ein Überlauf findet statt, und das Ergebnis ist -128. [Anm.: Das liegt an der Binärdarstellung der Werte.] Wenn dieser Wert in einem Programm zum Regeln einer Motorengeschwindigkeit genutzt wird, hätte der Überlauf fatale Folgen. Lachen Sie jetzt nicht; die europäische Rakete Ariane 5 sprengte sich bei ihrem Jungfernflug aufgrund eines Überlaufs selbst in die Luft!\nIn der Konsolenausgabe zu Listing 7.5 sehen Sie dasselbe Verhalten, diesmal mit einem Integer-Wert:\n2012-08-02 21:19:38.561 Top25Foo[77833:c07]\nbar vorher: 4294967295\nbar nachher: 0\nDieses Mal ist der Datentyp ohne Vorzeichen (unsigned). Die Addition von 1 und dem maximalen Integer-Wert 4.294.967.296 (32-Bit-Integer) führt zu einem Überlauf, und der Wert steht anschließend auf dem Minimalwert 0.\nDas Listing 7.6 zeigt den umgekehrten Fall, die Subtraktion vom Minimalwert bei einem unsignierten 32-Bit-Integer. Der Wert »wrappt«, und heraus kommt der Maximalwert:\n2012-08-02 21:19:38.562 Top25Foo[77833:c07]\nbar vorher: 0\n2012-08-02 21:19:38.563 Top25Foo[77833:c07]\nbar nachher: 4294967295\nDie Auswirkungen von Integer Overflows können mannigfaltig sein. Im besten Fall führen sie zum Absturz einer App, in schlimmeren Fällen zum Absturz einer Rakete. Achten Sie daher tunlichst darauf, Datentypen zu verwenden, die groß genug für die erwarteten Werte sind. Und vertrauen Sie nicht darauf, dass ein Benutzer nur Werte eingibt, die Sie erwarten. Aber dieses Thema hatten wir ja bereits.\nÜbrigens, die Verwendung von NSNumber als Wrapper für die primitiven C-Datentypen schützt Sie auch nicht vor Integer Overflows, wie das folgende Code-Beispiel zeigt:\nNSNumber *tschar = [NSNumber numberWithChar:257];\nNSLog(@"tschar: %i", [tschar charValue]);\nListing 7.7 »NSNumber« mit »char«-Wert 257\n2012-08-02 21:31:43.466 Top25Foo[79525:c07] tschar: 1\nCocoa Touch nimmt Ihnen in Sachen Integer Overflows nicht das Denken ab. Denken Sie daran!\nTop 25: Verwendung von Hashfunktionen ohne Salz\nDie letzte Sicherheitslücke aus der Top 25 ist die Verwendung von Hashfunktionen ohne Salz. Das hört sich nicht lecker an, und es ist auch nicht lecker. Kryptografische Hashfunktionen verwendet man häufig dazu, Geheimnisse so zu speichern, dass sie nicht mehr wiederhergestellt werden können. Ein Anwendungsfall ist das Speichern von Passwort-Hashes.\nWer die Passwörter seiner Benutzer nicht im Klartext speichern möchte, was ja ein ungeheures Missbrauchspotenzial eröffnet, schickt sie durch eine kryptografische Hashfunktion – eine sogenannte Falltür-Funktion – und speichert nur den daraus resultierenden Hashwert. Aus diesem lässt sich das Passwort nicht mehr zurückrechnen. Um anschließend zu überprüfen, ob ein Benutzer sein Passwort korrekt eingegeben hat, müssen Sie nur die Eingabe durch dieselbe Hashfunktion schicken und das Ergebnis mit dem gespeicherten Hash vergleichen.\nEs gibt zwar für aktuelle Hashfunktionen keine Möglichkeit, den Ausgangstext aus dem Hash zurückzurechnen, man kann aber Hashes im Voraus berechnen. [Anm.: http://www.freerainbowtables.com/de] Gelangt man dann als Angreifer in den Besitz von Passwort-Hashes, muss man nur noch die erbeuteten Hashes mit den Listen bereits errechneter Hashes vergleichen, um so auf die Passwörter zu kommen.\nNun nehmen die Listen vorausberechneter Hashes schnell viele Terabyte an Platz ein, und die Berechnung ist aufwendig, so dass es nicht für beliebige Texte vorberechnete Listen gibt, sondern nur für Passwörter bestimmter Länge und Komplexität. Da Benutzer gerne einfach zu merkende Passwörter nehmen, ist die Wahrscheinlichkeit sehr groß, dass sich aus einer erbeuten Datenbank die Passwörter über die vorausberechneten Hashes wiederherstellen lassen. Sind darüber hinaus Hashes von verschiedenen Systemen gleich, weiß der Angreifer, dass dort auch die Passwörter gleich sind.\nEine sichere Hashfunktion zeichnet sich dadurch aus, dass sie zwei Bedingungen erfüllt:\nUnumkehrbarkeit: Aus dem Hashwert darf der Klartext nicht rekonstruierbar sein.\nKollisionsfreiheit: Verschiedene Klartexte dürfen nicht denselben Hashwert ergeben.\nUm dies zu verhindern, sollte man beim Hashen von Passwörtern (oder anderen Geheimnissen) eine zufällige Zeichenkette vor den eigentlichen Text stellen. Diese Zeichenkette nennt man Salt (Salz), und sie sorgt dafür, dass Angriffe mit vorausberechneten Hash-Tabellen ins Leere laufen. Das ist wenig Aufwand für viel Sicherheit. Ein guter Tausch.\nFalls Sie sich bisher noch nicht mit sicherer Programmierung und typischen Sicherheitslücken auseinandergesetzt haben, werden Sie nun wahrscheinlich den Eindruck gewonnen haben, dass man in der IT-Sicherheit eine durchweg misanthropische Einstellung aufweisen muss. Und in der Tat ist es so, dass Misstrauen das oberste Gebot bei der sicheren Programmierung ist. Sie müssen zwar nicht gleich zum Menschenfeind werden, aber vertrauen Sie nichts und niemandem, den Sie nicht kennen. Daten aus nicht vertrauenswürdiger Quelle sind gefährlich.\nDoch sichere Software lässt sich nicht allein durch das Beachten relevanter Punkte in der Implementierungsphase produzieren. Sicherheit lässt sich vielmehr nur durch einen Softwareentwicklungsprozess gewährleisten, der verschiedene Sicherheitsaspekte berücksichtigt, so dass eine durchgängige Qualität von der Anforderungsphase bis zum Ausrollen der Software entsteht.\nIm Anhang des Buches finden Sie einen Anforderungskatalog, der die Anforderungen an einen Softwareentwicklungsprozess definiert, der das Erstellen sicherer Software ermöglicht. Insbesondere im Firmenumfeld lohnt sich ein Blick in diesen Anforderungskatalog.\nDoch nun zurück zum Threat Model, einem integralen Bestandteil sicherer Softwareentwicklung, dem Sie sich jetzt – gewappnet mit dem Wissen um die typischsten Sicherheitslücken – nähern können.\nNachdem Sie das Datenflussdiagramm (DFD) für Ihre App erstellt und alle Elemente in eine Tabelle überführt haben, kommt STRIDE ins Spiel. STRIDE hat seinen Ursprung ebenfalls bei Microsoft und ist ein Akronym, das sich aus den Anfangsbuchstaben der sechs Kategorien zusammensetzt, in die sich alle Bedrohungen einordnen lassen, die nach der STRIDE-Kategorisierung auf ein IT-System wirken können.\nSTRIDE ist also genau die Hilfe, die Sie benötigen, um Bedrohungen identifizieren zu können. Für jedes Element im DFD, also für jede Zeile der Tabelle, müssen Sie jetzt »nur« noch überlegen, welche Art von Bedrohungen aus den sechs STRIDE-Kategorien wirken kann. Sie erhalten mit STRIDE also eine generische Bedrohungsvorlage und können daraus eine konkrete Bedrohung ableiten – oder eben auch nicht, wenn keine Bedrohung vorhanden ist.\nTabelle 7.2 führt für jede der sechs STRIDE-Bedrohungen eine generische Gegenmaßnahme und konkrete Maßnahmen auf:\nTabelle 7.2 STRIDE-Bedrohungen und Gegenmaßnahmen\nAufgrund ihrer Natur unterliegen nicht alle Elemente des DFD allen STRIDE-Bedrohungskategorien. Da eine Entität z. B. keine Daten verarbeitet, kann kein Tampering stattfinden. Ebenso ist Information Disclosure bei einer Entität keine Bedrohung. Ein Benutzer kann zwar seine Zugangsdaten für das Online-Banking bei Facebook veröffentlichen, dies ist aber keine Bedrohung, die für den Programmierer der Banking-App relevant ist – die Bedrohung ist out-of-scope oder, um Douglas Adams zu bemühen, ein PAL (Problem anderer Leute).\nAbbildung 7.11 zeigt die möglichen Kombinationen von DFD-Element und STRIDE-Kategorie.\nAbbildung 7.11 Zuordnung von DFD-Elementen zu STRIDE-Kategorien\nAbbildung 7.12 Threat Model der Beispiel-App\nDer große Nutzen des Threat Modelings liegt in der Methodik. Diese Methodik leitet auch einen unerfahrenen Anwender durch die schwierige Aufgabe, spezifische Bedrohungen für seine App zu ermitteln. Das Threat Modeling ist diese Methodik, und daher ist es für den Erfolg unerlässlich, diese Methodik strikt anzuwenden. Das Zeichnen eines DFD und das anschließende Anfertigen einer Tabelle aller Elemente und ihrer Bedrohungen führt für sich genommen zu keinen bahnbrechenden Erkenntnissen; beide Tätigkeiten sind aber darauf ausgerichtet, den Anwender zu führen.\nDurch das methodische Vorgehen wird der Blick des Anwenders auf die wesentlichen Punkte gelenkt. Der Anwender wird gezwungen, sich intensiv Gedanken über seine App zu machen, und er erhält mit der STRIDE-Kategorisierung eine gute Hilfestellung, um selbständig Bedrohungen identifizieren zu können.\nEs gibt zwei typische Fehler beim Threat Modeling. Der erste Fehler ist, die Methodik nicht durchgehend anzuwenden. Machen Sie sich immer die Mühe, ein ausreichend detailliertes DFD zu erstellen. Das zwingt Sie dazu, sich intensiv mit der Architektur Ihrer App auseinanderzusetzen. Erstellen Sie im Anschluss die Tabelle der Elemente und der Bedrohungen. Dieser Schritt ist nicht nur dazu gedacht, alle Elemente auf Bedrohungen aus dem STRIDE-Katalog abzuklopfen, die Tabelle ist überdies das zentrale Dokument des gesamten Vorgangs. Liegt eine vernünftige Dokumentation vor, können Sie immer darauf zurückgreifen, was insbesondere bei der Weiterentwicklung Ihrer App wichtig ist. Sie möchten nicht für jedes neue Feature ein neues Threat Model erstellen, sondern das vorhandene erweitern können.\nDer zweite Fehler beim Threat Modeling ist es, über die Einordnung einer Bedrohung in eine der sechs STRIDE-Kategorien zu diskutieren. Ist, um bei der Beispiel-App zu bleiben, der Zugriff per Jailbreak (ID 1) nun ein Spoofing oder nicht eher eine Elevation of Privileges? Die Antwort ist: Das ist total egal! Es geht nicht darum, mögliche Bedrohungen möglichst passgenau in die sechs STRIDE-Kategorien einzuordnen, sondern darum, die sechs STRIDE-Kategorien zu verwenden, um Bedrohungen zu identifizieren! Allzu häufig verlieren sich Threat-Modeling-Workshops in dieser Diskussion, und das Ergebnis sind ein unvollständiges Threat Model, eine Software mit unentdeckten Sicherheitslücken und ein Team von Teilnehmern, das mit dem trügerischen Gefühl nach Hause geht, »richtig was geschafft« zu haben.\nDenken Sie also immer daran: Niemand gibt Ihnen eine gute Note für eine schöne Zeichnung, eine formvollendete Tabelle und korrekt klassifizierte Bedrohungen. Heise online wird Ihnen aber sicher einen prominenten Platz in seinem Newsticker geben, wenn Ihre App durch eklatante Sicherheitslücken aufgefallen ist.\nUm Ihnen den Einstieg und die Arbeit mit den STRIDE-Kategorien zu erleichtern, finden Sie nachfolgend zu jeder STRIDE-Kategorie einige Beispiele für Bedrohungen samt geeigneten Gegenmaßnahmen.\nSpoofing subsumiert alle Bedrohungen, bei denen ein Angreifer eine Identität fälscht, austauscht oder austauscht. Der Begriff der Identität ist dabei nicht auf die Identität einer Person beschränkt, sondern umfasst alle Objekte, die über eine Identität verfügen. Das können die verschiedensten Arten von Objekten sein:\nTabelle 7.3 Spoofing\nEin Angreifer fälscht die MAC-Adresse oder die IP-Adresse seines Rechners und umgeht auf diese Weise eine darauf basierende Authentisierung.\nAuthentisierung in der Anwendungsschicht durchführen oder zusätzliche netzwerkseitige Sicherungsmaßnahmen verwenden, z. B. SSL-Zertifikate für Server und/oder Client\nEin Angreifer tauscht eine von der App verwendete Bibliothek gegen eine mit Schadcode präparierte Bibliothek aus.\nIntegritäts- oder Versionsprüfung der verwendeten Bibliotheken. Sicherstellen, dass Bibliotheken ausschließlich von vertrauenswürdigen Verzeichnissen aus geladen werden\nDurch die Manipulation des Routings oder der Namensauflösung leitet ein Angreifer die Zugriffe der App auf einen Webserver auf einen von ihm kontrollierten Webserver um und erlangt auf diese Weise Zugriff auf sensible Daten.\nVerwenden von SSL zur Identifizierung des Webservers (z. B. Prüfen des Zertifikats über den Vergleich des Fingerprints)\nAlle Angriffe, die mit der Veränderung von Daten zu tun haben, fallen in die Kategorie Tampering. Das reicht vom schreibenden Zugriff in eine Datenbank mittels SQL Injection über Manipulationen am Dateisystem bis zur Veränderung der Netzwerkkommunikation.\nTabelle 7.4 Tampering\nEin Angreifer fängt über einen Man-in-the-Middle-Angriff unverschlüsselte Netzwerkkommunikation ab (z. B. in einem öffentlichen Hotspot), verändert den Datenstrom und greift so z. B. in Transaktionen ein.\nÜbertragung sensibler Daten ausschließlich über verschlüsselte Protokolle\nEin Angreifer deaktiviert durch einen über das Netzwerk applizierten Jailbreak die Sicherheitsmechanismen des iPhones seines Opfers und damit auch der App.\nPrüfen auf das Vorhandensein eines Jailbreaks beim Start der App\nEin Angreifer greift über eine SQL Injection in der App schreibend auf die Datenbank des Serversystems zu, das mit der App kommuniziert.\nFiltern aller Benutzereingaben auf potenziell schädliche Sonderzeichen\nRepudiation fasst sowohl das Verschleiern von Aktionen und Angriffen durch fehlendes Logging als auch Angriffe gegen und über Logging-Mechanismen zusammen.\nTabelle 7.5 Repudiation\nEin Angreifer führt Aktionen gegen eine App oder gegen ein aus einer App und einem Server bestehendes Kommunikationssystem durch, ohne dass diese Aktionen durch einen Logging-Mechanismus registriert werden.\nSchreiben aussagekräftiger Log-Dateien und Speicherung der Daten an sicherer (dritter) Stelle\nEin Angreifer liest sensible Daten aus Log-Dateien aus.\nLog-Dateien sollten gegen unbefugten Zugriff geschützt sein und keine sensiblen Daten wie z. B. Passwörter oder Transaktionsinterna (Kontostand etc.) enthalten.\nEin Angreifer kann den Logging-Mechanismus so beeinflussen, dass die Log-Dateien durch Rotation gelöscht werden, und dadurch seinen Angriff verschleiern.\nRotierte Log-Dateien nicht löschen. Logging in angemessener Detailtiefe, um das Anfallen zu großer Datenmengen in den Logfiles zu verhindern\nDie Preisgabe von Informationen jeglicher Art fällt in die Kategorie Information Disclosure. Informationen können dabei an den verschiedensten Stellen anfallen und von beliebiger Natur sein. Beispiele für Information Disclosure sind:\nTabelle 7.6 Information Disclosure\nEine App gibt bei (gezielter) Fehlbenutzung Fehlermeldungen mit Debug-Informationen aus.\nFehlermeldungen sollten grundsätzlich neutral gehalten sein. Debug-Informationen und Stack-Traces sollten ausschließlich in separate Debug-Log-Dateien oder an den Syslog-Server geschrieben werden.\nDer geheime Schlüssel für die Verwendung eines symmetrischen Kryptoalgorithmus ist als String im App-Binary gespeichert. Ein Angreifer kann den String ohne großen Aufwand auslesen und erhält auf diese Weise Zugriff auf die Verschlüsselung.\nSichere Ablage geheim zu haltender Informationen, z. B. in der Keychain. Keine Verwendung eines einzigen statischen Schlüssels für alle Instanzen einer App\nÜbertragung von Zugangsdaten über ein Klartextprotokoll (anfällig für Man-in-the-Middle-Angriffe)\nTabelle 7.7 Denial of Service\nEin Angreifer schleust über die Importfunktion einer App eine Datei mit manipuliertem Format ein und legt dadurch den Import-Parser der App lahm.\nRobuste Programmierung von Importfiltern und Parsern, um Angriffe über manipulierte Formate zu verhindern\nWiederholte fehlerhafte Anmeldung an der App führt kommentarlos zum Löschen aller lokalen Daten.\nVerwenden von Hinweisen, um den Benutzer auf die Gefahr aufmerksam zu machen; gegebenenfalls Implementierung einer Funktion zur Passwort-Merkhilfe\nEine schmalbandige Netzwerkverbindung führt dazu, dass Kernfunktionalitäten einer App nicht mehr funktionieren. Ein Angreifer im lokalen Netzwerk kann dies beim Start der App für DoS-Angriffe ausnutzen, indem er das Netzwerk mit Paketen flutet.\neffiziente Netzwerkprogrammierung und angemessenes Error-Handling verwenden\nDie letzte STRIDE-Kategorie umfasst alle Angriffe, bei denen ein Angreifer Aktionen in einem anderen als dem eigenen Rechtekontext ausführt. Im Webbereich ist das Cross-Site-Scripting eine bekannte Schwachstelle, bei der ein Angreifer eigenen Code im Sicherheitskontext eines anderen Webservers ausführen kann.\nTabelle 7.8 Elevation of Privileges\nEin unbefugter Benutzer greift auf die in den Hintergrund geschickte App zu und gelangt so in den Besitz sensibler Daten.\nSperren der App beim Wechsel in den Hintergrund. Reaktivierung nur über Eingabe der gültigen Zugangsdaten.\nEin Benutzer einer App oder ein Angreifer im Netz manipuliert von einer App an einen Server übermittelte Daten so mit Schadcode, dass der Server diesen Schadcode an andere Benutzer ausliefert.\nStrikte Filterung von Benutzereingaben auf potenziell schädliche Sonderzeichen und Sicherstellen der Integrität der Netzwerkübertragung. Auf dem Server zusätzlich strikte Filterung aller Ausgaben auf potenziell schädliche Sonderzeichen.\nDatenimport von einer nicht geprüften URL erlaubt einem Angreifer das Einschleusen von fehlerhaften Daten oder Schadcode.\nSemantische Prüfung von importiertem Content, Filterung auf potenziell schädliche Sonderzeichen, Verwenden von SSL, um Kommunikationspartner im Netz eindeutig identifizieren zu können\nBeim sicheren Design von Software gibt es einige grundsätzliche Prinzipen, die Sie als Entwickler verinnerlichen sollten. Da es nur eine Handvoll sind, sollte es Ihnen nicht allzu schwerfallen, sie sich zu merken. Die konsequente Beachtung dieser Prinzipien beim Design kann aber helfen, grobe Schnitzer zu vermeiden. Überdies taugt die Liste der Prinzipien in Kundengesprächen gut zum Bullshit-Bingo.\nKeep it simple, stupid: Von der Implementierung einer Klasse bis zum Design der Architektur sollte alles so einfach wie möglich gehalten sein. Komplexität führt zu Unübersichtlichkeit und Fehlern. Anstatt eine Methode in zwölf Ebenen zu schachteln, sollten Sie lieber eine Pause machen und darüber nachdenken, wo in der Planung etwas falsch gelaufen sein könnte.\nAttack Surface Reduction: Die Anzahl der Eintrittspunkte für Daten (Entry Points) sollte immer so gering wie möglich sein. Bevor Sie auf dem iPhone einen Serverdienst starten, sollten Sie lieber darüber nachdenken, ob es nicht auch umgekehrt geht (als Client).\nLeast Privilege: Verwenden Sie grundsätzlich die geringstmöglichen Rechte zur Ausführung von Operationen.\n7.3.4Threat Modeling aus der Tube – das Microsoft SDL Threat Modeling Tool\nWie wir in der Einführung zum Threat Modeling bereits erwähnt haben, wurde diese Methodik im Bereich der Softwareentwicklung ursprünglich von Microsoft eingeführt und verfeinert. Nach den großen Wurm-Plagen und den nicht abreißenden Meldungen über Sicherheitslücken in Microsoft-Produkten trat Microsoft im Jahr 2003 auf die Bremse und legte mit dem Security Push den Grundstein für den in den folgenden Jahren immer weiter intensivierten und verfeinerten Secure Development Lifecycle (SDL).\nNeben dem Ziel, eigene Produkte sicherer zu machen, lässt Microsoft auch Dritte an seinen Erkenntnissen rund um den SDL teilhaben und hat dazu das Microsoft SDL Pro Network ins Leben gerufen. Auf der dazugehörenden Website (http://www.microsoft.com/security/sdl) gibt es das Microsoft SDL Threat Modeling Tool kostenlos zum Download. Dieses Tool bietet eine Oberfläche zum Erstellen eines Datenflussdiagramms und erstellt aus diesem DFD selbständig die Tabelle der für die Elemente des DFD potenziell gefährlichen Bedrohungen – einfacher geht es wirklich nicht.\nNun wäre Microsoft nicht Microsoft, wenn es an der Sache nicht einen klitzekleinen Haken gäbe. Dieser äußert sich dergestalt, dass zwar das Tool kostenlos ist, Sie zum Benutzen aber eine installierte Version von Visio auf dem Rechner haben müssen, da die DFD-Erstellung im Tool über die Visio-Engine erfolgt. Honi soit qui mal y pense ... Der Umstand, dass das Tool nur für Windows erhältlich ist, ergibt sich direkt aus dem Visio-Zwang und muss hier nicht extra erwähnt werden. Trotzdem ist es zurzeit das einzige Tool, das Threat Modeling am DFD ermöglicht und diese Aufgabe auch hinreichend gut erledigt. Daher lohnt sich, sofern Windows und Visio vorhanden sind, auf jeden Fall ein Blick auf das Tool.\nDas Tool wurde von Entwicklern für Entwickler konzipiert und nicht von Security-Experten für Security-Experten. Das schlägt sich in der angenehm intuitiven, zielgerichteten und einfachen Bedienung nieder. Nach dem Start erstellt das Tool ein rudimentäres DFD, um die grundlegende Funktionsweise zu demonstrieren (siehe Abbildung 7.13).\nAbbildung 7.13 Das Microsoft SDL Threat Modeling Tool\nDas DFD befindet sich, nicht zu übersehen, im rechten Teil des GUI. Links daneben, im Bereich Shapes, finden Sie alle Elemente, die Sie für die Erstellung eines DFD benötigen. Ziehen Sie die benötigten Elemente einfach in den Zeichenbereich rechts, und erstellen Sie die notwendigen Verknüpfungen.\nDas Tool analysiert das DFD in Echtzeit und gibt Verstöße gegen die Semantik links im Bereich Diagram Validation aus. Das merken Sie spätestens dann, wenn Sie ein oder mehrere Elemente im DFD nicht korrekt verknüpft haben. So führt z. B. ein Prozess ohne Verbindungen zu der in Abbildung 7.14 gezeigten Fehlermeldung.\nDer Bereich Help im linken Teil des GUI gibt eine Minimal-Anleitung für die Erstellung eines DFD und verweist auf die dem Tool beiliegende Hilfedatei, die übrigens sehr gut ist.\nLinks oben befindet sich im Bereich Diagrams die Übersicht über die Ebenen des DFD. Fügen Sie mit der rechten Maustaste einfach weitere Ebenen hinzu, wenn Sie Ihr Diagramm weiter aufteilen möchten. Das DFD unserer Beispiel-App lässt sich somit ohne großen Aufwand über alle Ebenen in dem Tool darstellen (siehe Abbildung 7.15).\nAbbildung 7.14 Das Tool meldet einen Validierungsfehler.\nAbbildung 7.15 DFD der Beispiel-App im Threat Modeling Tool\nDer wahre Nutzen des Tools ergibt sich erst aus der Transformation der DFD-Elemente in die Liste der STRIDE-Kategorien. Dies erfolgt über den Button Analyze Model links unten im Fenster. Das Tool erstellt eine Liste der DFD-Elemente und fügt jedem Element die STRIDE-Bedrohungen hinzu, die für dieses Element wirken können (siehe die Zuordnungen in Abbildung 7.16).\nAbbildung 7.16 Die Liste der DFD-Elemente und ihrer STRIDE-Bedrohungen\nDurch Auswahl eines Elements öffnet sich rechts im Fenster die Liste der STRIDE-Bedrohungen. Neben einigen Informationen und Beispielen zu den einzelnen Bedrohungen gibt es dort für jede Bedrohung ein Textfeld mit dem Titel Impact und eines mit dem Titel Solution (siehe Abbildung 7.17). Im Feld Impact formulieren Sie die von Ihnen identifizierte Bedrohung und im Feld Solution die entsprechende Maßnahme.\nMöchten Sie keine Bedrohung formulieren, beispielsweise weil Ihnen keine einfällt oder weil Sie eine mögliche Bedrohung als akzeptabel erachten, klicken Sie auf den Link Certify that there are no threat of this type und geben die Begründung für diese Entscheidung an (siehe Abbildung 7.18).\nAbbildung 7.17 Spoofing für das Element »User«\nAbbildung 7.18 Ein akzeptiertes Risiko\nAbbildung 7.19 Der Threat-Model-Report\nDer Benutzer muss eine Liste aller Anwendungsfälle seiner App erstellen, und das Tool versucht, zu diesen Anwendungsfällen aus einer Bedrohungsdatenbank selbständig Bedrohungen zu identifizieren. Der Ansatz ist interessant, die Umsetzung ist aber wenig gelungen, und überdies wird das Tool von Microsoft nicht weiter gepflegt. Es lohnt sich also nicht, sich näher damit zu beschäftigen.


10 Hotels Xinzhu - Gratis-Storno für viele Hotels | Preisgarantie bei Hotels.com\nHotelsuche für Xinzhu\nGuangxi Natural MuseumEin Museumsbesuch darf auf Ihrer Urlaubscheckliste nicht fehlen? Dann sind die Sammlungen von Guangxi Natural Museum in Xing Ning bestimmt genau das Richtige für Sie. Wenn Sie von den Museen in Xinzhu nicht genug kriegen, besichtigen Sie Provinzmuseum, was nicht weit entfernt ist.\nProvinzmuseumEin Museumsbesuch darf auf Ihrer Urlaubscheckliste nicht fehlen? Dann sind die Sammlungen von Provinzmuseum in Qingxiu bestimmt genau das Richtige für Sie. Wenn Sie das kulturelle Angebot in Xinzhu in vollen Zügen genießen möchten, planen Sie einen Abstecher hierhin: Nanning People's Park, Chaoyang Square und Guangxi-Universität.\nMinorities Cultural Relics CenterEin Museumsbesuch darf auf Ihrer Urlaubscheckliste nicht fehlen? Dann sind die Sammlungen von Minorities Cultural Relics Center in Qingxiu bestimmt genau das Richtige für Sie. Wenn Sie das Angebot an Museen in Xinzhu voll ausschöpfen möchten, besichtigen Sie Provinzmuseum, bequem zu Fuß erreichbar.\nMehr über Xinzhu erfahren\nSuchen Sie Ihr neues Lieblingsreiseziel? Da haben wir etwas für Sie: Xinzhu. Ganz egal, ob Sie nur eine Nacht bleiben möchten oder eine ganze Woche, die Gegend um Xinzhu bietet Unterkünfte für jeden Geschmack. Über Hotels.com können Sie mithilfe unserer Online-Karte Hotels in und um Xinzhu suchen. Unsere Karte zeigt die Umgebung aller Hotels in Xinzhu, damit Sie einschätzen können, wie nah Sie an Sehenswürdigkeiten und Attraktionen sind, und Ihre Suche anschließend verfeinern können. Hier finden Sie unsere besten Hotelangebote in Xinzhu mit unserer Preisgarantie.


Schweißrauch absaugen - aber nur wenn es sein muss - bbr Bänder Bleche Rohre\nSchweißrauch absaugen - aber nur wenn es sein muss\nSensor-gesteuerte Schweißrauch-Absaugung mit dem NOVUS Airtower. Wie man die Betriebskosten bei der Luftreinhaltung gezielt senken kann.\nDer neue Sensor basiert auf der Streulichtdetektion und misst im Bereich zwischen 0 und 1.000 µg/m³. Es werden Partikelgrößen zwischen 0,1 und 100 Mikrometern erfasst. Eine LED-Anzeige zeigt den Verschmutzungsgrad der Prozessluft. In Zehner-Schritten leuchten die LEDS grün, gelb oder rot und geben so Rückschluss auf die Luftqualität.\nAb einer Partikeldichte von fünf Prozent wird der Novus Airtower in Betrieb genommen. Wenn dieser Wert länger als zwanzig Minuten unterschritten wird, fährt die Anlage in den Standby-Modus. Ein Ausgangssignal sendet die Messwerte an die Steuerung des Filterturms, der daraufhin seinen Betriebszustand fortsetzt oder anpasst. Optional bietet Novus Air eine drahtlose Messwertübertragung zwischen Sensor und Steuereinheit des Filterturms an.\nEin Highlight ist der austauschbare Partikelsensor. Denn bei Verschmutzung der Sensoreinheit muss nicht das komplette Modul, sondern nur ein Bauteil ausgetauscht werden. Der Raumluftqualitätssensor unterstützt alle vier Varianten des Airtowers zwischen 5.000 und 20.000 m³/h Luftvolumen. Er kann bei Umgebungstemperaturen von -10 bis 50 Grad Celsius eingesetzt werden. Zudem gehört er laut Anbieter zu den geräuschärmsten und energieeffizientesten Filtertürmen auf dem Markt.\nNovus Air bietet neben einem 360-Grad-Service von der Planung über Installation, Inbetriebnahme bis zur Wartung des Filterturms ein umfangreiches Paket optionaler Leistungen an, unter anderem IFA-W3-geprüfte Anlagenausführungen, Heiz- und Kühlmodule, kundenspezifische Designs, Möglichkeiten zur sensorischen Reststaubüberwachung, Fernwartungsservice oder spezielle Wechselfilter.\nNOVUS air GmbH, Weinböhla


Jonny vom Dahl: Christ und coole Socke - Weimar\n4. August 2017, 13:35 Uhr\nJonny vom Dahl bei seinem Auftritt bei »The Voice of Germany«\nFoto: Screenshot G + H\n»The Voice of Germany«: In der Castingshow von SAT 1 und ProSieben hat er es ganz weit gebracht, Jonny vom Dahl, BWL-Student in Jena und christlicher Musiker. Trotz des Erfolgs ist er auf dem Teppich geblieben.\nEr ist da. Es ist doch kein Werbe-Gag. Der Gottesdienst hat schon angefangen und da schlängelt er sich durch die Reihen. Ganz unauffällig, im Holzfällerhemd. An Jonny vom Dahl erinnert wenig an einen Bühnenstar. In der Weimarer Baptisten-Gemeinde geht auch kein Raunen durch das Gemeindezentrum, wenn der Sänger den Raum betritt. Immerhin ein junger Musiker, vor dem sogar Weltstar Robbie Williams den Hut zog: »Deine Stimme und dein Klang sind großartig.«\nMan kennt ihn hier, seit zwei Jahren besucht er, für einen Studenten relativ regelmäßig, am Sonntagmorgen den Gottesdienst. Die moderne Form gefällt dem 21-Jährigen. Vor allem der Lobpreis. Mit Lobpreisliedern und eigenen Songs ist er dann auch vor einem Jahr zum Casting gefahren. Eine Wette mit seinen Kumpels. Er scheint noch immer erstaunt darüber, dass es geklappt hat, wenn er heute davon erzählt. Unter vielen hundert Bewerbern hat man ihn zunächst für die Vorrunde der SAT 1-Castingshow »The Voice of Germany« (die Stimme Deutschlands) ausgewählt. Sein Vater, evangelischer Pfarrer im hessischen Hofheim und selbst Musiker, war zunächst überrascht von der verrückten Idee. Aber dann saß die ganze Familie am Fernseher und fieberte mit. Vom Vater hat er auch das Talent geerbt. Das Cello tauschte Jonathan, genannt Jonny, im Alter von 11 Jahren mit der Gitarre und gestaltete Jugendgottesdienste, sang im Jugendchor. Bald hat er seine erste Band. Dass er Musik mit christlichen Texten macht, ist für ihn selbstverständlich. »Ich bin mit einem sehr positiven Bild von Kirche aufgewachsen.«\nEigentlich kommt er aus einer evangelisch-lutherischen Kirchengemeinde. Dass er bei den Baptisten gelandet ist, hat mit seinen Freunden und der Freundin zu tun. Er sieht das ganz locker. Unterschiede scheint es für ihn nicht zu geben. Jungschar, Konfi-Gruppe, Jugendgruppen, das habe ihn geprägt. »Dass ich Christ geworden bin, hängt aber nicht mit meiner Herkunft oder dem Elternhaus zusammen«, erklärt er. Vor anderthalb Jahren erst habe er sich tatsächlich dafür entschieden. »Es gibt keinen speziellen Zeitpunkt, aber in dieser Zeit hat sich mein Glaube gefestigt«, versucht er den Vorgang zu beschreiben.\nNeben seinem Glauben spielt die Musik in seinem Leben eine wichtige Rolle. »Ich höre gern Musik, um abzuschalten. Wenn ich Musik höre oder selber mache, dann kann ich mich darin fallen lassen.« Gitarre, Bass, Klavier, Cajón oder Gesang, Jonny vom Dahl ist vielseitig.\nSmudo von den »Fantastischen Vier«, einer seiner prominenten Begleiter beim Talente-Wettbewerb im Fernsehen, bescheinigt ihm eine starke Bühnenpräsenz und eine coole Stimme, trotzdem muss und will der sympathische Student nicht ständig im Rampenlicht stehen. Sein Betriebswirtschaftsstudium hat auch nach dem Fernseherfolg Priorität. »Das BWL-Studium gibt mir die Grundlage, als Mensch, der irgendwie auch erwachsen werden muss.« Sollte der Weg ihn später doch mal ins Musikgeschäft führen, sei es ja auch nicht schlecht, Ahnung von Wirtschaft, Recht und Finanzen zu haben, meint er vorausschauend.\nAngebote von Produzenten habe er nach der Castingshow einige gehabt. Schneller Erfolg sei ihm aber nicht wichtig. Deshalb hat er sich auch für die Zusammenarbeit mit einem Musikproduzenten aus seiner Kirchengemeinde entschieden. In aller Ruhe will er darangehen, Lieder zu komponieren und aufzunehmen. Seine Fangemeinde ist durch die Medienpräsenz enorm gewachsen. Auf Facebook hat er mittlerweile fast 5 000 Follower. Sein Leben habe sich aber durch den Schnupperkurs im Showbusiness nicht verändert.\nIm Gegensatz zu seinem Glauben: »Ich habe einen Sprung ins Ungewisse gewagt. In eine Welt, die ich nicht kannte. Und ich bin mit der Mission da reingegangen, ein Beispiel für einen normalen, jungen Menschen zu sein, der Christ ist.« Gott habe aus seinem Ausflug ins Showgeschäft ganz viel gemacht, glaubt vom Dahl. Jeder Zuschauer hätte mitbekommen, dass er als Christ dort auftrete und der Glaube seine Lebensgrundlage sei. Dass man ihn in seiner Kirchengemeinde aufgefangen hat und ganz normal mit ihm umgeht, dafür ist er dankbar. Das gebe ihm ein Gefühl von Heimat und Geborgenheit. »Ich werde trotzdem noch zum Kaffeekochen eingeteilt«, bemerkt er schmunzelnd. »Ich war im Fernsehen nur der Jonny und niemand anders, und ich bin auch jetzt kein anderer Typ als vorher.« Mit den Mitgliedern der Band »Die Fantastischen Vier« und mit Yvonne Catterfeld steht er im persönlichen Kontakt. Mit Catterfeld hat er auch über seinen christlichen Glauben gesprochen. Sie hat ihn bei der Präsentation ihres neuen Studioalbums bei einem Konzert auf die Bühne geholt. »Du weißt, Jonny, ich bin ein Fan von dir«, sagte die Sängerin bei »The Voice of Germany«, und da ist sie wahrlich nicht die Einzige.


WBO König Joseph Parker vs Hughie Fury's - BET-IBC\nMelden Sie sich bei einem asiatischen Buchmacher an und bekommen Sie die besten Quoten für die besten Events. Unter dieser Vorraussetzung erwartet uns schon bald eines der meist erwarteten Events und Sie sollten nicht vergessen unseren Angeboten zu folgen.\nAm 23. September werden Hughie Fury und Joseph Parker gegeneinander kämpfen. Beide sind jung und unbeschlagen und beide wollen zeigen, dass sie die besten sind. Außerdem sind sie dazu bereit, die Ehre ihres Landes zu verteidigen.\nDer große Kampf wird in der Manchester Arena im Vereinigten Königreich stattfinden. Es wird das erste Hauptevent sein, dass dort nach der Terrorattacke im Mai veranstaltet wird. Manchester ist Fury’s Heimat während es für Joseph der erste Kampf dort sein wird. Diese Vorraussetzung könnte als Vorteil für Fury gesehen werden, da er der obligatorische Herrausforderer für den Titel ist obwohl er WBO’s #1 im Rang ist.\nJoseph Parker ist erfahrener, da er seit 1992 kämpft. Er erworb einen Rekord von 20-0-KO10 und ist zur Zeit der WBO Meister im Schwergewicht, wo er den Titel 2016 an sich nahm und ihn seit dem hält. Als ein Anfänger repräsentierte er Neuseeland bei den Commonwealth Spielen 2010 in der super Schwergewicht Klasse, während er eng die Qualifikation für die Olympia 2012 verpasste.\nHughie Fury hat einen Rekord von 23-0-KO18 obwohl er erst 22 Jahre alt ist. Er wurde professionell mit 18 Jahren im Jahr nachdem er den Sieg für die Goldmedaille bei den Jugend Welt Amateur Meisterschaft gewann. Im Dezember 2016 war er an zweiter Stelle nach Joseph Parker in der WBO Schwergewicht Meisterschaft.\nEs ist sehr ungewöhnlich imboxen, besonders in der Schwergewichts Klasse, zwei Kämpfer zu haben die:\ndie gleiche Anzahl an Rekorden haben,\nbeide in einem eher jungen Alter sind und\nbeide dazu bereit sind, deren Titel und deren Rekorde der Unbesiegbarkeit zu riskieren\nHolen Sie sich ein Konto bei einem asiatischen Buchmacher und unterstützen Sie Ihren Lieblings Kämpfer in einem der meist erwartenden Kämpfe des Jahres. Finden Sie die besten Quoten für dieses Event und wählen Sie aus einer Vielzahl der asiatischen Buchmacher. Matchbook hat bereits die Quoten veröffentlicht also sind Sie willkommen sich diese anzuschauen nachdem Sie das Anmeldeformular ausgefüllt haben und eingezahlt haben. Falls Sie weitere Fragen haben, dann kontaktieren Sie doch unseren Kundenservice und wir beantworten Ihre Fragen.\nPrevious StoryWyndham Meisterschaft 2017\nNext StoryFormula 1 Großer Preis von Belgien 2017


Steuererklärung ausfüllen lassen Baltschieder | GRATIS Steuerberater Offerten\nSie sind auf auf der Suche nach einem Steuerberater in Baltschieder und aus der Umgebung? Dann sind Sie bei uns genau richtig. Hier bekommen Sie Optimierungsvorschläge für die Steuerberatung in Baltschieder.\nSteuererklärung ausfüllen lassen in Baltschieder\nWenn Sie zu den Schweizerinnen und Schweizern gehören, welchen das Ausfüllen der Steuererklärung grosse Besorgnis bereitet, sind Sie nicht im Geringsten alleine. Ständig mehr Menschen in unserem Land lassen sich einige dabei von einem fachkundigen Steuerberater in Baltschieder VS unter die Arme greifen. Die Beweggründe sind verschiedenartig. Indem die einen aus Zeitgründen einen Steuerexperten an die Arbeit lassen, haben andere in Steuerfragen einfach zu wenig Durchblick um die Sparpotentiale im Bereich der Abzüge selber voll ausschöpfen zu können. In solchen Fällen ist es ratsam einen Steuerberater beizuziehen.\nGünstiger Steuerberater in Baltschieder und Umgebung finden für die Steuererklärung\nSo funktioniert es, damit Sie 3 kostenlose Offerten für Steuerberater in Baltschieder erhalten:\nWann rentiert es sich, die Steuererklärung von dem Steuerexperten ausfüllen zu lassen? Günstige Steuerberater in Baltschieder VS sind das Geld immer wert.\nGerade wenn Liegenschaften oder Wohneigentum vorliegen, wird dieses für den Normalbürger knifflig, den Überblick im Steuerdschungel zu behalten. Welche Aufwendungen für die Immobilie können abgerechnet werden? Was sind die maximalen Beträge, die in Abzug gebracht werden können? Wie plane ich für meinen Teil Renovationen der Liegenschaft am besten, damit man möglichst reichlich Steuern spart? Die möglichen Kostensenkungen in dem Gebiet können rasch die Kosten für einen fachkundigen Steuerberater übersteigen. Auch wer über selbstständiges Gehalt besitzt, oder Wertschriften besitzt, muss den Zuzug eines Steuerexperten dringend in Betracht ziehen.\nSogar für weniger komplexe Steuererklärungen mag es sich für Sie lohnen, wenigstens für ein Jahr einen erfahrenen Steuerberater mit dem Ausfüllen zu beauftragen. So können Sie sich vergewissern, dass einmal sämtliche Steueroptimierungen enthalten sind. Verändert sich die Steuersituation in den Folgejahren nicht bedeutend, können Sie als Folge hiervon profitieren und stracks nur noch abgucken. So werden die Unkosten für die Steuerberatung Baltschieder auf zwei oder mehr Jahre verteilt, und der Beizug fachlicher Hilfe lohnt sich in sozusagen jedem Fall. Ebenfalls der zeitliche Aufwand in den weiteren Jahren wird dadurch merklich verkleinert.\nSofern Sie zu den Schweizerinnen und Schweizern gehören, denen das Ausfüllen der Steuererklärung grosses Unbehagen bereitet, sind Sie beileibe nicht alleine. Stetig mehr Leute in unserem Land lassen sich einige dazu seitens einem professionellen Steuerberater in Baltschieder VS helfen. Die Beweggründe sind verschiedenartig. Obschon die einen aus Zeitgründen einen Steuerexperten ans Werk lassen, verfügen andere in Steuerfragen schlichtweg zu wenig Durchblick um die Sparpotentiale im Bereich der Abzüge im Alleingang voll ausschöpfen zu können.\nWann lohnt es sich, die Steuererklärung vom Steuerexperten machen zu lassen? Günstige Steuerberater in Baltschieder im Kanton Wallis sind das Geld auf alle Fälle wert.\nGerade wenn Liegenschaften und Wohneigentum vorhanden sind, wird es für den Normalbürger schwierig, die Übersicht in dem Steuerdschungel zu behalten. Welche Aufwendungen für die Liegenschaft können abgezogen werden? Was sind die bestmöglichen Beträge, die in Abzug gebracht werden können? Wie plane ich meinerseits Renovationen der Immobilie am effizientesten, damit man möglichst reichlich Steuern spart? Die möglichen Kostensenkungen in dem Gebiet können schnell die Unkosten für einen professionellen Steuerberater übersteigen. Auch wer über selbstständiges Entlohnung verfügt, beziehungsweise Wertschriften verfügt, sollte den Zuzug eines Steuerexperten auf jeden Fall in Erwägung ziehen.\nSelbst für weniger anspruchsvolle Steuererklärungen kann es sich für Sie bezahlt machen, zumindest für ein Kalenderjahr einen erfahrenen Steuerberater mit dem Ausfüllen zu beauftragen. So können Sie sicherstellen, dass einmal sämtliche Steueroptimierungen enthalten sind. Verändert sich die Steuersituation in den Folgejahren nicht das kleinste bisschen schwer wiegend, können Sie dann davon einen Nutzen haben und schnell nur noch abgucken. Auf diese Weise können die Kosten für die Steuerberatung Baltschieder auf viele Jahre verteilt, und der Beizug fachlicher Hilfe lohnt sich in so gut wie jedem Fall. Auch der zeitliche Aufwand in den folgenden Jahren wird folglich fühlbar verkleinert.\nMit welchen Kosten ist für das Ausfüllen der Steuererklärung zu rechnen? Steuererklärung ausfüllen lassen Baltschieder vom Spezialisten!\nKosten um die Steuererklärung ausfüllen zu lassen in Baltschieder\nDie Ausgaben für eine erfahrene Steuerberatung sind oftmals weniger hoch, als Sie vielleicht vermuten könnten. Für das Ausfüllen einer einfachen Steuererklärung liegen diese im Bereich von gut. Fr. 100.-. Für Doppelverdiener muss mit ein wenig höheren Ausgaben gerechnet werden. Auch einen geringen Zuschlag bringt das Vorhandensein von Wertschriften, oder Wohneigentum mit sich. Besonders im letzteren Bereich sind indes die Einsparungsmöglichkeiten so vielfältig, dass es sich auf jeden Fall rentiert, einmal mit einem Steuerberater darüber zu unterhalten.\nWie finden Sie den angemessenen Steuerberater für die Steuererklärung Baltschieder?\nDamit man die Steuererklärung möglichst günstig ausfüllen zu lassen, müssen Sie auf jeden Fall den Steuerberater aus Ihrer Region damit beauftragen. Lange Anfahrtswege bringen nur unnötige Zusatzkosten mit sich. Möglicherweise haben Sie in Ihrem Bekanntenkreis jemanden, der Ihnen einen angemessenen Steuerberater empfehlen kann. Wenn Sie bereit sind ein wenig Zeit zu investieren, lohnt es sich ausserdem, mehrere Steuerberater um eine Offerte zu bitten. Da es sich beim Ausfüllen der Steuererklärung aber um eine relativ günstige Dienstleistung handelt, sind keine allzu bedeutenden Unterschiede im Preis zu erwarten. Eine günstige Offerte von einem lokalen Steuerberater erhalten bei jedem Steuerberater.


Jacko's Wundermaschenland: Infiziert\nwurde ich bereits letzte Woche durch Ewa's Beitrag in der SKL. Da hat sie über ihre neuen Färbungen nach diesen Rezepten mit diesem Effekt berichtet.\nDas hat mich sehr neugierig gemacht und ich mußte es unbedingt ausprobieren. So habe ich mir das trübe Wetter der letzten Tage bunt gestaltet Leider kann ich euch kein Foto von den frisch gefärbten Knäulen zeigen. Ich habe die fixierten Knäule auf der Haspel zu einem Strang gewickelt, damit die Wolle besser trocknet. In meiner Einfalt dachte ich nämlich, wenn ich dann den Stang wieder aufwickel sieht er genauso aus wie vorher. Aber das war ein Irrtum!\nSo sah es am Freitag Abend in meinem Badezimmer aus:\nGleich am Samstag Morgen habe ich dann wie eine Wilde gewickelt, und das ist meine Ausbeute\nInsgesamt 400,0 Sockenwolle, das Knäuel immer mit doppelten Faden gewickelt, damit zwei ziemlich identische Knäule à 50,0 entstehen. Die beiden Knäule oben sind eine Baumwollmischung und noch nicht geteilt. Links unten seht ihr eine Merino/ Leinenmischung und rechts ist ein klassisches Schurwollgarn 75/25.\nDiese Art zu Färben hat viel Spaß gemacht und ich werde es wieder tun ;-)\nEingestellt von Jacko um 5:50:00 PM\nLiebe Jacko, das mache ich auch demnächst mal und freue mich schon auf die Art des Färbens. Aber überprüfe doch noch mal den Link bei "diesen Rezepten", denn der führt momentan ins Leere.\nLiebe Grüße, Catrin, die dein neues Blogoutfit bemerkt hat, *zwinker*.\n23. Februar 2009 um 19:33\nSchöne Farben, viel Spaß beim Verstricken.\n23. Februar 2009 um 20:06\nDeine Knäulchen sehen so richtig schön frühlingshaft aus. Besonders die Färbung rechts unten gefällt mir richtig gut.\n23. Februar 2009 um 20:18\ndie sehen ja toll aus! Da hast Du bestimmt ne Menge Spaß gehabt!\n24. Februar 2009 um 08:38\nTolle Färbereien zeigst Du.\n24. Februar 2009 um 09:06\nEcht schöne Farben! Da gefallen mir alle gleich gut.\nSobald ich wieder zu weisser Wolle komme (kann nur noch ein paar Tage dauern) werde ich auch mit dieser Technik Färben.\nGanz toll sieht deine Knäule aus - bin gespannt wie sie angestrickt aussehen werden.\nMir war sofort nach Färben...aber keine weisse Wolle ins Haus und Frau hat auch nicht das "Ding", wodrauf solche schöne Knäule gedreht werden ;-(...also wird es noch eine Weile dauern bis ich dieser Technik ausprobieren kann.\nDir wünsche ich viel Spass beim Stricken.\n24. Februar 2009 um 14:31


book of ra online | mikevanoverveld.nl\n20 juli 2021 book of ra onlineadmin\nDes der beliebtesten Spiele der Online Gluecksspieltempel Welt ist freilich Book of Ra. Das Game lasst sich auch an Spielautomaten kostenlos zocken ohne Anmeldung. Es entfuhrt uns in das alte agypten und man findet man wieder in von Welt von Pharaonen und Pyramiden. Erfahrene Glucksspieler schatzen die simple Struktur in einem tollen Design. Egal, ob die Zocker sich gerade erst angemeldet haben oder aber schon mehrere Jahr in Spielbanken aktiv sind, der Gluecksspieltempel Klassiker verliert bei weitem nicht an Attraktivitat ferner book of ra online https://bookofra.fm kostenlos spiel ist immer erneut moglich. Wer die Bonusgelder geschickt einsetzt, der kann bei diesem Game unterhalb von Umstanden Book of Ra kostenlos spielen und dabei deutliche Gewinne einfahren. Bestimmte User Erfahrungen weisen darauf hin, dass man hier jetzt erst einmal nicht abgeschlossen zogerlich sein hat. Oftmals wird dieses belohnt, alle Gewinnlinien zu spielen. Um wirklich groBe Gewinne zu erzielen, müssten schon mindestens 30 Punkte erreicht werden. Naturlich gibt das kein einheitliches Schema fur “Wie siegt man an Spielautomaten”, aber ein psychologischer Faktor fur mehrere Gamer ist die manuelle Betatigung der Spins. Das erhoht zudem ganz nebenbei den SpielspaB. Die Kombination, welche mehrere Glucksspielherzen hoher überrunden lassen durfte, ist echt die von drei Buchern in von Gewinnreihe. Diese sogenannten Scattersymbole erlauben deinem Nutzer Freispiele. Ferner so kann man wahrend eines laufenden Spiels Book of Ra kostenlos zocken. Naturlich sollte man dies voll ausnutzen und alle Gewinnlinien zocken. SchlieBlich ist dasjenige eigene Risiko da ja in einem solchen Fall mehr als beschrankt. Dies nennt sich eine Bet-Max-Strategie. Wer auf ganz einfach setzt, hat logischerweise auch hohere Gewinnmoeglichkeiten.\nZehn Gewinnlinien aus funf Rollen erwarten die Gamer. Dabei situation sich sowohl der Start-Button, als darüber hinaus der Autoplay-Button dafur verwenden, eine Partie zu starten. Mit ein wenig Gluck vereint man die entsprechenden Symbole, was es einem zum beispiel erlaubt, mithilfe vonseiten Freispielen den Spielautomaten gratis online abgeschlossen genieBen. Book of Ra befinden sich ausser auf der beliebten Originalversion auch noch in einer Deluxe Version.\nBesondere Vorkenntnisse ist fur dieses Spielautomaten online spielen nicht erforderlich und schon nach kurzer Zeit gesammelt sich ein jedweder in das Spiel eingearbeitet. Wer das zunachst nur probieren mochte, kann Book of Ra kostenlos spielen ohne Eintragung. Naturlich werden doch erst mit ihrer Registrierung Gewinne moglich. Diese weiB tatsachlich durch eine artikuliert verbesserte Grafik und Soundgestaltung zu uberzeugen. AuBerdem wurden hierbei die Gewinnlinien auf zehn erhoht, was noch hohere Auszahlungen ermoglicht.\nAm Spielautomaten erhalten ist so einfacher als in jeder echten Spielbank. Wie User empfiehlt es sich, unter allen Umstanden kaufen, Book of Ra kostenlos zu schlucken. Dabei helfen allerhand Boni weiter, die die verschiedenen Anbieter ausschutten. Neben Freispielen kann man sich ebenso seine eigenen Einzahlungen oftmals verdoppeln situation, so dass book of ra online kostenlos spielen vom Prinzip kein Problem ist. Automatenspiele kostenlos sind immer das willkommenes Geschenk fur Spieler. Gerade book of ra online ist dabei des der beliebtesten Games. Im Testmodus kontext sich diese Spielautomaten kostenlos spielen minus Anmeldung. Registrierte User (umgangssprachlich) kommen moglicherweise via der richtigen Spielautomaten Strategie aber jetzt hier zu versauten Gewinnen.\n← casino automaten tricks\thuuuge casino anmelden →


Jose Mourinho will Inter Mailands Javier Zanetti zu Chelsea holen - Goal.com\nJose Mourinho will Javier Zanetti zum FC Chelsea holen\nJavier Zanetti und Jose Mourinho gewannen gemeinsam mit Inter Mailand die Champions League\nGennaro Gattuso: Würde Juventus oder Inter trainieren\nUEFA untersucht Pellegrinis Kritik am Schiedsrichter\nJavier Zanettis Vertrag in Mailand läuft im Juni aus. Jose Mourinho will davon profitieren und den Routinier zu Chelsea lotsen. Dort soll Zanetti erst Spieler und dann Coach sein.\nVon Fabrizio Romano\nJose Mourinho bemüht sich um eine Verpflichtung von Javier Zanetti. Er möchte den argentinischen Routinier von Inter Mailand zum FC Chelsea holen und es hat nach Informationen von Goal in dieser Angelegenheit bereits ein informelles Gespräch gegeben.\nDer 40 Jahre alte Zanetti ist bei Inter ein echtes Urgestein: 1995 wechselte er von Ateltico Banfield zu den Nerazzurri und hat dem Klub seitdem ununterbrochen die Treue gehalten. Er arbeitete mit Mourinho während dessen zweijähriger Amtszeit in Mailand zusammen und gemeinsam gewannen sie 2010 das historische Triple.\nNun läuft der Vertrag des vielseitigen Defensivspielers am Ende dieser Spielzeit aus. Zwar ist Zanettis Familie in Mailand mittlerweile stark verwurzelt und fühlt sich dort sehr wohl, doch er denkt ernsthaft über Mourinhos Offerte nach. Die Aussicht, erneut mit "The Special One" arbeiten zu können, ist für ihn verlockend.\nZanetti will das Gespräch mti Thohir suchen\nMourinho hat er kürzlich die Unerfahrenheit in seiner aktuellen Chelsea-Mannschaft bemängelt. Er möchte, dass Zanetti in der Saison 2014/15 als Spieler mit seiner Erfahrung hilft und dann ein Jahr später in seinen Trainerstab aufrückt. Diesen Plan hat der 51-Jährige Startrainer auch bereits mit Klubbesitzer Roman Abramovich besprochen und der Russe hat dies abgesegnet.\nZanetti hängt seinerseits natürlich noch sehr an Inter. Er möchte nun zunächst mit dem neuen Präsidenten Erick Thohir sprechen und seine Perspektive ausloten. Vor allem geht es ihm darum, ob er seine Trainerlaufbahn bei Inter beginnen kann. Zanetti, der 145 Länderspiele für Argentinien absolviert hat, fühlt sich in Mailand mittlerweile längst zuhause. Es bedarf gewiss einer großen Charmeoffensive Mourinhos, um seinen Wunschspieler auf die Insel zu locken.\nEURE MEINUNG: Hat Mourinho mit seinem Werben um Zanetti tatsächlich Erfolg? Wie bewertet Ihr diesen Schachzug des Portugiesen?\nPremier League, Serie A, FC Chelsea, Inter Mailand, José Mourinho, Javier Zanetti