Decoding IBM WebShere Portlet URLs

 Portlet based web applications built with the IBM Web Experience Factory, previously known as the WebSphere Portlet Factory, produce long URL's containing GZIP'd and base64-encoded data. Viewing and tampering with the data transmitted between the client browser and backing application server is quintessential to application penetration testing.

The IBM WebSphere application server 'Rich-URL' scheme:

scheme://host:port/ctx/!ut/p(/codec/compressed-state)

URL FragmentDescription

/ctxThe portal context, i.e. /wps/portal

/!ut/pIdentifier that denotes the start of the first codec

codecEncoding algorithm and the version of the state document

compressed-stategzipped and base64 encoded proprietary binary xml serialized data

The WebSphere application server provides a servlet that decodes the state information. The request structure to decode state information is shown below. If you make a request with the first URL, you get redirected to the second URL which presents the decoded data.

scheme://host:port/wps/poc?uri=state:<uri>
scheme://host:port/wps/mycontenthandler?uri=state:<full_url>

Example:

Ideally you get an XML response from the application server, the above decodes into something like this:

I wrote a BurpSuite plugin that displays the decoded XML state in a new tab when the request is viewed (https://github.com/AccuvantLABS/burp-ibm-websphere-portlet-decoder). Upon clicking the tab, the plugin makes a request against the endpoint on the application server that decodes the URL (shown above), formats the resulting XML and displays it in the tab.

Note: The plugin does not cache or temporarily save the decoded state data, it is requested every time the decoded state tab is viewed.