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"
(→Request headers in XSS attacks: emphasize my doubt in Referer attacks) |
m |
||
| Line 9: | Line 9: | ||
The Test Case Details tab says that only Referer headers can act as tainted input in XSS scenario. But <s>(a)</s> I doubt it is possible to craft a malicious path hosting the link to a site with the vulnerability <s>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).</s> --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 20:34, 25 July 2016 (CDT) | The Test Case Details tab says that only Referer headers can act as tainted input in XSS scenario. But <s>(a)</s> I doubt it is possible to craft a malicious path hosting the link to a site with the vulnerability <s>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).</s> --[[User:Eelgheez|Eelgheez]] ([[User talk: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. | :: 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. (CORS seems to allow manipulating 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) | :: 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. (CORS seems to allow manipulating 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:49, 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. (CORS seems to allow manipulating 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)
