Author Archives: Jeremiah Grossman

About Jeremiah Grossman

Jeremiah Grossman is the Founder and interim CEO of WhiteHat Security, where he is responsible for Web security R&D and industry outreach. Over the last decade, Mr. Grossman has written dozens of articles, white papers, and is a published author. His work has been featured in the Wall Street Journal, Forbes, NY Times and hundreds of other media outlets around the world. As a well-known security expert and industry veteran, Mr. Grossman has been a guest speaker on six continents at hundreds of events including TED, BlackHat Briefings, RSA, SANS, and others. He has been invited to guest lecture at top universities such as UC Berkeley, Stanford, Harvard, UoW Madison, and UCLA. Mr. Grossman is also a co-founder of the Web Application Security Consortium (WASC) and previously named one of InfoWorld's Top 25 CTOs. He serves on the advisory board of two hot start-ups, Risk I/O and SD Elements, and is a Brazilian Jiu-Jitsu Black Belt. Before founding WhiteHat, Mr. Grossman was an information security officer at Yahoo!

Sentinel Elite: Adding $250,000 Worth of Breach Protection

A week ago WhiteHat launched Sentinel Elite where we made a bold statement, perhaps one of the boldest statements any security vendor can make. We’re offering a financially backed security guarantee: if a website covered by Sentinel Elite gets hacked, specifically using a vulnerability we didn’t identify and should have, the customer will be refunded in full.

Since the announcement, the feedback we’ve received has been both incredible and incredibly interesting. It’s clear to us the concept of a ‘security guarantee’ strikes a nerve and we are finding that others in the industry have called for similar action. In fact, a recent report by ChangeWave (a subsidiary of 451 Research), entitled ‘Corporate Cloud Computing Trends’, says the following:

“We also asked about the importance of being offered a ‘security guarantee’ by cloud service providers. Three-quarters of respondents (74%) say it’s ‘Very Important’ that cloud providers offer a guarantee, and another 22% say ‘Somewhat Important.’ Companies not using cloud place a greater importance on security guarantees than current users. As such, security guarantees give cloud service providers an opportunity to attract new customers.”

Even Dan Geer (CISO, In-Q-Tel), in his Black Hat keynote, called for software liability: “the only two products not covered by product liability are religion and software, and software shall not escape much longer.”

Clearly, this is an idea whose time has come!

While many have been commending us for putting our money where our mouth is, which we appreciate, we’ve also been asked to do more. We heard multiple times that in the long run, a product refund is not substantive enough when compared to customer breach costs in the event of an incident — which could easily extend from six figures on up. And you know what? They are absolutely right! WhiteHat should have more skin in the game. So, we’re taking this feedback to heart and we are upping the ante:

Now, not only will Sentinel Elite customers receive a full refund in the event that their site is breached as a result of a vulnerability that we should have discovered but missed, we will also cover up to $250,000 in damages to the affected company.

Like we’ve said before, WhiteHat is serious about web security. We’re serious when we say a security vendor’s interests should be in line with their customers. We encourage other vendors to follow suit and we encourage their customers to settle for nothing less. This is the best way to achieve better security outcomes, more secure software, and a more secure Web. Other industries have already done this. InfoSec can too!

For more information about Sentinel Elite, please click here.

Security Guaranteed: Customers Deserve Nothing Less

WhiteHat Security Sentinel Elite

Ever notice how everything in the information security industry is sold “as is”? No guarantees, no warrantees, no return policies. This provides little peace of mind that any of the billions that are spent every year on security products and services will deliver as advertised. In other words, there is no way of ensuring that what customers purchase truly protects them from getting hacked, breached, or defrauded. And when these security products fail – and I do mean when – customers are left to deal with the mess on their own, letting the vendors completely off the hook. This does not seem fair to me, so I can only imagine how a customer might feel in such a case. What’s worse, any time someone mentions the idea of a security guaranty or warranty, the standard retort is “perfect security is impossible,” “we provide defense-in-depth,” or some other dismissive and ultimately unaccountable response.

