Amazon klickt meine Links

  • Moin,


    ich mal wieder mit meinen komischen Problemen :D


    Eine (legacy) Anwendung verschickt nach der Registrierung eines Nutzers zwei Links an den Administrator der Seite: Ein Link zum Bestätigen der Registrierung, einen zum Ablehnen.

    Report vom Kunden: "Wenn sich jemand registriert, wird der immer automatisch abgelehnt"

    Ich, als klassischer ITler: "Kann nicht sein" :D

    Naja, ist natürlich auch nicht so, aber der Kunde hat aus seiner Sicht recht: Er tut nichts aktiv und die Registrierungen werden abgelehnt.


    Was passiert?

    Die Links werden von EC2-Computing-Instanzen aufgerufen (z.B. 3.86.165.80 oder 54.166.184.127). Es wird erst der "Angenommen"-Link aufgerufen und wenige Sekunden (2-4) später auch der "Ablehnen"-Link (andere IP).

    Aktuelle Arbeitstheorie ist, dass die Links abgerufen werden, um die Inhalte zu scannen (Virenscanner o.ä.); wäre für mich generell auch plausibel. Durch Tests konnten wir auch herausfinden, dass die URLs nicht von einem Browser gecrawlt werden (JS, CSS werden nicht nachgeladen und weitere <a>-Tags auf der Seite nicht gecrawlt), sondern wohl tatsächlich nur als Dokument abgerufen.


    Ich stehe jetzt ein bisschen vor der Qual der Wahl: Meine Vorschläge reichen von "Zugriff aus US unterbinden" (Registrierungen finden nur aus DACH statt und alle EC2-Zugriffe kamen aus US) bis zu Applikationsumbau, dass der Link in der E-Mail entweder gar nicht erst drinsteht oder nach Klick noch eine weitere Aktion unternommen werden muss, um die Registrierung zu bestätigen.

    Basic-Auth vor dem Endpunkt ist leider nicht praktikabel, weil auch der Registrierende einen Link gegen diesen Endpunkt aufrufen muss.



    Das Problem kann ja eigentlich nicht neu sein.

    Hatte sojemand schonmal einen ähnlichen Fall? Ggf. mit welcher Lösung?

    Jemand Lösungsansätze?

  • Sehr treffender Titel ^^:thumbup:


    Auch wenn es wahrscheinlich ins leere laufen wird: Eventuell könnte es sich ja lohnen Amazon über den Sachverhalt und der daraus resultierenden Problematik zu unterrichten.


    Alternativ, wie du schon selber sagst, z.B. einen zusätzlichen Button bei der Verifizierung des Registrierungsprozesses einbauen.

  • Das dürfte von Proofpoint kommen. Die rufen in Emails alles was halbwegs nach einer URL auf und checken dann, ob auf der Seite gefährlicher Content liegt.


    Das ist total nervig,

    - weil du so automatisch von Security-Newslettern unsubscribed wirst

    - wenn die URL nicht public ist (z.B. interner Jenkins), dann wird die Email aus Security-Gründen um 1h verzögert und man bekommt kaputte Builds nicht mit.

    - nicht jede URL sauber erkannt wird

    - unerfahrene Benutzer dir die URL in Confluence & Co kopieren

    - Proofpoint öfters mal down ist und somit alle Links in Email tot sind

    - Du nicht mehr sauber erkennen kannst, ob du auf eine Phishging-Domain geleitet wirst

    - Dein Surfverhalten ausgehend von Emails wird in den USA getrackt


    Aber es befriedigt die Security-Auditoren der größeren Firmen.


    vgl. https://www.proofpoint.com/us/…ts/essentials-url-defense und https://www.google.com/search?…source=lnms&tbm=isch&sa=X


    Das Teil ist meiner Meinung nach eine echte Seuche.

  • Lösung: Nicht 1 Klick URLs anbieten. Baue die Webseite dahinter so um, dass dort um eine Bestätigung al a "Sie wollen wirklich die Waschmaschinen im Abo? Dann drücken Sie jetzt hier" angeboten wird.

  • Ein zusätzliches (POST) Formular hat halt wieder den Nachteil, dass eventuell einige Nutzer abspringen oder die Bedienung nicht verstehen.


    Eine alternative oder zusätzliche Lösung wäre meiner Meinung nach, dass die Bestätigungsseite die Aktion über JavaScript auslöst. Bei Bots passiert somit hoffentlich nichts, bei aktiviertem JS wird ein Ajax-Request ausgelöst und ohne JS bietet man als Fallback einen Submit-Button mit POST-Formular an.

  • eigentlich ist es kein Problem, sondern eher ein Failure by Design;

    jede noch so doofe Seite fragt den User Agent und sonst noch so einiges ab;

    (es hat lange gedauert bis ich einen UserAgent gefunden habe, den ich als Fake verwenden konnte, und dennoch alles funktionierte - ich hab nicht wirklich einen Cray im Wohnzimmer stehen :D)

    genau das sollte auch hier greifen - UserAgent/Quell-IP prüfen, und wenn die nicht plausibel sind, einen 403 werfen ...

    Grüße / Greetings

    Walter H.


    RS 1000 SAS G8 xRAM; RS 500 SSD G8; S 1000 G7; VPS 200 G8 Akt.; Webhost. 1000 m. 75%

  • Wenn du den Prozess umbauen kannst:


    Ich habe das bei einem Projekt so gelöst, dass ein Secret hinter einem # steht. Alles was hinter einem Hash steht wird nicht an den Server gesendet.


    Anschließend schickt ein Javascript Schnipsel den Hash Inhalt via Ajax an den Server und macht die Arbeit.


    Das hat den Vorteil daß kein crawler das so einfach nachstellen kann und der User nichts zusätzliches machen muss.


    Nachteil ist halt Javascript.


    Funktioniert seit Jahren ohne Probleme.