Difference between revisions of "Talk:Benchmark"

From OWASP
Jump to: navigation, search
m (The meaning of the diagonal: follow the meaning of FPR and TPR instead of attributing misunderstood meanings)
(Request headers in XSS attacks: emphasize my doubt in Referer attacks)
Line 7: Line 7:
 
== Request headers in XSS attacks ==
 
== 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). --[[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. 
 +
:: 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 12: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)