Still, the naysayers have a valid point. Given enough time and energy, everything can be hacked, including security products, but this admission does not inspire much confidence in those who buy our warez and whose only fear is getting hacked. We, as an industry, are not doing anything to alleviate that fear. With something as important as information security is today, personally I think customers deserve more assurance. I believe customers should demand accountability from their vendors in particular. I believe the “as is” culture in security is something the industry must move away from. Why? Because if it were incumbent upon vendors to stand by their product(s) we would start to see more push against the status quo and, perhaps, even renewed innovation.

At the core of the issue is bridging the gap between the “nothing-is-perfect” mindset and the business requirements for providing security guarantees.

If you think about it, many other industries already offer guarantees, warrantees, or 100% return policies for less than perfect products. Examples include electronics, clothing, cars, lawn care equipment, and basically anything you buy on Amazon. As we know, all these items have defect rates, yet it doesn’t appear to prevent those sellers from standing behind their products. Perhaps the difference is, unlike most security vendors, these merchants know their product failure rates and replacement costs. This business insight is precisely why they’re willing to reimburse their customers accordingly. Security vendors by contrast tend NOT to know their failure rates, and if they do, they’re likely horrible (anti-virus is a perfect example of this). As such, vendors are unwilling to put their money where their mouth is, the “as is” culture remains, and interests between security vendor and customer are misaligned.

The key then, is knowing the security performance metrics and failure rates (i.e. having enough data on how the bad guys broke in and why the security controls failed) of the products. With this information in hand, offering a security guarantee is not only possible, but essential!

WhiteHat Security is in a unique position to lead the charge away from selling “as is” and towards security guarantees. We can do this, because we have the data and metrics to prove our performance. Other Software-as-a-Service vendors could theoretically do the same, and we encourage them to consider doing so.

For example, at WhiteHat we help our customers protect their websites from getting hacked by identifying vulnerabilities and helping to get them fixed before they’re exploited. If the bad guys are then unable to find and exploit a vulnerability we missed, or if they decide to move on to easier targets, that’s success! Failure, on the other hand, is missing a vulnerability we should have found which results in the website getting hacked. This metric – the product failure rate – is something any self-respecting vulnerability assessment vendor should track very closely. We do, and here’s how we bring it all together:

  1. WhiteHat’s Sentinel scanning platform and the 100+ person army of Web security experts behind it in our Threat Research Center (TRC) tests tens of thousands of websites on a 24x7x365 basis. We’ve been doing this for more than a decade and we have a larger and more accurate website vulnerability data set than anyone else. We know with a fine degree of accuracy what vulnerabilities we are able to identify – and which ones we are not.
  2. We also have data sharing relationships with Verizon (and others) on the incident side of the equation. This is to say we have good visibility into what attack techniques the bad guys are trying and what they’re likely to successfully exploit. This insight helps us focus R&D resources towards the vulnerabilities that matter most.
  3. We also have great working relationships with our customers so that when something unfortunate does occur – which can be anything from something as simple as a ‘missed’ vulnerability, to a site that was no longer being scanned by our solution that contained a vulnerability, all the way to a real breach – we’re in the loop. This is how we can determine whether something we missed and should have found actually results in a breach.

Bottom line: in the past 10+ years of performing countless assessments and identifying millions of vulnerabilities, there have been only a small number of instances in which we missed a vulnerability that we should have found that we know was likely used to cause material harm to our customers. All told, our failure rate is far less than even one percent (<.01%), which is an impressive track record and one that we are quite proud of. I am not familiar with any other software scanning vendor who even claims to know what their failure rate metric is, let alone has the confidence to publicly talk about it. And it is for this reason that we can confidently stand behind our own security guarantee for customers with the new Sentinel Elite.

Introducing: Sentinel Elite

Sentinel Elite is a brand new service line from WhiteHat in which we deploy our best and most comprehensive website vulnerability assessment processes. Sentinel Elite builds on the proven security of WhiteHat Sentinel, which offers the lowest false-positive rate of any web application security solution available as well as more than 10 years of website vulnerability assessment experience. This service, combined with a one-of-a-kind security guarantee from WhiteHat gives customers the confidence in both their purchase decisions as well as the integrity of their websites and data.

