Den falschen HTTP-Antwortcode absichtlich zurückgeben?

Ich schreibe eine einfache REST-API und möchte den Zugriff nur auf meinen mobilen Client beschränken. Mit anderen Worten, ich versuche zu verhindern, dass ein böswilliger Benutzer z. Verwenden von curl zum Erstellen einer nicht autorisierten POST-Anforderung.

Das ist natürlich unmöglich. Es gibt jedoch bestimmte Gegenmaßnahmen, die den Erfolg eines Hackers erschweren. Im Moment verschlüssele ich alle Anfragen mit einem privaten Schlüssel, der auf der Clientseite gespeichert ist (natürlich ist dies nicht ideal, aber die Schwierigkeit beim Reverse-Engineering einer iOS-App wird hoffentlich alle außer den entschlossensten Hackern abschrecken).

Eine einfache Idee war, den falschen HTTP-Antwortcode für eine nicht autorisierte Anforderung zurückzugeben. Anstatt ein "401 Unauthorized" zurückzugeben, warum nicht z. "305 Use Proxy", d. H. Absichtlich verwirrend. Hat jemand jemals darüber nachgedacht?

36
Kommentare sind nicht für eine erweiterte Diskussion vorgesehen. Dieses Gespräch wurde geführt zum Chat verschoben .
hinzugefügt der Autor Rory Alsop, Quelle
@Pascal Sie möchten 404 anstelle von 403 verwenden. Der HTTP-Standard erlaubt dies ausdrücklich, um zu verhindern, dass einem Benutzer, der nicht auf die Ressource zugreifen darf, die Existenz einer Ressource angezeigt wird. Sie können verhindern, dass ein 401 Informationen über die Existenz durchläuft, wenn Sie dies für alle Standorte benötigen, die dem Muster anderer Standorte entsprechen, für die eine Authentifizierung erforderlich ist. (Ich hoffe, dass die erneute Veröffentlichung dieses Kommentars in Ordnung ist; ich denke, dass dies wichtige Informationen sind.)
hinzugefügt der Autor jpmc26, Quelle
Wenn Sie nicht die richtigen HTTP-Statuscodes zurückgeben, kann man sagen, dass Sie streng genommen kein HTTP sprechen. Wenn Sie also so weit gegangen sind, können Sie einfach ein völlig anderes Protokoll implementieren ...
hinzugefügt der Autor Magnus Johansson, Quelle
@Pascal Dies ist der Ansatz von GitHub (zumindest), wenn versucht wird, auf ein privates Repository zuzugreifen, wenn es nicht authentifiziert oder nicht autorisiert ist.
hinzugefügt der Autor Alexandre Amato, Quelle
Es heißt "Sicherheit durch Unbekanntheit". Es kann jemanden verlangsamen, aber das war es auch schon.
hinzugefügt der Autor sluukkonen, Quelle
Ich lese irgendwo in einem offiziellen Dokument über HTTP (sorry, erinnere mich nicht an die Quelle), dass die Rückgabe von 404 anstelle von 401 zulässig ist, um Informationen über das Vorhandensein von Ressourcen nicht an unbefugte Clients weiterzuleiten.
hinzugefügt der Autor Pascal, Quelle

11 Antworten

Hat jemals jemand darüber nachgedacht?

Ja, genau darüber wurde auf der defcon 21 gesprochen ( video , Rutschen ).

Ihre Schlussfolgerung war, dass das Arbeiten mit Antwortcodes als anstößige Sicherheit manchmal dazu führen kann, dass automatische Scanner, nicht funktionierende Scanner und eine große Anzahl von falsch-positiven oder falsch-negativen Effekten stark abgebremst werden (dies führt bei manuellen Scans offensichtlich zu wenig). .

Sicherheit durch Unbekanntheit sollte zwar niemals Ihre einzige Verteidigung sein, sie kann jedoch als Tiefenverteidigung vorteilhaft sein (ein anderes Beispiel: Es wird empfohlen, keine Versionsnummern aller verwendeten Komponenten zu verbreiten).

Auf der anderen Seite sollte eine REST-API so sauber wie möglich sein, und das Beantworten mit absichtlich falschen HTTP-Codes kann für Entwickler und rechtmäßige Clients verwirrend sein (für Browser ist dies weniger ein Problem, bei dem die Benutzer dies nicht wirklich sehen Codes). Aus diesem Grund würde ich es in Ihrem Fall nicht empfehlen, aber es ist immer noch eine interessante Idee.

