Increasing Website Security

To be honest, I know absolutely nothing about website security other than coding Guestbooks in PHP is a bad idea because a malicious person could post and execute another script through it. That is the extent of my knowledge about cyber security and even that is probably faulty.

I would like to know what steps can be taken to increase my website's security. There isn't anything interactive about my website at the moment - I have so little visitors, and they've likely all left considering the domain expired and I'm waiting until it's released again to buy. However, I want to take all the steps necessary.

In addition, what are some good, secure forums? I would like to add a forum to my site in the future, and I don't want a forum that is easily hacked (the Cutenews thing really made me worry considering how widespread it is).

This is just extra at this point, but I would also like to know the forms in which a virus can come. I know they can be encoded or wrapped into Mp3s and MPEGs, but I don't know how they function or how this is possible. I've heard the stories about how simply viewing a folder with the corrupted folder can allow for remote control of a system. This kind of thing really freaks me out, and I want to be prepared and be able to recognize something like that if I see it.

Thanks to anyone who responds.

Oh, yeah, those incidents. He's just a white hat. Those CuteNews incidents died out after BassDrum.MP3 forced them to update their CuteNews to 1.4.6.

I'm assuming you're using PHP in this post. Otherwise, just correct me with whatever language you use. Most of these security tips apply to every language, though I'll only reference to functions/hashes/variables specifically as they'll pertain to PHP.

In my experience of securing my websites, its user input that edifies hackers. You should never trust your users with a form, because it can contain arbitrary code. One mistake many people make is gathering excess input from their users, which sort of benefits the attacker. If you, for example, make a username field, set a limit of characters on it. 32 Characters max for the username field is OK. Anymore characters than that should either result in an error, or you just collect the first 32 characters in it. It's not the most efficient way to security, but it is a start.

If you happen to be using PHP, your web host should always these php.ini settings set to off. It's rare to see them on, though: register_globals, allow_url_fopen, magic_quotes_gpc. You can Google up on why enabling those settings on php.ini is generally a bad idea. If your web host does have those settings set to on and the web server is Apache, you can create an .htaccess file disabling the. register_globals and magic_quotes_gpc should not be a problem at all, since I believe they will be removed once PHP 6 is released.

Filtering user input happens to be the most conventional method in securing your application. There are different ways that you can control what input is to be gathered when a user submits a form, and the $_POST hash is created. You can always filter input by using Regular Expressions, or PCRE (Google it if you have no clue) if you're very paranoid on the type of text that your form collects. If your form uses the select menus, you may want to have a conditional that checks if that option is valid (I personally have used an array for this. You can see my <a href="http://faltzer.net/stuff/styleswitcher/download.zip">styleswitcher example</a> for reference on that). Some common PHP functions to escape or strip input from a string: strip_tag(), addslashes(), htmlentities(). Reference on those functions can be found in the PHP manual. There are more functions on filtering data. You should look those up too when you get the chance.

Remember that you should also be worried about filtering $_GET requests as well. Speaking of $_GET, you should never allow confidential data such as passwords inside of the URL (index.php?password=passwordhere). If possible, everything should be collected by $_POST if you're using a form.

Oh, yeah, and I forgot to mention that you should also try to set a variable before usage, to prevent variable poisoning. Technically, that's what happened with CuteNews and how that security hole came into existence. There's still many more ways to protect your application, and filtering input is definitely a good way to do so.


I think Vee might know a bit better than me on this, but they've all pretty much worked with my sites for a long time. Hope this helps.

Well, since you asked, I'd use ASP.net to code things. I will keep your hints in mind, though, particularly that one about setting a limit on the number of characters. That seems easy enough to do. I'll have to look that up when making a guestbook. Thanks for responding. =]

I would also like to see what other people would have to say for this.

PunBB is the best forum software that I'm aware of.

There isn't anything interactive about my website at the moment

Click to expand...

Then unless you administrate its server, there's nothing to worry about.

I know they can be encoded or wrapped into Mp3s and MPEGs, but I don't know how they function or how this is possible.

Click to expand...

Um... it isn't. Well, anything can be embedded in anything else, but not executably.

Faltzer said:

Some common PHP functions to escape or strip input from a string: strip_tag(), addslashes(), htmlentities().

Click to expand...

htmlentities() is the only function of those that is useful for sanitization.

Database input should be escaped using mysql_real_escape_string(), and occasionally addcslashes() (for LIKE).