Sentinel Elite customers will have access to a dedicated subject matter expert (SME) who expedites communication and response times, as well as coordinates the internal and external activities supporting your applications security program. The SME will also supply prioritized guidance support, so customers know which vulnerabilities to fix first… or not! Customers also receive access to the WhiteHat Limited Platinum Support program, which includes a one-hour SLA, quarterly summaries and exploit reviews, as well as a direct line to our TRC. Sentinel Elite customers must in turn provide us with what we need to do our work, such as giving us valid website credentials and taking action to remediate identified vulnerabilities. Provided everyone does what they are responsible for, our customers can rest assured that their website and critical applications will not be breached. And we are prepared to stand behind that claim.

If it happens that a website covered by Sentinel Elite gets hacked, specifically using a vulnerability we missed and should have found, the customer will be refunded in full. It’s that simple.

We know there will be those in the community who will be skeptical. That’s the nature of our industry and we understand the skepticism. In the past, other security vendors have offered half-hearted or gimmicky guarantees, but that’s not what we’re doing here. We’re serious about web security, we always have been. We envision an industry where outcomes and results matter, a future where all security products come with security guarantees, and most importantly, a future where the vendors’ best interests are in line with their customers’ best interests. How amazing would that be not only for customers but also for the Internet and the world we live, work and do business in? Sentinel Elite is the first of many steps we are taking to make this a reality.

For more information about Sentinel Elite, please click here.

Podcast: An Anthropologist’s Approach to Application Security

In this edition of the WhiteHat Security podcast, I talk with Walt Williams, Senior Security and Compliance Manager Lattice Engines. Hear how Walt went from Anthropologist to Security Engineer, his approach to building relationships with developers, and why his biggest security surprise involved broken windshields.

Want to do a podcast with us? Signup to become an “Unsung Hero”.

About our “Unsung Hero Program”
Every day app sec professionals tirelessly protect the Web, and we recognize that this is largely owed to a series of small victories. These represent untold stories. We want to help share your story. To learn more click here.

Relative Security of Programming Languages: Putting Assumptions to the Test

“In theory there is no difference between theory and practice. In practice there is.” – Yogi Berra

I like this quote because I think it sums up the way we as an industry all too often approach application security. We have our “best practices” and our conventional wisdom of how we think things operate, what we think is “secure” and standards that we think will constitute true security, in theory. However, in practice — in reality — all too often we find that what we think is wrong. We found this to be true when examining the relative security of popular programming languages, which is the topic of the WhiteHat Security 2014 Website Statistics Report that we launched today. The data we collected from the field defies the conventional wisdom we carry and pass down about the security of .Net, Java, ASP, Perl, and others.

The data that we derived in this report puts our beliefs around application security to the test by measuring how various web programming languages and development frameworks actually perform in the field. To which classes of attack are they most prone, how often and for how long? How do they fare against popular alternatives? Is it really true that the most popular modern languages and frameworks yield similar results in production websites?

By examining these questions and approaching their answers not with assumptions, but with hard evidence, our goal is to elevate conversations around how to “build-in” security from the start of the development process by picking a language and framework that not only solves business requirements, but security requirements as well.

For example, whereas one might assume that newer programming languages such as .Net or Java would be less prone to vulnerabilities, what we found was that there was not a huge difference between old languages and newer frameworks in terms of the average number of vulnerabilities. And when it comes to remediating vulnerabilities, contrary to what one might expect, legacy frameworks tended to have a higher rate of remediation – in fact, ColdFusion bested the whole field with an average remediation rate of almost 75% despite having been in existence for more than 20 years.

Similarly, many companies assume that secure coding is challenging because they have a ‘little bit of everything’ when it comes to the underlying languages used in building their applications. in our research, however, we found that not to be completely accurate. In most cases, organizations have a significant investment in one or two languages and very minimal investment in any others.

Our recommendations based on our findings? Don’t be content with assumptions. Remember, all your adversary needs is one vulnerability that they can exploit. Security and development teams must continue to measure their programs on an ongoing basis. Determine how many vulnerabilities you have and then how fast you should fix them. Don’t assume that your software development lifecycle is working just because you are doing a lot of things; anything measured tends to improve over time. This report can help serve as a real-world baseline to measure against your own.

To view the complete report, click here. I would also invite you to join the conversation on Twitter at #2014WebStats @whitehatsec.

Adding Open Source Framework Hardening to Your SDLC – Podcast

I talk with G.S. McNamara, Federal Information Security Senior Consultant, about fixing open source framework vulnerabilities, what to consider when pushing open source, how to implement a system around patches without impacting performance, and security considerations on framework selections.





