Coding SEO into a CMS

**ddvvns** · 03-17-2008, 04:18 AM

All good CMS systems have the same characteristics:
Clean Structure - Admin side is easy to navigate
Fexible and powerfull content editor
Ability to manges content - code sniplets, parts of pages, whole pages, <head> section
Ability to have integration with other components.

Val

**VirtuosiMedia** · 03-17-2008, 05:03 AM

Quote:

Originally Posted by ddvvns

All good CMS systems have the same characteristics:

I agree completely and thank you for your comment. What I'd like to know, though, is what would make it better than just good?

**ADAM Web Design** · 03-17-2008, 02:00 PM

"Be different". Don't just follow along...come up with something that hasn't been done before.

For example, WordPress completely destroys Google Maps code. Both Forrest and I have had this happen completely independently. Have a way to add in Google Maps code, with clear step-by-step instructions on how to sign up for the API and use it. That would be huge right there.

Allow users to convert from other formats. That would be big from a market share point of view.

There are two...you owe me $129.975 cents (that half cent is big to me.

)

**VirtuosiMedia** · 03-17-2008, 02:35 PM

Thanks Adam, great suggestions. I'll play around with the Google Maps thing. Easy content insertion is a definite must. I don't think I'm going to try to rewrite any user submitted code in order to "fix it".

As for allowing users to convert from different systems, I hadn't thought of that previously, but you're right on the mark with that one as well. It would be HUGE from a market share point of view. The two main data types to import that come to mind right away are content and user data. Wordpress, Joomla, and Drupal seem like they would be worthwhile making a conversion script for, but I don't know beyond that. I'll have a forum and shopping cart system eventually as well, but not right away. Any advice in regards to all this? Wordpress is probably what I would work on right away and then add anything else after I get other major features done.

**ADAM Web Design** · 03-17-2008, 05:02 PM

Quote:

I don't think I'm going to try to rewrite any user submitted code in order to "fix it".

Amen to that. If you're going to do anything, make "suggestions", and give the user the option to implement them. But don't fix what someone else puts in. I like it already.

As far as what to convert first, I'd suggest WordPress for both vested-interest reasons (I want to look at an alternative at some point, as I was never really satisfied with the "product") and for market share reasons (it and Joomla are the "big ones").

**Learning Newbie** · 03-17-2008, 05:44 PM

Quote:

Originally Posted by VirtuosiMedia

I'll have a forum and shopping cart system eventually as well, but not right away. Any advice in regards to all this?

If a user doesn't accept cookies, send them a gif file of someone flipping them the finger.

A lot of PHP based open source but I'll gladly take your money systems put session ID hash values in the URL as a query string argument. They're implementing the part of Google's guidelines that says to do what you can to prevent GoogleBot from being able to access your site. It's like the Bot Olympics, where you don't just ban them entirely, but throw up all kinds of obsticals and see if they can make it. Don't do that.

**VirtuosiMedia** · 08:22 PM

Quote:

Originally Posted by Learning Newbie

If a user doesn't accept cookies, send them a gif file of someone flipping them the finger.

A lot of PHP based open source but I'll gladly take your money systems put session ID hash values in the URL as a query string argument. They're implementing the part of Google's guidelines that says to do what you can to prevent GoogleBot from being able to access your site. It's like the Bot Olympics, where you don't just ban them entirely, but throw up all kinds of obsticals and see if they can make it. Don't do that.

Some things I'm considering security-wise, but would love advice on:

