introduced numbering for classification and added 3.8 #1

Merged
christian.tramnitz merged 2 commits from ctr-policy-suggestion-01 into master 2 months ago

make clear that accessing public information is not considered a vulnerability

make clear that accessing public information is not considered a vulnerability
christian.tramnitz added 1 commit 2 months ago
7f1b4d6273 introduced numbering for classification and added 3.8
sven.seeberg reviewed 2 months ago
sven.seeberg left a comment
Owner

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

Danke. Ich würde den Punkt mit einem existierenden zusammenfürhen. Aber das ist Geschmackssache.
policy.txt Outdated
We will consider a vulnerability report most likely as relevant if it

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.

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.
Poster
Owner

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

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

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

Aktuell ist das plain text, ganz ohne Markdown ;-)
christian.tramnitz marked this conversation as resolved
policy.txt Outdated
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.

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.`
Poster
Owner

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.

"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".
Poster
Owner

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.
Poster
Owner

@sven.seeberg passt es so?

@sven.seeberg passt es so?
christian.tramnitz added 1 commit 2 months ago

Danke, ja. Finde ich gut.

Danke, ja. Finde ich gut.
sven.seeberg approved these changes 2 months ago
christian.tramnitz merged commit 5ee619229e into master 2 months ago
christian.tramnitz deleted branch ctr-policy-suggestion-01 2 months ago

Reviewers

sven.seeberg approved these changes 2 months ago
The pull request has been merged as 5ee619229e.
Sign in to join this conversation.
No reviewers
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: NB-Public/security-hall-of-fame#1
Loading…
There is no content yet.