Want to do a podcast with us? Signup to be part of our Unsung Hero program.

About our “Unsung Hero Program”
Every day app sec professionals tirelessly protect the Web, and we recognize that this is largely owed to a series of small victories. These represent untold stories. We want to help share your story. To learn more click here.

Top 10 Web Hacking Techniques 2013

Every year the security community produces a stunning number of new Web hacking techniques that are published in various white papers, blog posts, magazine articles, mailing list emails, conference presentations, etc. Within the thousands of pages are the latest ways to attack websites, Web browsers, Web proxies, and their mobile platform equivalents. Beyond individual vulnerabilities with CVE numbers or system compromises, we are solely focused on new and creative methods of Web-based attack. Now in its eighth year, the Top 10 Web Hacking Techniques list encourages information sharing, provides a centralized knowledge base, and recognizes researchers who contribute excellent work. Past Top 10s and the number of new attack techniques discovered in each year:
2006 (65), 2007 (83), 2008 (70), 2009 (82), 2010 (69), 2011 (51) and 2012 (56).

Phase 1: Open community voting for the final 15 [Jan 23-Feb 3]
Each attack technique (listed alphabetically) receives points depending on how high the entry is ranked in each ballot. For example, an entry in position #1 will be given 15 points, position #2 will get 14 points, position #3 gets 13 points, and so on down to 1 point. At the end all points from all ballots will be tabulated to ascertain the top 15 overall. Comment with your vote!

Phase 2: Panel of Security Experts Voting [Feb 4-Feb 11]
From the result of the open community voting, the final 15 Web Hacking Techniques will be ranked based on votes by a panel of security experts. (Panel to be announced soon!) Using the exact same voting process as phase 1, the judges will rank the final 20 based on novelty, impact, and overall pervasiveness. Once tabulation is completed, we’ll have the Top 10 Web Hacking Techniques of 2013!

Complete 2013 List (in no particular order):

  1. Tor Hidden-Service Passive De-Cloaking
  2. Top 3 Proxy Issues That No One Ever Told You
  3. Gravatar Email Enumeration in JavaScript
  4. Pixel Perfect Timing Attacks with HTML5
  5. Million Browser Botnet Video Briefing
    Slideshare
  6. Auto-Complete Hack by Hiding Filled in Input Fields with CSS
  7. Site Plagiarizes Blog Posts, Then Files DMCA Takedown on Originals
  8. The Case of the Unconventional CSRF Attack in Firefox
  9. Ruby on Rails Session Termination Design Flaw
  10. HTML5 Hard Disk Filler™ API
  11. Aaron Patterson – Serialized YAML Remote Code Execution
  12. Fireeye – Arbitrary reading and writing of the JVM process
  13. Timothy Morgan – What You Didn’t Know About XML External Entity Attacks
  14. Angelo Prado, Neal Harris, Yoel Gluck – BREACH
  15. James Bennett – Django DOS
  16. Phil Purviance – Don’t Use Linksys Routers
  17. Mario Heiderich – Mutation XSS
  18. Timur Yunusov and Alexey Osipov – XML Out of Band Data Retrieval
  19. Carlos Munoz – Bypassing Internet Explorer’s Anti-XSS Filter
  20. Zach Cutlip – Remote Code Execution in Netgear routers
  21. Cody Collier – Exposing Verizon Wireless SMS History
  22. Compromising an unreachable Solr Serve
  23. Finding Weak Rails Security Tokens
  24. Ashar Javad Attack against Facebook’s password reset process.
  25. Father/Daughter Team Finds Valuable Facebook Bug
  26. Hacker scans the internet
  27. Eradicating DNS Rebinding with the Extended Same-Origin Policy
  28. Large Scale Detection of DOM based XSS
  29. Struts 2 OGNL Double Evaluation RCE
  30. Lucky 13 Attack
  31. Weaknesses in RC4

Leave a comment if you know of some techniques that we’ve missed, and we’ll add them in up until the submission deadline.

