Secure Web

2007 - Another crisis year for Web Security!

Today we published our application security trend report for Q4 and the full year 2007. And, although there was some progress made by a lot of corporations and government agencies, prognosis continues to be grim. We are barely scratching the surface. We have a long way to go and many companies are still trying to figure out what they should be doing. Here's my abbreviated executive summary from the trend report. You can download the full report from Cenzic home page at www.cenzic.com. Please feel free to provide feedback or start a dialogue on the subject here.

2007 was certainly an eventful year. And, not just for election primaries. In 2007, we saw a number of creative and lethal attacks - not just in election debates. Web site hacking continued to gain momentum as hackers had a field day exploiting vulnerabilities across all geographies and across different types of Web applications. From SQL Injection Robot to a Russian Malware gang attacking a government site to exploitation of various Google vulnerabilities to various universities – attacks continue. Financial gains continue to be the primary goal but we also saw attacks to steal intellectual property, student records, and in a few cases to deface Web sites. The total number of vulnerabilities stabilized but Web application related vulnerabilities continue to hover around 70 percent of total vulnerabilities. The “bad guys” go where the vulnerabilities are and Web applications are certainly appealing and inviting to these constituents.

 

Application vulnerabilities in Q4 tracked the first three quarters in terms of their dominance, forming 71 percent, a three percent increase over Q3, of the total 1,404 published vulnerabilities. The scary part is that 70 percent of these vulnerabilities are easily exploitable. Application vulnerabilities are the ones that pertain to Web technologies including Web servers, Web browsers, and Web applications. These published vulnerabilities are for commercially available software and infrastructure that corporations and government agencies buy from ISVs (Independent Software Vendors). These don’t take into account thousands of vulnerabilities that are created while programming in-house or proprietary applications, many of which are outsourced to other countries including India, China, and Russia. Millions of consumers spent more than $29B during the 2007 holiday shopping season in the U.S. alone, putting their personal information including credit cards numbers into all kinds of Web sites. While there haven’t been many incidents reported of records stolen or major hacking since the holiday season, the silence is deafening. There’s actually a valid reason for this. First, it takes a while before companies realize that the information has been stolen from their databases. Secondly, hackers are no longer interested in publicizing their conquest stories. It’s in their best interest to steal the information and use it in stealth mode as long as possible. Rest assured, some of these sites have probably already been hacked and stories will start coming out as the year progresses.

 

Most of the vulnerabilities in Q4 were within the applications themselves, comprising about 85 percent of all Web application vulnerabilities. Web server and Web browser vulnerabilities were 10 percent and 5 percent respectively. Applications written in PHP continued to be a major chunk forming 30 percent of all vulnerabilities.

 

Our Top 10 vulnerabilities for Q4 2007 include various technologies and companies including OpenSSL, IBM Lotus Notes, Adobe Acrobat, Java, Realplayer, PHP, IBM Websphere, Apache, and Adobe Flash. Since this is a year-end report, we added a section for the Top Five Application Security Vulnerability Trends for all of 2007. Our Top Five for 2007 include Javascript Trickery, Universal XSS in Adobe Acrobat Reader, Mass-SQL Injection Worm, Google Gadgets and Gmail Hacks, and ORKUT XSS Worm.

 

Cenzic’s ClickToSecure managed service that tests customers’ Web applications remotely once again found that roughly 7 out of 10 Web applications are vulnerable to various types of vulnerabilities including Cross-Site Scripting, Information Leaks and Exposures, Authorization and Authentication flaws, Session Management, SQL Injection, and other security defects.

 

In 2007, we were encouraged to see more corporations and government agencies taking action by testing their applications for security vulnerabilities - partially driven by regulations like PCI, AB1950, and GLBA, and partially to protect their brands. But, we still have a long way to go. Technology and expertise is available for organizations to start their application security process quickly. Now, with virtualization integration to some Web application scanners, they can also start testing their production applications and not just the applications in development and Q.A. We hope we’ll continue to see this momentum of security consciousness in 2008 as we deal with Application Security, the next frontier.

    - Mandeep Khera

Reefer Madness or Session ID Pollution, you choose

So you can grok the title of this post, anyone remember that awful '50s documentary that tried to scare everyone into not smoking marijana? Reefer Madness! What I am getting at is this: back in early 2004 I reported a vulnerability in PHP and got ridiculed by a developer for even pointing out the issue. He said in a round about way that I was suffering from the Reefer Madness Syndrome, that is to say, that I was hyping an essentially benign issue and trying to scare everybody with it. Well, I was really busy back then and didn't feel like debating the issue so I let it drop. The flaw was later silently fixed in some 5 dot dot something release in 2006.