82
hinzugefügt
Ich erkenne zwar die Legitimität von 'Sicherheit durch Unbekanntheit' als Eintrittsbarriere an (d. H. Das Herausschreiben von Skriptkiddies), aber ich denke, es wird so stark überstrapaziert, dass es die Sicherheit der jeweiligen Anwendung stark beeinträchtigt. Von den beiden verwandten Bereichen - Kryptographie und Informationssicherheit - ist eines auf "Unklarheiten" angewiesen, während das andere dies nicht tut. Übrigens, die macht meistens einfacher. Darüber hinaus gilt Unklarheit für alle Parteien (einschließlich Pentester, die Sie bezahlen) und führt zu weiterer Komplexität, dh Angriffsvektoren.
hinzugefügt der Autor Ryan Versaw, Quelle
@ ypercubeᵀᴹ Nun, da ich meinen Kommentar gelesen habe, klingt es so, als würde ich sagen, dass, während ich genau das Gegenteil meinte - in der Kryptographie das Prinzip von Kerckhoffs im Wesentlichen das ideologische Gegenteil von 'Security by Obscurity' ist.
hinzugefügt der Autor Ryan Versaw, Quelle
@ K.Steff Jede Regierung, die klassifizierte kryptographische Algorithmen verwendet, verwendet in der Kryptographie "Sicherheit durch Unbekanntheit".
hinzugefügt der Autor mostlyinformed, Quelle
@ K.Steff "Kryptographie setzt auf Unbekanntheit" ? Wolltest du "steganography" schreiben?
hinzugefügt der Autor cupe, Quelle
Ich denke, das ist eine sehr praktische Antwort. Es macht mich wütend, wenn jemand Sicherheit durch Verschleierung ablehnt, weil er liest, dass es auf einem Blog oder so etwas schlecht war. In der realen Welt kann es auf jeden Fall nützlich sein. Es kann nicht der einzige Trick in Ihrer Tasche sein, das ist alles.
hinzugefügt der Autor corsiKa, Quelle
+1 für die Erwähnung von Entwicklern. Wenn ich eine Änderung an einem System vornehme und plötzlich eine 404 bekomme, bei der ich plötzlich eine 200 bekam, habe ich plötzlich ein Whisk-a-Mole-Spiel, das feststellt, wo entschieden wurde, eine andere Antwort zu senden. Alles, was ich zu OP sagen kann, ist, wenn Sie sich dazu entschließen, bitte dokumentieren Sie es bitte ordnungsgemäß, oder Ihr Name wird in der Zukunft schlammig sein
hinzugefügt der Autor booboo, Quelle

Ein Angreifer wird dadurch nicht nennenswert verlangsamt, sondern zukünftige Entwickler, die auf Ihrer Plattform arbeiten, werden Sie wirklich nerven. Es kann auch dazu führen, dass bestimmte nette Funktionen Ihrer HTTP-Anforderungsbibliotheken nicht so nett sind, da sie mit falschen Informationen arbeiten.

Dies ist eine sehr schwache Form der Sicherheit durch Unbekanntheit . Wenn Sie ein solches System entwerfen, sollten Sie darüber nachdenken, einen Angreifer um Hunderte von Jahren zu verlangsamen, nicht um Dutzende von Minuten - sonst verlieren Sie immer noch.

