This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Talk:Benchmark"
m |
|||
| (12 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== The meaning of the diagonal == | == The meaning of the diagonal == | ||
| − | I don't think it's fair to call the diagonal line in the FPR/TPR chart a "random guess" line. The FPR == TPR equation translates to FP/(FP+TN) == TP/(TP+FN), meaning FP*FN == TN*TP, or FP/TP == TN/FN. The FPR > TPR area below the line does not put the tool into a "worse than guessing" shame list. The | + | I don't think it's fair to call the diagonal line in the FPR/TPR chart a "random guess" line. The FPR == TPR equation translates to FP/(FP+TN) == TP/(TP+FN), meaning FP*FN == TN*TP, or FP/TP == TN/FN. The FPR > TPR area below the line does not put the tool into a "worse than guessing" shame list. The formulas suggests a different interpretation of that area, "the noise rate in reporting non-issues exceeds the sensitivity about real issues". |
| − | The "worse than guessing" interpretation seems to come from the following scenario. We have | + | The "worse than guessing" interpretation seems to come from the following scenario. We have ''n'' real and ''m'' fake vulnerabilities. For each of these vulnerabilities let the tool (or a monkey) decide if it is real. I guess this scenario ignores that the tool does not get the list of these vulnerabilities as its input. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 20:24, 13 July 2016 (CDT) |
| + | |||
| + | == Request headers in XSS attacks == | ||
| + | |||
| + | The Test Case Details tab says that out of all possible request headers only Referer can act as tainted input in the XSS scenario. Indeed, a malicious site can host a page at a maliciously crafted URL replying to HTTP requests such as <code>GET /foo%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1</code>. On visiting such pages and clicking a link in them victim users' browsers will carry the crafted URL in their Referer header. However, I think the HTTP verb requests (such as the above HTTP GET) to the original host will URL-encode paths and query strings regardless of what it or any other communication medium showed before visiting it. This makes the abuse of the Referer reflection conditional on the application's decoding the URL before reflecting it. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 15:34, 13 June 2019 (CDT) | ||
| + | : When the target site resides behind a caching server, the server's dropping request headers from its cache key and the application's reflecting unconventional request headers result in a cache poisoning vulnerability, https://blog.cloudflare.com/cache-poisoning-protection/ . This makes non-Referer headers attack vectors possible because attackers can poison the cache, then let victims receive the cached poisoned HTML contents. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 15:34, 13 June 2019 (CDT) | ||
Latest revision as of 12:50, 14 June 2019
The meaning of the diagonal
I don't think it's fair to call the diagonal line in the FPR/TPR chart a "random guess" line. The FPR == TPR equation translates to FP/(FP+TN) == TP/(TP+FN), meaning FP*FN == TN*TP, or FP/TP == TN/FN. The FPR > TPR area below the line does not put the tool into a "worse than guessing" shame list. The formulas suggests a different interpretation of that area, "the noise rate in reporting non-issues exceeds the sensitivity about real issues".
The "worse than guessing" interpretation seems to come from the following scenario. We have n real and m fake vulnerabilities. For each of these vulnerabilities let the tool (or a monkey) decide if it is real. I guess this scenario ignores that the tool does not get the list of these vulnerabilities as its input. --Eelgheez (talk) 20:24, 13 July 2016 (CDT)
Request headers in XSS attacks
The Test Case Details tab says that out of all possible request headers only Referer can act as tainted input in the XSS scenario. Indeed, a malicious site can host a page at a maliciously crafted URL replying to HTTP requests such as GET /foo%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1. On visiting such pages and clicking a link in them victim users' browsers will carry the crafted URL in their Referer header. However, I think the HTTP verb requests (such as the above HTTP GET) to the original host will URL-encode paths and query strings regardless of what it or any other communication medium showed before visiting it. This makes the abuse of the Referer reflection conditional on the application's decoding the URL before reflecting it. --Eelgheez (talk) 15:34, 13 June 2019 (CDT)
- When the target site resides behind a caching server, the server's dropping request headers from its cache key and the application's reflecting unconventional request headers result in a cache poisoning vulnerability, https://blog.cloudflare.com/cache-poisoning-protection/ . This makes non-Referer headers attack vectors possible because attackers can poison the cache, then let victims receive the cached poisoned HTML contents. --Eelgheez (talk) 15:34, 13 June 2019 (CDT)
