Stop App snooping through Session scope

[Owainnorth]

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.

[Adam Cameron.]

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]

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.

[Reed_Powell-ttnmOb]

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

[Owainnorth]

Ah, we definitely do the ol' "Disable access to internal CF components", so hopefully that'll cover that one off.

I'll have a look tomorrow, off to Docklands to shift some servers. Thanks for the inputs so far.

[Adam Cameron.]

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.

Someone's already pointed you at what to search for regarding the SessionTracker stuff, so I'll leave that.  But the shared hosting thing.  I don't get why people use (or even offer) shared hosting any more, given CF licensing is done per physical CPU, so one can have any number of virtual servers on a given box on the same licence.

--

Adam

[Owainnorth]

Adam Cameron. wrote: I don't get why people use (or even offer) shared hosting any more, given CF licensing is done per physical CPU, so one can have any number of virtual servers on a given box on the same licence.

But only on Enterprise Edition, which is nearly £5,000 as opposed to a £100-a-year shared hosting account. Seems pretty cut and dried to me? Why would you not offer shared hosting? There's no way you could run your own CF server and instance for £100 a year.

[Adam Cameron.]

Sorry, we're talking @ crossed-purposes.

What I mean is why an ISP would offer shared hosting instead of hosted VPSes.

That said, they'd still need to foot the bill for enterprise, and if they only had a few CF clients, it would might not be worth the £3k price difference.

--

Adam

[Owainnorth]

What I mean is why an ISP would offer shared hosting instead of hosted VPSes.

Well, working for an ISP, let me tell you

Maintainability and resource. One standalone machine with 4GB of RAM and a quad-core CPU can happily run 500 CF websites as a shared server setup. There's simply no way that machine could run 500 VPS servers, all with their individual memory, CPU and disk overheads from both CF and the OS.

You also would need to do 500 CF installations. Yes, you can deploy from archives or whatever but it's still a significant time and effort. Once done, you have 500 different CF installations you have to patch when Adobe release a hotfix or a new version. You have 500 lots of Windows Updates to do. 500 backups to configure to 500 iSCSI drives.

And all for £50 a year per customer? Not a chance. That's the very nature of shared hosting; it's quite incredible value when you consider what (can) be included. I know many hosts don't, but we run ColdFusion Enterprise with sandbox security on SAS-based 64-bit servers, and all for £50 a year upwards. When you look into the costs of doing it yourself, it's a simple no-brainer.

Incidentally for our own benefit we are now splitting machines to an extent - each physical server now runs VMware ESXi, onto which we install four or five virtual machines, each running Windows and ColdFusion. So to a degree we're splitting them up, but that's more for our own benefit - if a customer brings down a server, it affects only a quarter of the customers it would have. If we need to reboot a box for updates, the same. Also virtual machines are far quicker to reboot, another benefit for us.

But as for running a VPS per customer on shared hosting - forget it. Never going to happen

[Adam Cameron.]

Yeah fair enough.  I thought, though, that VPS management software had moved on a bit from the "lots and lots of stand-alone images, each of which have discrete resources", to systems that emulated stand-alone environments whilst sharing a single base OS install (and other application installs too), and the RAM - if not the disk - was allocated from a shared pool rather than actually needing to have - for example - each VM having its own 4GB.  But anyway, it's been a while since I needed to even think about that sort of thing, and it's never been something I've had any more than a superficial interest in, so I bow to your likely superior knowledge on the topic.

Also... you'd be doing something wrong if you needed to do 500 (your example) CF installs.  Wouldn't you just do one image and reuse it?  And the patch management can be centralised too.  And (another thing ~!) you'd be backing up the the VM images (or the diffs thereof), not treating each one as running on a "real" drive, surely?

But, anyway, yes, it's more hassle that just setting up one shared server.  And for £50pa, the client is getting what they pay for, I guess.  But that's fine for a lot of people.

--

Adam

[Owainnorth]

Wouldn't you just do one image and reuse it?

Yes, but even rolling out from an archive takes time.

you'd be backing up the the VM images (or the diffs thereof), not treating each one as running on a "real" drive, surely?

Even so, that's still 500 backups of a Windows install as opposed to one.

And the patch management can be centralised too.

Again it can, but it's not how we work. We have 24 hour monitors checking CF is running and alerting a member of stuff if it's not. Again, we'd have to set that up on every single server, and make sure they were all suspended during patch installs.

We also do Windows Updates manually to avoid random hangs and issues, so Automatic Updates are very much disabled.

Yes if we were a budget shedhost kinda company we might do things differently, but there will always be a need for Shared Hosting.

[Owainnorth]

And for posterity, I've looked into and had a play with the SessionTracker and ApplicationTracker, and yes they do both require access to Internal ColdFusion Components as expected.

Therefore as long as the host has this access disabled (as we do) I see no problem storing the database credentials encrypted in the App scope and plain in the Session scope.

I cannot see any more secure way than that, but am happy to be corrected if anyone has any further thoughts.

[mkane1]

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]

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