CVE-2024-42353

WebOb provides objects for HTTP requests and responses. When WebOb normalizes the HTTP Location header to include the request hostname, it does so by parsing the URL that the user is to be redirected to with Python's urlparse, and joining it to the base URL. urlparse however treats a // at the start of a string as a URI without a scheme, and then treats the next part as the hostname. urljoin will then use that hostname from the second part as the hostname replacing the original one from the request. This vulnerability is patched in WebOb version 1.8.8.

WebOb provides objects for HTTP requests and responses. When WebOb normalizes the HTTP Location header to include the request hostname, it does so by parsing the URL that the user is to be redirected to with Python's urlparse, and joining it to the base URL. urlparse however treats a // at the start of a string as a URI without a scheme, and then treats the next part as the hostname. urljoin will then use that hostname from the second part as the hostname replacing the original one from the request. This vulnerability is patched in WebOb version 1.8.8.

Impact

When WebOb normalizes the HTTP Location header to include the request hostname, it does so by parsing the URL that the user is to be redirected to with Python's urlparse, and joining it to the base URL. urlparse however treats a // at the start of a string as a URI without a scheme, and then treats the next part as the hostname. urljoin will then use that hostname from the second part as the hostname replacing the original one from the request.

>>> parse.urlparse("//example.com/test/path")
ParseResult(scheme='', netloc='example.com', path='/test/path', params='', query='', fragment='')

WebOb uses urljoin to take the request URI and joining the redirect location, so assuming the request URI is: https://example.org//example.com/some/path, and the URL to redirect to (for example by adding a slash automatically) is //example.com/some/path/ that gets turned by urljoin into:

>>> parse.urljoin("https://example.org//attacker.com/some/path", "//attacker.com/some/path/")
'https://attacker.com/some/path/'

Which redirects from example.org where we want the user to stay to attacker.com

Patches

This issue is patched in WebOb 1.8.8

Older versions of WebOb continue to be vulnerable to this issue, and should be avoided.

Workarounds

Any use of the Response class that includes a location can be rewritten to make sure to always pass a full URI that includes the hostname to redirect the user to.

Thanks

• Sara Gao

This issue was reported via the Pylons Project Security List

WebOb provides wrappers around the WSGI request environment, and an object to help create WSGI responses. The objects map much of the specified behavior of HTTP, including header parsing and accessors for other standard parts of the environment.

Security Fix(es):

WebOb provides objects for HTTP requests and responses. When WebOb normalizes the HTTP Location header to include the request hostname, it does so by parsing the URL that the user is to be redirected to with Python's urlparse, and joining it to the base URL. urlparse however treats a // at the start of a string as a URI without a scheme, and then treats the next part as the hostname. urljoin will then use that hostname from the second part as the hostname replacing the original one from the request. This vulnerability is patched in WebOb version 1.8.8.(CVE-2024-42353)

WebOb provides objects for HTTP requests and responses. When WebOb normalizes the HTTP Location header to include the request hostname, it does so by parsing the URL that the user is to be redirected to with Python's urlparse, and joining it to the base URL. urlparse however treats a // at the start of a string as a URI without a scheme, and then treats the next part as the hostname. urljoin will then use that hostname from the second part as the hostname replacing the original one from the request. This vulnerability is patched in WebOb version 1.8.8.

WebOb provides objects for HTTP requests and responses. When WebOb normalizes the HTTP Location header to include the request hostname, it does so by parsing the URL that the user is to be redirected to with Python's urlparse, and joining it to the base URL. urlparse however treats a // at the start of a string as a URI without a scheme, and then treats the next part as the hostname. urljoin will then use that hostname from the second part as the hostname replacing the original one from the request. This vulnerability is patched in WebOb version 1.8.8.

When WebOb normalizes the HTTP Location header to include the request hostname, it does so by parsing the URL that the user is to be redirected to with Python's urlparse, and joining it to the base URL. urlparse however treats a // at the start of a string as a URI without a scheme, and then treats the next part as the hostname. urljoin will then use that hostname from the second part as the hostname replacing the original one from the request.

These are all security issues fixed in the python-WebOb-doc-1.8.8-1.1 package on the GA media of openSUSE Tumbleweed.

This update for python-WebOb fixes the following issues:

• CVE-2024-42353: Fixed open redirect via WebOb's Response object in Location header (bsc#1229221)

This update for python-WebOb fixes the following issues:

• CVE-2024-42353: Fixed open redirect via WebOb's Response object in Location header (bsc#1229221)

This update for python-WebOb fixes the following issues:

• CVE-2024-42353: Fixed open redirect via WebOb's Response object in Location header (bsc#1229221)

It was discovered that WebOb incorrectly handled certain URLs. An attacker could possibly use this issue to control a redirect or forward to another URL.

It was discovered that WebOb incorrectly handled certain URLs. An attacker could possibly use this issue to control a redirect or forward to another URL. This issue was only addressed in Ubuntu 16.04 LTS and Ubuntu 18.04 LTS. (CVE-2024-42353)

Caleb Brown discovered that WebOb incorrectly handled certain URLs. An attacker could possibly use this issue to control a redirect or forward to another URL. (CVE-2026-44889)