But still, the idea interests me because I am curious the degree to which its a localized problem in older versions of PHP or a broader issue. The root cause of what I called Session ID Pollution during my talk at OWASP Appsec 2007 is a failure to sanitize the session id of a web application, allowing an attacker to append some junk to it which gets passed around by the web application. The appended junk is essentially ignored by the application itself, but as its passed between content brokers like proxies or content portals, it has the potential to do harm.  One specific example that I cited was appending <script>foo<script> to a valid session ID token and as that information is passed around, it can become cached or directly execute within a web portal when a user follows a link. Wrapping your head around this issue is really a two part process:

1. A web application allows a user to append arbitrary data to a Session ID token, and this data is not filtered or sanitized, but is transmitted as if it were part of the valid session id, like so:

SessionID=24378923479<script>malicious code</script>

The script gets more or less tacked on to the end of the session id and it doesn't affect the session or disrupt it, but its not stripped away or sanitized either, so it effectively becomes part of the session ID as its passed around, its just not a part of the session Id that the application cares about. This is the benign aspect of the vulnerability. But don't read benign to literally, because in the same way a person or animal can carry a disease, manifest no outward symptoms, but spread it around just like the monkey in the movie Outbreak with Dustin Hoffman.

2. The session ID that has been polluted is then passed around various applications, and thus it has the potential to be executable as one of these other applications parse the URI in question when presenting data to the user.  This is the part of the movie where the monkey  gives  the disease to everybody in the village and the UN has to drop a fuel  air bomb on it. The original application hands off its polluted session ID to a content broker, content portal, proxy, or web logging server.  Thus a user follows a link to a web application, the application does not filter the session ID and the malicious content contained in the link is preserved. In fact, the application goes so far as to assign the user a new session ID but preserves the data appended onto the session id in the original request. But when the user receives the response from the application, the malicious code executes in their browser as the polluted session ID is parsed by the proxy sitting between the user and the application.

Ok... so  what? (The "so what" test is venerable tradition of college debaters. Subjecting an argument to the rigors of the "'So What' test" requires asking does anybody give a damn.) Evidently, when I reported this issue back in 2004 it didn't pass the so what test of the developer to whom I reported it. Objections to the significance of so called "Session ID Pollution" were as follows:

1. Its not the fault of the application, or a bug in the application, its the Proxy's problem. I.E. The content portal, proxy, or broker should filter hazardous characters from input not pass potentially harmful data off to the user.

2. The issue is not new, its just lame old boring cross-site scripting.

3.  You're a lamer for bringing this issue to my inbox.

My rejoinder:  Applications and servers should ensure that the session ID doesn't contain harmful or dangerous characters and that it has not been modified. Failure to do so means increased risk that some other application will recieve dangerous input from the application. One simple example is webtrends-like software that logs browsed urls in and does so in an insecure fashion. When someone views the log the script executes in their browser. Yes its a problem of the logging software, but the application, which transmits the information unsanitized, is being abused by the attacker to get their exploit into proper attack vector where it can have its impact. Now we shouldnt' go about blunting our scissors because its unsafe to run with them, but in the case of sanitizing the session ID,  there really is no good reason for someone to be able to append arbitrary data onto it, and failure to check and prevent its modification is, I suggest, a vulnerability.

At OWASP Appsec 2007 I called this vulnerability "Session ID Pollution." Because I'm interested in the topic and have been for a few years, you will be hearing more about this from me as I continue to research the issue. Consequently, at the conference where I recently presented on this topic I was challenged that the problem is only a PHP problem, and for that, at the present, I have no answer. More to follow.

-Tom S.

Q3 2007 Trends Report: First Look