57
hinzugefügt
@Nacht "Sicherheit durch Unkenntlichkeit ist die einzige Möglichkeit", d. H. "Keine Sicherheit ist die einzige Möglichkeit" (Hyperbelalarm). Wenn Sie ein System nicht sichern können und es sicher benötigen, implementieren Sie es nicht. Gleiches gilt für Geschäftsmodelle wie Anzeigen.
hinzugefügt der Autor Ryan Versaw, Quelle
"Wenn Sie ein solches System entwerfen, sollten Sie daran denken, einen Angreifer um Hunderte von Jahren zu verlangsamen, nicht um Dutzende von Minuten - sonst verlieren Sie immer noch." Gegen einen engagierten, entschlossenen, fähigen Angreifer? Ja. Aber um automatisierte Angriffsprogramme oder menschliche Angreifer zu besiegen, die nur nach den einfachsten und verwundbarsten Zielen Ausschau halten, um davon zu profitieren? Sie werden sich wahrscheinlich gleich bewegen. Übrigens bietet BTW Ihnen oft bessere Sichtbarkeit, um mehr vorsätzliche Bedrohungen zu erkennen, wenn sie die besten "echten" Sicherheitsmaßnahmen, die Sie einsetzen können, besiegen.
hinzugefügt der Autor mostlyinformed, Quelle
Bei dieser Frage geht es um ein Szenario, in dem Sicherheit durch Unklarheit die einzige Möglichkeit ist. Ihr erster Absatz ist gut, aber der zweite ist irrelevant.
hinzugefügt der Autor Francisco Corrales Morales, Quelle
@Cruncher, nein, Sicherheit durch Unbekanntheit wird niemanden Hunderte von Jahren bremsen. Er sagt, Sie brauchen "richtige" Sicherheit, was mit dem aktuellen Design des OP unmöglich ist.
hinzugefügt der Autor Francisco Corrales Morales, Quelle
@mostltinformed OP erwähnte speziell einen böswilligen Benutzer, der curl oder eine andere Methode zum Erstellen von (nicht autorisierten) Anforderungen verwendet. Der Angreifer hat die iOS-App bereits zurückentwickelt, um unter anderem einen für den Angriff erforderlichen Schlüssel zu erhalten. Es wird nicht durch geringfügige Unannehmlichkeiten in Bezug auf Rückkehrcodes aufgehalten.
hinzugefügt der Autor Robert, Quelle
Hart, aber nur. Ich mag das :) . Es bringt die Natur der Schwäche in die richtige Perspektive.
hinzugefügt der Autor J.A.K., Quelle
Ich denke, dass dies WIRKLICH von starken Annahmen über den Angreifer abhängt. Sicherlich wird ein erfahrener Angreifer, der speziell auf die Website abzielt, nicht verlangsamt, er kann jedoch automatisierte Scan-Versuche verhindern oder Angreifer verlangsamen, die möglicherweise durch den Antwortcode verwirrt werden. Es ist also nicht unbedingt notwendig, die Sicherheit zu verbessern, aber es kann die Dinge verbessern. Die Frage ist, ob es die Zeit wert ist, etwas zu implementieren, das einen weniger entschlossenen Angreifer verlangsamen könnte.
hinzugefügt der Autor Kat, Quelle
@Nacht wie ist der zweite irrelevant? Es ist sehr relevant. Er sagt, wenn Sie Sicherheit durch Unbekanntheit nutzen, ist es besser verdammt gute Unbekanntheit. Er sagt, diese spezielle Verteidigung würde niemanden, der sich durch nichts ausrichtet, aufhalten
hinzugefügt der Autor Cruncher, Quelle

Statt "401 Unauthorized" zurückzugeben, warum nicht z. "305 Use Proxy", d. H. Absichtlich verwirrend.

Ja, es wird einen Angreifer verwirren. Aber für einen trainierten kann es nicht länger als zwei Sekunden dauern. Und Statuscodes sind nicht besonders nützlich, vor allem, wenn Dateinamen brutal erzwungen werden.

Angenommen, ich habe einen gültigen Schlüssel, und ich kann feststellen, dass Sie 200-Bereichscodes für meine Authentifizierung zurückgeben. Wenn ich ein wenig in meinem Schlüssel ändere und für jede Anfrage entweder 305s zurückschicke, werde ich sofort denken "Hmm. Scheint, als hätte der Dev vielleicht einen Fehler gemacht". Wenn Sie zufällige Codes zurückgeben, weiß ich, dass es absichtlich war und ich ignoriere sie einfach.

Die Schwierigkeit beim Reverse-Engineering einer iOS-App wird hoffentlich alle außer den entschlossensten Hackern abschrecken

Ja, das wird es, aber da es nur einen braucht, um es zu veröffentlichen, verlangsamt es sich wieder.

8
hinzugefügt
Vor langer Zeit habe ich einen Code geschrieben, der einen Angriff auf jeden startet, der so etwas versucht. Am Ende habe ich gelernt, dass es nicht die klügsten Ideen sind. Weitaus vernünftiger ist möglicherweise eine schlechte Anforderung -> IP auf der Firewall-Ebene für 100 Stunden gesperrt.
hinzugefügt der Autor Joshua, Quelle

Dies ist Sicherheit durch Unklarheit, das heißt, es bietet überhaupt keine Sicherheit. Die von Ihnen vorgeschlagene Lösung verlangsamt nur einen Angreifer und hindert ihn nicht daran, seinen eigenen Client zu verwenden. Tatsächlich kann Ihre Methode zum Verschlüsseln der Anforderungen, abhängig von Ihrer Implementierung, die Sicherheit Ihrer Anwendung verringern, indem Sie Angriffe auf andere Teile des Kryptosystems öffnen. Ihre Bemühungen sollten besser mit dem Versuch unternommen werden, die API-Funktionen selbst abzusichern (d. H. Pen-Test und Sicherung gegen Angriffe wie SQL-Injektion), anstatt zu verhindern, dass nicht autorisierte Clients auf sie zugreifen.

