There's no two ways about it: Successful phishing attacks can cause serious damage to a business. While preventing phishing attacks entirely isn't possible, companies can take
The past several months have seen customers of several big enterprises such as Google and Microsoft fall victim to phishing attacks. The big problem facing these companies and others that offer online services is that phishing attacks target the companies' users in order to gain illegal access to Web services and the data behind them.
As an aside, it is essential to ensure all online applications are as secure as possible. While that is an important consideration, in this tip we'll focus specifically on preventing phishing attacks.
Some experts say there is little that application developers can do to combat phishing, but this is not true: Changing how certain application features are implemented can make attacks harder to execute.
Firstly, it's critical to check for cross site scripting (XSS) vulnerabilities in the network, as phishers often target unvalidated forms and URL query strings to take users to their attack sites. (My article on how to prevent an XSS tracing vulnerability exploit covers the best ways to check and fix these problems.)
In conjunction with XSS, phishers often employ iFrames to create seamless website overlays, making it difficult for users to know the site with which they are actually interacting. They can then use bugs and features of the Document Object Model, an application programming interface for HTML and XML documents, to collect other data from applications.
To ensure webpages load into the full body of browser windows and break out of any iFrame traps, Web developers can employ the TARGET _top directive. For example:
A HREF="http://www.mysite.com/login.aspx" TARGET="_top"
Also, don't use pop-up windows on your site as these too are used in attacks to surreptitiously take over a user's session.
Applications need to be able to resist indirect or automated attacks, so it's worth considering implementing a simple HTTP referrer header check to see where a request came from. Referrer fields are easily spoofed, but this check will close off links in spam emails as attack vectors; a hostile site cannot force a user's browser to send forged referrer headers.
A similar tactic is to enforce local referrers for images and other resources on your website, and to run an anti-leeching script on the Web server to prevent the images and resources from being used by others, such as the phishers. Making phishers use their own saved copies when replicating a site will increase the chances that they will get it wrong, particularly if images are changed and watermarked on a regular basis.
Applications should also be configured to monitor, react to, and notify administrators of unusual account activity, such as orders from multiple accounts being delivered to the same shipping address, or the same transaction being performed quickly from the same IP address. Automated attacks like this can be throttled by preventing too many transactions from the same user being performed in a certain period of time.
Preventing successful phishing attacks: The human factor
Tackling the problem of phishing requires more than just well-built, secure applications and controls. These controls must be augmented with strictly enforced communication processes and a comprehensive user education programme which teaches users how to recognise, resist and report phishing attacks. A corporate communications policy should define how the organisation will communicate securely with its customers so that legitimate emails can't be confused with phishing attacks.
To cut down on emails spoofed to look like they come from the company's domain, a Sender Policy Framework (SPF) record should be set up in the DNS to validate all SMTP servers. SPF-aware mail transfer agents will reject emails not sent from servers listed in SPF records, and the latest versions of Outlook, Thunderbird and Eudora will also flag them as suspect.
As a rule of thumb, it's a good idea to communicate with users using a corporate website rather than email. It's more secure and the content can be in rich HTML without posing a risk. Either way, details of what exactly the company will and will not do need to be explained somewhere on the site in easy-to-understand terms. Short notifications or clear links to help pages should be located on all key pages. For example, the phrase: "This bank will never send you an email" located on webpages and in emails lets customers know they will never receive email from the company, so any emails received from "you" have to be fraudulent.
If email must be used, it's important to ensure it contains information not readily available to phishers that would aid authentication. For example, PayPal always addresses its customers by their username in emails so they know any email with a generic greeting such as "Dear Customer" is going to be a phishing attempt.
When it comes to phishing, a company's clients are the first and last line of defence, so any effective solution must include them. It may not seem like the responsibility of the company to educate clients about online security, but ensuring that they can recognise phishing attempts and protect themselves is a low-cost, low-tech solution to defending the reputation of the business. Clients should be told how to check the security settings of their Web browsers, how to check for the "padlock" and certificate signature on pages, as well as tips such as not sharing passwords, PIN or account numbers with anyone.
From time to time, clients should be reminded to install the latest patches and to run an antivirus scan. It's also, however, wise not to overload them with too much information and make them fearful of using the company's online services. Special deals on antivirus software should be provided as low-cost protection and to show that the company does take security seriously. Customers also need an easy method to report phishing scams and advice on recognising a scam.
Finally, it's best to assume users will at some point fall victim to phishing attacks. For this reason it's vital to have a phishing incident-management policy ready and tested with sufficient resources to handle an attack. Everyone in the organisation needs to know what role they play in restricting the damage caused by the attack. This will involve working with the police, so any evidence needs to be collated and handled carefully. Clients need to know that their business associates at the company are working to protect clients against the attack, advising them of their rights and certainly supporting any that have suffered serious loss.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.
This was first published in February 2010