Site Logs and PHP protection

Question

I was checking my logs and noticed the following

[Tue Apr 02 16:12:02 2013] [error] [client 31.181.33.208] File does not exist:/xxx/join.php+++++++++++++++++++++++++++++++++++++++++++++++++++Result:+\xed\xe5+\xed\xe0\xf8\xeb\xee\xf1\xfc+\xf4\xee\xf0\xec\xfb+\xe4\xeb\xff+\xee\xf2\xef\xf0\xe0\xe2\xea\xe8;, referer: http://www.edrobe.com/join.php+++++++++++++++++++++++++++++++++++++++++++++++++++Result:+%ed%e5+%ed%e0%f8%eb%ee%f1%fc+%f4%ee%f0%ec%fb+%e4%eb%ff+%ee%f2%ef%f0%e0%e2%ea%e8%3b

I have never seen anything like this. Should I be worried? is there anything i can do to prevent such code from being run on my site?

Thanks

Answer 1

The error indicates that someone was trying to hit /xxx/join.php and pass it some unusual data.

The good news is:

That file doesn't exist so this action didn't really result in anything useful for them.

The bad news is:

They'll likely try other things (as will others).

Things to consider

• Sanitizing user input is a good idea
• Protecting folders where you allow uploads is a good idea (both with permissions and via your web server config).
• You can also use a firewall to block traffic from this IP and/or a range of IPs.

Answer 2

The comment by 'dirt' is very bad advice.

It's very difficult to validate input before it gets to your application logic - and by then the vulnerability which your example targets has already been exploited. You should NEVER sanitize input (for multiple reasons) - either accept it or reject it - but you must always sanitize output.

Mostly stuff you see in your logs is failed attempts at compromising your system (a successful attack doesn't leave evidence behind). But detecting failed attacks are a very useful way of preventing sucessful attacks - if you're running on Unix/Linux, fail2ban can monitor your logs for abnormalaities and inject firewall rules to block that client.

Don't waste your time in a knee jerk response to a single incident. If you're serious about the security of your site, then the best advice is to plan how to protect your site, plan how you will detect if you have been compromised and plan for how you get the service back on line after it has been compromised.

There's a lot of useful stuff on setting up a secure server at SANS and OWASP . This should be essential reading for anyone plugging a server into the internet. Specifically for PHP, have a lok at Suhosin .

If you're on a shared host and only have access to .htaccess, then you have no security - all you can do is pester your service provider to implement proper security measures and re-upload your site when it gets defaced.

Answer 3

All you can do is protect your site as best possible. Unless you specifically are being targeted, an attacker will just move on to a less protected site.

Some recommendations:

Use regular expressions. This limits the possible input a user can submit. In the new HTML5 you can add a pattern parameter to your input tags. For example:

<input type="tel" name="phone" max="20" pattern="\d{3}[\-]\d{3}[\-]\d{4}">

HTML5 also has new input types, but these are not supported by all browsers yet, so it is good to include patterns. HTML5Pattern.com has common patterns for various input types. As you might have noticed, you can also limit the length of the input. If you know the input cannot be longer than X characters, don't allow users to input more than X characters.

If your user input is being stored in a database, PHP database extensions have functions to escape strings . Thus any special alt code characters or functions will not be executed but entered as a literal string.

For PostgreSQL: pg_escape_string()
For MySQL: mysql_real_escape_string()

Other functions exist such as stripslashes() that remove the slashes from input, thus disabling special character.

Follow the above and you've prevented:
- bad input from being submitted
- submitted bad input invalidated
- protected your database from SQL injections

You can also configure your server to block IP addresses that attacks are originating from. If your server is on Linux, this reference guide (pdf) has very useful information.