6
hinzugefügt
Das ist eine ganz andere Frage als die ursprüngliche und auch immer noch schwierig. Sie benötigen einen serverseitigen Mechanismus, um festzustellen, ob der Nutzer die Anzeige wirklich und wirklich angesehen hat. Möglicherweise senden Sie ein digital signiertes Token, das den Zeitstempel enthält, zu dem die Anforderung für die Anzeige eingegangen ist, sowie die Länge der Anzeige. Dieses Token muss dann erneut übermittelt und überprüft werden, wenn der Benutzer den geschützten Endpunkt anfordern möchte. Ich würde nach DRM-Lösungen suchen. Ohne Kryptographie-Erfahrung selbst zu rollen, wäre schwierig, dies sicher zu tun.
hinzugefügt der Autor Denis, Quelle
Bin aber verwirrt Alle sagen, dass OP echte Sicherheit braucht und NOBODY hat bereits erwähnt, wie das geht. Das Problem ist, dass der Endpunkt nur dann aufgerufen werden soll, wenn eine Anzeige angesehen wurde. Wie schaffen sie das?
hinzugefügt der Autor Cruncher, Quelle

Der Benutzer verwendet jedoch bereits Ihr Protokoll.

Your problem is that your server’s interface of what the user can do is not secure!
You decide what data your server sends out to whom!
(Hello, dear online newspapers. Yes, I’m looking at you!)

Entwerfen Sie es, vorausgesetzt, der Benutzer ist der Kunde. Nicht dein Code. Weil er ist. Es sollte keine Rolle spielen, welcher Client verwendet wird.
Ihre App läuft auf einer CPU, die vom Benutzer hardwaregesteuert wird. Ihr Code ist nur eine Liste von Befehlen/Daten, und der Benutzer und seine CPU können sie nach Belieben verarbeiten. Einschließlich der Verarbeitung von nicht .
Er entscheidet, was seine CPU macht. Verwechseln Sie nicht seine Gnade, Ihren App-Code so zu akzeptieren, dass er das Recht auf blinde Ausführung hat. Sie sind derjenige, dem hier vertraut wird, und dieses Vertrauen ist sehr flüchtig.
Besonders bei schlechten Taktiken wie dieser.

In jedem Fall: Sie geben dem Benutzer den Verschlüsselungsschlüssel und alles und erwarten, dass er ihn nicht selbst verwendet, weil Sie ihn irgendwo in Ihren Warenkorb legen. … Genau wie DRM ist das Schlangenöl und kann niemals funktionieren.
Es ist nur eine Person erforderlich, um herauszufinden, wo Sie den Schlüssel ablegen. (Das wäre zum Beispiel ich.) Alle anderen müssen einfach googeln.

Ich bin jedoch überrascht, dass Sie nur darüber nachdenken, das Protokoll gegen den Benutzer zu verschlüsseln, anstatt zu seinem Schutz vor Man-in-the-Middle-Angriffen Angenommen, der Grund ist normalerweise der Fall (Ja, ich spreche wieder mit Ihnen "Content-Industrie".): Wenn Ihr Benutzer Ihr Feind ist, sollten Sie vielleicht nach einem Geschäftsmodell suchen, das auf Fairness und einer Win-Win-Situation basiert. Anstatt den Benutzer abzureißen und sich mit Spiel zu beschäftigen.

P.: Ignorieren Sie alle Antworten auf "Sicherheit durch Unbekanntheit". Dies ist ein Irrtum, der zu korrektem Verhalten führt, aber immer noch auf ungültigen Annahmen beruht. Das Argument als Argument zu verwenden, ist bestenfalls amateurhaft und nicht wirklich kompetent In Wirklichkeit ist alle Sicherheit durch Verschleierung. Manche sind nur undeutlicher (= besser verkleidet). Der eigentliche Grund dafür ist schlecht, weil das, was wir als echte Sicherheit bezeichnen, eine Bazillion mal dunkler ist, wodurch es eine tatsächliche (statistische) vertrauenswürdige, hohe Vertrautheit gibt, im Gegensatz zu sehr Einfache Unbekanntheit, die einfach zu viel für jemanden ist, der aus dem Nichts auftaucht.