Cenzic's CIA Labs will be releasing our Application Security Trends Report for Q3 2007 next week but I wanted to give our blog readers a first look into our results. First though a few remarks are in order about the report itself for those who haven't read our previous application security trend reports. Cenzic's trends report is an industry first in many ways. Its only such report of its type that focuses entirely upon application-layer vulnerabilities, attacks, and trends. Symantec's Internet Security Threat Report, now on volume 12, is the best security trend report in publication, but its focus is also very broad and web application security is only a very small part of the overall content. Understandably, the Symantec threat reports have a much broader goal and scope than our own, and being an avid reader of the Symantec report, I noticed the need for a security trends report that focused entirely on web application security. It was our (lofty) goal to do for web application security what Symantec's report does for Internet security in general, and although this sets a very high bar, its the gradual striving toward this goal which means that our trends report will continue to evolve and improve over time.
        I want to take a moment and thank all those who contribute to the report. Since we began producing this trend report in Q1 2007 we've already seen some interesting emerging trends within the data. Although Cenzic CIA Labs performs all the research, the final report is a cooperative effort that relies on individual contributions from people both within Cenzic and a network of friends and contacts. And of course our report could not be what it is without dshield.org and the CVE (of which I am an editorial board member).
        Our Q3 trends report signals in many ways "business as usual" in the application security space. In other words, many core trends remain the same:
        1. Web application vulnerabilities continue to comprise the largest part of all vulnerability data. In Q3 2007 web application security vulnerabilities comprised 68% of the total vulnerability information.
        2. Cross-Site Scripting continues to be the most prevalent web application vulnerability reported, with SQL Injection and RFI attacks not far behind.
        3. Directory Traversal vulnerabilities, the dot-dot-slash type attacks (../../) are among the least reported web application vulnerability types, typically ranging from less than 1 to 4% of the total web application vulnerability volume.
        4.  SQL injection vulnerabilities still continue to constitute roughly 20% of the total web application vulnerability volume. In other words, 1 out of 5 reported vulnerabilities is usually a SQL related vulnerability.
        5.  Insecure coding practices in PHP continue to contribute to 30% of the total web application vulnerability volume. Vulnerabilities in PHP itself, as a programming language,  tend to contribute 1-3% of the total vulnerability volume, indicating its insecurity coding practices, and not PHP as a programming language, that contribute to the usual storm of PHP-related vulnerabilities.
        These are some of the trends that have remained constant since our first trends report in Q1, trends further substantiated by the result of our Q3 report and analysis. There are several emerging trends that signal the affects of Web 2.0 programming practices and architectures within the reported vulnerability information, but if you want to learn more about these trends, you'll have to read our full report when its published next week.

Thanks again to all our readers,

-Tom S.

   

How Programs Can Behave Unexpectedly from Cenzic's SANs Contest Winner!

Dereferencing a Freed Pointer During Linked List Deletion

I've decided to discuss this block of code since deleting nodes from linked lists is a common topic in introductory programming courses and online tutorials. It is a textbook example of how programs can behave unexpectedly when there is a lack of attention to subtle details. Observe the following C code loop:

for(p = head; p != NULL; p = p->next) {

free(p);

}

The problem becomes more apparent when the for loop is converted to its equivalent while syntax. It is easier to see how the value of the pointer identified by the p variable is referenced by the assignment statement in successive loop iterations after being freed.

p = head;

while(p != NULL)

{

free(p);

p = p->next;

}

It is quite possible that no memory corruption will occur during runtime depending on the execution environment. I was able to compile and run the code on Linux and the program exited successfully instead of terminating from receipt of a memory fault signal. This is why these types of errors can go overlooked and undetected.

However, there is no guarantee that the memory will hold the same value after it has been freed. The memory address holding the pointer location could be reallocated or overwritten. At a minimum, this could cause a denial of service condition because the program will crash when it attempts to access an invalid memory address.

Reflexive Cross-Site Scripting in ASP

<html>

<body>

<p>

<b>You are browsing this site with:</b>

<%Response.Write(Request.ServerVariables("http_user_agent"))%>

</p>

<p>

<b>Your IP address is:</b>

<%Response.Write(Request.ServerVariables("remote_addr"))%>

</p>

<p>

<b>The DNS lookup of the IP address is:</b>

<%Response.Write(Request.ServerVariables("remote_host"))%>

</p>

<p>

<b>The method used to call the page:</b>

<%Response.Write(Request.ServerVariables("request_method"))%>

</p>

<p>

<b>The server's domain name:</b>

<%Response.Write(Request.ServerVariables("server_name"))%>

</p>

<p>

<b>The server's port:</b>

<%Response.Write(Request.ServerVariables("server_port"))%>

</p>

<p>

<b>The server's software:</b>

<%Response.Write(Request.ServerVariables("server_software"))%>

</p>

</body>

</html>

