A user with a valid saspfs_sessionid can access content as another user without authenticating if the original session is still active. In an EBI environment, the platform session that is associated with the saspfs_sessionid can remain valid until the user logs out of the SAS^® Information Delivery Portal. In a solutions environment, it is possible for the platform session to be valid for a longer period of time.

Custom applications that receive or pass single sign-on information must adhere to the following recommendations.

To prevent this from happening, modify any code that generates a URL that contains the session passing request parameters (commonly generated using the WebappContextParams class) to exclude the request parameters from the static URL. The session passing request parameters are:

    saspfs_sessionid (whose string constant is stored in 
     CommonKeys.PFS_SESSIONID) 
   saspfs_sessionrequest (whose string constant is stored in 
     CommonKeys.PFS_SESSIONREQUEST) 
   com.sas.bip.sessionid (an obsolete parameter still passed for 
     compatibility; no string constant is available) 

The goal is make sure that the session that is passing request parameters is not part of the URL that shows up in the Web browser address bar. This will eliminate the most likely scenario of someone accidentally using the wrong platform session; a URL copied from the address bar and mailed to someone else will not contain these request parameters.

One way to achieve this is to modify the code that currently generates the static URL so that it generates a URL to new code that can dynamically build the URL and POST the request parameters. If the WebappContextParams class is used, the new code can remove the session passing request parameters from the URL string generated by the WebappContextParams.getURL() method and set them as request attributes. The new code can then forward to a JSP that reads these attributes and sets them as form-hidden fields and immediately submits the form using POST. In addition, the sas.web.framework.jar file from the provided hot fix needs to be deployed into the Web applications that generate URLs.

Also, any Web application that is passed single sign-on information using the WebappContextParams / SAS services application approach should add the new UrlReplayBlocker filter to provide security so that an application transfer HTTP URL cannot be stolen and used inappropriately.

Modify the web.xml file for the Web application to include the UrlReplayBlocker filter and filter-mapping elements. The UrlReplayBlocker filter should be listed immediately after the CharacterEncodingFilter. If the CharacterEncodingFilter does not exist, the UrlReplayBlocker should be the first filter listed. In addition, deploy the sas.web.framework.jar file from the provided hot fix into the Web applications that contain the UrlReplayBlocker filter.

 <filter> 
    <filter-name>UrlReplayBlocker</filter-name>  
    <filter-class>com.sas.webapp.servlet.filters.UrlReplayBlockerFilter</filter-class> 
    <!-- uncomment to allow bip session id pass through filter if there 
    is no SessionContext map id parameter 'saspfs_sessionrequest' 
    <init-param> 
        <param-name>less-secure</param-name> 
        <param-value>true</param-value> 
    </init-param> 
    --> 
</filter> 

and

<filter-mapping> 
    <filter-name>UrlReplayBlocker</filter-name> 
    <url-pattern>/*</url-pattern> 
</filter-mapping> 

Select the Hot Fix tab in this note to access the hot fix for this issue.

Operating System and Release Information

A fix for this issue for SAS Web Report Viewer 3.1 is available at:

A fix for this issue for SAS Web Report Studio 3.1 is available at:

A fix for this issue for SAS Web Olap Viewer 3.1 is available at:

A fix for this issue for SAS Information Delivery Portal 9.1.3 SP3 is available at: