![](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2015\/01\/Schutz.jpg\")
Phisher k\u00f6nnen sich gewisser Tricks bedienen, um die verlinkten URLs zu verschleiern. Unicode-Domains stellen eine solche Methode dar. Das Gef\u00e4hrliche: Nutzer k\u00f6nnen in g\u00e4ngigen Browsern diese Angriffe kaum erkennen.<\/p>\nPhisher k\u00f6nnen sich gewisser Tricks bedienen, um die verlinkten URLs zu verschleiern. Unicode-Domains stellen eine solche Methode dar. Das Gef\u00e4hrliche: Nutzer k\u00f6nnen in g\u00e4ngigen Browsern diese Angriffe kaum erkennen.<\/p>\n
<\/p>\n
Problem ist, dass man bei diesen Punycode-Domains Zeichen verwenden kann, die im Browser nicht darstellbar sind. Man kann also eine Domain mit \"xn--pple-43d.com\" registrieren, die im Browser als \"\u0430pple.com\" angezeigt wird. Der obige Screenshot zeigt vordergr\u00fcndig eine Apple-URL an. Aber der Browser verwendet intern die Domain \"xn--pple-43d.com\". Durch die Unicode-Zeichen wird die URL verschleiert. Der Benutzer kann nicht erkennen, dass er nicht auf der aktuell angezeigten Domain unterwegs ist.<\/p>\n Selbst die https-Verschl\u00fcsselung ist kein Indiz, dass die Ziel-URL sauber ist. Man muss das Zertifikate \u00fcberpr\u00fcfen. Und das ist jetzt eine Sache, die mich pers\u00f6nlich kolossal \u00e4rgert. Denn die Browserentwickler scheinen die Nutzer f\u00fcr Dumpfbacken zu halten. Warum? Aktuell wird von Google und Konsorten ja m\u00e4chtig Druck ausge\u00fcbt, damit alle Kommunikation mit Webservern k\u00fcnftig per https verschl\u00fcsselt wird. Andererseits werden essentielle Browserfunktionen als Flachsch\u00fcsse angelegt, um den Benutzer nur ja nicht zu \u00fcberfordern. Das Abrufen von https-Zertifikatsinformationen ger\u00e4t mitunter zum Abenteuer.<\/p>\n Wer einmal im Google Chrome versucht hat, auf die Schnelle ein Zertifikat und dessen Details zu \u00fcberpr\u00fcfen, wei\u00df, was ich im letzten Punkt meine. Man muss die Spalte mit den Entwicklertools \u00fcber das Men\u00fc und den Befehl Tools<\/em> \u00f6ffnen, um dort unter 'Security Overview' irgendwo unter 'Valid Certificate' die grau abgeblendete Schaltfl\u00e4che View certificate <\/em>anzuw\u00e4hlen. Erst dann bekommt man das Zertifikat samt Details angezeigt. Nur im Zertifikat kann ich erkennen, f\u00fcr wen dieses ausgestellt wurde (und muss dem Aussteller vertrauen, was auch nicht mehr als Gott gegeben gelten darf).<\/p>\n Lange Rede kurzer Sinn: Mit den Punycode-Domainnamen lie\u00dfen sich sogenannte IDN homograph attack<\/a> durchf\u00fchren. Der Benutzer wiegt sich in Sicherheit, weil die Anzeigen ja scheinbar stimmen. Der Bug wurde von Zengh bereits am 20. Januar 2017 an Google und die Mozilla-Entwickler gemeldet. In Chrome wurde das Problem in der Version 58 behoben (dort bekommt man die gesamte URL angezeigt). In Firefox 53 wird auch die gesamte URL angezeigt \u2013 aber der Slimjet-Browser zeigt die URL noch fehlerhaft an \u2013 und Nutzer, die \u00e4lter Browserversionen verwenden, haben das Problem ebenfalls. Man kann diese Testseite<\/a> aufrufen. Wird dort apple.com in der Adresszeile angezeigt, ist der Browser anf\u00e4llig f\u00fcr solche Angriffe.<\/p>\nIch bin gestern bei hackernews.com wieder auf das Thema<\/a> gesto\u00dfen. Deren Artikel bezieht sich auf den Beitrag<\/a> des Chinesen Xudong Zheng vom April 2017. Dort geht Zheng auf Punycodes<\/a> ein, \u00fcber die man Domainnamen mit fremdsprachigen Zeichen registrieren kann. Das w\u00e4ren z.B. Umlaut-Domains f\u00fcr deutsche Nutzer.<\/p>\n
![](\"https:\/\/web.archive.org\/web\/20170813153824\/https:\/\/www.xudongz.com\/cache\/daea1fdcd6a324778f3274a64b6dfc24e6073874067835efefe5e26870baa383.png\")
\n(Quelle<\/a>)<\/p>\nhttps hilft nicht<\/h2>\n
\n