I previously demonstrated how servlet filters can be used to view and modify HTTP requests that the client sends to the web server. This post will demonstrate how servlet filters can view and modify the HTTP responses that the web server sends back to the client. The servlet filter that will be used in this demonstration is one to mask social security numbers (SSNs) that appear in the response messages. Using servlet filters to perform sensitive data masking does not change the actual value of the data in the database, but it still protects the true values from being exposed through the PIA.
CLICK HERE to download the project.
Extract the zip and you should see the following files:
Take the folder named “custom” and place it in the following directory:
Take the folder named “DataMaskingFilter” and place it in the following directory:
Navigate to and open up the web.xml file. The web.xml file is located in the following directory:
Copy the text from the downloaded file named “webxml.txt” and paste the text into your web.xml file. Paste in the text so that it is the first <filter> to show up in the web.xml file. For my environment, I pasted the filter before the delivered “psfilter”.
Go to the web profile configuration page in the PIA and select the web profile that you are applying this servlet filter to. You will need to uncheck the checkbox for the “Compress Responses” option.
If you would like to keep the compression enabled on the web profile, then you can implement my response compression servlet filter here.
You will need to bounce the web server at this point.
After bouncing the web server, login to the PIA and navigate to a page that would normally expose an SSN value. In my Campus Solutions environment, I navigated to the Relationships page and saw the following:
Similarly, I got the following when I went to the Add/Update a Person Page:
I also tested the html output of a PS Query that returned SSNs.
The output of the query only showed masked SSNs.
The demonstrated functionality of this servlet filter is powerful, but it is not very robust. A somewhat easy way to improve the robustness would be to allow for conditionally masking data based on the user’s location and/or if the user has successfully performed 2FA for the session. As demonstrated, the functionality is either all or nothing based on whether the filter is enabled in the web.xml file. This provides for a rather poor user experience and can be problematic under certain circumstances. The servlet filter can be enhanced to reference custom session variables or custom cookie values to determine if a mask is needed.
An improvement in a different direction would be to provide a separate complementary functionality. The complementary functionality would provide the ability for the masked data to be interactive with custom injected client side code that can enable the following scenarios:
- Click To View – A user will click the masked value on a page to view the unmasked version. Under the hood, the click event will make a request to an iscript that will return the unmasked value to replace the masked value on the page.
- Click To Challenge To View – In this scenario, A user will click the masked value on a page, but will be challenged (2FA) to view the unmasked version. The click event will call an iscript that will return a modal window to be displayed for the user. The modal window will challenge the user for 2FA. Inputting a correct TOTP into the 2FA modal window will invoke an iscript to return the unmasked value to replace the masked value on the page.
Each of the “Click To” scenarios shall use AJAX to not lose the page’s originally loaded state. Also, the iscripts that get called on the click events will log important details of the transaction such as the emplid requesting the data, the menu/component/page names, and time.
The brilliant solution to enable the “Click To” functionality to expose the unmasked data/log the event was inspired by Grey Heller’s ERP firewall solution. I recently had the pleasure of chatting with one of the Grey Heller representatives. The representative had explained the importance of the ability to capture and log the details of the sensitive data exposure event. Enforcing the user to click a button to view a sensitive piece of data provides for an avenue to log the details of the specific transaction. If you do not enforce an event like a button click to view a sensitive piece of data , then you lose the desired ability to log at a granular level.
In the future, I plan to expand on the functionality demonstrated in this post by adding the additional functionality described above.