Verwendung des QueryString als Debug-Schalter?

Question

Ich habe heute den Code einer Webanwendung überarbeitet und bin dabei in der Basisklasse für alle Webseiten auf etwas Ähnliches gestoßen:

if (Request.QueryString["IgnoreValidation"] != null)
{
    if (Request.QueryString["IgnoreValidation"].ToUpper() == "TRUE")
    {
        SessionData.IgnoreValidation = true;
    }
}

Mir scheint dies eine sehr schlechte Sache™ zu sein, also habe ich sofort alle Spuren dieser Markierung aus dem Code entfernt. Zum einen waren mehrere if-Anweisungen eingestreut, die den Wert des Flags überprüften, was zu einer unübersichtlichen und unklaren Logik führte. Zweitens stieß ich auf ein anderes, noch gefährlicheres Flag namens "IgnoreCreditCardValidation". Sie können sich denken, was diese Flagge bewirkt hat...

Dann dachte ich darüber nach und erinnerte mich an ein ähnliches Beispiel aus einer früheren Tätigkeit. Im Code einer Anwendung, die als "sicheres Authentifizierungsmodul" verkauft wurde, gab es einen QueryString-Parameter, mit dem das Standardverhalten außer Kraft gesetzt wurde und der es jedem, der ihn kannte, ermöglichte, die Authentifizierung zu umgehen.

Jetzt ist meine Frage eher eine Bestätigung, ist diese Praxis so schlimm, wie sie in meinem Kopf erscheint, oder reagiere ich nur über und dies ist alltäglich? Gibt es Fälle, in denen es einen triftigen Grund gibt, dies zu tun? Mir scheint es einfach eine schreckliche Mischung aus Faulheit und Nachlässigkeit zu sein.

Falls es sich um eine Kopie handelt, können Sie mich gerne auf die richtige Seite verweisen.

Danke!

Answer 1

Es ist entsetzlich, ob es nun gängige Praxis ist oder nicht. +1 für dich, weil du es mit extremer Vorverurteilung vernichtet hast.

Answer 2

Ich stimme mit Ihnen überein. Vor allem, wenn das Modul darauf ausgelegt ist, die Sicherheit zu erhöhen, ist dies eine dumme Sache, die in einem Freigabe erstellen (es ist auch keine gute Idee, es in Debug-Builds zu haben, aber das könnte sinnvoll sein). Es ist im Wesentlichen Sicherheit durch Verunsicherung.

Answer 3

Das sind nicht Sie. Wer auch immer das geschrieben hat, hat sich noch nie mit öffentlich zugänglichen Webanwendungen beschäftigt. Wie Sie richtig bemerkt haben, kann jeder, der von dieser "Hintertür" weiß, Ihre Anwendung in den Ruin treiben.

Answer 4

Das liegt daran, dass der ursprüngliche Entwickler sowohl beim Design als auch beim Testen zu faul war.

Die ideale Lösung besteht darin, die Validierung oder Kreditkartenauthentifizierung usw. aus dem Code in separate DLLs/Dienste usw. auszulagern. Die echten Versionen können dann durch Mocks ersetzt werden, um das Testen der Website zu erleichtern. Die Dienste können auch unabhängig voneinander getestet werden.

Diese Mocks kommen nie in die Nähe des Produktionsservers, so dass Sie keine Hintertüren in Ihren Code haben sollten.

Sie können auch einen oder alle Dienste ersetzen, ohne Ihre Anwendung aktualisieren zu müssen - solange der neue Dienst die gleiche Schnittstelle wie der ursprüngliche hat.

Answer 5

Ich gehe gegen den Strich und sage Querystrings sind gute Debug-Schalter.

Bevor sich alle auf mich stürzen - Die Verwendung von Querystrings zur Deaktivierung der Validierung ist schrecklich dumm, eine riesige Sicherheitslücke, und sollte niemals passieren. Es war völlig richtig und gerechtfertigt, den Code sofort zu löschen.

Aber für die Fehlersuche sind Querystrings hervorragend geeignet. Wir haben ein paar Querystrings, die IDs für ein paar Objekte auf unseren Seiten einschalten, damit wir sie schnell abrufen können, ohne uns in die Produktionsdatenbank einloggen zu müssen (natürlich hat nicht jeder Zugriff auf die Prod DB), oder um Berechnungskomponenten zu überprüfen. Man muss nur vorsichtig und intelligent mit ihnen umgehen.