9. Januar 20242 j  Hallo zusammen, ich stehe gerade vor der Herausforderung, eine API in mein selbst entwickeltes Shopsystem zu integrieren, und möchte sicherstellen, dass die Sicherheitsaspekte angemessen berĂŒcksichtigt werden. Ein Ansatz, den ich in Betracht ziehe, ist das Verbergen von Admin-Funktionen hinter einem Login, indem beispielsweise der "Produkt hinzufĂŒgen"-Button nur fĂŒr Admins sichtbar ist. Allerdings frage ich mich, ob das ausreichend ist oder ob zusĂ€tzliche SicherheitsmaĂnahmen auf der Endpointebene erforderlich sind. DarĂŒber hinaus wĂŒrde mich interessieren, wie man verhindern kann, dass Benutzer einfach Postman oder Ă€hnliche Tools verwenden, um meine Endpoints abzufragen. Welche MaĂnahmen sind hier sinnvoll, um unerlaubten Zugriff zu verhindern? Vielen Dank im Voraus fĂŒr eure Erfahrungen und RatschlĂ€ge!  VG, MAGGS Â
10. Januar 20242 j Hallo, bei der API musst du die gleichen Sicherheitsmechanismen berĂŒcksichtigen wie bei Aufrufen mit dem Browser. Technisch gesehen ist das das Gleiche, nur statt HTML kommt halt JSON zurĂŒck (oder was auch immer). Alles was im Browser direkt passiert, ist nette Spielerei bzw. nur die die Benutzerfreundlichkeit gedacht. Es ist nett, wenn der Benutzer den Button "Produkt hinzufĂŒgen" Button nicht sieht, wenn er eh nichts damit anfangen kann. Wichtig ist aber, dass der Webrequest zum Produkt hinzufĂŒgen abgesichert ist bzw. mit Login/Berechtigung etc. ĂŒberprĂŒft wird. Postman wirst du nicht verhindern können. Es gibt ein paar Möglichkeiten um es schwerer zu machen (User-Agent ĂŒberprĂŒfen, CSRF etc), aber ob jetzt am Ende Firefox, Chrome, CURL oder Postman dahinter steht, wirst du nie absolut sicher feststellen können. Konzentriere dich darauf, die API bzw den Shop richtig abzusichern, dann kann es dir egal sein wie genau er aufgerufen wird. (Es macht ja auch keinen Unterschied, ob ein User jetzt Postman oder Chrome/Firefox etc benutzt, er kann so oder so das gleiche machen)
10. Januar 20242 j Autor vor 23 Minuten schrieb Funfare1337: Hallo, bei der API musst du die gleichen Sicherheitsmechanismen berĂŒcksichtigen wie bei Aufrufen mit dem Browser. Technisch gesehen ist das das Gleiche, nur statt HTML kommt halt JSON zurĂŒck (oder was auch immer). Alles was im Browser direkt passiert, ist nette Spielerei bzw. nur die die Benutzerfreundlichkeit gedacht. Es ist nett, wenn der Benutzer den Button "Produkt hinzufĂŒgen" Button nicht sieht, wenn er eh nichts damit anfangen kann. Wichtig ist aber, dass der Webrequest zum Produkt hinzufĂŒgen abgesichert ist bzw. mit Login/Berechtigung etc. ĂŒberprĂŒft wird. Postman wirst du nicht verhindern können. Es gibt ein paar Möglichkeiten um es schwerer zu machen (User-Agent ĂŒberprĂŒfen, CSRF etc), aber ob jetzt am Ende Firefox, Chrome, CURL oder Postman dahinter steht, wirst du nie absolut sicher feststellen können. Konzentriere dich darauf, die API bzw den Shop richtig abzusichern, dann kann es dir egal sein wie genau er aufgerufen wird. (Es macht ja auch keinen Unterschied, ob ein User jetzt Postman oder Chrome/Firefox etc benutzt, er kann so oder so das gleiche machen) @Funfare1337 vielen lieben dank fĂŒr deine Tipps,!
13. Januar 20242 j Mit C++? Was verwendest denn fĂŒr libs/frameworks? Sagt dir OWASP was? https://owasp.org/www-project-top-ten/ https://owasp.org/www-project-api-security/ Â
13. Januar 20242 j Was du brauchst ist im Kern eine vernĂŒnftige Authentifizierung (und Autorisierung) an der API, z. B. token basiert via JWT oder Oauth. Wer keine Permissions hat, darf dann halt die API Endpunkte nicht nutzen und auch keine Produkte eben ĂŒber diese hinzufĂŒgen. HTTPs sollte eh klar sein. Weitere Security MaĂnahmen (OWASP, RateLimiting, ...) wĂŒrde ich eher ganzheitlich betrachten, denn der Shop wird ja auch ohne API Angriffen ausgesetzt sein. Eventuell habt ihr schon eine WAF oder Ă€hnliches mit OWASP Ruleset und könntet ĂŒber ein API Gateway nachdenken, mit der du das Thema Authentifizierung+Autorisierung ebenfalls angehen könntest. Bearbeitet 13. Januar 20242 j von bloodyberry
Erstelle ein Konto oder melde dich an, um einen Kommentar zu schreiben.