Forum OpenACS Development: Security breach in ad_returnredirect! Really?

Request notifications

Hi!

ad_returnredirect is capable of redirecting users to servers different that the current one. This is apparently considered a security flaw, as the company says that is currently conducting a security analysis of ]project-open[:

Open redirection vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. An attacker can construct a URL within the application which causes a redirection to an arbitrary external domain. This behavior can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting the correct domain with a valid SSL certificate (if SSL is used) lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain. The value of the return_url request parameter is used to perform an HTTP redirect.

My proposal: By default prohibit redirection to absolute URLs, unless a specific parameter allows such redirection. What do you think about including this in OpenACS 8.5?

Cheers!
Frank

Collapse
Posted by Gustaf Neumann on
The redirection to absolute URLs is disallowed by default since a while in OpenACS. One can use "-allow_complete_url" to enforce usage to trusted hosts.

see: http://openacs.org/api-doc/proc-view?proc=ad_returnredirect

Collapse
Posted by Frank Bergmann on
There is something going wrong with the check for external_url in my OpenACS 5.7:

util::external_url_p "http://www.google.com/"
=> 0

Frank

Collapse
Posted by Gustaf Neumann on
can it be, that ]po[ was bought in the meantime by google, and this url is therefore internal? :)

anyhow, in oacs-5-8, the test returns correctly =>1

-g

Collapse
2: Header Injection (response to 1)
Posted by Frank Bergmann on
Here is another security issues with ad_returnredirect: Header Injection

ad_returnredirect doesn't check the URL parameter for \n line breaks and so allows to modify the header of the response. Here is the explanation:

HTTP header injection vulnerabilities arise when user-supplied data is copied into a response header in an unsafe way. If an attacker can inject newline characters into the header, then they can inject new HTTP headers and also, by injecting an empty line, break out of the headers into the message body and write arbitrary content into the application's response. Various kinds of attack can be delivered via HTTP header injection vulnerabilities. Any attack that can be delivered via cross-site scripting can usually be delivered via header injection, because the attacker can construct a request which causes arbitrary JavaScript to appear within the response body. Further, it is sometimes possible to leverage header injection vulnerabilities to poison the cache of any proxy server via which users access the application. Here, an attacker sends a crafted request which results in a "split" response containing arbitrary content. If the proxy server can be manipulated to associate the injected response with another URL used within the application, then the attacker can perform a "stored" attack against this URL which will compromise other users who request that URL in future. The value of the return%5furl request parameter is copied into the Location response header.

You can test this behavior on any ]po[ page (for example: http://po40demo.project-open.net/intranet/, email=bbigboss@tigerpond.com, passwd=ben). Then enter the URL: /intranet/biz-object-tree-open-close?open%5fp=c&return%5furl=b5a54%0d%0aa882d&object%5fid=29137&page%5furl=default&user%5fid=624

The resulting HTTP response contains:

- b5a54
- a882d

The problem occurs because ad_returnredirect passes on the %0d and %0a characters to the response header. So sanitizing the return_url this way should be mostly harmless and be a security enhancement for OpenACS 5.8, isn't it?

Cheers!
Frank

Collapse
6: Re: Header Injection (response to 2)
Posted by Gustaf Neumann on
yes it is/was possible to inject strings to the header this way (slight more complicated than your description above). Actually naviserver/aolserver should sanitize this string in ns_returnredirect, by they don't do this currently. This potential attack is fixed in the oacs-5-8 branch.

many thanks for reporting!
-g

Collapse
7: Re: Header Injection (response to 6)
Posted by Gustaf Neumann on
actually, my reply was not fully correct: NaviServer sanitizes all header fields since September 2013 (first i thought, i've missed this case, but it is covered as well).

https://bitbucket.org/naviserver/naviserver/commits/def03a4dc7568ca27ea5ee0111d51930d8d65801

however, the "double-fix" in OpenACS fixes the ad_returnredirect case for older versions of NaviServer and AolServer as well.