Security

[Don E]

Hello everyone, I thought I would start a topic about security in regards to web development. 'So Called' made some interesting threads worth taking a look but in this thread I thought I'd ask some general questions in regards to making sure your website is secured... well.. at least for the most part. :)Basically, what is the number one concern when it comes to your websites' security? Is it the database? Of course it is how you process form information, but when it comes to 'hackers' etc, what are most likely their goals/objectives when trying to compromise your website? Yes I know it depends on the site of what their goal would be, but I'm asking in a more general/overall way.I remember years ago on mIRC there were and probably still are channels(chatrooms) that promoted things of the above, like "getting access to the .htaccess file" was one of them for example. They would get username and password lists from certain sites via htaccess file because of the HTTP authentication some sites used to log-in in users. Some site owns learned about this and do now form-based log-in's which we see almost everywhere now. With the HTTP authentication route some sites took for logging in users, there were and probably still are programs where you load a username/password combo word list and scan the site. I'm sure that over all security probably most likely has to do with your hosting company settings etc, but in regards to the developer, what are some required/suggested routes to go when it comes to designing/developing the site besides using good username/password for logging into your cPanel and database(s)? Appreciate it. Thanks.

[boen_robot]

SQL injection - despite all the red flags in almost every PHP tutorial and the manual - is still one of the most common types of attack attempts. It's not always successful, but it's the one everyone tries, mostly because it's very easy to detect if you're vulnerable - add an ' to every possible form field (trying them one by one)... does anything weird happen at any point? If yes, you're definitely vulnerable. If not... you could be vulnerable, although the stuff that an attacker could do is now more limited.The other stuff, as you said, depends on what the site is for, but mostly, on what you're using.If you're at any point allowing file upload, the most common type of attack is for attackers to upload a file that would be interpreted by the server in some way, which would in turn provide a gateway for something more malicious - it could be an .htaccess file, a PHP file, etc.If you're at any point sending emails, a common attack is header injection, used to trick your server into sending (spam) messages that the attacker wants you to send.If at any point you're accepting "fancy" text from users in any form (such as how this forum has ways to let you bold, underline, etc. content), XSS attacks - ones that try to trick your app to display raw HTML "script" elements - is the most common type of attack. The more complex stuff you allow users to do, the more potential stuff for attackers to target.BTW, it should be noted that even in .htpasswd files, passwords are encrypted... the problem is they're encrypted with MD5, for which now it is easy to brute force the original string. But if you somehow end up opening the door to this file, that's actually the bigger problem anyway.

[niche]

Great general question Don E. We back our database twice a day, compare critical files to the originals everyday, and only allow a-z , A-Z, 0-9, ., -, _, @, ? as user input. So far no problems, but I.m sure something will happen eventually. As we get more users, I'm sure we'll back-up more often and make more file comparisons. Everything else we leave to our host. EDIT: We'll consider making exceptions upon request. So far, we haven't had any. Also, data is verified with static tables when ever reasonable.

Edited June 1, 2012 by niche

[boen_robot]

and only allow a-z , 0-9, ., -, _, @, ? as user input.

