Frage:
Ist das nicht autorisierte Löschen ein Integritäts- oder Verfügbarkeitsproblem?
paj28
2016-12-15 19:18:12 UTC
view on stackexchange narkive permalink

Während eines Webanwendungstests habe ich ein Problem mit der Manipulation von Parametern festgestellt, mit dem ein Benutzer Kommentare anderer Benutzer löschen kann. Sie können den Inhalt der Kommentare anderer Benutzer nicht ändern und sie nur dort anzeigen, wo dies beabsichtigt ist.

Ich berechne jetzt den CVSS-Score mit diesem Rechner. Es ist ziemlich klar, dass die Auswirkungen auf die Vertraulichkeit keine sind, aber ich bin mir über die anderen nicht sicher.

Meine Frage lautet also: Für CVSSv3 ist das unbefugte Löschen ein Integritätsproblem oder ein Verfügbarkeitsproblem (oder) beide)?

Ich bin mit CVSS in keiner Weise vertraut, aber das unbefugte Löschen wäre für mich ein Integritätsproblem.Ein Verfügbarkeitsproblem wäre eher ein Fall, in dem die Informationen nicht zugänglich gemacht werden, aber immer noch vorhanden sind.
Die Verfügbarkeit gilt für Dienste, nicht für reine Daten.Eine Änderung der Verfügbarkeit ändert keine Informationen.Das ist also ein Integritätsproblem.
In der Zeit, die Sie für die Berechnung des CVSS-Scores benötigt haben, hätten Sie das Problem isolieren und einen Patch vorbereiten können.
@DepressedDaniel - Dies ist eine Client-App, daher mache ich den Patch nicht.Ich denke, der Aufwand, nach dieser speziellen App zu fragen, ist unverhältnismäßig - aber dies jetzt zu bekommen, hilft allen zukünftigen ähnlichen Instanzen.
Umfrage sagt ... "Ja"
@JoelCoehoorn - Umfrage sagt ... "Integrität" :-)
Fünf antworten:
Rhymoid
2016-12-16 00:59:59 UTC
view on stackexchange narkive permalink

Wie in dieser (unbeantworteten) Frage ausgeführt, geht es bei Verfügbarkeit in CVSSv3 darum, wie gut der Webdienst funktioniert und nicht darum, ob seine Daten verfügbar sind:

Während die Auswirkungsmetriken für Vertraulichkeit und Integrität für den Verlust der Vertraulichkeit oder Integrität von Daten (z. B. Informationen, Dateien) gelten, die von der betroffenen Komponente verwendet werden, bezieht sich diese Metrik auf den Verlust der Verfügbarkeit der betroffenen Komponente selbst. B. ein Netzwerkdienst (z. B. Web, Datenbank, E-Mail).

Um Ihre Frage zu beantworten: Hier ist nur Integrität relevant.

iainpb
2016-12-15 19:27:21 UTC
view on stackexchange narkive permalink

Ich würde sagen, dass dies ein klares Verfügbarkeitsproblem darstellt, da der Angreifer diese bestimmte Ressource vollständig entfernen und den Zugriff anderer Benutzer verhindern kann.

Ich würde auch sagen, dass es auch ein Integritätsproblem gibt. Der Rechner definiert eine niedrige Punktzahl für die Integrität als "Änderung von Daten ist möglich", was ich hier mit Sicherheit sagen würde.

So beantworten Sie Ihre Frage: Beides. Wie Sie punkten, hängt davon ab, wie wichtig diese Kommentare für Ihre Bewerbung sind.

