it-swarm.com.de

Wenn in einer Webseiten-URL ein ungültiger Abfragezeichenfolgenparameter erkannt wird: Fehler auslösen oder ignorieren?

Was ist eine bessere Vorgehensweise, wenn Benutzer die Abfrageparameter einer Website ändern: einen Fehler auslösen oder ignorieren?

Zum Beispiel versucht jemand, einem page -Parameter eine "abc" -String anstelle einer Zahl zuzuweisen:

http://example.com/list/?page=abc

Sollte die Website die Listenelemente trotzdem mit der ersten Standardseite anzeigen oder sollte sie einen 404-Fehler anzeigen?

18

Sie erhalten unterschiedliche Antworten auf verschiedenen Stack Exchange-Sites.

UX POV

Es kann sich um einen Kopier- und Einfügefehler oder einen (power-) Benutzertippo handeln. -), nicht unbedingt ein böswilliger Angriff auf die Sicherheit der Website.

Ich bin (allgemein) gegen stillschweigend ignorierte Fehler , weil Fehler unbemerkt bleiben können und der Benutzer nicht das bekommt, was er erwartet.

Ich würde immer werfen den entsprechenden Fehler. Für eine Website kann eine fehlerhafte Abfragezeichenfolge HTTP 4 Statuscode ( Bad Request zurückgeben. Lesen Sie weiter, um eine kurze Diskussion darüber zu erhalten.) mit einer entsprechenden Fehlerseite .

Benutzerdefinierte Fehlerseite (jede anständige Site sollte benutzerdefinierte Fehlerseiten für häufige Fehler hat) ist der Ort, an dem Benutzer verstehen, was falsch ist (Statuscode, egal welcher, ist fast nie erklärend für nicht technische Benutzer). In eine solche Seite werden Sie setzen:

  • Eine benutzerfreundliche Fehlerbeschreibung , die auch nicht technische Benutzer verstehen werden.
  • Eine mögliche Lösung .
  • Wenn Sie einen Fehler entdeckt haben, können Sie diesen korrigieren (z. B. eine Zeichenfolge anstelle einer Zahl in der URL, die standardmäßig auf einen angemessenen Wert eingestellt werden kann) Link zu angepasst URL.
  • Optional können Sie Rechtschreibprüfung für die fehlgeschlagene Adresse bereitstellen.
  • Stellen Sie einen Link zum Webmaster/technischen Support bereit, um Supportanfragen zu senden.
  • Protokollieren Sie immer fehlgeschlagene Anfragen (und benachrichtigen Sie den Webmaster, wenn der Referrer Ihre eigene Site ist). Die meisten Benutzer senden keine Benachrichtigung, und ein defekter Link befindet sich möglicherweise auf Ihrer eigenen Site. Das ist eine schreckliche Benutzererfahrung.

Die von Ihnen eingegebene Adresse ist ungültig .

Mögliche Ursachen und Lösungen:
• Wenn Sie diese Adresse direkt eingegeben haben, suchen Sie bitte nach Tippfehlern .
• Wenn Sie diese Adresse kopiert und eingefügt haben, überprüfen Sie bitte , ob Sie die gesamte Adresse angegeben haben (z. B. können E-Mail-Programme Adressen auf mehrere Zeilen aufteilen und Sie müssen sie manuell neu zusammensetzen).
• Wenn Sie über einen Link auf diese Seite gelangt sind, benachrichtigen Sie bitte den Eigentümer der Quellwebsite, dass der Link defekt ist .

Dies sind mögliche Seiten, die Sie stattdessen anzeigen möchten:
Ähnliche Seite: http://www.example.com/products?page=2
Produktkatalog: http://www.example.com/products/index
Site-Homepage: http://www.example.com

Müssen Sie sich an unseren [technischen] (mailto: [email protected]] Support oder an unseren Webmaster wenden?

Technische Details:
Anfrage: GET www.example.com/products?page=w HTTP/1.1
Antwort: HTTP 400 (schlechte Anfrage)
Fehler: Argument "Seite" muss numerisch sein
Referrer: www.brokenlinks.com

Beachten Sie, dass dieses Schema nicht auf diesen speziellen Fall (oder auf 400/404 Statuscodes) beschränkt ist. Sie Fehlermeldungen/Seiten müssen immer nützlich und benutzerfreundlich sein , siehe auch Feedback-Beispiele „Kein Videogerät“ .

Sicherheit POV

Aus Sicherheitsgründen kann eine fehlerhafte Anforderung ein Versuch sein, Ihre Sicherheit zu beeinträchtigen.

Sie haben verschiedene Optionen und Aktionen. Dieser Abschnitt ist weitaus genauer und umfassender und fragt Sicherheitsexperten (in Ihrem Team oder zumindest unter security.stackexchange.com ) nach besseren Ansätzen.

Angenommen, der Benutzer (siehe oben) gibt möglicherweise eine falsche URL ein. Sie können ihn nicht als böswilligen Angriff betrachten, jedoch sind nicht alle URLs gleich. Möglicherweise haben Sie beispielsweise eine sichtbare URL /Home Und eine GET-Anforderung zum Abrufen von Elementen in einer Liste mit /Home/News?page=1&itemsPerPage=5&mode=overview. Der Benutzer wird die zweite URL nie sehen, da es sich um eine AJAX handelt, die von main Seite zum Abrufen von Inhalten für ein Seitenelement angefordert wird.

