-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Struts Users,
I'm coming to the list hoping that anyone working in a TeaLeaf
implementation with Struts might shed some light on the problems with
a suggested solution vs. what TeaLeaf states in its documentation
should be an out of the box feature for marking and hiding/encrypting
sensitive data.
First, just to be complete, what is TeaLeaf?
> IBM TeaLeaf is, at its core, a HTTP dialog recorder. Developed at
> SAP in 1999, to reproduce problems reported by users, TeaLeaf
> builds on the idea that web sites could have a "black box" similar
> to an airplane cockpit voice recorder to understand what happened
> in any user visit. TeaLeaf records all the dynamically generated
> HTML at the network level and stores it for later searching and
> visual replay. While the technology was originally created to
> assist software developers the technology has since been adapted
> for use by business users, call centers and legal compliance groups
> within organizations.
That said, our TeaLeaf admin, intentionally or possibly due to
inexperience with the complete toolset [1], has come to us with a
request to alter the Struts tag library in support of filtering
sensitive data by "guaranteeing attribute order" in the form field on
the response.
The HTML spec, and Struts by implementation of the spec, places no
necessity on attribute order between the coded tag on the page and the
HTML response to the client.
This "guaranteed attribute order" would, in practice, allow developers
to "bookend" attributes with "sensitive data" that the TeaLeaf
"network tap" would capture and drop the data from the TeaLeaf record.
For example, in the JSP (pseudo code)
<html:text name="ssn" data-sensitive-start value="${bean.value}"
data-sensitive-end ...>
Produces an HTML element on the client
<input type="text" name="ssn" data-sensitive-start value=""
data-sensitive-end ...>
Produces a request payload
ssn=123456789
Produces an HTML response of
<input type="text" name="ssn data-sensitive-start value="123456789"
data-sensitive-end ...>
You'll note that the "bookending" and attribute order allows TeaLeaf,
in the understanding that the TeaLeaf admin/dev has posited, to regex
(or other TeaLeaf proprietary search feature) the value out of the
response (and request payload).
Personally, I think the TeaLeaf admin is pushing a lack of
understanding of the scope of TeaLeaf data filtering down to the
development teams and asking for framework change to lessen his burden.
If anyone should have TeaLeaf experience with sensitive data and
Struts, I would like to learn more as it relates to Struts, or
solutions in TeaLeaf that I might bring to the table in conversations
with the admin.
Regards,
Tim
[1] TeaLeaf states it supports sensitive data-filtering out of the box:
• Global data filtering: IBM Tealeaf solutions can globally destroy
sensitive data from the data stream to help prevent unauthorized users
from accessing and exploiting sensitive data. Data selected for
destruction is deleted in memory and not persisted in the Tealeaf
Server. For example, data such as user passwords, social security
numbers, account numbers or other data determined as sensitive that is
being passed as an attribute in the HTTP(S) request or appearing in
the HTTP(S) response page can be completely or partially destroyed.
• Encryption of sensitive data: IBM Tealeaf solutions possess a robust
set of rules to catch and encrypt sensitive data at the point of
capture. For example a credit card number or SSN can be encrypted
using the 3DES or AES algorithm.This helps to ensure that even if
these fields of data are preserved in the session, it will not be
stored in clear-text on the Tealeaf Server.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: Seeking grim and perilous adventure!
Comment: Get my public key at http://bit.ly/9UQHQv
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCgAGBQJTFLcjAAoJEHJJ3jMipSyCrs8QAJlCWVJ0f5BZ2glpiHJwurIN
VinzGhq7xQj9qaE4aASakIKknp8WgDJkQzeyJ3pF6/eu3QzS/qVMd2YS01ldc4J9
n9Wg7SbmBRDONSnv9uKwddtTSLz33QSQ836YW2plf6aphqbqTVMF0uXdqwi476eT
Kl1+WrZAnar1VOqVA/ouUVPikt4H6ONc2bsSXNXsfBEAK9Il9NtID6fXfEkuhbmo
JkULXkr4gMFERMzbob+K8BSjloV/074w9esuwVkbZPnz7tOdCKznSmBoPx83xdGH
T6g7GkyTdHaqvtA0LnoWjwuUNJ9eFOr37axksjW9I/a481YhN1KTrochQVtn9nnd
F9CPVOCzFC7JqJ1vcmbeSjAD4DVhwtGo5bAopISeCjgYn1ZUhvSOEgsrgknp5G0m
GColAvdtCRg8D4SD19jTvBfbRIklOG7yw+AH4reIjH6XcA4S/IEfA8FpfI1KH3lc
jndkUAQUsrBXW8Qk2wt+eBWha3iPHa9EtettDyhP+Ef3L5R6Hrqr18BL+5azbgeY
rvYUSdL9KFFMvx+HbxI6Ru+RzyHtbYHCEVrImYMv/TZaGzdD6kzXc+wfJ6X3yZ9D
czcrzBhVbi4O9hZj52KxlTvgXUdLl4XohluGZNdrGlSPnpT8AUyMRG2V8WMra+qE
Ie7O/lUxpYBsOhtYjm54
=azg9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