4
hinzugefügt
@DavidRicherby: Sie wiederholen meinen Punkt genau so, als wäre es ein Gegenargument. Mein Punkt ist, dass sich alle Sicherheitsaspekte nur durch die Menge an Arbeit unterscheiden, die zum Cracken/Fixieren (aka Obscurity) erforderlich ist, und daher es keine besondere magische Trennung mit "nicht auf Unschärfebasis" "real" gibt Sicherheit".
hinzugefügt der Autor NotoriousWebmaster, Quelle
@ DavidRicherby: Sagen Sie mir, was ich gesagt habe? ^^ Dude, ich stimme dir zu! (Oder lieber du bei mir.) Was willst du mehr? Entspannen Sie Sich! Und bitte "interpretieren" Sie nicht Dinge, die ich nicht gesagt habe. Ich habe nicht gesagt, dass der Begriff "Sicherheit" nutzlos ist. Und ja, es gibt KEINE 100% Sicherheit. Je. Es ist alles nur eine Ebene der Verschleierung. Sie können bequem eine beliebige Definition für "sicher" auswählen, aber dann geht es weiter in das Fantasyland.
hinzugefügt der Autor NotoriousWebmaster, Quelle
P.S .: Dies ist ein weiteres Beispiel dafür, warum Text ein schlechtes Medium für menschliche Konversation ist. Alle Missverständnisse.
hinzugefügt der Autor NotoriousWebmaster, Quelle
@Cruncher: Ein gutes Zeichen für den Fall, dass Menschen stärker an etwas glauben, weil sie weniger davon verstehen, ist, wenn sie emotionale Argumente wie "aus sehr guten Gründen" verwenden, aber nicht unterstützen. Wenn es keine Überzeugung war, würden sie einfach diesen Grund anstelle einer abgenutzten Phase angeben. Eine leider sehr häufige Sache unter Menschen. Ebenso wie Argumentation, selektive Interpretation, Strohmann-Argumente, alles als persönlich und beleidigend empfinden usw.
hinzugefügt der Autor NotoriousWebmaster, Quelle
@DavidRicherby: Und 1. warum argumentieren Sie dann dagegen, und 2. wann beginnen Sie Argumente zu machen, um dies zu unterstützen. :)/Ich rieche ein bisschen Trolling
hinzugefügt der Autor NotoriousWebmaster, Quelle
Die Verschleierung des Ausdrucks Sicherheit durch Verschleierung bezieht sich speziell auf die Verschleierung des Designs des Systems im Gegensatz zu Schlüsselmaterial. Es ist eine Möglichkeit, auf das Prinzip von Kertschow zu verweisen.
hinzugefügt der Autor Filegedhiel, Quelle
@DavidRicherby Ich möchte diesen Kommentar 100 Mal befürworten. Es ist überhaupt nicht sinnvoll, alle Sicherheitseinträge in unterschiedlichen Behältern in einem Behälter abzulegen. Wir haben die Terminologie "Sicherheit durch Unbekanntheit" aus einem sehr guten Grund erfunden.
hinzugefügt der Autor Cruncher, Quelle
@ Evi1M4chine Für jemanden, der "emotionale" Argumente züchtigte, sind Sie sicher, sehr emotional zu sein. Der "sehr gute" Grund war eigentlich mehr ein Appell an die Autorität als alles andere. Nichts emotionales daran. Ich habe auch nicht direkt auf Sie reagiert. Ich habe nur Davids Standpunkt verstärkt. Wir sind hier nicht in einer Debatte. Die Tatsache, dass mein Argument unvollständig war, bedeutet nicht, dass es ungültig oder unbegründet ist.
hinzugefügt der Autor Cruncher, Quelle
Interessanter Standpunkt in Bezug auf "alle Sicherheit liegt in der Dunkelheit". Wenn etwas unmöglich ist, im Leben eines Menschen zu knacken, ist es dann nicht sicher? :)
hinzugefügt der Autor niilzon, Quelle
Ihre Behauptung, dass "Sicherheit durch Unbekanntheit" kein nützliches Konzept ist, ist nicht wirklich gültig. Ich denke, Ihr Punkt ist, dass ein geheimer Schlüssel beispielsweise nur Sicherheit ist, wenn er den Schlüssel unkenntlich macht. Wenn ich jedoch Ihren geheimen Schlüssel herausfinde, können Sie ihn einfach durch einen neuen Schlüssel ersetzen, wieder betriebsbereit sein und versuchen, mit Ihrem neuen Schlüssel vorsichtiger zu sein. Wenn ich Ihren geheimen Algorithmus herausfinde, müssen Sie ein ganz neues System aufbauen, was viel mehr Arbeit bedeutet. Sie können auch viel bessere Grenzen setzen, wie lange ich brauche, um Ihren Schlüssel herauszufinden, oder wie lange ich brauche, um Ihren Algorithmus herauszufinden.
hinzugefügt der Autor William Pietri, Quelle
@ Evi1M4chine Nein, bin ich nicht. Sie sagen, dass alle Sicherheit letztendlich Sicherheit ist, indem sie etwas Unverständliches bewahren. Ich sage, dass wir nicht den Ausdruck "Sicherheit durch Unbekanntheit" verwenden, um "Sicherheit zu bedeuten, indem man etwas Unklares hält". Es ist, als würde man behaupten, dass kein System sicher ist, weil etwas von einem ausreichend entschlossenen, ausreichend starken Gegner gehackt werden kann und daher das Wort "Sicherheit" nutzlos ist, weil nichts wirklich sicher ist. Das ist nicht das, was das Wort "Sicherheit" bedeutet, und das dünne Wort, von dem Sie sprechen, ist nicht das, was "Sicherheit durch Unbekanntheit" bedeutet.
hinzugefügt der Autor William Pietri, Quelle
@ Evi1M4chine "Aus gutem Grund" ist kein emotionales Argument. Aber es ist ein Argument der Dunkelheit. ;-)
hinzugefügt der Autor William Pietri, Quelle
@ Evi1M4chine Nein, ich stimme dir nicht zu. Sie sagten, dass das Konzept der Sicherheit durch Unklarheit "ein Trugschluss" ist. Ich sagte, dass es nicht so ist. Es ist ein äußerst nützliches Konzept.
hinzugefügt der Autor William Pietri, Quelle

