Die Verletzung der Regeln der Web-Entwicklung

Question

prüfen this page von der New York Times aus:

http://homedelivery.nytimes.com/HDS/learnMorePopUp.do ?mode=common.learnMorePopUp
&productId=NDS
&prodRate=7.40

Ich war überrascht zu sehen, dass, wenn ich die manuell geändert prodRate Parameter, die Seite aktualisiert:

• Die einleitende Abonnement-Rate.
• Die reguläre Abonnement-Rate.

Probieren Sie es selbst aus! Nun, ich habe nicht viel Webentwicklung gemacht, aber ich weiß, das sollte wahrscheinlich nicht passieren. Also frage ich mich:

• Welche Art von Implementierung würde dieses Verhalten verursachen?
• Wie würden Sie die Seite ändern, um solche sensiblen Parameter vor dem Endbenutzer zu verbergen?

Answer 1

Sie möchten Ihre Frage, als die einzigen Antworten auf umformulieren ich nicht zu beleuchte vorstellen kann:

F: Welche Art der Umsetzung dieses Verhalten verursachen würde?
A: Eine, in der Benutzereingaben das interne, vertrauenswürdige Verhalten steuern können. Wenn Sie fragen "warum sollte jemand das tun", habe ich es normalerweise als ein Missverständnis gesehen.Der Autor des Codes erkennt im Allgemeinen nicht, dass der Benutzer (a) den Wert kontrollieren kann und/oder (b) sogar feststellen kann, dass er existiert. Meistens habe ich gesehen, dass dies als Redirect implementiert ist - Sie klicken auf eine Schaltfläche, der Server bestimmt den Betrag und leitet den Browser dann auf eine neue Seite um, die den Wert

F: Wie würden Sie die Seite ändern, um solche zu verbergen empfindliche Parameter vom Endbenutzer?
A: Speichern Sie den Wert nicht so, dass er vom Endbenutzer bearbeitet werden kann. Wenn auf dem Server Speicher verfügbar ist (wie eine Servlet-Engine), speichern Sie ihn im Sitzungskontext. Wenn Sie keinen guten Sitzungsmechanismus haben, können Sie ihn in einem signierten oder HMAC-Cookie speichern.

Answer 2

Sie lesen wahrscheinlich nur den Wert direkt aus der Querystring für Anzeigezwecke. Ich bezweifle stark (oder vielmehr hoffe ich wirklich), dass eine tatsächliche Bestellverarbeitung nicht auf diesem Wert basiert und eher auf einer Suche mit der Produkt-ID basiert.

Answer 3

Nun, haben Sie tatsächlich versucht, es noch zu bestellen? Es könnte die Eingabe am Back-End validieren.

Zu anderen Optionen könnten sie in Erwägung gezogen haben, entweder die Informationen zu posten oder die Informationen in einen Cookie zu schreiben. Beide sind nicht genau narrensicher. Sie können kein neues Fenster mit einem Beitrag erhalten und ein Benutzer kann Cookies deaktivieren.

Answer 4

Sie können nicht von dieser Seite aus bestellen, daher sehe ich hier kein Sicherheitsloch. Ja, es ist kitschig, aber ich wäre viel mehr besorgt, wenn der tatsächliche Bestellfluss so schlecht konstruiert wäre. Es macht es einfach, die Rate an einer Stelle zu aktualisieren und den Wert einfach zu übergeben, damit ich sehen kann, wie es passiert ist.

Wir haben einige Bewertungsseiten, die ziemlich genau dasselbe tun. Sie sind nicht mit dem tatsächlichen Einkaufsfluss verbunden, daher sind die Parameter in Ordnung. Wenn der Kunde sich selbst durch Bearbeiten einer URL verwirren möchte, ist es so, dass ... der tatsächliche Bestellungsfluss durch die Datenbank gesteuert wird und Benutzeränderungen niemals vertrauenswürdig sind.

Answer 5

Ich habe alle Arten von schlechter Praxis wie folgt gefunden. Ich habe gesehen, Websites übergeben ganze SQL-Abfragen in der Querystring herum, die dann ausgeführt werden. Ich erinnere mich auch daran, einen Online-Shop gefunden zu haben, der Preise in Querystring weitergegeben hat. Ich habe einen auf einen negativen Wert geändert und, tatsächlich, an der Kasse war der Preis minus! Ich bin jedoch nicht weiter gegangen - technisch gesehen ist es Betrug und es lohnt sich nicht zu riskieren.