Vulnerability notification: WPP-101 Webproxy Portlet caching

[Andrew Petro]

uPortal community,

This is a public disclosure of a security vulnerability, near the tail end of applying the uPortal Security Incident Response Plan to this issue.

All Webproxy Portlet 2 versions through 2.2.1 are affected . 2.2.2 includes a fix.

Recent uPortal versions ship with bugged Webproxy Portlet versions.

See apereo.github.io post for details.

Kind regards,

Andrew

[Andrew Petro]

Here's the version intended for posting to uportal-dev@:

Subject: Webproxy Portlet v2.2.2 removes bugged caching feature

uPortal developers,

Webproxy Portlet 2 versions prior to `2.2.2` had overzealous caching, with security vulnerability implications.

Version `2.2.2` addresses this issue by simply removing the caching feature.

Addressing the vulnerability quickly and simply in this way creates the opportunity to collaborate on implementing more nuanced caching, or to collaboratively realize that the feature is not yet needed.

Kind regards,

Andrew

[Andrew Petro]

The uPortal security incident response plan calls for

The uportal-dev@ list discusses the technical substance of the vulnerability and its fix, identifying opportunities to refactor the fix in subsequent releases now that it has more eyes on it and opportunities to improve the product and development practices to prevent or mitigate these issues in the future.

So, in the spirit of "blameless post-mortem":

• Is caching worth re-adding more carefully to the Web Proxy Portlet v2?
• How might we improve practices to reduce bad-caching security bugs in the future?

Kind regards,

Andrew

[Drew Wills]

My $.02…

On Dec 20, 2016, at 10:00 AM, Andrew Petro <andrew...@wisc.edu> wrote:

• Is caching worth re-adding more carefully to the Web Proxy Portlet v2?

I think it is;  I think there are a tremendous number of WPP use cases where all users see (exactly) the same content.  It’s a shame if that content must be fetched for each one.

• How might we improve practices to reduce bad-caching security bugs in the future?

Just brainstorming...

Subclass HttpUriRequest (Apache httpclient) and add cache key generation logic.  @Override all mutative methods so that any time the request changes in a meaningful way — URI, query string, headers, anything — those changes get captured and reflected in the key.

In this way, future interceptors can be written for adjusting these things in new ways, but all the final — fully evaluated — elements of the request contribute to the cache key.

drew