Final 15 (in no particular order):

  1. Million Browser Botnet Video Briefing
    Slideshare
  2. Timur Yunusov and Alexey Osipov – XML Out of Band Data Retrieval
  3. Hacker scans the internet
  4. HTML5 Hard Disk Filler™ API
  5. Eradicating DNS Rebinding with the Extended Same-Origin Policy
  6. Aaron Patterson – Serialized YAML Remote Code Execution
  7. Mario Heiderich – Mutation XSS
  8. Timothy Morgan – What You Didn’t Know About XML External Entity Attacks
  9. Tor Hidden-Service Passive De-Cloaking
  10. Auto-Complete Hack by Hiding Filled in Input Fields with CSS
  11. Pixel Perfect Timing Attacks with HTML5
  12. Large Scale Detection of DOM based XSS
  13. Angelo Prado, Neal Harris, Yoel Gluck – BREACH
  14. Weaknesses in RC4
  15. Lucky 13 Attack

Prizes [to be announced]

  1. The winner of this year’s top 10 will receive a prize!
  2. After the open community voting process, two survey respondents will be chosen at random to receive a prize.

The Top 10

  1. Mario Heiderich – Mutation XSS
  2. Angelo Prado, Neal Harris, Yoel Gluck – BREACH
  3. Pixel Perfect Timing Attacks with HTML5
  4. Lucky 13 Attack
  5. Weaknesses in RC4
  6. Timur Yunusov and Alexey Osipov – XML Out of Band Data Retrieval
  7. Million Browser Botnet Video Briefing
    Slideshare
  8. Large Scale Detection of DOM based XSS
  9. Tor Hidden-Service Passive De-Cloaking
  10. HTML5 Hard Disk Filler™ API

Honorable Mention

  1. Aaron Patterson – Serialized YAML Remote Code Execution

iCEO

As many of you know, I started WhiteHat Security more than 10 years ago with the mission to help secure the Web, company by company. It has been an incredible roller coaster ride over the past decade, both at WhiteHat Security, which has experienced phenomenal growth, as well as within the industry itself. By that I mean that we have come a long way: organizations and companies are now more aware of how critical their presence is on the web, and therefore how crucial it is that they ensure that presence is secure. I am proud to say that we now manage more than 30,000 websites today, but with more than 900 million websites on the Internet today, we clearly still have a long way to go. And with that, I am pleased to announce that I have accepted the WhiteHat Security Board of Director’s invitation to step in to the role of interim CEO of WhiteHat Security.

I am very proud of what this company has achieved since 2001: we have grown from a team of one to more than 350 passionate contributors in all areas of the business, including the world’s largest army of hackers; we have received some of the highest industry accolades and awards out there; WhiteHat Sentinel is now a leading web application security solution for nearly 600 of the world’s best-known brands, and we continue to experience exponential growth. All of this success is due in large part to the leadership and direction of our former CEO Stephanie Fohn who took a leap of faith with us more than 8 years ago and who will remain one of the company’s biggest supporters. I would be remiss if I did not acknowledge the work and dedication that she has put in to this company and I wish her the best as she takes time to be with family.

The Internet is a continuously evolving space. New websites launch every day and new threats emerge constantly. As such, web security is complex even for some of the most seasoned security practitioners. My focus will remain on ensuring that our customers – both current and future – have the best product and technology experience and that they get the highest levels of support that such a fast-paced market dictates. We will continue to lead on the fronts of innovation and customer success, and we will do that with a team of some of the most talented application security technologists, business executives, practitioners and contributors that this industry has to offer.

I look forward to leading WhiteHat Security into this next chapter.

Aviator: Some Answered Questions

We publicly released Aviator on Monday, Oct 21. Since then we’ve received an avalanche of questions, suggestions, and feature requests regarding the browser. The level of positive feedback and support has been overwhelming. Lots of great ideas and comments that will help shape where we go from here. If you have something to share, a question or concern, please contact us at aviator@whitehatsec.com.

Now let’s address some of the most often heard questions so far:

Where’s the source code to Aviator?

WhiteHat Security is still in the very early stages of Aviator’s public release and we are gathering all feedback internally. We’ll be using this feedback to prioritize where our resources will be spent. Deciding whether or not to release the source code is part of these discussions.

Aviator unitizes open source software via Chromium, don’t you have to release the source?

WhiteHat Security respects and appreciates the open source software community. We’ve long supported various open source organizations and projects throughout our history. We also know how important OSS licenses are, so we diligently studied what was required for when Aviator would be publicly available.

