2012-11-05 11:27

如何保护我的PHP网站免受.htaccess URL重定向恶意软件脚本攻击?


How this .htaccess file was injected into the website with malware code?

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*(msn|search|live|altavista|excite|ask|aol|google|mail|bing|yahoo).*$ [NC]

How can I prevent my website from same attack?

This link was useful till some extent

but my team expects me to protect the website using coding. Is this is possible?

I also found that few other websites had a similar attack but they use a specific kind of code to prevent their website. I cannot use those script because that's not suitable for me exactly.

The website is a core php website. If moderators found this question to be a not real question or an exact duplicate then before closing or hitting minus, please provide help with a link. I trust this website.

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答


  • dravpuso44681 dravpuso44681 9年前

    Are you using timthumb.php or a similar upload / linking script? Older versions are frought with XSS vulnerabilities. It's a very common vulnerability on Wordpress installations, especially those which use themes that come bundled with their own timthumb.php / thumb.php.

    If that's the issue, lock that script down! If it's a custom script, take a look at the latest timthumb.php source code & try to use some of their techniques.

    Also, make sure your file permissions are locked down for the apache / web users & groups. E.G., do NOT allow .htaccess to be writable by apache user/group!

    点赞 评论 复制链接分享
  • doujizhong8352 doujizhong8352 9年前

    How this .htaccess code was injected into the .htaccess file?

    If it has been injected then either someone has got root on your machine (not going to conjecture why/how) or your permissions model is wrong.

    If someone has root, then you are totally PWNed - brush up your CV and go looking for another job - you don't need to bother reading the rest of this post.

    But it's much more likely that the permissions are wrong (but even this, on its own is not sufficient for the files to be modified - you have a vulnerability elsewhere).

    You should be able to identify the primary vulnerability. If you don't know how to do this then get some help. In addition to fixing this, you need to fix the permissions on your site. Only specifically designated locations should be writeable by the webserver uid - and if these are inside the document root then you should take appropriate measures to protect your system from code injection (disable PHP access, preferably all webserver access, although this is still a lot less secure than keeping it outside the document root altogether).

    点赞 评论 复制链接分享