Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
4 added 256 characters in body
source | link

No, there are no web APIs that an attacker could employ to modify the HTTP version string in a reflected XSS attack.

I often come across similar flaws during penetration testing that are technically XSS, but not directly exploitable without manually altering the HTTP request. These bugs often get rejected by bug bounty programs. Another common example for this type of flaw is the Host header:

Host: vulnerable.example

You would often see that vulnerable.example is reflected in the response body without any filtering but you simply can't choose the value of the host header in a real-life XSS attack, so the vulnerability is most likelyturns out to be rather useless.

  Yet another example is user-agent XSSXSS via the user agent. UnlessSimilarly - unless it's a persistent XSS flaw, just printing back a modified user-agent string will most likely not be exploitable.

Beyond reflected XSS there are obviously other vulnerabilities to look out for. The response might be cached somewhere, enabling you to turn it into a persistent XSS flaw. Or the value might be stored unfiltered in some backend logging system.

No, there are no web APIs that an attacker could employ to modify the HTTP version string in a reflected XSS attack.

I often come across similar flaws during penetration testing that are technically XSS, but not directly exploitable without manually altering the HTTP request. These bugs often get rejected by bug bounty programs. Another common example for this type of flaw is the Host header:

Host: vulnerable.example

You would often see that vulnerable.example is reflected in the response body without any filtering but you simply can't choose the value of the host header in a real-life XSS attack, so the vulnerability is most likely useless.

  Yet another example is user-agent XSS. Unless it's a persistent XSS flaw, printing back a modified user-agent string will most likely not be exploitable.

No, there are no web APIs that an attacker could employ to modify the HTTP version string in a reflected XSS attack.

I often come across similar flaws during penetration testing that are technically XSS, but not directly exploitable without manually altering the HTTP request. These bugs often get rejected by bug bounty programs. Another common example for this type of flaw is the Host header:

Host: vulnerable.example

You would often see that vulnerable.example is reflected in the response body without any filtering but you simply can't choose the value of the host header in a real-life XSS attack, so the vulnerability turns out to be rather useless. Yet another example is XSS via the user agent. Similarly - unless it's a persistent XSS flaw, just printing back a modified user-agent string will most likely not be exploitable.

Beyond reflected XSS there are obviously other vulnerabilities to look out for. The response might be cached somewhere, enabling you to turn it into a persistent XSS flaw. Or the value might be stored unfiltered in some backend logging system.

3 added 297 characters in body
source | link

No, there are no web APIs that an attacker could employ to modify the HTTP version string in ana reflected XSS attack.

I often come across similar flaws during penetration testing that are technically XSS, but not directly exploitable without manually altering the HTTP request. These bugs often get rejected by bug bounty programs. Another common example for this type of flaw is the Host header:

Host: vulnerable.example

You would often see that vulnerable.example is reflected in the site's contentresponse body without any filtering but you simply can't choose the value of the host header in a realisticreal-life XSS attack, so the vulnerability is effectivelymost likely useless.

Yet another example is user-agent XSS. Unless it's a persistent XSS flaw, printing back a modified user-agent string will most likely not be exploitable.

No, there are no web APIs that an attacker could employ to modify the HTTP version string in an XSS attack.

I often come across similar flaws during penetration testing that are technically XSS but not directly exploitable without manually altering the HTTP request. These bugs often get rejected by bug bounty programs. Another common example for this type of flaw is the Host header:

Host: vulnerable.example

You often see that vulnerable.example is reflected in the site's content without any filtering but you simply can't choose the value of the host header in a realistic XSS attack, so the vulnerability is effectively useless.

No, there are no web APIs that an attacker could employ to modify the HTTP version string in a reflected XSS attack.

I often come across similar flaws during penetration testing that are technically XSS, but not directly exploitable without manually altering the HTTP request. These bugs often get rejected by bug bounty programs. Another common example for this type of flaw is the Host header:

Host: vulnerable.example

You would often see that vulnerable.example is reflected in the response body without any filtering but you simply can't choose the value of the host header in a real-life XSS attack, so the vulnerability is most likely useless.

Yet another example is user-agent XSS. Unless it's a persistent XSS flaw, printing back a modified user-agent string will most likely not be exploitable.

2 added 37 characters in body
source | link

No,No, there are no web APIs that an attacker could employ to changemodify the HTTP version valuestring in an XSS attack.

I often come across similar flaws during penetration teststesting that are technically XSS but not directly exploitable without manually altering the HTTP request. These bugs often get rejected as not exploitable by bug bounty programs.

A similar Another common example for this type of flaw is the hostHost header:

Host: vulnerable.example

The valueYou often see that vulnerable.example is reflected in the site's content without any filtering but you simply can't changechoose the value of the host header in ana realistic XSS attack, so the vulnerability is effectively useless.

No, there are no web APIs that an attacker could employ to change the HTTP version value in an XSS attack.

I often come across similar flaws during penetration tests that are technically XSS but not directly exploitable without manually altering the HTTP request. These often get rejected as not exploitable by bug bounty programs.

A similar common example is the host header:

Host: vulnerable.example

The value vulnerable.example is reflected in the site's content without any filtering but you can't change the value of the host header in an XSS attack.

No, there are no web APIs that an attacker could employ to modify the HTTP version string in an XSS attack.

I often come across similar flaws during penetration testing that are technically XSS but not directly exploitable without manually altering the HTTP request. These bugs often get rejected by bug bounty programs. Another common example for this type of flaw is the Host header:

Host: vulnerable.example

You often see that vulnerable.example is reflected in the site's content without any filtering but you simply can't choose the value of the host header in a realistic XSS attack, so the vulnerability is effectively useless.

1
source | link