Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Sitelock neccessary with Textpattern?
While pondering changing my webhost provider I wonder how useful a Sitelock account will be ?
I.e. even older versions of Textpattern (and php) by its philosophy seems to be quite immune against, e.g.:- accessing non-existent pages
- injections of many kinds
- harmful uploading or modifying files, images, webpages
- etc.
What do you think? Did you ever use Sitelock? What did you observe?
Thank you
Last edited by ms-spo (2023-11-11 16:51:51)
Offline
Re: Sitelock neccessary with Textpattern?
This is not a (kind of) service I’ve ever used, so I can’t report on Sitelock itself. In many years of using Textpattern, I’ve only ever had two clients who have reported being notified of vulnerabilities from bug bounty sites. Both are sites I inherited, i.e. originally made by other web designers, and both those sites also used a mix of Textpattern and custom code in tandem, which added further potential points of failure that were not solely Textpattern related. I resolved those vulnerabilities with a mix of the following:
- For non-existent pages, you can restrict what the server will show on erroneous pages.
- Organise your public website installation separately from other content on your server, i.e. not interleaved in each other. That way other data on your server can’t be stumbled across by people guessing urls. Likewise make sure any backups kept are stored in directories that are not publicly reachable.
- For injections and database vulnerabilities, the most common points of attacks are form inputs or url variables – places where user-supplied input is passed to the database. PHP provides methods for sanitising user input before it is passed to a database query and Textpattern already employs them to sanitise things like search input and pagination. If you wish, you can add own methods to further restrict what kinds of search requests will be accepted. If you have your own php scripts, or have written your own php plugin, you should check they use the relevant methods.
- Keep Textpattern up to date as the devs do fix actual vulnerabilities that come to light.
- To mitigate against cross-site scripting, you can add CORS headers and a Content Security Policy, CSP to restrict from where a browser can load scripts. That will get easier with the next version of Textpattern. Also check that any third-party scripts you are loading from your server are up to date in case they include a vulnerability.
- If you have found yourself the target of repeated DDOS (Distributed Denial of Service) attacks, you may get some respite by fronting your site with Cloudflare.
Most (all?) of the other txp vulnerabilities mentioned on the internet or reported via GitHub, presume an attacker already has access to the admin area. If you’re the only user, or you only have trusted admin users, this risk is very low, provided, of course, your password is not compromised.
How far you want to pursue all this also depends on how high you view the risk to be. Do you have sensitive data that shouldn’t be revealed? If so, consider whether that really need to be linked to Textpattern or could it be stored separately. Do you have lots of visitors, or otherwise a lot to lose? For most of my clients, the risk is mostly disruption to their site’s availability, and the bother of having to remove any injected page context. You can reduce that risk by taking regular (automated) backups of your data and files and storing multiple past backups (so that you don’t run the risk of your backup also being infected) on another server, storage service or your own computer. That way you have a quick way back to a recent past version of the site.
TXP Builders – finely-crafted code, design and txp
Offline
Re: Sitelock neccessary with Textpattern?
Thank you jakob, good advice again : )
Offline