Decoding IBM WebShere Portlet URLs
Decoding IBM WebShere Portlet URLs
Decoding IBM WebShere Portlet URLs
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.