It’s pretty obvious that this Active Server Page is returning untrusted input data to the browser that has not been sanitized. The question immediately becomes how do we exploit it? The four server variables that a malicious party would be capable of modifying are request_method, remote_host, remote_addr, and http_user_agent. request_method is out of the question since it would invalidate the HTTP request. Perhaps remote_host or remote_addr could be modified through a spoofing attack such as DNS cache poisoning, but if the user’s network addressing scheme has already been compromised they have bigger problems.

Injecting the payload into the User-Agent HTTP header field looks like the most fruitful approach. This can be accomplished with the setRequestHeader method from the XMLHttpRequest JavaScript API or ActionScript’s addRequestHeader method. Microsoft, Mozilla, Adobe, and Apple have all been updating their client code in an attempt to prevent HTTP header injection. Regardless, attackers will continue to find ways to bypass any client-side restrictions as long as the server side programming is vulnerable--recent HTTP header injection techniques in the aforementioned API’s have involved the insertion of newline characters within header string arguments (see CVE2006-5330 and CVE2007-2401.)

- Derek Callaway, Security Consultant (Cenzic's SANS Contest Winner August 2007)

HP follows suit by gobbling up SpiDynamics

As expected, HP announced the acquisition of SpiDynamics today. Another huge validation for the Application Security space. Finally, companies are realizing that with 75% of attacks occurring at the application layer and 7 out of 10 applications vulnerable, there's a drastic need to take action. Large companies like IBM and HP realize this tremendously upward movement and want to get ahead of the curve to meet the customers needs. HP had been in conversation with Spi for the last couple of months and plans to integrate Spi's products into the Mercury quality assurance suite.

While integrating security testing with functional testing is important (note: Cenzic has already integrated with Mercury and Borland), we believe that for customers it's not a good solution if the security product loses its identity completely for a number of reasons. First, customers like best of breed products. They don't want to buy Mercury just because they want security testing. Secondly, most of the testing and buying is still taking place at the Chief Security Officer (CSO) and the InfoSec group levels. This organization is typically separate from Development/Q.A. organization. Not having a stand-alone product can severely hinder Information Security group's efforts. Finally, about 99% of the applications are already in production and until they go through new development, some one still needs to test for security and find vulnerabilities.

People are asking us if Cenzic is next in the acquisition train. Frankly, we are focused on building the business and continue significant enhancements to our risk-management solutions. We will always be open to strategic relationships with security vendors like Cisco, Juniper, Symantec, McAfee, Verisign, and CA or ALM vendors like Compuware, and Borland, that help enhance value for the customers. Our motto continues to be - Superior Solution, Superior Service. Stay tuned.

- Mandeep Khera, Cenzic Inc.

Impact of IBM Acquisition of Watchfire

As the announcement of IBM acquisition of Watchfire hit the wire on Wednesday, June 6th, there was a lot of buzz going around in the media about the impact of this acquisition. I have provided some of the links from these articles below. Many reporters and security executives have asked me about my thoughts on the topic which I would like to share here as well.

First of all, I think the acquisition is a big-time validation for the application security space. It also means that more and more companies are getting serious about application security. However, application security still has a long way to go. As far as the impact on the existing Watchfire customers, we'll have to wait and see. From all the indications so far, it looks like IBM will suck Watchfire product Appscan into its Rational suite. This can't be good for Watchfire customers because there won't be a standalone product and IBM will not focus on enhancing the security functionality in the product. It'll become just another feature or Rational quality testing suite.

We also believe that there's too much hype about integrating security testing tools into Software Development Lifecycle (SDLC). We agree that's important to test early in the development lifecycle. However, with all this people, companies are starting to focus only on the new applications as they develop. What about the remaining 99% of Web applications that are already in production?  A good analogy is the anti-virus products where anti-virus scan can be run before OS and other software are installed on the desktop but most of the testing occurs after the user starts using the desktop.

Cenzic believes that companies need to take a holistic risk-management approach. Find out how many apps you have and at what stage, find out who owns those apps, track when those apps were tested and how often, understand what's still vulnerable, and at the management level create metrics to understand the security posture of the company and monitor on an ongoing basis. This is not about ad-hoc testing of a few applications just to get a check box item crossed. This is about protecting your brand and your customers.

We are sure there'll be more consolidation in this space as various Application Lifecycle Management (ALM) vendors (HP, Compuware, Microsoft, and Borland), Security vendors (Symantec, McAfee, Verisign, and CA), and Infrastructure vendors (Cisco, Juniper, Citrix, and many others) need to add similar functionality to their portfolio. We just hope that the customers will push their vendors to offer combined solutions that are more holistic rather than a point solution as part of a development suite.

Whatever the solution, companies need to start testing applications for security vulnerabilities NOW. We have a catastrophe waiting to happen based on what we saw in Cenzic's first Quarterly Trends Report (download from http://www.cenzic.com) - 7 out of 10 applications are vulnerable, about 70% of total vulnerabilities are application related, and over 75% of attacks happening at the application layer - a recipe for a disaster for the Commercial and the Government sectors.

News stories from IBM/Watchfire deal:

http://www.computerwire.com/industries/research/?pid=53971D9D%2D84F3%2D4D7B%2DAFCF%2DB26EC2D93CAA
http://www.onstrategies.com/blog/?p=198 http://www.scmagazine.com/us/news/article/662742/ibm-keeps-mind-security-watchfire-buy
http://www.infoworld.com/article/07/06/06/IBM-to-buy-Watchfire_1.html
http://www.networkcomputing.com/showArticle.jhtml?articleID=199902344&queryText=watchfire+cenzic
http://www.internetnews.com/bus-news/article.php/3681766
http://www.computerworld.com/blogs/node/5652

Mandeep Khera, Cenzic Inc.

Reflections on our Q1 2007 Application Security Trends Report

Now that our Application Security Trends Report Q1 2007 is out the door I want to discuss some of the major challenges we faced in putting it together and also give our audience a sense of our vision for the future of the report. Our goals for the quarterly trends report were three-fold, and some of the these goals we were able to achieve better than others: to discuss major events that affected application security during Q1 time-frame, to compile relevant and accurate statistics for the period, and to give a sense of attack patterns and events in the so-called underground.  These were lofty goals to begin with, but we did our best. That being said, our first Trends Report was still our first report, and we didn't get to do everything we wanted to do. Below are a some of the areas that we hope to improve upon in the future.

1. Level of Abstraction: Its a challenge to strike a balance between an appropriate high-level overview of the vulnerability data verses a very low-level and comprehensive categorization. The more detailed your categorization system the more risk you run of confusing your audience or producing a final work that's more convoluted than informative.The  OWASP Top 10, for example has 10 categories for web application vulnerability types, whereas WASC has 6 top level threat classes with 24 subcategories. Future versions of our report will utilize a list of Web Application Risks that we think strikes the best balance between detail and breadth. In other words, we were not entirely satisfied with either of the major web application vulnerability taxonomies, so we're going to come up with our own.

2. Definition of a Web Application verses Web-enabled technology. As the web becomes more diversified and dynamic in the types of applications that interact to deliver its functionality and content, web application vulnerabilities will become more diversified. This time around we used a working definition of a web application: those server-side technologies that provide for infrastructure and functionality for delivering web content to the user, plus the web browser. While I won't go into our motivation for including browser vulnerabilities in the report, its clear that when one begins to categorize things this way you have departed from a strict definition of a web-application as a pure server-side technology that you assess or scan from a black-box perspective when doing an assessment. This can cause some confusion since its a departure from the ordinary way we think of web applications.

We're ok with this departure because it makes sense, but it also doesn't go far enough or do justice to very large amounts of vulnerability data relevant to web application security. In future reports you can expect us to broaden our definition of a web application even further, which will lengthen the report, but also pull in additional security information that is important for web users. This doesn't mean that we will treat traditional web application vulnerabilities with any less importance, it means that the definition of a traditional web application is showing signs of stress, and a broader definition will be a better overall fit for the vulnerability data. To keep things clear we will create categories for types of web application vulnerabilities that exist in non server-side technologies, and detail this broader picture as vulnerabilities disclosed in web-enabled technologies. Web Applications and Web-enabled technologies will be covered in separate sections to avoid confusion. Here are a few examples:

*A cross-site scripting vulnerability in Poodle-cart 1.0 would be categorized as a web application vulnerability.

*A cross-site scripting vulnerability in Adobe Acrobat Reader would be categorized and counted under the web-enabled technology section. (This time around we did not include or count any of these types of web-enabled technology vulnerabilities).

*A web-exploitable vulnerability in Quicktime would be categorized under the web-enabled technology section.

*A Web-exploitable vulnerability in the Super-Slurp Desktop Buddy ToolBar would be categorized under the web-enabled technology section.

*Vulnerabilities in web browsers will be categorized under the web-enabled technology section.

*Web-exploitable vulnerabilities in ActiveX controls for web applications will be categorized under the web-enabled technology section.

*Vulnerabilities in web servers, web application servers, etc., will be included among web application vulnerabilities, as a subcategory (i.e. the web application pie chart will have two slices).

By covering both traditional web application vulnerabilities as well as web-enabled technology vulnerabilities we can avoid leaving out information that will help to inform and protect our readers, while at the same time keeping a clear distinction between traditional server-side applications and client-side technologies with web-based vulnerabilities.

Why do things this way? Why all the craziness? Well, (to quell the conspiratorial types) we're not trying to pad the report for length so that we can win the my Trends Report is bigger than your Trends Report contest. We're not trying to out-Symantec Symantec. Rather, its our viewpoint that all technologies which use HTTP, and have HTTP exploitable vulnerabilities, should get coverage in our Application Security Trends Report. We want to provide this coverage while still keeping traditional web application vulnerabilities front and center.   

-Tom

 

SQL Injection Cheat Sheet

Ferruh Mavituna released a new version of their SQL Injection Cheat Sheet, currently version 1.4. This is a great resource for anyone doing appliation penetration testing, but it also assumes some advanced SQL knowledge on the part of the reader in order to understand the usefulness of some of the examples.

You can view the 1.4 version of the cheat sheet here. Where MySQL is concerned, another helpful resource is the MySQL 5.0 Reference Manual.

Enjoy!

-tom

Swimming with Sharks: Introduction

Have you ever wanted to know just how phishers perform their scams, get a peek into their inner workings? I decided to start this series due to the number of people I have run into who were interested in learning how and why that Phishing was so successful and the types of strategies and technologies that Phishers use.

In each installment of this series we will look at a different Phishing site and analyze it in detail. Like Marcus Aurellius we will ask: "what is the thing-in-itself; what is its proper constitution;". We will start by determining where the site is located, who owns the domain, who is running the server on which the phishing site is installed. Then we will examine the technical aspects of the site: its structure, composition, and function. We will try and discover how the site originated, that is, how it got installed on the server where we found it. In many cases it won't be clear, but if enough evidence is turned up I will offer a theory.

A word of caution. Do not attempt to casually explore Phishing websites in your browser. It's not difficult for a hostile website to install Malware on any visitors system.  A Phishing site is in its very nature a malicious construct and should be treated with the same care with which you handle toxic waste. Even if you are fully patched there are vectors of attack that arise from both reported but unpatched security vulnerabilities as well as operating system vulnerabilities that can be exploited via the browser.

When studying Phishing sites I use the following configuration:

Vmware Server:  running Windows 2003 with the latest security patches. I surf the phishing sites using IE 7 for maximum compatibility, i.e. I want to see the sites as the victim see them.

Paros Proxy: An open-source Man-in-the-Middle Proxy

Ethereal: A Protocol Sniffer/Analyzer Program

If you want to open a Phishing email for purposes of reporting the site, I recommend you use Lynx, a text-based web browser. You can download a lynx installer for Win32 from here. For general web browsing, I recommend running Firefox with NoScript.

Finally, there are number of anti-phishing clearing houses where you can report phishing when you get an email. There is the Anti-Phishing Working Group as well as Phishtank. The first installment of Swimming with Sharks will be coming out on Friday April 6.

-Tom

Protecting Yourself From XSS

While an organization can run security assessments against their own web applications on a regular basis and fix any discovered Cross-Site Scripting (XSS) vulnerabilities, there are still many web sites out there that aren't fixing their own XSS problems. Or worse yet, don't even know what XSS is or how it can affect them. But there is a way for individuals to protect themselves.

One of the ways that a XSS vulnerability gets exploited is via phishing, faking a company's web site in order to gain information. This is most commonly done with a pop-up window faking another web site. In this case the pop-up window hides the location bar, thereby trying to emulate the original web site. Normally, there might be a legitimate reason for hiding the location such as better using the window space available but it might also be to hide that the web page is being served up from a non-expected location. Fortunately Firefox provides an easy method of uncovering this type of problem.

• From within Firefox, type about:config in the URL box
• Filter down to dom.disable_window_open_feature.location
• Toggle the value to true

This will modify all your pop-up windows to always display the URL box. It's then a simple matter to verify that the site you are visiting is really sticking to the expected URL.

- Mike Kazmierczak, Cenzic, Inc.