introduced numbering for classification and added 3.8 #1

christian.tramnitz · 2022-07-27T14:18:32+02:00

christian.tramnitz commented

2022-07-27 14:18:32 +02:00

make clear that accessing public information is not considered a vulnerability

christian.tramnitz added 1 commit 2022-07-27 14:18:33 +02:00

7f1b4d6273 introduced numbering for classification and added 3.8

make clear that accessing public information is not considered a vulnerability

Signed-off-by: Christian Tramnitz <christian.tramnitz@git@verdigado.com>

sven.seeberg reviewed 2022-07-27 14:39:53 +02:00

sven.seeberg left a comment

Danke. Ich würde den Punkt mit einem existierenden zusammenfürhen. Aber das ist Geschmackssache.

policy.txt Outdated

					
				@ -18,22 +18,24 @@ production systems at risk.

				We will consider a vulnerability report most likely as relevant if it

sven.seeberg commented

2022-07-27 14:38:06 +02:00

Wenn wir nummerieren, dann würde ich die Listen jweils noch benennen. A) und B). Und dann können wir jeweils wieder bei 1 Anfangen.

christian.tramnitz commented

2022-07-28 12:19:08 +02:00

Gern - wenn Du noch eine kreative Idee hast, wie das auch in markdown ordentlich aussieht noch besser. Mit der reinen Nummerierung klappte das nicht.

sven.seeberg commented

2022-07-28 12:20:08 +02:00

Aktuell ist das plain text, ganz ohne Markdown ;-)

christian.tramnitz marked this conversation as resolved

policy.txt Outdated

					
				@ -36,1 +32,3 @@

				  used account.

				    5. Missing security features, for example HTTP headers, if they are not

				       actually preventing a vulnerability.

				    6. Publicly accessible version strings of used software.

sven.seeberg commented

2022-07-27 14:39:13 +02:00

Ich würde den Punkt 8 ggf hier dazu packen: Any information that a software considers to be public, for example version strings or user names.

Ich würde den Punkt 8 ggf hier dazu packen: `Any information that a software considers to be public, for example version strings or user names.`

christian.tramnitz commented

2022-07-28 12:22:30 +02:00

Grundsätzlich habe ich kein Problem es woanders unterzubringen, aber ich glaube
"Publicly available information even when retrieved over usually non-public channels (i.e. APIs)." und "Any information that a software considers to be public, for example [...] or user names." haben nochmal andere Bedeutungen.

"Publicly available" heißt in dem Fall Informationen, die auch auf einem anderen Weg verfügbar sind (analog zu den meisten Klauseln in NDAs und ähnlichen Vertragsdokumenten).

"Any information that a software considers to be public" ist schon sehr weit gefasst. Insbesondere da ich hoffe, dass eine Software diese Entscheidung nicht trifft sondern eine Person oder Organisation, die diese Software nutzt.

Grundsätzlich habe ich kein Problem es woanders unterzubringen, aber ich glaube "Publicly available information even when retrieved over usually non-public channels (i.e. APIs)." und "Any information that a software considers to be public, for example [...] or user names." haben nochmal andere Bedeutungen. "Publicly available" heißt in dem Fall Informationen, die auch auf einem anderen Weg verfügbar sind (analog zu den meisten Klauseln in NDAs und ähnlichen Vertragsdokumenten). "Any information that a software considers to be public" ist schon sehr weit gefasst. Insbesondere da ich hoffe, dass eine Software diese Entscheidung nicht trifft sondern eine Person oder Organisation, die diese Software nutzt.

sven.seeberg commented

2022-07-28 12:38:14 +02:00

"Any information that a software considers to be public" ist schon sehr weit gefasst. Insbesondere da ich hoffe, dass eine Software diese Entscheidung nicht trifft sondern eine Person oder Organisation, die diese Software nutzt.

Der einleitende Satz sagt daher auch nur "most likely" nicht trifft keine absolute Aussage. Wir treffen ja auch keine Aussage darüber, ob wir gewisse Infos weg-konfigurieren, bevor wir eine Werkzeug öffentlich machen. Aber wenn man Informationen öffentlich lässt, die die Software als solche als öffentlich deklariert (z.B. Usernames in WP), dann kann man daran von außen zumindest grob einsortieren, ob es gewolltes oder ungewolltes Verhalten sein könnte.

"Publicly available information even when retrieved over usually non-public channels (i.e. APIs)."

Das Konzept der API finde ich an der Stelle verwirrend. Aus meiner Sicht ist eine API genauso öffentlich wie andere Front Ends. Für mich wäre nur ein durch Login geschützter Pfad "nicht öffentlich".

> "Any information that a software considers to be public" ist schon sehr weit gefasst. Insbesondere da ich hoffe, dass eine Software diese Entscheidung nicht trifft sondern eine Person oder Organisation, die diese Software nutzt. Der einleitende Satz sagt daher auch nur "most likely" nicht trifft keine absolute Aussage. Wir treffen ja auch keine Aussage darüber, ob wir gewisse Infos weg-konfigurieren, bevor wir eine Werkzeug öffentlich machen. Aber wenn man Informationen öffentlich lässt, die die Software als solche als öffentlich deklariert (z.B. Usernames in WP), dann kann man daran von außen zumindest grob einsortieren, ob es gewolltes oder ungewolltes Verhalten sein könnte. > "Publicly available information even when retrieved over usually non-public channels (i.e. APIs)." Das Konzept der API finde ich an der Stelle verwirrend. Aus meiner Sicht ist eine API genauso öffentlich wie andere Front Ends. Für mich wäre nur ein durch Login geschützter Pfad "nicht öffentlich".

christian.tramnitz commented

2022-07-28 18:11:21 +02:00

Den Teil mit der API können wir auch weglassen, war ja nur ein Beispiel. Es ging mir nur darum zu sagen, dass nur weil Du etwas über eine (public) API bekommst, heißt es noch nicht, dass es interne Informationen sind.

Aber gerade bei "usernames in WP" gehe ich nicht konform mit der Aussage, dass es deswegen ok ist, weil WP entschieden hat, dass das so ist, sondern weil wir (wissentlich) die Entscheidung getroffen haben (oder eben auch nicht) dass diese Information als öffentlich zu betrachten ist. Ansonsten kannst Du immer hingehen und auf die (ggf. default) Konfiguration einer Software verweisen wenn damit Zugriff möglich ist und ggf. sensitive Daten abfließen.

Den Teil mit der API können wir auch weglassen, war ja nur ein Beispiel. Es ging mir nur darum zu sagen, dass nur weil Du etwas über eine (public) API bekommst, heißt es noch nicht, dass es interne Informationen sind. Aber gerade bei "usernames in WP" gehe ich nicht konform mit der Aussage, dass es deswegen ok ist, weil WP entschieden hat, dass das so ist, sondern weil wir (wissentlich) die Entscheidung getroffen haben (oder eben auch nicht) dass diese Information als öffentlich zu betrachten ist. Ansonsten kannst Du immer hingehen und auf die (ggf. default) Konfiguration einer Software verweisen wenn damit Zugriff möglich ist und ggf. sensitive Daten abfließen.

christian.tramnitz commented

2022-07-29 13:12:07 +02:00

@sven.seeberg passt es so?