Has somebody ever experienced this kind of situation and what could be the solution? We have taken security measures that you would expect someone to take but there has been a second attempt after that as well.
It sounds like you’re allowing your website to run some arbitrary code, known as XSS (cross-site-scripting). You can google to find articles on the subject. Another possibility is that you’re allowing visitors to upload files to your website without first sanitising the file. Without having access to your code, though, we can only provide vague answers.
I’ve had a few sites that got hacked because the client had weak passwords or "heaven forbid" I didn’t write the code correctly! 🙂
There are a tremendous number of automated "vulnerability scans" and "password hacks" running on the Internet that insert code into sites. And yes your problem may have started with an uploaded file.
Make sure any ftp & admin panel passwords are "STRONG" so at least your site isn’t susceptible to these kind of hacks.
As far as XSS and CSRF go – see:
Also, review your raw log files and look for a series of request for files that returned 404 errors from the same IP address. You’ll notice that there will be a bunch of requests returning 404’s all throughout your raw logs that are in close proximity. This is an indication of an automated vulnerability scan, but sometimes it’s just a determined "script kiddy."
Many times these scans are trying to access files such as: admin/index.php, phpMyAdmin/index.php, phpMyAdmin, etc. and as stated they’re bunched together in a group.
Also, look at the modification time of the file(s) that that have been hacked to limit your log search to around that time (typically the damage doesn’t start to show up until some time after the file changes). Also, look at the file time of the php script file that inserted the bad code. This is of course post-mortem, but it will help in protecting against the problem in the future. CHANGE YOUR PASSWORDS!
Finally, as Markus mentioned, it might just be an XSS attack based upon comments in the blog. Make sure that b2Evolution is properly cleansing any comments being posted by users and no b2evolution installation files are still on the server.
(This last one I’m just making an assumption as I’ve never installed or used b2evolution on a site.)
Sanitize ALL user input before using it.
User input includes, but is not limited to:The $_POST array, The $_GET array, The $_FILES array, The $_COOKIE array, The $_SERVER array in regards to client information and URL information, And the the non-recommended $_REQUEST array.
Sanitation is a case-by-case process. In other words, the same data can be filtered differently for MySQL queries (i.e. mysql_real_escape_string) and display on the website (i.e. htmlspecialchars). Just note that whenever you have an occurrence of any elements from the arrays that I mentioned, you are NOT **EVER** taking the data at face value unless you want to run the risk of unwanted data.
all advices are valuable but i want to add one more advice is… do you have any public area from where your visitors can post sum data which is not validated for the <HTML> and other scripting tags e.g
this also can be a problem please also check this thing.
If this is the problem then you can use
function for it.
htmlspecialchars is less invasive and preferred over strip_tags. This is due to the fact that strip_tags actually changes what the user inputs. So, lets say that a user is writing something like command-line arguments for an application that they use. The accepted format for doing this is "command <argument1> <…>".
See how that could be a problem?
After looking into logs, we have found some useful information on attack and the method used. I can post the log here if that is OK. During the research, found countless sites infected with this particular r57.php shell.
Then you need to find out where in your website you allowed this download and quarantine that section until you fix the problem.