Yeah, about that... this reminds me of another more general principle - Ideally, providing security should NOT come at the price of convenience or harmless power. But that's exactly what one is doing when going to extremes like that - security, yes, convenience, no.I mean, sure, people might email you with the problem if it's really important for them that your site works (like, if you were their bank or something), but generally, the majority of people would instead simply not do whatever it is they originally wanted to do. E.g. if posting a comment is too restrictive (what? I can't have any "<" because this might be "HTML tag start"? I don't even know what that means! I'm out of here!), people won't comment, if your contact form is too restrictive, they won't contact you, etc.

[niche]

I know. As we know better, we'll do better. In the meantime, we're fortunate that the type of work we do minimizes those issues. EDIT: What does the "middle ground" look like to you?

Edited June 1, 2012 by niche

[boen_robot]

In a word, the ideal middle ground is "sanitization", which basically means that you accept arbitrary data at all places, but always ensure that regardless of the context it's used in, it's escaped properly in order not to "leak".Sometimes, sanitization is not really possible, or is not feasible for one reason or another, in which case the best thing is to convert the input to something which can be sanitized (with the possible caveat of some data loss when people try to escape outside the boundaries), and sanitize that new format.

[Guest So Called]

I too like these subjects. As far as I'm concerned you have to keep yourself informed on security matters, and you have to think like a hacker and constantly review your own code and come up with ideas on how you could hack yourself. To some degree you're better off than hackers because you have access to your source code, so you can search your code for vulnerabilities. To some degree the hackers are better off than you because (1) there's more of them than you, and (2) there's bound to be many hackers who are more clever than you. IMO the #1 goal of any hacker is to gain the ability to execute server side code. If you can execute server side code you can upload a script with your own code. If you can do that you can write scripts to do anything you want. If a hacker can execute their own script on the server, they OWN the server. One thing about databases (MySQL), you should assume that if a hacker can execute a script on your site they will own your database too. ("All your database are belong to us! ) Why? Because there is one important bit of data that you cannot put in your database: the database username and password (and often, the database name and server path). You need that information before your script can connect to the database server. You could perhaps encrypt that data and decode it in your script, but if a hacker can execute code on your site he can read your scripts and he can reverse engineer them. There is only one means that is 100% guaranteed to protect your site, and it comes at a cost. You must backup your database offsite in a place where hackers will have no access. (I presume you can wipe your file structure and reinitialize the files with no problem.) The cost is that if you get hacked you will lose everything since your most recent backup. And finally, any important data in your database should be protected by one-way encryption, something that works well for username-password data, probably among the most important information on social sites like forums etc. (If you are processing financial data such as credit cards then that is way over my pay scale and I couldn't possibly address such complex issues.) So the #1 hacker goal is to be able to execute server side code on your site. Your #1 priority should be to prevent that.

[niche]

What's a simple code example of sanitizing arbitrary data?

[Ingolme]

It depends on the purpose of the data. If it's meant to be shown on an HTML page, use htmlspecialchars().If you're putting data into a database then use real_escape_string or prepared statements.

[Don E]

Interesting replies so far. Do you guys recommend using PHP's built in filtering and sanitation for processing input uploads etc?http://www.php.net/manual/en/book.filter.php

Edited June 2, 2012 by Don E

[boen_robot]

Funny you should ask that. Two days ago, a new tutorial on PHPMaster (an interesting, but young site for PHP articles, derived from the more popular Sitepoint) discusses that.The caveats section is an important one... it basically means to say "It's good, but may be allow stuff that may not be expected by your app further down the chain". This doesn't mean that any malicious data would go through - no. It means that it would allow exotic features of formats, which may behave weird when not supported by the app.For example, a "+" is a valid sign in an email address (when it appears before the "@"), but some SMTP servers fail to send messages to addresses that have it. Another example is host names, which can technically be not just domains, but could instead be intranet names or IP addresses, but unlike domain names, those depend on the location of the server, and can therefore have unexpected effect if the wrong computer uses them to connect to something.This brings me to another thing I forgot in all of the "ideally" stuff... sometimes, when you're aware of the limitations (such as the above cases), it's not enough to sanitize data, which is why "validation" is still a very important piece of the puzzle - if you know in advance that something will fail down the chain, even if sanitized (such as an email that has an intranet name after the "@", or an email field that's missing a "@" to begin with), it's best to forbid it, and just give error messages about it, like most sites do.

[davej]

I try to filter user input to allow only characters that are really necessary, and I use parameterization, and I limit the lengths of input fields, and I use a data access layer. They say cookies and session variables need to be encrypted so that is the next thing I need to learn how to do. Also I wonder if there are any vulnerabilities related to system configuration or guessable filenames.

[niche]

encrypted cookies and session variables. Didn't know they can be encrypted. Thanks davej.

[davej]

Well, SQL injection can be fed in through a cookie.

[birbal]

not only cookie but also any kind of user inputs in query is vulnerable for SQL injection. $_GET,$_POST even $_SERVER['HTTP_USER_AGENT']. encrypting session will not protect from sql injection. it will defend against revealing the data if session resources in shared host environment, one user is being compromised. When its in secure connection cookies are being encrypted and passed in server most safest way is to using prepared statement. escaping has issues with multi-byte charset.

Edited June 6, 2012 by birbal

[boen_robot]

most safest way is to using prepared statement. escaping has issues with multi-byte charset.

mysql_escape_string() has issues with that. Not mysql(i)_real_escape(), because these check the charset of the connection, and act accordingly.

