Ich habe eine Domäne, die Subdomänen für Benutzer verwendet, zum Beispiel:
user1.example.com
Um zwischen anderen offiziellen Subdomains und Benutzer-Subdomains zu unterscheiden, habe ich "at" für alle diese Fälle reserviert. Einige offizielle Subdomains sind beispielsweise:
api.at.example.com, releases.at.example.com, support.at.example.com
Ich bin jetzt schon zweimal auf Sperren aufgrund falscher Phishing-Erkennung gestoßen. Bisher von Google und Cisco. Sie scheinen anzudeuten, dass meine Site versucht, sich als „api.at“ oder „releases.at“ auszugeben.
Es ist ziemlich ärgerlich, dass Dienste Subdomains ohne andere Anzeichen böswilliger Aktivitäten blockieren, einfach aufgrund eines ziemlich generischen Namens, den sie erhalten. Besonders ärgerlich ist das bei Cisco, da sie Fetch/XHR-Anfragen blockieren, ohne dass der Benutzer die Möglichkeit hat, sie zu umgehen. Google blockiert Fetch/XHR zumindest nicht, sondern nur, wenn Sie die Domain im Browser als Seite besuchen.
Ich würde gerne wissen, wie häufig das vorkommt. Ich überlege, stattdessen einige Subdomains der ersten Ebene zu reservieren, um das Problem zu umgehen (z. B. api.example.com), aber es erscheint mir unsinnig, dass Dienste alle verschachtelten Subdomains effektiv blockieren. Wenn das nicht häufig vorkommt, versuche ich vielleicht einfach, Support-Tickets an die betreffenden Dienste zu senden.
(Dies gilt für eine brandneue Domäne ohne Vorbesitzer und ohne jeglichen schädlichen Inhalt, da ich die gesamte App selbst geschrieben habe.)
Antwort1
Ja, obwohl ich zustimme, dass es rücksichtslos ist, mit einer solchen Überblockierung weitverbreitete Probleme zu verursachen, ist diesnicht auf einzelne Entitäten beschränktdass Sie das Problem individuell für Sie beheben lassen können.
Ich habe ähnliche Sperrregeln in Desktop-Systemen installiert, die ich verwalte, und habe bei bedeutenden kommerziellen Unternehmen bestätigt, dass sie derartige Sperren auf allen ihren Geräteflotten durchsetzen. Meine Regeln gelten zumindest nur für Domänen, die eigene und zugehörige Markennamen enthalten oder diesen ähneln. Andere Unternehmen behaupten, „maschinelles Lernen“ zu verwenden, um ihre „URL-Bedrohungsklassifizierung“ zu bestimmen, was für mich noch wahrscheinlicher klingt, als dass es zu dem führen würde, was Sie mit Cisco erlebt haben.
Diese Art der Erkennung ist definitivhäufig inE-Mail-Kontext- Sie müssen damit rechnen, sofort als Spam-Quelle eingestuft zu werden, wenn festgestellt wird, dass Sie nicht autorisierte E-Mails weiterleiten <brandname>.<tld>.<otherdomain>.<tld>.
Von Ihnen wird erwartet, dass Sie Ihre Kunden überprüfen und überwachen, damit bankofamerica.com.yourdomain.exampleBetrüger niemals Dinge wie diese verwenden können. Wenn Ihre Domains so aussehen, als hätten Sie es versäumt, sichere Standardeinstellungen zu wählen, müssen Sie mit Problemen bei besonders sensiblen Heuristiken rechnen. Ich empfehle IhnenHalten Sie sich von beliebten ccTLDs fern(zB .at)und uTLD(z. B. .com) für die von Ihnen verwendeten Labelsmitten drinIhrer längeren Domänennamen.
Abhängig von der Art der Dienste, die Sie den Benutzern anbieten, kann es sogar angebracht sein, diese Domäne zu habenzur öffentlichen Suffixliste hinzugefügt. Auch wenn dies nicht der Fall ist, lesen Sie die entsprechende Dokumentation. Sie kann Ihnen dabei helfen zu entscheiden, ob es überhaupt eine gute Idee ist, Benutzerinhalte unter einer Domäne zu hosten, die auch für andere Dienste verwendet wird (Hinweis: Browser sind heutzutage komplexe Biester).