Chromium, of which Aviator is derived, contains a wide variety of OSS licenses. As can be seen here using aviator://credits/ in Aviator or chrome://credits/ in Google Chrome. The portions of the code we modified in Aviator are all under BSD, or BSD-like licenses. As such, publishing our changes is, strictly speaking, not a licensing requirement. This is not to say we won’t in the future, just that we’re discussing it internally first. Doing so is a big decision that shouldn’t be taken lightly. Of course, when and/if we make a change to the GPL or similar licensed software in Chromium, we’ll happily publish the updates as required.

When is Aviator going to be available for Windows, Linux, iOS, Android, etc.?

Aviator was originally an internal project designed for WhiteHat Security employees. This served as a great environment to test our theories about how a truly secure and privacy-protecting browser should work. Since WhiteHat is primarily a Mac shop, we built it for OS X. Those outside of WhiteHat wanted to use the same browser that we did, so this week we made Aviator publicly available.

We are still in the very early days of making Aviator available to the public. The feedback so far has been very positive and requests for a Windows, Linux and even open source versions are pouring in, so we are definitely determining where to focus our resources on what should come next, but there is not definite timeframe yet of when other versions will be available.

How long has WhiteHat been working on Aviator?

Browser security has been a subject of personal and professional interest for both myself, and Robert “RSnake” Hansen (Director, Product Management) for years. Both of us have discussed the risks of browser security around the world. A big part of Aviator research was spent creating something to protect WhiteHat employees and the data they are responsible for. Outside of WhiteHat many people ask us what browser we use. Individually our answer has been, “mine.” Now we can be more specific: that browser is Aviator. A browser we feel confident in using not only for our own security and privacy, but one we may confidently recommend to family and friends when asked.

Browsers have pop up blockers to deal with ads. What is different about Aviator’s approach?

Popup blockers used to work wonders, but advertisers switched to sourcing in JavaScript and actually putting content on the page. They no longer have to physically create a new window because they can take over the entire page. Using Aviator, the user’s browser doesn’t even make the connection to an advertising networks’ servers, so obnoxious or potentially dangerous ads simply don’t load.

Why isn’t the Aviator application binary signed?

During the initial phases of development we considered releasing Aviator as a Beta through the Mac Store. Browsers attempt to take advantage of the fastest method of rendering they can. These APIs are sometimes unsupported by the OS and are called “private APIs”. Apple does not support these APIs because they may change and they don’t want to be held accountable for when things break. As a result, while they allow people to use their undocumented and highly speed private APIs, they don’t allow people to distribute applications that use private APIs. We can speculate the reason being that users are likely to think it’s Apple’s fault as opposed to the program when things break. So after about a month of wrestling with it, we decided that for now, we’d avoid using the Mac Store. In the shuffle we didn’t continue signing the binaries as we had been. It was simply an oversight.

Update: November 8, 2013:
Our dev team analyzed the overly-permissive chmod settings that Aviator 1.1 shipped with. We agreed it was overly permissive and have fixed the issue to be more in line with existing browsers to protect users on multi-user systems. Click to read more on our Aviator Browser 1.2 Beta release.

Why is Aviator’s application directory world-writable?

During the development process all of our developers were on dedicated computers, not shared computers. So this was an oversight brought on by the fact that there was no need to hide data from one another and therefore chmod permissions were too lax as source files were being copied and edited. This wouldn’t have been an issue if the permissions had been changed back to their less permissive state, but it was missed. We will get it fixed in an upcoming release.

Update: November 8, 2013:
Our dev team analyzed the overly-permissive chmod settings that Aviator 1.1 shipped with. We agreed it was overly permissive and have fixed the issue to be more in line with existing browsers to protect users on multi-user systems. Click to read more on our Aviator Browser 1.2 Beta release.

Does Aviator support Chrome extensions?

Yes, all Chrome extensions should function under Aviator. If an issue comes up, please report it to aviator@whitehatsec.com so we can investigate.

Wait a minute, first you say, “if you aren’t paying you are the product,” then you offer a free browser?
Fair point. Like we’ve said, Aviator started off as an internal project simply to protect WhiteHat employees and is not an official company “product.” Those outside the company asked if they could use the same browser that we do. Aviator is our answer to that. Since we’re not in the advertising and tracking business, how could we say no? At some point in the future we’ll figure out a way to generate revenue from Aviator, but in the mean time, we’re mostly interested in offering a browser that security and privacy-conscious people want to use.

