Skip to main content
Owainnorth
Inspiring
June 6, 2011
Question

Stop App snooping through Session scope

  • June 6, 2011
  • 2 replies
  • 2040 views

Right, haven't had to think about this too much before as I've always been working on projects on our own servers, but I'm now working on a project which will be hosted on a shared server. Irritatingly this brings me back to investigating Application scope snooping, and trying to find a way around it.

And no don't even bother saying about a Multiserver install, I know that's for an ideal world but it's not the case here.

Generally, I'd store my database connection details in the App scope, but obviously they can be read by other users on the box. I could wrap it up in a class, but even that can be executed by another app.

I did, however, have a thought - what they *cannot* do is read my actual Application.cfc file. So how about I do something like this:

<onAppStart>

  <cfset variables.secretkey =  '94yhf934h9p3v' />

  <cfset application.database.secretpassword = encrypt('mypassword', variables.secretkey , 'DESEDE') />

</onAppStart>

That way, the password is in the app scope (ie one place) but encrypted if anyone tries to look at it. I then do:

<onSessionStart>

  <cfset session.database.secretpassword = decrypt(application.database.secretpassword , variables.secretkey, 'DESEDE') />

</onSessionStart>

Then in my code just reference session.database.secretpassword rather than the application-level version. That way nothing is visible in the Application scope, as it's all in the Session scope which other users cannot traverse. I know memory-wise it's not as efficient, but if it's the difference between giving away my database credentials and not, then I'm not overly fussed.

Any issues anyone can see with that? Anything obvious I've missed? Any ways of improving it?

Damn, I am ALL OVER these forums today.

Cheers people

O.

This topic has been closed for replies.

2 replies

Inspiring
June 20, 2011

If the service provider will allow for encrypting files with the Cold Fusion cfencode utility, that would be even better. I do that for my sensitive apps: omit the username and password from the Cold Fusion datasource, create a .cfm file with variables that store the values for username and password, encrypt that file with cfencode and include the encrypted file within application.cfm (or cfc), and pass them in every cfquery.

Owainnorth
Inspiring
June 20, 2011

Incidentally, I was reading up on that very idea just last night

Inspiring
June 6, 2011

It doesn't take much to sniff the session scopes of a given application, I'm afraid.

And - as you say - it's easy for code in one application to access the application scope of another application.

If you have stuff that needs to be secured: don't use shared hosting.

--

Adam

Owainnorth
Inspiring
June 6, 2011
It doesn't take much to sniff the session scopes of a given application, I'm afraid.

What's involved in doing that? Unfortunately shared hosting is simply the only option when CF Enterprise costs £5k. It's not like it needs to be PCI compliant, I just don't want any old muppet being able to see the database credentials with a single line of code.

Inspiring
June 6, 2011

Depends on the shared hosting environment - I think that most of them don't allow

access to objects like the SessionTracker and ApplicationScopeTracker.

Do a Google search on "coldfusion.runtime tracker" and you'll get most of the info.

-reed