Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Best practices to Secure your Website
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.

Best practices to Secure your Website

fresher_06fresher_06 Member
edited October 2012 in General

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
«13

Comments

  • jhjh Member

    Most important in my opinion - key everything up to date.

    Thanked by 1Nexus
  • Seems like we get lots of these types of threads. It would be nice to compile something on the wiki.

    Thanked by 1Nexus
  • 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.

    Thanked by 2Nexus bnmkl
  • @jhadley said: Most important in my opinion - key everything up to date.

    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.

    Thanked by 1Nexus
  • 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.

    Thanked by 1Nexus
    • Look at prepared statements for sql injection.
    • Don't use root as administrative user, only sudo.
    • Key based SSH login
    • Firewall what you don't need open.
    • Don't run your webserver as root
    • Don't run your webserver as root
    Thanked by 2Nexus ajit
  • @pubcrawler said: Install as much custom rolled software as you can create.

    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,

    @pubcrawler said: Install as much custom rolled software as you can create.>

    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.

    Thanked by 1Nexus
  • @pubcrawler Let me know when you find an exploit for phpbb :) >

    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.

    Thanked by 1Nexus
  • gsrdgrdghdgsrdgrdghd Member
    edited October 2012

    How many severe security bugs have been found in the Wordpress core? Or in the Joomla core?

    Thanked by 1Nexus
  • NexusNexus Member
    edited October 2012

    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.

    @pubcrawler said: Install as much custom rolled software as you can create. Avoid common PHP admin tools and if you do use them

    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 :)

    Thanked by 1Nexus
  • Do you mean avoid tools like SQL Buddy / phpmyadmin? >

    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).

    Thanked by 1Nexus
  • 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.

    Thanked by 1Nexus
  • 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.

    Thanked by 1Nexus
  • 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.

  • fresher_06fresher_06 Member
    edited October 2012

    Guys .. can we more concentrate on the checklist something like @mount and @mrowen have provided above ..

    Thanked by 1Nexus
  • ReeRee Member

    +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.

  • joepie91joepie91 Member, Patron Provider
    edited October 2012

    @gsrdgrdghd said: Just run every POST and GET through the appropriate filters mysql_real_escape_string, htmlspecialchars, etc.

    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.

    • Use parameterized queries for all database queries, no matter what it is. Don't use mysql_*.
    • Use htmlspecialchars() when outputting anything that is not supposed to be HTML. Do not use htmlspecialchars before inserting things into your database! The data in your database should always be the original untouched data. You really do not want to have to fix inconsistent data later because you made a mistake somewhere (if fixing the data is possible in the first place). Also don't use htmlentities(), it doesn't play nice with Unicode data.
    • Properly hash passwords using something like a few thousand rounds of SHA256/SHA512 (using the crypt() function). Do not use md5. Do not use SHA1. Do not use bcrypt (Blowfish), it has a character limit and can actually cause dangerous situations. Absolutely never ever ever ever EVER store any kind of password in plaintext.
    • Make wrong code look wrong. Name your variables along the lines of $uUsername and $sUsername to indicate whether a variable holds safe or unsafe data.
    • Back up your data with a script. Use something that can only push files and not pull or delete them, such as a push over HTTP or a write-only FTP account.
    • Use keypair authentication over SSH and disable password authentication entirely.
    • Never reuse passwords, anywhere. Use something like KeePass (or KeePassX) to store unique passwords for everything.
    • Probably the most important one of all: don't ignore advice of others just because you're used to doing it differently. Take their advice seriously and if there's a point to it, adapt. Pretty much every large fuck-up in web security I've seen so far has been because of someone not following the advice of someone else - usually they would either claim that "it's not that bad to do it like I do" or "there's no need for that".
  • gsrdgrdghdgsrdgrdghd Member
    edited October 2012

    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.

    @joepie91 said: Use htmlspecialchars() when outputting anything that is not supposed to be HTML. Do not use htmlspecialchars before inserting things into your database!

    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.

    Thanked by 1Nexus
  • @gsrdgrdghd said: 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.

    Thanked by 1Nexus
  • Host your website at hostbluff. So much secure with their guaranteed downtime =)

    Thanked by 2Nexus klikli
  • fresher_06fresher_06 Member
    edited October 2012

    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

    Thanked by 1Nexus
  • NexusNexus Member
    edited October 2012

    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

    Thanked by 1Nexus
  • joepie91joepie91 Member, Patron Provider

    @gsrdgrdghd said: 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.

    And that is why you use htmlspecialchars when outputting. If some piece of third-party software fucks up, then get better third-party software.

    Thanked by 1Nexus
  • joepie91joepie91 Member, Patron Provider
    edited October 2012

    @fresher_06 said: 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

    A few issues I can see:

    • You should be using PDO, not mysql_*
    • You're doing mysql_real_escape_string before hashing a password. You should be hashing the password that the user gave you, not an escaped version of it.
    • You should be using the crypt() function with a few thousand rounds of SHA256, not the hash() function.

    Positive point: you are correctly putting the MySQL field names in backticks - very few people do this :)

    Thanked by 1Nexus
  • Got the below useful Tutorial -- seems interesting

    http://www.openwall.com/articles/PHP-Users-Passwords

    Thanked by 1Nexus
  • joepie91joepie91 Member, Patron Provider
    edited October 2012

    @fresher_06 said: 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.

    Thanked by 1Nexus
Sign In or Register to comment.