Vielen Dank.Ich stimme Ihrer (und M'vys) Ansicht zu, dass es sich um ein Integritätsproblem handelt.Ich habe beschlossen, es als "Verfügbarkeitsauswirkung keine" zu bewerten, da der Zugriff immer verfügbar ist - aber möglicherweise auf geänderte Daten.Ich denke, es für beide zu bewerten wäre "Doppelzählung".
Um die "Doppelzählung" zu korrigieren, können Sie sie als Maximum beider Bewertungen zählen.
@domen Wenn ich nur ein Tief mache, bekomme ich 4,3 (CVSS: 3,0 / AV: N / AC: L / PR: L / UI: N / S: U / C: N / I: L / A: N), aber beide niedrigist 5,4 (CVSS: 3,0 / AV: N / AC: L / PR: L / UI: N / S: U / C: N / I: L / A: L)
Billy C.
2016-12-16 03:25:13 UTC
view on stackexchange narkive permalink

INTEGRITY

Nach dem Löschen bestätigt der resultierende Datensatz, dass kein solcher Kommentar jemals hinterlassen wurde. Diese Behauptung ist falsch.

Die Integrität des Datensatzes ist fraglich.Wir wissen nicht, dass es falsch ist, es sei denn, wir wissen, dass dieser Exploit dagegen begangen wurde.Je nachdem, welche Aufzeichnungen darin aufbewahrt werden, kann es schwierig sein, dies zu beweisen.
Sie haben ein hypothetisches Szenario eingerichtet, in dem die Löschung * erfolgt * ist.Ihre Aussage "Nach dem Löschen ... die Integrität ist in Frage" ist also nicht so genau, wie sie sein sollte.Siehe meine vorgeschlagene Bearbeitung.
sleblanc
2016-12-16 04:13:56 UTC
view on stackexchange narkive permalink

Es hängt davon ab, ob in Ihrem Dienst umfangreiche Sicherungsverfahren vorhanden sind. Wenn Ihre Sicherungsverfahren Fehler und Benutzerfehler berücksichtigen, die zu Datenverlust führen können, und der Benutzer eine Anforderung zur Wiederherstellung dieser Daten sendet oder Sie die Sicherheitsanfälligkeit entdecken und behaupten können, dass alle nicht ordnungsgemäß gelöschten Kommentare weiterhin verfügbar sind In den Sicherungen könnte argumentiert werden, dass es sich um ein Problem der Verfügbarkeit handelt, da die Daten einfach vorübergehend nicht verfügbar sind, bis ein DBA sie wiederherstellt. Nicht viel anders, als beispielsweise alle Kommentare versehentlich privat zu machen.

Nur wenn die Datensätze dauerhaft verloren gehen, wird dies zu einem einfachen Problem der Datenintegrität.

Darüber hinaus kann es zu Problemen mit der Vertraulichkeit kommen, wenn ein Angreifer Kommentare löscht, die er sonst nicht sehen darf, da einige Metadaten aus der (vorherigen) Existenz des Kommentars abgeleitet werden können, basierend auf Beispiel für die Sequenznummer eines solchen Kommentars. Sie können beispielsweise auf Aktivitäts- oder Inaktivitätsperioden schließen, auf die Anzahl der Kommentare, die ein Element erhält…

Interessante Aufnahme.Ich denke, es hat nächtliche Schnappschüsse, daher wird ein Kommentar gesichert, wenn er über Nacht existiert.Es gibt jedoch keinen Prozess für einen Benutzer, um eine Wiederherstellung von der Sicherung anzufordern, und der Aufwand wäre unverhältnismäßig.
Ralph Bolton
2016-12-16 21:39:09 UTC
view on stackexchange narkive permalink

Ich bin mit CVSS nicht vertraut, aber als Systemadministrator würde ich Ihr Problem als Integritätsproblem betrachten - das heißt, ein Teil des Systems kann einen anderen Teil davon fälschlicherweise beeinflussen. In Ihrem Fall kann Benutzer B die Kommentare von Benutzer A löschen.

Es ist unwahrscheinlich, dass ein Systemadministrator dieses Problem ohne einige App-Änderungen lösen kann, aber man könnte sich ein ähnliches Problem bei (sagen wir) a vorstellen Netzwerklaufwerk auf einem Arbeitsserver. Benutzer A speichert ein wichtiges Dokument, aber Benutzer B löscht es (und schafft es nie zu nächtlichen Sicherungen). Dies würde als Integritätsproblem behandelt, und wir würden einen Weg finden, die Benutzer so zu trennen, dass Benutzer A in einen Bereich lesen / schreiben kann, B jedoch nur aus diesem Bereich lesen kann. Wir würden es nicht als "Verfügbarkeit" bezeichnen, da das Netzwerklaufwerk (wie angekündigt) durchgehend funktioniert.

Dies wirft auch die Frage nach "wie angekündigt" auf. Mein Beispiel für eine Netzwerkfreigabe enthält einige implizite "Nutzungsbedingungen" (ich sage implizit, weil ich nicht sicher bin, ob jemand sie aufschreibt), ebenso wie Ihre Web-App. Obwohl es unwahrscheinlich ist, dass viele Web-Apps, mit denen ein Benutzer den Inhalt eines anderen Benutzers löschen kann, als äußerst nützlich angesehen werden, könnten Sie argumentieren, dass dies so sein soll und dass Sie eine zusätzliche Softwareschicht benötigen, um den Inhalt des Benutzers zu trennen. Dies ist eine etwas umstrittene Semantik, aber es kann hilfreich sein, (zumindest meine Wahrnehmung) von "Verfügbarkeit" gegenüber "Integrität" zu verstehen.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...