Im Allgemeinen sollten ungültige Parameter für URLs, auf die nur über AJAX Anforderungen zugegriffen wird, als potenzielle Angriffe behandelt werden. Du darfst:

  • Geben Sie einfach eine Fehlerseite zurück (mit oder ohne 40x HTTP-Statuscode). Der Benutzer wird dies nur sehen, wenn er die Tools der Browser-Entwickler überprüft.
  • Fügen Sie optional eine Verzögerung hinzu (um sie zu verlangsamen, wenn sie einen Brute-Force-Angriff (!) Mit zufälligen Abfragezeichenfolgen versuchen). Seien Sie vorsichtig, es kann kontraproduktiv sein, wenn sie eine große Anzahl paralleler Anforderungen generieren können, da dies zu einem DoS auf Ihrem Server führen kann.
  • Wenn mehrere fehlerhafte Anfragen nacheinander aus derselben Quelle auftreten, können Sie eine temporäre schwarze Liste anwenden.
  • Wenn mehrere fehlerhafte Anforderungen nacheinander an dieselbe Zielressource gesendet werden, können Sie sie verlangsamen (gleicher Grund von Punkt 2) und sie schließlich mit HTTP 301 oder 307 auf eine fiktive Website (example.com) umleiten.

Welcher Fehlercode?

Ich denke nicht, dass dies ein wichtiger Punkt ist (insbesondere wenn Benutzer Menschen sind), aber ... welchen HTTP-Fehlercode sollten wir verwenden? Jemand schlägt jedoch 404 vor:

Die angeforderte Ressource wurde nicht gefunden, ist aber möglicherweise in Zukunft wieder verfügbar. Nachträgliche Anfragen des Kunden sind zulässig.

Offensichtlich ist dies bei einer fehlerhaften URL nicht der Fall (zum Beispiel www.example.com?page=1&pageSize=A). 404 kann ein akzeptabler Statuscode sein, wenn die URL www.example.com?page=1000&pageSize=20 War. Für den 400-Statuscode wissen wir (wie besser beschrieben durch HTTPbis ):

Der Statuscode 400 (Bad Request) gibt an, dass der Server die Anforderung nicht verarbeiten kann oder will, da die empfangene Syntax ungültig und unsinnig ist oder eine Einschränkung der Verarbeitungsbereitschaft des Servers überschreitet.

Es veraltet RFC 2616 wo angemessener Fehlercode für logische Fehler unklar war. Beachten Sie, dass Sie (für was es wichtig ist) RFC 4918 (aktualisiert von RFC 5689 ) einhalten und den Statuscode 422 verwenden können:

Der Statuscode 422 (nicht verarbeitbare Entität) bedeutet, dass der Server den Inhaltstyp der Anforderungsentität versteht (daher ist ein 415-Statuscode (nicht unterstützter Medientyp) unangemessen) und die Syntax der Anforderungsentität korrekt ist (daher eine 400 (fehlerhafte Anforderung) ) Statuscode ist unangemessen) konnte die enthaltenen Anweisungen jedoch nicht verarbeiten. Beispielsweise kann diese Fehlerbedingung auftreten, wenn ein XML-Anforderungshauptteil wohlgeformte (d. H. Syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.

Aber all dies sagte ... dies ist ein fast nutzloses Detail (in diesem Fall), zum Beispiel gibt der Stapelüberlauf manchmal in beiden Fällen 200 zurück (.. .und ignorieren fehlerhafte URLs stillschweigend mit Standardeinstellungen) und manchmal wird 404 (Seite nicht gefunden) zurückgegeben, je nachdem, welchen URL-Parameter Sie falsch schreiben. Wählen Sie einen Fehlercode und geben Sie die richtige Seite zurück (dies ist der wichtige Teil, siehe auch MonkeyZeus Kommentar).

20
Adriano Repetti

Das Ändern der URL im Browser ist absolut nicht "hacken" *. Dies ist nur eine grundlegende Funktion des Webs: Sie können die URL nach Belieben ändern. Was Sie hier im Wesentlichen fragen, ist "Was ist, wenn die URL keine gültige Ressource zurückgibt?" Sie zeigen eine 404.

* zumindest im Zusammenhang mit der heutzutage verwendeten einheimischen Definition von Hacking, die sich auf den Versuch bezieht, etwas Bösartiges zu versuchen

22
DA01

Szenario :

Ich bin ein Blogger und möchte auf Inhalte auf Ihrer Website verlinken. Beim Erstellen meines Links mache ich einen Tippfehler und mein Link lautet: .http://example.com/list/?page=q23

Jetzt klickt ein anderer Benutzer, ein Leser des Blogs, auf diesen Link. Es wäre weniger wünschenswert, wenn das erste, was sie sehen, "Stop Hacking" oder sogar der generische Fehlerbildschirm ist, den Ihre Programmiersprache Ihrer Wahl bietet. Fragen Sie sich stattdessen:

  • Wie könnte mein Benutzer hier gelandet sein?
  • Was versuchten sie zu erreichen, als sie hier landeten?
  • Wie kann ich ihnen am besten helfen, das zu erreichen, was sie sich vorgenommen haben?

Je nachdem, was Sie in Ihrer Abfragezeichenfolge erhalten haben, können Sie ihnen Seiten mit ähnlichen Begriffen anzeigen oder sie zur Anzeige einer Ergebnisliste auf die richtige Seite weiterleiten. Es ist auch üblich, einen freundlichen 404 mit einer Suchleiste für den Inhalt Ihrer Website als Haupt-CTA auf der Seite zu werfen.

Technisch :

  • Protokollieren Sie den "Referrer" und die versuchte URL für fehlerhafte Anfragen (prüfen Sie, ob Sie Trends erkennen können).
  • Sie nehmen eine Abfragezeichenfolge auf. Programmieren Sie entsprechend, um sich vor Schwachstellen zu schützen (es gibt viele Ressourcen dazu)
9
Daniel Brown