Chopping off an arbitrary number of characters is silly and not likely to stop much. If you don't escape output, this is a hopeful stopgap measure at best.


"Variable poisoning" is a problem that only exists because of the gaping security hole that is register_globals.


POST should only be used for form submissions that change something server-side. Do NOT use POST for every single form submission; it's a pain in the ass. Frankly, the best thing to do is to never leave the user on a POSTed page at all; redirect to a GET instead.


mysql_real_escape_string() is a complete joke and anyone who uses it is just begging for SQL injection.

This problem was definitively solved years ago, but it continues to pop up amongst PHP amateurs who learn everything they know from other PHP amateurs. If you have to do extra work for every single variable you stick into every single query, you are GOING to forget once, and then it was all for nothing. It's really pathetic.

Use prepared statements and you should never have problems with SQL injection. It creates secure code that is far more easily read and modified. You won't even have to validate that an id is an integer or whatever. Look into mysqli.

Eevee said:

Do NOT use POST for every single form submission

Click to expand...

Unless you want abominable URLs, use POST for every single form submission before redirecting to a GET.

Eevee said:

mysql_real_escape_string() is a complete joke and anyone who uses it is just begging for SQL injection.

Click to expand...

mysql_real_escape_string() works perfectly. Stop being deceptive. Problems only arise when sloppy, lazy coders screw their code up. mysql_real_escape_string() isn't at fault there.

Eevee said:

If you have to do extra work for every single variable you stick into every single query, you are GOING to forget once, and then it was all for nothing.

Click to expand...

For those sloppy, lazy coders, sure. Others read their code over, test it, and generally just don't make retarded mistakes. It's a simple habit to get into.

Eevee said:

Use prepared statements and you should never have problems with SQL injection.

Click to expand...

What do you have against app portability? mysqli is only supported by PHP 5+, which most Web servers have yet to upgrade to. Use prepared statements if you don't mind breaking your open scripts for half their audience.

Eevee said:

It creates secure code that is far more easily read

Click to expand...

Except it forces you to use ugly OOP...

Geneva said:

mysql_real_escape_string() works perfectly.

Click to expand...

Considering how many times the PHP people have rewritten their escaping routines, I’m personally not very confident of that.

Geneva said:

What do you have against app portability? mysqli is only supported by PHP 5+, which most Web servers have yet to upgrade to.

Click to expand...

If you’re worried about security then why use PHP 4? A desire for portability is understandable, but at some point you have to let go.

Geneva said:

htmlentities() is the only function of those that is useful for sanitization.

Click to expand...

And no need for that if you use UTF8: htmlspecialchars() will be sufficient.

Geneva said:

Database input should be escaped using mysql_real_escape_string()

Click to expand...

Not always—when using integers, for instance, this is definitely the wrong choice.

I’ve never used prepared statements but from what I’ve read they seem to be the best choice for this sort of thing. Is there any reason not to use them? Should they be used for all database queries, or are there instances (ignoring portability) when they shouldn’t be used?

IIMarckus said:

Considering how many times the PHP people have rewritten their escaping routines, I’m personally not very confident of that.

Click to expand...

?

mysql_real_escape_string() is not a rewrite of mysql_escape_string(), if that's what you meant. A real_escape is done by MySQL, not PHP.

IIMarckus said:

If you’re worried about security then why use PHP 4? A desire for portability is understandable, but at some point you have to let go.

Click to expand...

The servers I use all have PHP 5. The servers of people who adopt my scripts may not, however. I could also be forced to switch to a PHP 4 box, or I might gain access to one/be comissioned and want to reuse my code, etc.

IIMarckus said:

Not always—when using integers, for instance, this is definitely the wrong choice.

Click to expand...

Escape an integer? Umm...

Chopping off an arbitrary number of characters is silly and not likely to stop much. If you don't escape output, this is a hopeful stopgap measure at best.

Click to expand...

Well, as weak as the solution is, I always stuck to the main idea of my post, which was pretty much to just escape input.

Use prepared statements and you should never have problems with SQL injection.

Click to expand...

Do you mean something similar as to what Python does?

c.execute("SELECT * FROM TABLE WHERE NAME=? AND ADDRESS=?", (name, address))

Click to expand...

Geneva said:

PunBB is the best forum software that I'm aware of.

Click to expand...

I stopped reading right there. PunBB is a terribly coded pile of crap. Coding islands, globals, short-hand and long-hand statements are too inconsistent, and upgrading just sucks. I've questioned your taste in languages, and now I'm forced to question your taste in terrible software too?