Wie bereits erwähnt, verlangsamt Sicherheit durch Unbekanntheit einen Angreifer bestenfalls.

In Ihrem speziellen Fall würde ich sagen, dass dies keine nennenswerten Auswirkungen haben wird. Um dies zu erreichen, musste der Angreifer Ihre App bereits zurückentwickeln und den privaten Schlüssel extrahieren. Das bedeutet, dass Ihr Angreifer kein Idiot ist und weiß, was er tut. Ein wenig Unklarheit kostet ihn weniger Zeit, als Sie für die Implementierung benötigen.

3
hinzugefügt
Nun, technisch gesehen ist dies der Versuch, die Tatsache zu verbergen, dass sie den privaten Schlüssel aus der App beziehen müssen. Das heißt, das passiert zuerst. Wer jedoch den Schlüssel aus der App bekommen kann, wird von ALLEN nicht aufgehalten
hinzugefügt der Autor Cruncher, Quelle
Jeder Nicht-Idiot-Angreifer würde zuerst den legitimen Datenverkehr beobachten und sofort sehen, dass die Anforderungen verschlüsselt sind. Es wäre buchstäblich das Erste, was er bemerkt.
hinzugefügt der Autor Tom, Quelle

Grundsätzlich KÖNNEN Sie NICHT verhindern, dass nicht autorisierte Kunden Anfragen senden. Das nächste, was möglich wäre, wäre eine Art kryptografischer Prüfung im Client, aber wie Sherlock Holmes sagte, "was man erfinden kann, kann ein anderer entdecken". (Ich weiß das sicher, weil ich die Client-Sicherheit anderer Leute mehrfach geknackt habe.)

Erstellen Sie stattdessen Ihre API so, dass jeder es verwenden darf, um benutzerdefinierte Clients zu verwenden. Machen Sie es freundlich. Was verlierst du dadurch? Angreifer greifen an, egal was Sie tun, und wenn Sie Ihre API benutzerfreundlich gestalten, wird Ihnen jemand etwas einfallen lassen, an das Sie nie gedacht haben, und Ihren Server sogar noch größer machen, als Sie sich jemals vorstellen konnten. Was kann ein Client tun, der sowohl mit Ihrer API als auch mit anderen kommuniziert? Welche unzähligen Möglichkeiten gibt es, und wird es Ihnen wirklich weh tun, sie zuzulassen?

1
hinzugefügt

