New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Best practices to Secure your Website
fresher_06
Member
Hi All,
Just wanted to check that what all best practices which everybody uses to secure their websites,it can be even as simple as using the mysql_real_escape_string but if we get a check list so that we should not leave any loopholes atleast from our side and our knowledge.However if somebody really targets your website then at least you should have the basic defense.
So please share the common best practices which you generally use to secure your website.
***Please note even if it is about securing the server that would be an addon.
Thanks
Thanked by 1Nexus
Comments
Most important in my opinion - key everything up to date.
Seems like we get lots of these types of threads. It would be nice to compile something on the wiki.
Do not try to implement your own SQL injection filters or XSS filters. They will fail. Just run every POST and GET through the appropriate filters mysql_real_escape_string, htmlspecialchars, etc.
This. I like to use
apticron
which sends me an email twice per day for updates which aren't security related (those get installed automagically).-CloudFlare to at least deter the nasties.
-Use non-default port for SSH
-Use key-based authentication for SSH
-Disable root login
-Dome9 offers pretty cool remote firewall management
-Don't allow external connections to MySQL (unless you're using slave/master or some crazy HA setup)
I also run a lot of WordPress sites so something like InfiniteWP is invaluable for ensuring all of the installs are up to date.
Backups.
Don't use commonly abused software that attracts every hack in the world (Wordpress and PHP).
Install as much custom rolled software as you can create. Avoid common PHP admin tools and if you do use them, hide them and limit access heavily based on IP, SSL, etc.
Bunch of root kit admin tools out there. Scan regularly, just in case.
That is very bad advice and will much more likely lead to being hacked than using software that has been reviewed by hundreds of people.
@pubcrawler Let me know when you find an exploit for phpbb
@gsrdgrdghd,
Depends on who is developing and what their knowledge base is plus their best practices.
I've never had a compromised anything since we went Linux only 3-4 years back. That was until Wordpress entered our environment.
Peer review is great. Nerdware is great. Problem is, the most popular platforms and most popular software everyone clings to usually are the most compromised. More updates for security issues than features and bound to get worse.
So, if you want to secure your website you have a bunch of layers. The OS, the network, the middleware, the database and finally the public facing applications. Seek out specific docs for each of those layers with the term hardening.
I don't specialize in hacks and exploits. That phase of my life was way more than a decade ago.
Plenty of phpbb hacks out there or at least have been in the past from a cursory search.
How many severe security bugs have been found in the Wordpress core? Or in the Joomla core?
You do have a point, creating custom software / web apps are nice. But there is a fine line where people try to re-invent the wheel as in compared to just downloading a free GPL app.
Do you mean avoid tools like SQL Buddy / phpmyadmin? We would have to create our own for that? That's where I personally cross the line and say hell with it. (SQL Buddy is amazing btw)
@gsrdgrdghd,
The problem with Wordpress may or may not be the core. It tends to be loaded up with plugins and users add heaps more of them. Unsure of how many exploits are the core's fault.
Wordpress runs on top of PHP which has it's own security issues and is widely facing the internet ready to be exploited. And you have a database there in the mix too.
Wordpress has three main areas that need constant attention: Wordpress, PHP and MySQL (typically) and throw in the web server too = 4.
Folks need all that just to blather and collect occasional comments? That is a huge overhead just for that. Most folks would do better, scale better, etc. with custom rolled straightforward software they understand and is able to be understood.
I tend to isolate dynamic tools to a production server which pumps out static versions near-time. Pretty simple. Scales like crazy and I can worry about production servers users pound that are Nginx-only.
If dynamic stuff is needed, there is a server or VPS for that. Like conversations/comments on blog entries. If that gets dragged down, we lose that limited functionality due to attack, hack, etc. All the static, dead printed material still works
PHP front ends for MySQL are just keeping you from learning MySQL.
When something breaks and the CLI is needed for MySQL you are emergency forced to learn = bad idea. Some of them are nice though
Lots of data we muck with is too big to be dealt with usually with the PHP admin tools. They have their place, but I'd be might careful having them exposed in any way.
I mean rolling the common stuff, blogs, comments, etc.
Software for web is rather simple and should be super light weight to no weight. Less baggage ports to new machines well and doesn't require oddball forum support which often can lead to more problems than solutions (especially when in emergency mode).
There are benefits and drawbacks to using either a popular application like Wordpress and using something that you've written yourself.
With, for example, Wordpress, you get the benefit of many people reviewing the code and finding/fixing exploits. The drawback is that when there is an exploit, it's widely available extremely quickly, and you have a giant target on your back until you patch it. You're more likely to be exploited by some random person scanning using a botnet.
With a custom application, you don't have the benefit of multiple eyes on your code looking for exploits, but because it's not a popular widely used application, you're relatively safe from random people scanning websites for known exploits. It's security by obscurity, to a degree. However, you're probably more likely to be compromised by someone who has a problem with you and is targeting you specifically - someone you've banned or written a negative review about, or whatever.
Good summary of the situations @NickM.
Something like Wordpress has the plugin issue too. So you have exploit potential across many pieces and different authors who aren't going to be so quick to patch and update if at all.
Wordpress plugins are definitely a problem. As far as I know, they receive little if any review from the developers of Wordpress. In any case, standard best practices such as privilege separation, routine backups, and reviewing logs (among other things) can minimize the likelihood and impact of a security breach.
Guys .. can we more concentrate on the checklist something like @mount and @mrowen have provided above ..
+1 to ditching mysql_real_escape_string in favour of prepared statements. The introduction page for the mysql_* functions says it all:
This extension is not recommended for writing new code. Instead, either the mysqli or PDO_MySQL extension should be used.
No. Don't. You'll fuck up some bit of data at some point. Overzealous 'sanitation' is just as bad as no sanitation at all.
The question isn't just how to secure things, the question is how to secure things without negatively affecting other things, such as data integrity.
I was under the impression that @fresher_06 was working with an existing (non-PDO) project since he mentioned mysql_real_escape_string. I agree that for new projects only PDO should be used.
That can lead to very nasty things one wouldn't think of at first, e.g. people putting HTML code in their browser agent, thus triggering XSS bugs in statistics scripts or PMA.
That's a problem with your stats script / PMA then.
Host your website at hostbluff. So much secure with their guaranteed downtime
Guys . I have the below basic PHP login script which I am using on my main website for the customers to log in ..Please let me know the potential threats in this script and any kind of loophole,which you feel ..any kind of suggestion will be highly appreciable ..
Here is the script --
http://pastebin.com/TtbBmKvJ
MySQL Vulnerability if entering a negative number. Check for < 1 and error/exit out. If you want more detailed answers / help you can try posting your script here.
Also use this for correct email formatting server side.
Also this will help a ton.
As a Wordpress user for over 4 years, I recall little if not less than one or two issues affecting WP core. It's all been third party, contributed plugins or themes by questionable programmers.
A popular example of a vulnerable theme is the TimThumb.php vulnerability that was fixed by plugin developers but still lived for months in themes that had TimThumb.php hard coded in
And that is why you use htmlspecialchars when outputting. If some piece of third-party software fucks up, then get better third-party software.
A few issues I can see:
Positive point: you are correctly putting the MySQL field names in backticks - very few people do this
Got the below useful Tutorial -- seems interesting
http://www.openwall.com/articles/PHP-Users-Passwords
From what I was able to find, PHPass will attempt to use Bcrypt - which is an insecure algorithm in the sense that it will silently cut off passwords longer than 50 characters or so. It's better to use crypt() with a different algorithm such as SHA256/SHA512.
EDIT: With a few thousand rounds, of course.