Talk:Benchmark - Revision history

Eelgheez at 12:50, 14 June 2019

2019-06-14T12:50:51Z

Eelgheez at 20:35, 13 June 2019

2019-06-13T20:35:14Z

Eelgheez: the app would have to decode Referer before reflecting it in order to be abused

2019-06-13T20:34:51Z

the app would have to decode Referer before reflecting it in order to be abused

Eelgheez: +cache poisoning for XSS via unconventional headers

2018-11-14T16:40:42Z

+cache poisoning for XSS via unconventional headers

Eelgheez: Clean up and agree

2017-07-17T12:37:03Z

Clean up and agree

Eelgheez at 17:51, 20 October 2016

2016-10-20T17:51:35Z

Eelgheez at 17:49, 20 October 2016

2016-10-20T17:49:25Z

Eelgheez: /* Request headers in XSS attacks */ emphasize my doubt in Referer attacks

2016-10-20T17:49:12Z

‎Request headers in XSS attacks: emphasize my doubt in Referer attacks

Eelgheez: /* The meaning of the diagonal */ follow the meaning of FPR and TPR instead of attributing misunderstood meanings

2016-08-05T20:00:38Z

‎The meaning of the diagonal: follow the meaning of FPR and TPR instead of attributing misunderstood meanings

Eelgheez: /* Request headers in XSS attacks */ new section

2016-07-26T01:34:55Z

‎Request headers in XSS attacks: new section

← Older revision		Revision as of 12:50, 14 June 2019
Line 8:		Line 8:

	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)		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 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)	+	: 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)

@@ Line 7: / Line 7: @@
 == 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</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)
+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 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)

@@ Line 7: / Line 7: @@
 == 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 malicioously crafted URL replying to HTTP requests such as <code>GET /foo&lt;script&gt;alert(1)&lt;/script&gt;</code>.  On visiting such pages and clicking a link in them victim users' browsers will carry the crafted URL in their Referer header.  --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 07:37, 17 July 2017 (CDT)
+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</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/ . 10:40, 14 November 2018 (CST)
+: 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 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)

← Older revision		Revision as of 16:40, 14 November 2018
Line 8:		Line 8:

	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 malicioously crafted URL replying to HTTP requests such as <code>GET /foo<script>alert(1)</script></code>. On visiting such pages and clicking a link in them victim users' browsers will carry the crafted URL in their Referer header. --[[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 07:37, 17 July 2017 (CDT)		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 malicioously crafted URL replying to HTTP requests such as <code>GET /foo<script>alert(1)</script></code>. On visiting such pages and clicking a link in them victim users' browsers will carry the crafted URL in their Referer header. --[[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 07:37, 17 July 2017 (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/ . 10:40, 14 November 2018 (CST)

← Older revision		Revision as of 12:37, 17 July 2017
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 <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 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 malicioously crafted URL replying to HTTP requests such as <code>GET /foo<script>alert(1)</script></code>. On visiting such pages and clicking a link in them victim users' browsers will carry the crafted URL in their Referer header. --[[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 07:37, 17 July 2017 (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. ([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)

← Older revision		Revision as of 17:51, 20 October 2016
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. (~~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. ([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)

@@ 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)
 :: 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)

← Older revision		Revision as of 17:49, 20 October 2016
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)

@@ Line 1: / Line 1: @@
 == 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 last equation suggests a different interpretation of that area, "the noise rate in reporting suspects exceeds the silence rate about non-issues".
+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. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 20:24, 13 July 2016 (CDT)

← Older revision		Revision as of 01:34, 26 July 2016
Line 4:		Line 4:

	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)		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 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)