Not using URL parameters at all except for the creation of an SEF URL or for pagination purposes. For checkout purposes, I'll have to research that a little more. Is session data safe enough if it's just passed from page to page? Initially, I'm going to just integrate with Paypal and perhaps a few other payment processing systems. We'll see where it goes from there. Password verification would probably also be required for any purchases, even if someone is logged in.
Requiring that every form processed check if the referring page originated on the same site, however, I need to do some research on if that can be spoofed or not. I could also create a unique hash as a hidden input for each form and validate that against a session token.
I created my own form validation class that (among other things) escapes all form data to prevent SQL injection attacks. It doesn't strip tags natively, however, as I'll not always want to do that, especially in the admin section. I might create another class for allowing the admin to select which tags they want stripped from user-submitted data, but the <script>, <frame>, <iframe> and any <? tags will definitely be on the list.
Using the @ in front of every query and creating a custom error reporting system that will be available from the site administration. I might also use something similar for 404's and other quirks, etc.
I'm still looking at login security, but nothing will be displayed in the URL for sure. Sessions won't be cookie reliant, but will only use them as a 'remember me' feature. The cookies will expire after a certain time and I will reset their hash upon each login. I'll probably also log and check the UA against the database, even though I think that can be spoofed. After a set number of login failures, a new password will be emailed to the email on file for that account (maybe, although this could be abused too. Thoughts?).
No include or library files ending in .inc. Everything will end with .php.
Minimum password lengths and MD5 password storage with a salt.
Initializing all variables so that they can't be set from offsite through the global namespace if register globals are on.
A threat detection system that will automatically ban an IP address if certain triggers are tripped. (I haven't done any work into this one yet, but I wonder if it would be possible to have a dynamic .htaccess file, or if it should be done on the script level, or both). Each ban would be logged and the admin would be notified.
An index file in each directory and any modules or directories created from the admin would have the index file added automatically.
Renaming any file uploads.

Am I missing anything obvious for security? I'm researching more, but I'd like to make it as secure as possible. Also, in regards to SEF URLs, is a hyphen or underscore better? Right now I have an underscore, but it'd be great to get some more opinions. Thanks again, guys.

**ForrestCroce** · 03-17-2008, 09:03 PM

Quote:

Originally Posted by VirtuosiMedia

Is session data safe enough if it's just passed from page to page?

Depends what you store in session state. I'd use some type of hash, and then store all the goodies in the database, using that same hash to find them.

Quote:

Originally Posted by VirtuosiMedia

Password verification would probably also be required for any purchases, even if someone is logged in.

That might prevent a lot of people from making purchases.

Quote:

Originally Posted by VirtuosiMedia

Requiring that every form processed check if the referring page originated on the same site, however, I need to do some research on if that can be spoofed or not.

Give me any two urls, with one of them under your control, and I'll make it look like you have hundreds of referrals from the other. Just as Internet Explorer can set the referral header, a bot can do the same thing easily. Same goes for user agent, obviously.

Quote:

Originally Posted by VirtuosiMedia

I could also create a unique hash as a hidden input for each form and validate that against a session token.

In your database, or other session store, keep hold of the IP address. You can't use that alone thanks to network address translation, but if a user jumps between a lot of IP addresses, something fishy is going on.

Quote:

Originally Posted by VirtuosiMedia

as I'll not always want to do that, especially in the admin section.

What happens if an attacker figures out how to get at your admin section? That's a lesser concern, but...

Quote:

Originally Posted by VirtuosiMedia

I'll probably also log and check the UA against the database, even though I think that can be spoofed.

Make that easily spoofed; user agent really isn't for security. Also consider what happens when a user gets frustrated with one browser and tries another ... it's not an every day thing, but should be allowed.

Quote:

Originally Posted by VirtuosiMedia

No include or library files ending in .inc. Everything will end with .php.

No!!! You can publish the full source code to a perfectly secure system, without compromising its integrity. But unless you have a phd in math and a second in computer science, there's likely to be some flaw waiting to be discovered. Most people believe that hiding you implementation tools adds a layer of security. If everything is *.html, it's not clear what technology you're using, and I don't know off hand what are the flaws in your framework I might be able to exploit.

Quote:

Originally Posted by VirtuosiMedia

Minimum password lengths and MD5 password storage with a salt.

You know there's a search engine for MD5 hash sources?

Quote:

Originally Posted by VirtuosiMedia

A threat detection system that will automatically ban an IP address if certain triggers are tripped. (I haven't done any work into this one yet, but I wonder if it would be possible to have a dynamic .htaccess file, or if it should be done on the script level, or both).

Look into computing heuristics.

**VirtuosiMedia** · 03-18-2008, 01:36 AM

Thanks for pointing out a lot of things, Forrest. Like I said, these are things I'm considering, but I'm not completely sold on any of them yet. I'd just like to make things as secure as possible.

Quote:

Originally Posted by ForrestCroce

That might prevent a lot of people from making purchases.

It probably would. If it's included, it would be optional.

Quote:

Originally Posted by ForrestCroce

Give me any two urls, with one of them under your control, and I'll make it look like you have hundreds of referrals from the other. Just as Internet Explorer can set the referral header, a bot can do the same thing easily. Same goes for user agent, obviously.

I was thinking about using the $_SERVER['document_root'] variable, but if it can be spoofed, I won't probably bother. Mainly I was looking for a way to prevent CSRF attacks.

Quote:

Originally Posted by ForrestCroce

In your database, or other session store, keep hold of the IP address. You can't use that alone thanks to network address translation, but if a user jumps between a lot of IP addresses, something fishy is going on.

Can't the IP be falsified as well? How would this be any different from verifying the user agent?

Quote:

Originally Posted by ForrestCroce

What happens if an attacker figures out how to get at your admin section? That's a lesser concern, but...

Isn't this the same problem every script has, though? I'm going to have admin user groups and I could do things like force a password change for the super admin every month, but I'm definitely open to suggestions.

Quote:

Originally Posted by ForrestCroce

Make that easily spoofed; user agent really isn't for security. Also consider what happens when a user gets frustrated with one browser and tries another ... it's not an every day thing, but should be allowed.

Are cookies stored by browser or by computer? My understanding was that if you used another browser on the same computer, you'd have to login once more anyways. I wasn't thinking of having the UA as the ultimate security check, just a quick match (if the remember me cookie is set) to see if it was the same as the last time they visited and if not, force a login.

Quote:

Originally Posted by ForrestCroce

No!!! You can publish the full source code to a perfectly secure system, without compromising its integrity. But unless you have a phd in math and a second in computer science, there's likely to be some flaw waiting to be discovered. Most people believe that hiding you implementation tools adds a layer of security. If everything is *.html, it's not clear what technology you're using, and I don't know off hand what are the flaws in your framework I might be able to exploit.

I'm not totally sure if I understand what you're saying with this paragraph, but I have a feeling I may not have used the correct terminology. What I meant was the files that include many of my classes and functions, not the template files. However, wouldn't having SEF URLs also hide the technology?

Quote:

Originally Posted by ForrestCroce

You know there's a search engine for MD5 hash sources?

I do now, thank you. After a bit of reading, it looks like sha1 is also compromised, though not as badly yet. Any suggestions?

Quote:

Originally Posted by ForrestCroce

Look into computing heuristics.

I did and I think I get your point, that I wouldn't need to do that if I solve the smaller problems around it?

What kind of things would you specifically implement for security beyond what's already been listed? I realize that security isn't boolean, that it's more of a scale and it also needs to be balanced with usability and practicality (the checkout example as a case in point), but I still want to do my best. Thanks.

**mork29** · 03-18-2008, 06:37 AM

Check out the Drupal module: http://drupal.org/project/seo_checklist

It lists almost everything you can do with Drupal to make it SEO friendly. Some of them are just steps that you can do, others are modules you should install. I think it covers almost everything somebody could hope for in regards to SEO on a CMS.

**VirtuosiMedia** · 03-18-2008, 01:20 PM

Thanks for the link, mork29. I had trouble finding out what that module specifically does, however.

**ForrestCroce** · 03-18-2008, 11:21 PM

Quote:

Originally Posted by VirtuosiMedia

Can't the IP be falsified as well? How would this be any different from verifying the user agent?

Sure ... a lot of things can be spoofed, which is why none of them can be a security token alone. But the IP address is harder to spoof than a user agent or referral header. You can put anything in either of those; you can only pretend to be an IP you can receive packets through. The obvious spoof is to use a proxy server, which means a person has two IP addresses at their disposal instead of one; or a list of dozens. But they still have some connection to the box at the address, unlike user agent strings, which can be shed like nothing.

I've read that Digg and Wikipedia maintain proxy server lists, and discover new ones from their logs. A lot of people using the same IP address is a strong hint; once it's confirmed, I'm guessing you can't do anything from that proxy server.

Quote:

Originally Posted by VirtuosiMedia

Are cookies stored by browser or by computer?

Both ... different browsers have their own sets of cookies.

Quote:

Originally Posted by VirtuosiMedia

I'm not totally sure if I understand what you're saying with this paragraph, but I have a feeling I may not have used the correct terminology. What I meant was the files that include many of my classes and functions, not the template files. However, wouldn't having SEF URLs also hide the technology?

If you use a php extension for your pages, you're tipping your hand at least a little bit. All frameworks have their own weaknesses ... you've probably taken care of most of them, but a new exploitable hole discovered a month after you launch is always possible. If you use html instead of php as a file extension, it's a bit harder. A person can easily figure out it's an Apache server, but there are still a number of different ways an Apache server can be programmed against.

Quote:

Originally Posted by VirtuosiMedia

I do now, thank you. After a bit of reading, it looks like sha1 is also compromised, though not as badly yet. Any suggestions?

This is where a modular approach would be a really good idea. SHA-2 is the one to go with right now, but that could change any time. If you let the admin choose a hashing algorithm, that would make it a lot harder for anyone else to know which is being used at any given installation.

Quote:

Originally Posted by VirtuosiMedia

What kind of things would you specifically implement for security beyond what's already been listed? I realize that security isn't boolean, that it's more of a scale and it also needs to be balanced with usability and practicality (the checkout example as a case in point), but I still want to do my best. Thanks.

Netscape was brought down by a flaw in its random number generator, but you need to be a high value target before somebody is going to put that kind of time into an attack. The best thing to exploit in most systems is still the passwords.