• Post Reply Bookmark Topic Watch Topic
  • New Topic

JSF Request Scope security

 
David Sawyer
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm building an application that stores sensitive information (bank and other financial information). For security sake we are only keeping managed beans in request scope and sending and receiving data to=>from the database over an encrypted stream between each page of the application form. Is it safe to assume that no financial data will be saved to the session on the filesystem if the managed beans are all in request scope? If would like to feel confident that the only data outside of memory is in the database.

Thanks in advance for looking at this!
 
Tim Holloway
Bartender
Posts: 18417
60
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, David.

It sounds like your concept of security is actually backwards. Any time you expect sensitive data to come FROM a client, you're opening yourself up to exploits. And that includes pushing it out and getting it back via request-scope objects. It's a relatively trivial thing to substitute a counterfeit client that meddles with the data, and the encryption of the request/response streams matters not at all - other than keeping outsiders from doing likewise.

You should only send/receive sensitive data if it's absolutely essential and only the minimum amount of sensitive data needed for the task at hand. If you want to keep something secure, leave it behind on the server. You can maintain sensitive data in relative safety in session-scope objects because there's no direct client/data linkage to exploit. The sessionid is essentially a "random number" which only the server itself knows how to resolve into the session itself. If you're really paranoid - or need to save memory - you can purge sensitive objects from the session and retain only the minimal information needed to retrieve it if/when needed. And erase the objects before releasing them for garbage collection!
 
David Sawyer
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks very much for the reply.

I didn't explain myself very clearly. I was not referring to security concerns from a browser client => server perspective. What I am concerned about is PCI compliance which requires that no bank information is stored on the file system via the session. So a better way to phrase the question is:

1) If a jsf bean has a property "bankAccountNumber" and that bean is in request scope will the value bound to that property ever be stored on the file system via the session?

and

2) If a jsf bean has a property "bankAccountNumber" and that bean is in session scope will the value bound to that property ever be stored on the file system via the session?
 
Tim Holloway
Bartender
Posts: 18417
60
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK. As a former financials programmer in a fairly large bank myself, I'm happy to say that that was never a requirement for me.

Request objects are never persisted. They are constructed for the request, then discarded. If you want to really drive the security people nuts, however, mention that all the sensitive information in them WILL remain until the garbage collector breaks up the memory and gives it to the allocator to be overrwritten with new objects. Which is what Java security uses character arrays (which are eraseable) instead of strings (which are immutable). It won't be written to the filesystem, but it will remain in RAM. So if the RAM is paged out, it could end up on the swapfile disk. Believe it or not people actually DO try and exploit such things.

Session objects MAY persist, but if and how depends on the server you're using and the options that it's running under. And the load. And it may be files, databases, remote servers, or more arcane media. When in doubt, follow the advice I gave earlier.

Most of what keeps IT running is that IT people are fundamentally more honest than, say, bank executives. It's virtually impossible to effectively process data without granting a large amount of trust and/or expending more time and money than almost anyone short of agencies like the Federal Reserve can afford to grant.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!