[davej]

Well, I think encryption prevents anyone from easily modifying the data for any devious purpose. What about the topic of file security and system configuration? If a filename can be guessed anyone can download it, right?

[Guest So Called]

What about the topic of file security and system configuration? If a filename can be guessed anyone can download it, right?

Depends on what it is. If it's executable then not, like PHP. Here's a PHP script security tip, just to keep people from meddling where you don't want them meddling. If you have an index.php that loads other scripts... This is how my site works, everything goes through the index.php file. It calls (includes) whatever scripts it needs depending on the request. In the index file you have a statement define("SOMETHING", true). Doesn't really matter what the name is, or what you define it to. Then in every script that is an include script you have a check: if (!defined('SOMETHING')) exit; Then if somebody tries to call the include file directly from their browser it fails rather than executing in some odd or unpredictable context. AFAIK there is no way a hacker can define something and have it carry into the script unless the script got included from a legitimate script on your site. IOW it protects include scripts from being intentionally directly executed by a hacker. This works well on my site since every site visitor goes through one script first, index.php, which gives me a handy place to apply all the security I want directed at site accesses and at visitors. Edited June 7, 2012 by So Called

[niche]

I'm new to So Called's concept and define(). If I'm following you, you're saying I can use define() to authorize what can be included, required, etc. Right?

[Guest So Called]

Yeah Niche, I think it's a small risk that hackers will visit your include files and try to execute them to their advantage (and to your disadvantage) but IMO the method I described makes it totally impossible to execute an include script that wasn't called from your main script. But yeah, I cannot conceive of any way a PHP script could be called with something already defined, other than from another PHP script on your site. They would have to be able to upload their own script and define the constant before they can execute you include code. But if they can do that they already have you. I learned this concept from an open source project, where it was assumed that hackers already have your code, and assumed they would know the script file names (particularly the include file names) and that they would exploit your code if they could. This is just another way to slam the door in their faces, and to deny them any ability to execute your include script in a context independent from your main script. It's a layered security concept. We don't know if they can use our included scripts by executing them in an unintended context, but we can just deny them that ability and with that we strike off a whole category of hacks. ETA: All my include files on my site are protected by this method. Instead of my check terminating in exit; I have a line that echoes the shared hosting standard 404 response, that there is no such file, invalid URL. I will not hand hackers anything, even that their file could be found. Any time I can give potential hackers nothing, that's what I give them.

Edited June 7, 2012 by So Called

[Don E]

So Called, You made a very interesting point that crossed my mind before about people trying to run include files directly in their browser... Can you give us a quick example of your tip? Would appreciate it.

[Guest So Called]

Don I thought that was clear from my earlier post, but more explicitly: index.php:

define("SOMETHING", true);

all include files:

if (!defined("SOMETHING")) exit;

. Even better, access your website with a nonsense URL, then save the resultant source code to text. Then instead of exit; just echo the text that you captured from your shared hosting server for what it sends when a file was not found. It will drive the hackers nuts because they can't tell if it's the shared hosting service telling them the file can't be found, or if it's you lying to them pretending to be your shared hosting service telling them the file can't be found. One of my anti-hacker concepts: give the hackers nothing, or at least give them nothing when you have the choice or option.

[Guest So Called]

BTW it is an ancient concept that manifest constants are often named with all capital letters. Like from C: #define SOMETHING true; Google "manifest constants" for a description of this concept. The key concept is that once defined manifest constants cannot be redefined, which separates them from variables. Although I think even a variable could be used to embody this protection, but IMO a manifest constant -- define() -- is better.

[birbal]

If you want to prevent user from executing include files safest option will be putting it in outside of web root. which means user cant reach by any means to execute it but your php script can reach it and use it. same with other files if you dont want to expose your file openly to public you can set them outside web root. then let a php scipts to decide if it should show the file or not. if it it need to show the file let php pull the file and serve it.

Edited June 7, 2012 by birbal

[davej]

If you want to prevent user from executing include files safest option will be putting it in outside of web root. which means user cant reach by any means to execute it but your php script can reach it and use it.

THAT is something I want to experiment with. I came across an article several years ago that seemed to be written by someone who really didn't know what he was doing, but he had a detailed plan... http://ezinearticles.com/?E-Commerce---How-To-Prevent-Download-Theft&id=201853