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 |
m |
||
| Line 10: | Line 10: | ||
:: To sum up, I agree with the main article's point that only Referer headers could exploit the XSS scenario, but I think it is next to impossible to implement the Referer exploit. | :: To sum up, I agree with the main article's point that only Referer headers could exploit the XSS scenario, but I think it is next to impossible to implement the Referer exploit. | ||
| − | :: Vulnerabilities not relying on echoing indirect input back could still be exploited: a SQL injection could be performed by a foreign origin's javascript through request parameters and headers because XHR requests will be sent regardless of Same Origin Policy's preventing reading their output. ( | + | :: Vulnerabilities not relying on echoing indirect input back could still be exploited: a SQL injection could be performed by a foreign origin's javascript through request parameters and headers because XHR requests will be sent regardless of Same Origin Policy's preventing reading their output. ([https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Simple_requests Simple requests in modern browsers] seem to be allowed to manipulate 4 headers Accept, Accept-Language, Content-Language, Content-Type without requiring the javascript engine to send a pre-flight OPTIONS request. Also, a promiscuous CORS configuration could allow POST queries with any custom header as long as the OPTIONS pre-flight request receives a satisfying response). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 12:49, 20 October 2016 (CDT) |
Revision as of 17:51, 20 October 2016
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 only Referer headers can act as tainted input in XSS scenario. But (a) I doubt it is possible to craft a malicious path hosting the link to a site with the vulnerability and (b) in creating a stored XSS off a page on the attacker site with a crafted javascript, sending malicious values in any header but Referer appears possible (Same Origin Policy will prevent from reading the response but not from sending the request). --Eelgheez (talk) 20:34, 25 July 2016 (CDT)
- To sum up, I agree with the main article's point that only Referer headers could exploit the XSS scenario, but I think it is next to impossible to implement the Referer exploit.
- Vulnerabilities not relying on echoing indirect input back could still be exploited: a SQL injection could be performed by a foreign origin's javascript through request parameters and headers because XHR requests will be sent regardless of Same Origin Policy's preventing reading their output. (Simple requests in modern browsers seem to be allowed to manipulate 4 headers Accept, Accept-Language, Content-Language, Content-Type without requiring the javascript engine to send a pre-flight OPTIONS request. Also, a promiscuous CORS configuration could allow POST queries with any custom header as long as the OPTIONS pre-flight request receives a satisfying response). --Eelgheez (talk) 12:49, 20 October 2016 (CDT)