Have you gotten and feedback from the major browser vendors about Aviator? If so, what has it been?

We have not received any official feedback from any of the major browser vendors, though there has been some feedback from various employees of those vendors shared informally over Twitter. Some feedback has been positive, others negative. In either case, we’re most interested in server the everyday consumer.

Keep the questions and feedback coming and we will continue to endeavor to improve Aviator in ways that will be beneficial to the security community and to the average consumer.

What’s the Difference between Aviator and Chromium / Google Chrome?

Context:

It’s a fundamental rule of Web security: a Web browser must be able to defend itself against a hostile website. Presently, in our opinion, the market share leading browsers cannot do this adequately. This is an every day threat to personal security and privacy for the more than one billion people online, which includes us. We’ve long held and shared this point of view at WhiteHat Security. Like any sufficiently large company, we have many internal staff members who aren’t as tech savvy as WhiteHat’s Threat Research Center, so we had the same kind of security problem that the rest of the industry had: we had to rely on educating our users, because no browser on the market was suitable for our security needs. But education is a flawed approach – there are always new users and new security guidelines. So instead of engaging in a lengthy educational campaign, we began designing an internal browser that would be secure and privacy-protecting enough for our own users — by default. Over the years a great many people — friends, family members, and colleagues alike — have asked us what browser we recommend, even asked us what browser their children should use. Aviator became our answer.

Why Aviator:

The attacks a website can generate against a visiting browser are diverse and complex, but can be broadly categorized in two types. The first type of attack is designed to escape the confines of the browser walls and infect the desktop with malware. Today’s top tier browser defenses include software security in the browser core, an accompanying sandbox, URL blacklists, silent-updates, and plug-in click-to-play. Well-known browser vendors have done a great job in this regard and should be commended. No one wins when users desktops become part of a botnet.

Unfortunately, the second type of browser attack has been left largely undefended. These attacks are pernicious and carry out their exploits within the browser walls. They typically don’t implant malware, but they are indeed hazardous to online security and privacy. I’ve previously written up a lengthy 8-part blog post series on the subject documenting the problems. For a variety of reasons, these issues have not been addressed by the leading browser vendors. Rather than continue asking for updates that would likely never come, we decided we could do it ourselves.

To create Aviator we leveraged open source Chromium, the same browser core used by Google Chrome. Then, because the BSD license of Chromium allows us, we made many very particular changes to the code and configuration to enhance security and privacy. We named our product Aviator. Many people are eager to learn what exactly the differences are, so let’s go over them.

