introduced numbering for classification and added 3.8 #1
31
policy.txt
|
|
@ -16,24 +16,25 @@ production systems at risk.
|
|||
|
||||
3. Classification of Vulnerabilities
|
||||
|
||||
We will consider a vulnerability report most likely as relevant if it
|
||||
A) We will consider a vulnerability report most likely as relevant if it
|
||||
|
christian.tramnitz marked this conversation as resolved
Outdated
|
||||
reports one of the following problems:
|
||||
- The vulnerability can be used to directly access non-public
|
||||
information that either reveals further security relevant problems or
|
||||
contains user data, credentials, or sensitive data in general.
|
||||
- The vulnerability can be used to disrupt the orderly operation of a
|
||||
service (Denial of Service).
|
||||
- The vulnerability can be used to manipulate data within the service.
|
||||
- XSS, CSRF, RCE, authentication/authorization bypass, SQL inections,
|
||||
etc are considered relevant.
|
||||
1. The vulnerability can be used to directly access non-public
|
||||
information that either reveals further security relevant problems or
|
||||
contains user data, credentials, or sensitive data in general.
|
||||
2. The vulnerability can be used to disrupt the orderly operation of a
|
||||
service (Denial of Service).
|
||||
3. The vulnerability can be used to manipulate data within the service.
|
||||
4. XSS, CSRF, RCE, authentication/authorization bypass, SQL inections,
|
||||
etc are considered relevant.
|
||||
|
||||
We will consider a vulnerability report most likely as NOT relevant if
|
||||
B) We will consider a vulnerability report most likely as NOT relevant if
|
||||
it reports one of the following problems:
|
||||
- Missing security features, for example HTTP headers, if they are not
|
||||
actually preventing a vulnerability.
|
||||
- Publicly accessible version strings of used software.
|
||||
- Security vulnerablities that can only be used within the scope of the
|
||||
used account.
|
||||
1. Missing security features, for example HTTP headers, if they are not
|
||||
actually preventing a vulnerability.
|
||||
2. Publicly accessible information such as version strings of used
|
||||
sven.seeberg
commented
Ich würde den Punkt 8 ggf hier dazu packen: 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
Grundsätzlich habe ich kein Problem es woanders unterzubringen, aber ich glaube "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
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.
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
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
@sven.seeberg passt es so? @sven.seeberg passt es so?
|
||||
software and previously publicly known information in general.
|
||||
3. Security vulnerablities that can only be used within the scope of the
|
||||
used account.
|
||||
|
||||
4. Reporting Vulnerabilities
|
||||
|
||||
|
|
|
|||
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.
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 ;-)