Wie bereits erwähnt, schlagen Sie vor, Security by Obscurity zu verwenden. Während diese Technik ihren Zweck hat, sollten Sie Folgendes bedenken, bevor Sie sich für diesen Ansatz entscheiden:

  • Bereitstellung technischer Unterstützung für Ihre API. Die Verwendung von täuschenden HTTP-Antwortcodes macht es für andere als Sie schwierig, Support bereitzustellen. Sie müssen überlegen, ob in der jeweiligen Situation tatsächlich der richtige Antwortcode gesendet wird oder ob ein unbekannter Code gesendet wird. Sollten Sie sich dazu entschließen, der einzige Ansprechpartner für Supportanfragen zu bleiben, sollte dies kein Problem sein.
  • Was ist ein "böswilliger Benutzer"? Seien Sie vorsichtig, wenn Sie eine Anforderung als schädlich einstufen, da dies nachteilige Auswirkungen haben kann. Angenommen, eine IP sendet bösartigen Datenverkehr, und es werden Gegenmaßnahmen verwendet. Nehmen Sie nun an, dass dieselbe IP-Adresse tatsächlich ein Proxy ist, hinter dem Hunderte oder Tausende von Benutzern stehen. Sie haben jetzt Ihre Gegenmaßnahme auf alle angewendet. Derselbe Prinzip kann zum Identifizieren von schädlichen Aktivitäten in Kopfzeilen und/oder Textkörper angewendet werden.
  • Der Anwendungscode ist am langsamsten. Die Anforderung muss den gesamten Stapel durchlaufen, um schließlich zur "Sicherheits" -Logik zu gelangen. Diese Architektur skaliert nicht gut und ist langsam. Fehlerhafte Anforderungen sollten so früh wie möglich gestoppt werden. Dies ist die Voraussetzung für die Verwendung von Web Application Firewalls (WAF).
  • Zugriff erweitern. Wenn Ihre API für mehr Clients zugänglich ist, als für das ursprünglich vorgesehen, müssen diese neuen Clients über die mögliche Verwendung trügerischer HTTP-Antwortcodes informiert werden.
  • Anhaltende böswillige Benutzer. Wie andere bereits erwähnt haben, ist diese Technik nur eine Geschwindigkeitsschwelle.

Besserer Ansatz

Konzentrieren Sie Ihre Zeit auf das White-Listing aller bekannten guten Anfragen. Dies ist so viel einfacher als der Versuch, alle potenziell fehlerhaften Anfragen zu identifizieren. Alles, was nicht in der Whitelist erscheint, sollte sofort einen geeigneten Antwortcode erhalten, z. B. HTTP 400 oder HTTP 405, wenn Sie nach HTTP-Verben filtern (als Beispiele). Vorzugsweise geschieht dies, bevor die Anforderung Ihren Anwendungscode trifft.

Stellen Sie sicher, dass Ihre Anwendung neben den zulässigen White-Listings auf der Grundlage der OWASP-Richtlinien gesichert ist. Sie erhalten weitaus bessere Ergebnisse , um Ihre Zeit mit OWASP zu verbringen, dann werden Sie versuchen herauszufinden, was ein böswilliger Benutzer ist, und einen obskuren HTTP-Antwortcode zurückgeben.

1
hinzugefügt

Das würde ich nicht tun Im Allgemeinen bedeutet dies, dass Sie einen eigenen Standard erstellen, der Folgendes verursacht:

  1. Ihre API soll vorhersagbar sein, nachdem Sie eine Zuordnung Ihrer http-Antworten zu ihrer tatsächlichen Bedeutung erstellt haben. Das Ändern der HTTP-Antworten kann bei einigen "Hackern" funktionieren, die nach einigen Versuchen aufgeben würden, bei anderen jedoch nicht, bei entschlosseneren. Möchten Sie Ihre API nur vor einem früheren Typ schützen, d. H. Vor 11-Jährigen? Ich glaube nicht.

  2. ziemlich verwirrend für Entwickler und wahrscheinlich Tester, insbesondere für diejenigen, die nach globalen Standards arbeiten.

  3. Wählen Sie einen anderen Weg. Es gibt definitiv ein paar. Ich habe in letzter Zeit selbst mit dem gleichen Headscratcher zu kämpfen gehabt und habe mir mindestens zwei mehr oder weniger zuverlässige Wege zur Erreichung der gewünschten Einschränkungen ausgedacht [kann sie hier nicht posten].

Es gibt definitiv bessere und VIEL effektivere Wege, um zu bekommen, was Sie wollen. Versuchen Sie, Ihre API aus einem anderen Blickwinkel zu betrachten ... Wenn Sie ein Hacker wären und Ihr Leben davon abhinge, diese API zu hacken - was würden Sie tun, um erfolgreich zu sein? Was sollte passieren, damit Sie bei Ihren Versuchen, es zu brechen, frustriert sind?

