Das Offenlegen Ihrer Primärschlüssel (insbesondere wenn sie vorhersehbar sind) ist eine Schwachstelle namens Insecure Direct Object Reference.
Durch eine URL (oder einen anderen vom Client bereitgestellten Parameter) wie diese:
http://www.domain.com/myaccount?userid=12
Sie geben Ihren Endbenutzern die Möglichkeit, mit diesen Variablen herumzuspielen und beliebige Daten weiterzugeben. Die Gegenmaßnahme zur Minderung dieser Sicherheitsanfälligkeit besteht darin, stattdessen indirekte Objektverweise zu erstellen. Das mag nach einer großen Umstellung klingen, muss es aber nicht unbedingt sein. Sie müssen nicht alle Ihre Tabellen oder irgendetwas neu eingeben, Sie können dies tun, indem Sie mit Ihren Daten durch die Verwendung einer indirekten Referenzkarte clever umgehen.
Bedenken Sie Folgendes:Sie haben einen Benutzer, der auf Ihrer Website einen Kauf tätigt. Und wenn es an der Zeit ist zu bezahlen, wird ihnen eine Dropdown-Liste mit ihren Kreditkartennummern angezeigt, die Sie "in den Akten" haben. Wenn Sie sich den Code für das Dropdown-Menü ansehen, sehen Sie, dass die Kreditkartennummern den Schlüsseln 8055, 9044 und 10099 zugeordnet sind.
Der Benutzer könnte sich das ansehen und denken, dass sie sehr nach automatisch inkrementierenden Primärschlüsseln aussehen (der Benutzer hätte wahrscheinlich Recht). Also versucht er es mit anderen Schlüsseln, um zu sehen, ob er mit der Karte eines anderen bezahlen kann.
Technisch gesehen sollten Sie serverseitig Code haben, der sicherstellt, dass die ausgewählte Karte Teil des Benutzerkontos ist und dass er sie verwenden kann. Dies ist ein erfundenes Beispiel. Im Moment gehen wir davon aus, dass dies nicht der Fall ist oder dass dies ein anderer Formulartyp ist, der möglicherweise nicht über diese Art von serverseitiger Kontrolle verfügt.
Wie verhindern wir also, dass der Endbenutzer einen Schlüssel auswählt, der ihm nicht zur Verfügung stehen sollte?
Anstatt ihnen einen direkten Verweis auf den Datensatz in der DB zu zeigen, geben Sie ihnen einen indirekten Verweis.
Anstatt die DB-Schlüssel in das Dropdown-Menü zu packen, erstellen wir ein Array auf dem Server und stopfen es in die Sitzung des Benutzers.
Array cards = new Array(3);
cards[0] = 8055;
cards[1] = 9044;
cards[2] = 10099;
In der Dropdown-Liste geben wir nun den Verweis auf den Index des Arrays an, in dem die Karte gespeichert ist. Anstatt also die tatsächlichen Schlüssel zu sehen, sieht der Endbenutzer die Werte 0, 1 und 2, wenn er die Quelle anzeigt.
Beim Absenden des Formulars wird einer dieser Werte weitergegeben. Dann holen wir das Array aus der Sitzung des Benutzers und verwenden den Index, um den Wert zu erhalten. Der eigentliche Schlüssel hat den Server nie verlassen.
Und der Benutzer kann den ganzen Tag über verschiedene Werte eingeben, wenn er möchte, aber er wird niemals ein anderes Ergebnis als seine eigenen Karten erhalten, unabhängig von der serverseitigen Zugriffskontrolle, die vorhanden ist.
Denken Sie jedoch daran, dass Sie bei Verwendung des übergebenen Indexes, um den Wert herauszubekommen, einige Ausnahmen erhalten könnten, wenn der Benutzer damit herumspielt (ArrayOutOfBounds, InvalidIndex, was auch immer). Packen Sie dieses Zeug also in einen Versuch/Fang, damit Sie diese Fehler unterdrücken und die Fehler protokollieren können, um nach Cracking-Versuchen zu suchen.
Hoffe das hilft.
Um mehr über unsichere direkte Objektreferenzen zu erfahren, sehen Sie sich die OWASP Top 10 an. Es ist Risiko Nummer A4. https://www.owasp.org/index.php/Top_10_2010-A4 -Insecure_Direct_Object_References
