Some security points you've got to check

Here are some points you should definitively look at before announcing to everybody that your website is going live. This article is not exhaustive and if you think it lacks some important thing, just go and share by a comment.

How can I put some mess in your website ?

This is the standard question of the potential hacker. "How can I hijack your website to make it do something else ?"

Some tracks about how we can do that in a simple way :

• Use login forms to be logged as someone else
• Use standard HTTP methods (get and post) to access data and simulate normal operations
• Use content to generate bad things : bugs or bad content
• Use scripts / robots to generate bad content or decrease your performance
• Let the common configuration of the used solution

Those different tracks are more or less well managed by software. In the next part, I will take an example, the eZPublish CMS and show how they've protected each point.

An example : eZPublish

The editor user

A common mistake is to forget to remove default users (or to change their passwords). For example, try to login with editor/editor on a website running eZPublish. It's also very common to set password that are name of the project or common values ("test", "ezpublish" and so on). The best option is to remove this users and generates real passwords with a dedicated tool.

The user view

In eZPublish, the URL allow you to access point and features of the website. For example, if features are not explicitly unplugged, we can easily reach the following URLs : /user/login, /user/register and /user/forgotpassword. It means that by typing in the URL the correct /module/action URI I can have access to features you don't want to be shown on your website. The best choice is to use rights and policies to unplug them and to check the PolicyOmitList setting.

The Ajax based feature

It's not because you have an Ajax feature that delighted people cannot see how things works. Most modern browsers have an XHR Sniffer (see Firebug for Firefox and Google Chrome Inspector for Google Chrome) that allows you to see what URL is called and what are the response. If you use Ajax to get only compiled HTML, it will be ok, but if you use JSON, it can be tricky : what happens if I set different settings in the call and I analyze what it returns ?

The utility of a captcha

The captcha will avoid to let non human contributors to contribute. For example, if you write an article and that someone create a robot to automatically post generated comments on it, you may have to problems : the first is that the amount of not real comments will depreciate your article and the second is that it can show bad things you don't want to have on your website (bad words).

The solution of the captcha introduces a random field that is used to check that the person on the other side is a human. Some very clever robots can analyze pictures inside the generated picture with characters recognition.

I personally recommend the excellent reCaptcha service that is free and efficient.

The mail bomb

Another similar point is to use the system, eZPublish, to send mail to other people. A tip a friend feature without restriction of rights can be very dangerous. For example, a robot can send tip a friend messages with bad words to a list of people.

The security point is to insure that mail are sent via the system only when users are logged (with the form that uses a captcha) or to limit the number of sendings.

The XSS

If you do extra development in eZPublish, juste take care to follow the novel philosophy of this software. Store everything the user has typed and process it for restitution. If you don't process stored data, you may have the following issues :

• The user has set HTML in the body field of his comment. Rendering that directly, you can have extra design appearing because the user put a h1 markup in the input. Mostly, it's unintended because people does a lot of copy/paste things.
• The user has set Javascript in the body field of his comment. Rendering that directly can have bad implications, the user access to the DOM and potentially to anything that is loaded dynamically. For example, the user typed a window.close() inside the body of the comment. Each time the article will be loaded, the window will be closed. Hmmm. Not so good.

To prevent this, you can use the wash operator in eZPublish. It kills every extra markup to have pure data.

This methods can also be used to try to access restricted areas of the website using SQL injection for example. This is prevented in eZPublish with the eZDB class.

Conclusion

The best way to secure a website is always to understand how people will try to attack it. This post has listed some known tracks, feel free to add your owns.