Geneva said:

Unless you want abominable URLs, use POST for every single form submission before redirecting to a GET.

Click to expand...

Those "abominable" URLs can be shared, bookmarked, and returned to without a form submission.

This is even part of the HTTP spec. POST is for altering server state; GET is for just retrieving data.

Geneva said:

mysql_real_escape_string() works perfectly. Stop being deceptive. Problems only arise when sloppy, lazy coders screw their code up.

Click to expand...

People are imperfect, and having to needlessly wrap every single datum in an ugly function call is asking for trouble. There is no reason to leave yourself open for mistakes when you can prevent them entirely.

Geneva said:

What do you have against app portability? mysqli is only supported by PHP 5+, which most Web servers have yet to upgrade to.

Click to expand...

Given that PHP4 has not been supported for a year, I would hardly encourage anyone to target it or support its use. Get a better host.

Geneva said:

Except it forces you to use ugly OOP...

Click to expand...

Oh NO, I have to say $dbh->prepare() instead of mysql_prepare($dbh). Reducing namespace pollution and unnecessary verbosity are not bad things.

Or, hey, use Perl, where backwards compatibility requires that "prepare $dbh @params" works.

IIMarckus said:

I’ve never used prepared statements but from what I’ve read they seem to be the best choice for this sort of thing. Is there any reason not to use them? Should they be used for all database queries, or are there instances (ignoring portability) when they shouldn’t be used?

Click to expand...

The only place you can't use them is when the database engine doesn't support what you're doing, and then you still have to escape -- but those cases are rare, and most of the time you're interpolating your own data rather than user input. You can't, for example, use a placeholder for a table name.

Faltzer said:

Do you mean something similar as to what Python does?

Click to expand...

Yes, and every other respectable language. Much like every other ghastly practice in PHP, the developers opted to make a broken and embarrassingly insecure feature the only way of doing things for the longest time.

Faltzer said:

I stopped reading right there. PunBB is a terribly coded pile of crap.

Click to expand...

I mildly dislike PunBB (mainly because of the occasional OOP and lack of real sessions), but it's still less bloated, messy and slow than any other open-source forum software that I've examined.

Coding islands,

Click to expand...

What?

globals,

Click to expand...

Variables are globalized only where appropriate. The alternatives are sometimes hideous and slow and always cluttery and entirely pointless. They aim to fix a non-problem, and fail even at that.

I can't imagine the confusion it must take for someone to feel that singletons make their code cleaner or easier to understand...

short-hand and long-hand statements are too inconsistent,

Click to expand...

Are you talking about ternary operators?

I guess you prefer other languages to PHP because they let your scripts be just as indecipherable as your posts, huh?

Geneva said:

I mildly dislike PunBB (mainly because of the occasional OOP and lack of real sessions), but it's still less bloated, messy and slow than any other open-source forum software that I've examined.

Click to expand...

And its written in PHP. Also, what the hell is your problem with OOP? Also, its funny that you mention bloated. That is exactly the state of the PHP core as we speak.

Variables are globalized only where appropriate. The alternatives are sometimes hideous and slow and always cluttery and entirely pointless. They aim to fix a non-problem, and fail even at that.

I can't imagine the confusion it must take for someone to feel that singletons make their code cleaner or easier to understand...

Click to expand...

The entire point was to not use global variables. Globals are a bad practice in programming, and it applies to just about any language. If you're using a global, then it is a sign that you've fucked up in your design and should revise. You must think it is normal to 'global' 15 $config_ variables. It isn't even limited to that; objects, streams, etc.

Are you talking about ternary operators?

Click to expand...

Yes. Your code looks like spaghetti once you've applied that short-hand crap on to it. PHP encourages this sort of behavior, so I couldn't expect any less.

I guess you prefer other languages to PHP because they let your scripts be just as indecipherable as your posts, huh?

Click to expand...

Lol, what the hell are you talking. You've been failing miserably in all of the arguments where I've asked you why PHP > other languages, but you've yet to provide a valid reason as to why it is superior. I've seen your arguments with Vee, and they all stink. The only reason why I'm not interfering is because he has them all under control.

Geneva said:

I guess you prefer other languages to PHP because they let your scripts be just as indecipherable as your posts, huh?

Click to expand...

Please. PHP has barely any higher-level functionality at all, instead opting to stick with a syntax somewhere between C and JavaScript but not quite as useful as either.