1
hinzugefügt

Im Allgemeinen ist es keine gute Idee.

Ich habe dies sehr zielgerichtet genutzt, als die Website eines Kunden von einem gestohlenen Kreditkartenwäschering benutzt wurde. Es gab einige identifizierende Merkmale, die nur von den betrügerischen Transaktionen geteilt wurden. Statt sie höflich abzulehnen, hätte ich die Antwortzeit der Website um ein paar Minuten verzögert (niemand mag eine Website, die Minuten braucht, um etwas zu erledigen) und dann eine 500 mit der Website zurückgeben Standard "Entschuldigung, ich bin es nicht" für Serverfehler (es werden auch Details für die Weiterleitung an die Strafverfolgung protokolliert). Wir hatten drei Versuche bei Transaktionen, bei denen diese Antwort auf das Spiel gegeben wurde und die dann nie wieder von ihnen gehört wurden.

Das war aber:

  1. Als Reaktion auf etwas, von dem wir wussten, dass es sich um einen Angriff handelt, ist es nicht unangenehm für Benutzer, die ein Problem haben.
  2. Keine Verteidigung gegen einen Angriff auf die Sicherheit des Protokolls selbst, sondern auf der menschlichen Ebene darüber.
  3. Erklärbar durch andere Erklärungen, dh wir gaben vor, in einer Situation, in der dies plausibel war (es gibt viele saugfähige Websites), eine wirklich saugfähige Website zu haben, und wir waren kein bestimmtes Ziel (die Täter würden weiterziehen zu jemand anderem).

Benutzern, die ein Problem haben, sollte geholfen werden, nicht missbraucht zu werden. "Ich kann das nicht, weil Sie nicht richtig autorisiert sind", weigert sich, etwas auf hilfreiche Weise zu tun. "Ich kann das nicht, weil Sie einen Proxy verwenden müssen", wenn jemand keinen Proxy verwenden muss. Absichtlich nicht hilfreich zu sein, ist nur dann sinnvoll, wenn Sie wissen, dass Sie angegriffen werden, und dann sollte es nicht wie eine offensichtlich falsche Nachricht aussehen oder Sie haben nichts versteckt (möglicherweise haben Sie tatsächlich etwas preisgegeben, wenn der gleiche falsche Status nicht verwendet wird für jeden Kundenfehler).

Das heißt, es ist angemessen, Maßnahmen zu ergreifen, um Statusinformationen zu erhalten, die keine Informationen enthalten. Z.B. Es ist akzeptabel (als solches in den Standards beschrieben) für /admin/ bis 404, in einem anderen Fall (autorisierter Benutzer, zugelassene Client-IP-Adressen usw.) würde es 200 sein. Alternativ, wenn /mitglieder/mein-Profil wird 200 für einen berechtigten Benutzer und 403 oder 401, wenn /members/fdsasafdasfwefaxc für einen berechtigten Benutzer 404 wäre, ist es eine gute Idee, dass es 403 oder 401 ist der nicht autorisierte Benutzer. Dies ist nicht so sehr die Sicherheit durch Unklarheit, als zu berücksichtigen, welche URIs Ressourcen zu den Informationen zählen, die geschützt werden.

0
hinzugefügt

Ein guter Grund, dies nicht zu tun, insbesondere für eine mobile App. Es ist sehr wahrscheinlich, dass Ihre App über mehrere Proxies, z. B. in der Telefongesellschaft, bereits mit Ihrem Server kommuniziert. Die meisten großen Unternehmen verwenden Proxys in ihrem Netzwerk, um ihre Systeme vor schädlichen Inhalten zu schützen, und viele Telefongesellschaften beeinträchtigen die Qualität von Videos oder Bildern, die übertragen werden. Die Verwendung der verschiedenen Systembibliotheken für HTTP auf Ihrer Plattform wird für Sie nutzlos. Ein Ansatz, der häufig verwendet wird, besteht darin, einen Schlüssel oder ein Token aus Informationen abzuleiten, die der Benutzer wahrscheinlich nicht mit anderen teilen möchte, z. B. Hashing der Namensadresse und der Kreditkartendetails. Selbst wenn Ihre App gehackt wird, werden Benutzer auf diese Weise vorsichtig sein, die erforderlichen Informationen einem zufälligen Programm zu geben, das sie heruntergeladen haben, und die Freigabemöglichkeit eines nachgewiesenen Angriffs einschränken.

0
hinzugefügt