Ankündigung

Einklappen
Keine Ankündigung bisher.

Laravel API absichern

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Laravel API absichern

    Hallo,

    ich habe eine API in laravel entwickelt. Darin enthalten ist ein Registrierungsprozess, damit Kunden sich bei der Seite registrieren können. Die API wird von einem Angular Frontend bedient. Es sind also beide strikt getrennt.

    Was für Möglichkeiten habe ich, damit die öffentlichen API Endpoints, also die, die keine Authentifizierung brauchen, wie eben die Registrierung so abzusichern, dass kein Bot darauf permanent feuert und uns Fakekunden anlegt oder den Server damit lahmlegt? Gibt es da schon dinge die ich mit Laravel abfangen kann, oder helfen da nur Tools gegen DDoS Angriffe etc.?

    Liebe Grüße
    Kerstel




  • #2
    Man kann einmal Zugriff nur von einem bestimmten Referer zulassen (Die URL deiner Angular App), zusätzlich kann man schreibende public apis auch noch mit einer CSRF Protection "absichern". Ich weiß nicht ob Laravel dies bereits von Haus aus kann, aber ich denke schon.

    Kommentar


    • #3
      Zitat von Zeichen32 Beitrag anzeigen
      Man kann einmal Zugriff nur von einem bestimmten Referer zulassen (Die URL deiner Angular App)
      Der Referer kann halt beliebig manipuliert werden und wenn man Pech hat sitzt man hinter einem Proxy oder einer Firewall, die den Referer rauslöscht und somit die Webseite für einen unbrauchbar macht.

      Kommentar


      • #4
        Komplett verhindern lässt sich sowas auf einer Public-API nicht, man kann es aber erschweren.

        Fail2Ban ist schonmal ein guter Anfang. Dazu kannst du noch die IP Adresse und Request Header untersuchen und ggf. blocken.
        Was gerne gemacht wird, ist ein Delay einzubauen um Bots auszubremsen, kostet aber Ressourcen.
        "Software is like Sex, it's best if it's free." - Linus Torvalds

        Kommentar


        • #5
          Hallo,

          Fail2Ban klingt schon mal gut, schau ich mir an. Was haltet Ihr von Captchas und Honeypots?

          LG
          Kerstel

          Kommentar


          • #6
            Zitat von hellbringer Beitrag anzeigen

            Der Referer kann halt beliebig manipuliert werden und wenn man Pech hat sitzt man hinter einem Proxy oder einer Firewall, die den Referer rauslöscht und somit die Webseite für einen unbrauchbar macht.
            Das stimmt, es ist aber ein Weg von vielen. Ich habe das schon häufiger gesehen das man an öffentliche APIs den Referer übergeben muss, welcher vorher konfiguriert wurde. Passt dieser nicht, dann wird die Abfrage blockiert.
            Dazu dann noch das oben genannten CSRF Verfahren bei nicht idempotent HTTP Aufrufen implementieren und schon sollte man seine öffentliche API einiger maßen vor Bots geschützt haben.

            Das ganze funktioniert natürlich nur bei automatisierten Bots, wenn jemand sich jetzt die mühe macht und einen Bot speziell für diese API zu schreiben, dann kommt man so natürlich auch nicht weiter.

            Kommentar


            • #7
              Zitat von kerstel Beitrag anzeigen
              Hallo,

              Fail2Ban klingt schon mal gut, schau ich mir an. Was haltet Ihr von Captchas und Honeypots?

              LG
              Kerstel
              Was bedeutet in diesem Zusammenhang Honeypots?

              Kommentar


              • #8
                Die Angular App kann ja zB ein Hiddenfeld übermitteln, was leer sein muss. Wenn es nicht leer ist, dann ist ein Bot im spiel.

                Kommentar


                • #9
                  Zitat von kerstel Beitrag anzeigen
                  Die Angular App kann ja zB ein Hiddenfeld übermitteln, was leer sein muss. Wenn es nicht leer ist, dann ist ein Bot im spiel.
                  Bei API-Aufrufen gibts kein Hidden-Field, weil es ja kein Formular gibt. In der Regel sind die Requests als JSON formatiert.

                  Was man machen könnte ist im Header einen zusätzlichen Wert mitzuschicken, der dann im Backend validiert wird. Wobei es natürlich besser um einen generierten und begrenzt gültigen Token als einen statischen Wert handelt. Der Token muss vorher per API-Aufruf erstmal geholt werden. Wobei ein schlauer Bot das natürlich auch machen könnte, also 100% wasserdicht ist keine Lösung.

                  Möchte man einen Missbrauch großteils ausschließen, müsste man eine Authentifizierung (z.B. OAuth) verwenden, mit zugehörigem Login und valider Mail-Adresse. Wobei ein neuer Login kann auch recht schnell automatisiert angelegt werden. Wie gesagt, 100% wasserdicht ist keine Lösung und im Endeffekt muss man das miteinberechnen, dass irgendwer irgendwie die API missbrauchen könnte.

                  Die Frage ist auch das Kosten-Nutzen-Verhältnis. Hat die API so wertvolle Daten, dass sie um jeden Preis abgesichert werden muss? Wieviele Euro sind die Daten wert und wieviele Euro möchte man in die Absicherung stecken?

                  Kommentar


                  • #10
                    Die Angular App hat ein Formular und kann damit Hiddenfelder haben. Wenn ein Bot nun das Formular versucht nachzuahmen und mir das Hidden Feld schickt (natürlich dann als JSON) weiß ich es ist ein Bot. Es geht weniger um die Daten, sondern um zu verhindern, dass Fake Profile angelegt werden, was Events hinten raus auslöst, und uns die DB zumüllt.

                    Kommentar


                    • #11
                      Zitat von kerstel Beitrag anzeigen
                      Die Angular App hat ein Formular und kann damit Hiddenfelder haben. Wenn ein Bot nun das Formular versucht nachzuahmen und mir das Hidden Feld schickt (natürlich dann als JSON) weiß ich es ist ein Bot.
                      Wenn der Bot dazu fähig ist, dann kann er auch erkennen welches Feld hidden ist und welches nicht.

                      Zitat von kerstel Beitrag anzeigen
                      Es geht weniger um die Daten, sondern um zu verhindern, dass Fake Profile angelegt werden, was Events hinten raus auslöst, und uns die DB zumüllt.
                      Dann die E-Mail-Adresse validieren, mit der das Profil angelegt wird. Eine andere (sinnvolle) Möglichkeit gibt es nicht.

                      Kommentar


                      • #12
                        Fake Profile werden auch oft von Menschen angelegt, dagegen hilft dann nur einmal täglich drüber schauen und löschen.
                        Kannst ja dann die IP Bereiche sperren, da vieles aus Ländern kommt, wo eh kein normaler Mensch in Urlaub fahren würde.

                        Kommentar


                        • #13
                          Verstößt ein Login nicht gegen die von REST geforderte Zustandslosigkeit?

                          Kommentar


                          • #14
                            Mit Zustandslosigkeit ist gemeint, dass zb. keine Sessions verwendet werden sollten. Jeder Request sollte bei 0 Anfangen. Sprich, ein Session basierter Login verstößt wirklich gegen das Prinzip der Zustandslosigkeit. Wenn du aber bei jedem Request ein Token übergibst und darüber den User Authentifiziert und Autorisierst ist das vollkommen okay.

                            Kommentar


                            • #15
                              Die genaue Definition der Zustandlosigkeit bei REST ist mir bekannt, ich habe es daher bislang auch immer über Tokens gelöst.

                              Ich fragte nur so blöd, da das hier benutzte Wort Login für mich die Verwendung einer Session impliziert.

                              Kommentar

                              Lädt...
                              X