Differences:

  1. Protected Mode (Incognito Mode) / Not Protected Mode:
    TL;DR All Web history, cache, cookies, auto-complete, and local storage data is deleted after restart.
    Most people are unaware that there are 12 or more locations that websites may store cookie and cookie-like data in a browser. Cookies are typically used to track your surfing habits from one website to the next, but they also expose your online activity to nosy people with access to your computer. Protected Mode purges these storage areas automatically with each browser restart. While other browsers have this feature or something similar, it is not enabled by default, which can make it a chore to use. Aviator launches directly into Protected Mode by default and clearly indicates the mode of the current window. The security / privacy side effect of Protected Mode also helps protect against browser auto-complete hacking, login detection, and deanonymization via clickjacking by reducing the amount of session states you have open – due to an intentional lack of persistence in the browser over different sessions.
  2. Connection Control: 
    TL;DR Rules for controlling the connections made by Aviator. By default, Aviator blocks Intranet IP-addresses (RFC1918).
    When you visit a website, it can instruct your browser to make potentially dangerous connections to internal IP addresses on your network — IP addresses that could not otherwise be connected to from the outside (NAT). Exploitation may lead to simple reconnaissance of internet networks, or it may permanently compromise your network by overwriting the firmware on the router. Without installing special third-party software, it’s impossible to block any bit of Web code from carrying out browser-based intranet hacking. If Aviator happens to be blocking something you want to be able to get to, Connection Control allows the user to create custom rules — or temporarily use another browser.
  3. Disconnect bundled (Disconnect.me): 
    TL;DR Blocks ads and 3rd-party trackers.

    Essentially every ad on every website your browser encounters is tracking you, storing bits of information about where you go and what you do. These ads, along with invisible 3rd-party trackers, also often carry malware designed to exploit your browser when you load a page, or to try to trick you into installing something should you choose to click on it. Since ads can be authored by anyone, including attackers, both ads and trackers may also harness your browser to hack other systems, hack your intranet, incriminate you, etc. Then of course the visuals in the ads themselves are often distasteful, offensive, and inappropriate, especially for children. To help protect against tracking, login detection and deanonymization, auto cross-site scripting, drive-by-downloads, and evil cross-site request forgery delivered through malicious ads, we bundled in the Disconnect extension, which is specifically designed to block ads and trackers. According to the Chrome web store, over 400,000 people are already using Disconnect to protect their privacy. Whether you use Aviator or not, we recommend that you use Disconnect too (Chrome / Firefox supported). We understand many publishers depend on advertising to fund the content. They also must understand that many who use ad blocking software aren’t necessarily anti-advertising, but more pro security and privacy. Ads are dangerous. Publishers should simply ask visitors to enable ads on the website to support the content they want to see, which Disconnect’s icon makes it easy to do with a couple of mouse-clicks. This puts the power and the choice into the hands of the user, which is where we believe it should be.
  4. Block 3rd-party Cookies: 
    TL;DR Default configuration update. 

    While it’s very nice that cookies, including 3rd-party cookies, are deleted when the browser is closed, it’s even better when 3rd-party cookies are not allowed in the first place. Blocking 3rd-party cookies helps protect against tracking, login detection, and deanonymization during the current browser session.
  5. DuckDuckGo replaces Google search: 
    TL;DR Privacy enhanced replacement for the default search engine. 

    It is well-known that Google search makes the company billions of dollars annually via user advertising and user tracking / profiling. DuckDuckGo promises exactly the opposite, “Search anonymously. Find instantly.” We felt that that was a much better default option. Of course if you prefer another search engine (including Google), you are free to change the setting.
  6. Limit Referer Leaks: 
    TL;DR Referers no longer leak cross-domain, but are only sent same-domain by default. 

    When clicking from one link to the next, browsers will tell the destination website where the click came from via the Referer header (intentionally misspelled). Doing so could possibly leak sensitive information such as the search keywords used, internal IPs/hostnames, session tokens, etc. These leaks are often caused by the referring URL and offer little, if any, benefit to the user. Aviator therefore only sends these headers within the same domain.
  7. Plug-Ins Click-to-Play: 
    TL;DR Default configuration update enabled by default. 

    Plug-ins (E.g. Flash and Java) are a source for tracking, malware exploitation, and general annoyance. Plug-ins often keep their own storage for cookie-like data, which isn’t easy to delete, especially from within the browser. Plug-ins are also a huge attack vector for malware infection. Your browser might be secure, but the plug-ins are not and one must update constantly. Then of course all those annoying sounds and visuals made by plug-ins which are difficult to identify and block once they load. So, we blocked them all by default. When you want to run a plug-in, say on YouTube, just one-click on the puzzle piece. If you want a website to always load the plug-ins, that’s a configuration change as well. “Always allow plug-ins on…”
  8. Limit data leakage to Google: 
    TL;DR Default configuration update.

    In Aviator we’ve disabled “Use a web service to help resolve navigation errors” and “Use a prediction service to help complete searches and URLs typed in the address bar” by default. We also removed all options to sync / login to Google, and the tracking traffic sent to Google upon Chromium installation. For many of the same reasons that we have defaulted to DuckDuckGo as a search engine, we have limited what is sent in the browser to Google to protect your privacy. If you chose to use Google services, that is your choice. If you chose not to though, it can be difficult in some browsers. Again, our mantra is choice – and this gives you the choice.
  9. Do Not Track: 
    TL;DR Default configuration update.

    Enabled by default. While we prefer “Can-Not-Track” to “Do-Not-Track”, we figure it was safe enough to enable the “Do Not Track” signal by default in the event it gains traction.

We so far have appreciated the response to WhiteHat Aviator and welcome additional questions and feedback. Our goal is to continue to make this a better and more secure browser option for consumers. Please continue to spread the word and share your thoughts with us. Please download it and give it a test run. Let us know what you think! Click here to learn more about the Aviator browser.