Chapter 6
Advanced Web Browser Defenses
Information in this chapter:
In this chapter we will discuss what can be done on the client-side to defend or harden a system against security breaches and associated threats. By the end of this chapter you should have a better idea of the defensive countermeasures that can be employed to mitigate the risks associated with the Internet and connecting a client to it. In Chapter 10 we will look at total system hardening and applying all of the concepts learned in the entire work to ensure defense in depth. In this chapter we will learn how to protect your users from client-side attacks, mitigate attacks and provide the best defense possible.
In the previous chapter (Chapter 5) we looked at how a browser and client can be compromised through the use of various techniques and technologies. It may seem to the uninitiated that there is little, if anything; to do in order to protect yourself, but this is simply not the case. In reality a number of measures exist which can and do stem the rising tide of attacks against the client.
Note
While we will discuss a number of countermeasures here in this chapter there still are a large number that we cannot cover within the confines of this text. In a nutshell there so many countermeasures available that we have decided only to cover those that will yield the best results or those that counter attacks we have already discussed.
A Mix of Protective Measures
Fortunately, even though the attacks we have seen so far are dangerous, vendors have provided features, tools and other software designed to harden the system and make it more secure. In each browser a number of security features exist, but it is generally up to you, the system owner, to determine what is beneficial to use and what is not. Remember that enabling features can make your browser and browsing experience safe and more secure, but at the same time using them incorrectly can make a system less secure.
Warning
Some less experienced individuals in the security field as well as some overzealous veterans will assume if one security measure is good, more is better which simply, is not the case. Remember that you must first be acquainted with the features available in your chosen browser, the threats against the system, the weaknesses in the system on which it’s installed and then how to address these weaknesses or shortcoming with the correct tool.
In order to assist users who may be less than knowledgeable as to how to secure their browser vendors have pre-configured their package with the most commonly used options activated. Microsoft for example ships their browser with what it deems the most appropriate security settings for client systems, but these settings should be viewed as a “one-size fits all” type situation with the configured environment not particularly appropriate for any one client. In fact, it has been shown that in a number of cases the security measures that vendors provide out of the box have actually made client systems weaker in some cases. Microsoft has learned to refine this over the years with the simple deployment of policy (Group Policy) and configuring specifics users to groups, thereby allowing for more granular control. This however needs to be designed, deployed, managed and monitored by an experienced professional.
So what do these security features seek to protect? Most modern browsers include features designed to thwart or mitigate the following:
Theft of information and identification.
Destruction or corruption of data or configuration.
Each one of these vulnerabilities can be exploited in a modern browser within the web enabled world by an ambitious and creative attacker. In fact modern browsers with all their complexities lend themselves to these attacks and exploits quite well. Couple these with user ignorance, lack of education and an ever-changing battlefield and you have a recipe for disaster.
A Mix of Potential Threats
Web attacks can come in many ways as we have covered throughout this book. You can be attacked via your web browser, from a Java applet you have installed on your system and/or through an email client that is HTML-enabled. In the past, attackers have used the exploitable variables from all of these separately and together to bypass security controls. A perfect example is via social-networking sites such as Facebook, MySpace, Twitter, and LinkedIn.
In one example, (LinkedIn), an email spam attack was launched targeting LinkedIn users. An email was sent out to target users into clicking a link that then conducted a drive-by download. Because the recipients viewed it and it looked legitimate, it was executed and many systems became infected with malware. This is a very common occurrence and why it’s critical to ensure that your end user systems (the client-side) are hardened, protected and kept updated to mitigate these attacks.
Tip
As a reminder, you must be vigilant in your attempts to educate the users of your systems because no matter how many protective measures you put in place, you can still wind up in trouble if your end users do something such as clicking on links that they normally do not click on and/or put a policy in place limiting systems to business use only. That way, there should be no reason to click on a link from Facebook (as an example). Another way to attempt to mitigate attack through non-technical means is to simply walk the floor. This means, supervisors of staff should be watching what employees do and keep themselves open and available to questions that come up such as “I received this suspicious email, what should I do?” A supervisor with the help of the help desk and technical staff should be able to help the situation along.
As we move through this chapter, we will learn more about hardening the systems to prevent client-side attack. It’s important to remember that although we highlight security specific technical instructions here, there is always more to learn. In the following sections we will quickly review some of the most critical security issues and then move directly into how to secure your browsers and clients to prevent them.
Locking Down the Web Browser
One of the key elements of securing and defending against client-side attacks is to attempt to keep the desktop client operating system and the applications that run within it secure. That means, if you are accessing websites, it’s important to attempt to keep your web browser as secure as possible. Many features are available with currently available web browser clients.
The features vendors have introduced include, but are not limited to:
The features listed here, as well as others that are not, have been introduced and implemented by vendors in order to provide the protection that is so sorely needed on client systems. The features that vendors have implemented include mechanisms designed to protect against those situations where the attacks may be beyond user detection as well as those that rely on user interaction. If used together the result can be a much safer and enjoyable experience for both the client and the security professional.
Warning
When working with desktops, it can be a problem to run the latest web browser which is sometimes considered the most secure, or has the most security features available within it. Using an old web browser at times seems foolish because it would seem that the latest and greatest available would provide you with the most available security—however there are times when you must use a specific web browser version to use specific web-based applications. For example, when using specific applications within your company, only specific versions of a web browser have been certified to be used with it. This may provide the user the most control and functionality within the application, however not the most secure level of protection. A perfect example of this is any application using an intranet, which is web servers available only to the private network, not the public Internet. In cases like this, you need to either ensure that the application vendor is updating their software in order for you to use a later version of the web browser, or try to find a balance between what can be used and what should be used if the client is using the browser for the private intranet as well as the public Internet.
A Review of Browser Features and Security Risks
To understand how browser security features protect the client from attack let us do a quick review of the browser features covered in Chapters 4 and 5 with extra emphasis placed on the risks associated with each. Understanding the technologies, how they work, and how the risks associated with each impact the client will give you better insight into how the feature will really protect you beyond what is offered in the vendor’s own sales materials.
ActiveX Related Risks
ActiveX has suffered from various weaknesses and implementation problems since the very early days when it was introduced. One of the earliest and biggest problems to be realized with ActiveX is the fact that just by its very use a client is increasing the attack surface or vulnerability of a system. In essence the problem is that whenever any application, such as ActiveX, is installed on a system increases the potential vulnerabilities on that system. Add to the fact that users may be approving the download and installation of an application from an unknown source and the dangers become apparent. Consider the fact that most users on the client side are more interested in viewing the content they requested instead of how it is rendered and you have a situation where it is likely they will decide to approve a control without ascertaining its origin and the result is a weakened system. An attacker installing an ActiveX control on a system can easily take control of the system; then seize data, or any number of activities that severely compromises the security of the client. Remember that when protecting your client-side from attack, you should take multiple steps to include enforcing a policy that end users are blocked from installing anything on their system such as an ActiveX control.
Securing ActiveX
It is recommended that beyond the web browsers basic controls, you can fine tune Internet Explorer (as example) to use Group Policy which allows you to configure custom policies and preferences. On a corporate network, it is recommended that you use Group Policy to manage (and lock down) Internet Explorer for client computers. Although other web browser vendors supply security packages to control settings, we will focus on the most commonly used Internet Explorer.
Tip
Internet Explorer supports Group Policy management when using Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1 and above. Anything prior to these systems, you must use the IEAK. The Internet Explorer Administration Kit (IEAK) 6 Service Pack 1. The IEAK is likened to Group Policy; however it’s a separate tool that allows customization of security features.
With the release of Microsoft Windows Server 2003, the Internet Explorer Enhanced Security Configuration component allowed for the hardening of all IE related functions. This feature (which grew with all releases thereafter) applied more security to IE users. For example, it allowed for the disabling of scripts, disabling of ActiveX components, and helped configure security zones. This tool allowed for the inetres.adm to be applied which was a custom policy created for restricting specific IE features. It could be delivered via Group Policy by placing the policy in Group Policy objects (GPOs). This enabled the modification of the system Registry to quickly apply security settings where needed. This was (and remains to be) the easiest and most secure way to deliver IE security to all associated desktops within your purview.
The Group Policy Internet Explorer settings would allow for control over Binary Behavior Security Restrictions, Local Machine Zone Lockdown security, consistent Multipurpose Internet Mail Extensions (MIME) handling, MK Protocol Security restrictions, the MIME Sniffing Safety Feature, add-on management, Object Scripted Window Security restrictions, restrict ActiveX Install, protection from Zone Elevation, caching protection, control over the Information Bar, restrictive file download, and network protocol lockdown.
Policy can be delivered from any domain controller configure to do so by selecting “All Programs” and then clicking “Administrative Tools.” Within these tools, you can select the “Group Policy Editor” which would produce the Group Policy Microsoft Management Console (MMC) where you can configure these policies to be deployed as seen in Figure 6.1.
Figure 6.1 Controlling Internet Explorer with Group Policy
In sum, it’s easy to see that there are many related risks to using ActiveX. Denial of Service (DoS) attacks from Buffer overflows, manipulation of ActiveX controls to cause code execution and intrusion into the system from lack of security and control on the desktop system. You can mitigate these specific risks by disallowing ActiveX controls (applets) through user education, browser hardening, system hardening and through use of policy.
Tip
Within Internet Explorer 9, you can click on the Tools menu and select the “ActiveX Filtering” option. When configured, ActiveX Filtering disables and prompts you to use ActiveX controls. Since third-party companies write controls and quality control may be an issue, so Microsoft put a tool in place to allow you more control and security.
Oracle Java Related Risks
When considering the risks associated with Oracle Java, it’s important to consider that it is equally as problematic as ActiveX. It is active content in the form or an application (applet) that when downloaded and installed on your system, acts identically to malware such as a virus. A misnomer is that Java by design is more secure than ActiveX and other counterparts. It does have built in security features such as Java follows a security model designed to protect users by constricting it to its own Java Runtime Environment (JRE). What this essentially means is that because Java is contained to its own environment, it does not necessarily tie into the core operating system much like ActiveX does. In fact, because its locked into the JRE, local disk access, network connectivity, new process creation and using specific DLL’s are all limited and or restricted.
As well, the compiler used with Java is more secure and Java controls system memory access in order to provide a higher level of security. All of this however, means nothing when any uneducated user downloads a malicious app or a mistake made in the coding process (whether accidental or intentional) creates a client-side attack.
This programming language was designed from the beginning to be an object-oriented programming language that could be used to both develop content for websites as well as applications outside of the browser. In the Java system something known as a JVM or Java Virtual Machine is used as a platform to execute code, known as an applet, provided by a website. Java Virtual Machines are obtained either as part of an operating system or are provided after the fact by a third-party. Once this JVM is installed, applets which are designed to be platform independent, may be run as desired on the system.
In recent years, 2010 to present, Java has become more of a target to client-side attack. Due to this uptick in security attacks, known problems and flaws have been looked into. Because so many end systems have Java installed, it’s a big issue for security professionals looking to protect end user systems. The biggest issue is that many times patching of end user systems is not kept as current as security flaws emerge, and many companies do not block the use and or update of Java. Many end users do not know how to update Java to a more secure version and many times when Java attempts to alert users that they need to update Java, it’s not made clear that this is mainly because of security concerns.
Java’s Security Model
Java as a technology has been fortunate in that it was designed from the start to be hardened against attack or defects. The biggest advantage that Java has may very well be its use of the “Sandbox” model where applets are limited in the scope of their access to the host system until they reach a state where they can be trusted. Of course, nothing is absolute and “Sandboxing” can be weakened through the presence of defects or “bugs” in the JVM or the host itself. Java by design is meant to be secure. As seen in Figure 6.2, the model in which its created is purpose-built to be more secure.
Figure 6.2 Java Security Model
To understand Java’s security model, you should consider the architecture in which it’s designed to run. In sum, the Java compiler works with trusted bytecode which is then passed to JVM. The JVM has many components running within it to include loaders, translator’s verifiers and a security manager. The JVM runs within the operating system. Security starts with the Java compiler which by design catches more compile time errors which could result in problematic and unsecure applets. Security is also contained as Java programs execute within the boundaries of the JRE. The JRE is nothing more than the Java Application Programming Interface (API) combined with the JVM. The JVM is the Java Virtual Machine that like other virtual machines (VM) contains elements unto itself as a contained system in memory. Because of the security manager element, control is placed over the execution of trusted and untrusted code allowing for safer use. For example, because of sandboxing, remote code can be restricted and provide additional layers of security.
It is also possible for this mechanism to be outright bypassed by digital signing of applets meaning that no protection is offered. Signing was intended to ensure only trusted applets ran without being encumbered by the restrictions of the sandbox, but even though prompted a user may still choose to run an unknown applet without verifying its source. Adding to this problem is the fact that Java applets can run across platforms so the possibility is very real that information could be stolen off of system that are completely dissimilar, but still Java enabled thus breaking the mold of operating system specific vulnerabilities.
Securing Java
To enabled protection you must configured Java to be secure. Unfortunately, even though newer versions of Java are more secure by design, many times as most software packages, applications and operating systems do, security is not selected over usability. Therefore, even though the security controls are available, are often not selected by default and must be configured. For example, even though as Java was developed throughout the years more security features were added, some were built into the code whereas others were added as functionality needing configuration. For example, by default sandboxing and debugging were both added as inherent functions that were built into the code to make it more secure. However, the use of authentication, Secure Sockets Layer (SSL) use and other encryption methods are those that are built in but need to be configured for use. Certificates were added to allow for web content to be verified via trusted sources.
As mentioned, Java is more secure, however you need to configure it because by default it’s not locked down or hardened. To configure security features such as digital signing and the allowing of trusted content, you need to open the Java Control Panel applet to set specific security settings. As seen in Figure 6.3, to configure certificates for use, and/or verify that the certificates in use are valid, click on the Security tab. By selecting Certificates, you can view and modify the installed certificates for use.
Figure 6.3 Configure Security within Java
When Java 1.1 was released, security for signed applets was implemented. What this means is that when trusted applets are prompted for download and installation, a check can be run to validate the source of the content. That means that the JRE will attempt to alert the end user that the download has been trusted (or not) by a digital certificate. For example, it’s important to consider that if you were going to download an applet from Oracle, you may consider it to be trusted by nature; however it will still prompt you. By verifying the certificate, attacks can be mitigated. By selecting that the source is always trusted, you may get into trouble if you are redirected to a site that may appear to be Oracles website, but is not. This is how security can be thwarted, if in fact the end user doesn’t realize that even though the source is Oracle, there is an untrusted or un-validated certificate being presented.
You can also select more security features to mitigate attack. You should also click on the Advanced tab to configure more granular security within Java. By selecting Security, you can check or uncheck specific security settings as seen in Figure 6.4
Figure 6.4 Configuring Advanced Java Security Settings
Pay close attention to specific settings that are enabled and disabled by default. For example, you will want to uncheck options such as Allow user to grant permissions to signed content and Allow user to grant permissions to content from untrusted sources. You will also want to check the option for Check certifications for revocation and Enable online certificate validation.
Note
When considering ActiveX and Java, they are similar however very different by design. Yes, both are active content and install an application directly into your system, however when considering the desktop platform being used (such as Windows 7 as an example), each provides different functionality when used. For instance, let’s consider that ActiveX has always been proprietary to Microsoft technologies. That being said, there are underlying functions that allow ActiveX to work directly with Windows operating systems and Internet Explorer. When considering security, ActiveX uses what is called a kill bit to control a vulnerable applet. This works in conjunction with Windows Update. This kill bit will prevent an ActiveX control being used with Internet Explorer. There is no counterpart for Java. This kill bit is used as a secondary layer of security when Digital Certificates are used. This makes ActiveX slightly more secure than Java because it’s controlled by Microsoft. However, that means that Microsoft would have to be trusted as well. Java, when only relying on certificates, puts more risk to the user because you would have to know that the certificate is authentic, and you would also have to ensure that that the Certification Authority (CA) verified the true identity of the certificate representative. At least with ActiveX, you can expect a second layer of security with the kill bit.
As you can see, there are many ways that Java can be exploited, as equal to and or to a greater extent than its Microsoft counterpart, ActiveX. You must also consider that Java ties in with many other vendor software platforms creating an additional threat. Consider the many clients that can be used, for example Cisco management programs, Adobe software and even open-source browsers such as Konqueror usually found on free Linux systems. There are many exploits to be found there as well, not only in the Java platform itself.
Warning
Java itself has many known exploits such as well-known exploitable functions such as the Java Runtime Environment applet privilege escalation vulnerability which is problematic directly to JRE, a Java Plug-in fails to restrict access to private Java packages, which relates directly to additional functions added to Java, Java fails to properly validate Java applet signatures which is an attack aimed directly at its certificate security, the Java Runtime Environment Image Parsing Code buffer overflow vulnerability which is used to put pressure on Java’s buffering internals, the Java Reflection API security bypass vulnerabilities which is aimed directly at the API, the Java Web Start security bypass vulnerability which is directed at the Web Start tool, the Java Management Extensions privilege escalation vulnerability which is another extension used for managing Java, and the Java Runtime Environment vulnerable to DoS which is specific to denying service to Java through the JRE. The vulnerabilities are endless and the only way to protect against these specific types of exploits is to update your Java application. Also consider that as mentioned before, tools used with Java are also at risk. Such as is the case with Konqueror which fails to restrict access to Java classes, how Adobe PhotoDeluxe does not adequately restrict Java execution, how Apple QuickTime for Java may allow Java applets to gain elevated privileges and the Apple QuickTime for Java security bypass vulnerability. Make sure that you test all end systems and update Java to its most secure version and then configure it securely as much as possible.
JavaScript Related Risks
JavaScript (or ECMA Script), is widely used in today’s web environment to supply functionality, flexibility and enhanced use of the web. Users of the web can thank JavaScript for performing tasks such as validating web forms, making interactive buttons, presenting content, and many other common and not so common tasks. JavaScript has proliferated to the point where just about every major browser supports the technology and is able to process the scripts.
Note
Some security researchers have suggested that users disable the use of JavaScript in their web browsers altogether due to the very real security dangers. While most users would find the sudden lack or drop of usability during their web browsing experience to be less than acceptable it does make a valuable point with the technology and security in general namely the balance between security and convenience. For example, consider if the security risks introduced by JavaScript are enough to make one sacrifice convenience or is the convenience more important than the security. This is a problem and question that each client and organizations will have to solve for themselves in turn.
Securing JavaScript
Potentially JavaScript’s biggest problem is this same widespread support together with the ability inherent in JavaScript to run without any interaction and a problem starts to take shape. When interaction is not required a client may be running code that is performing tasks such as gathering information on the client configuration, scanning the network, or even locating and retrieving settings from a wireless access point to name a few dangers. To protect from these dangers, you should disable JavaScript, or configure your web browser to prompt you when it’s in use. For example, if using Microsoft IE, you can configure scripting as seen in Figure 6.5.
Figure 6.5 Configuring JavaScript Security Settings in IE
Here you can disable JavaScript, or set prompting. In Chapter 10 we will cover hardening in details, however it’s safe to assume that by at least giving yourself a prompt, you can interact with what is attempting to happen in your browser which gives you more control.
Firefox and other browsers offer the same level of protection For example, with Firefox you can configure JavaScript within the security settings as seen in Figure 6.6
Figure 6.6 Configuring JavaScript Security Settings in Firefox.
Here, you can enable or disable its use, or customize it by configuring what its allowed to do such as disable or replace context menus. As you can see, there is little you can do to control it overall, you can simply enable or disable it or give other optional functionality.
With Apple Safari, you have the same level of control as seen in Figure 6.7. You can enable or disable it only. When selecting a browser to use, these are factors you may want to consider.
Figure 6.7 Configuring Adobe x Security Settings
The ability to configure JavaScript security is seemingly endless as seen in Figure 6.8, where you can enable and disable and configure optional security settings within the Adobe Reader.
Figure 6.8 Configuring JavaScript Security Settings in Adobe Reader
As you can see, there is no global on and off button for JavaScipt, and it is used absolutely everywhere you can think or imagine. It should also be noted that like ActiveX and Java, vulnerabilities can share other application usage, such as in the case with XMLHttpRequest Object security bypass in Opera Web Browser and Apache Tomcat vulnerable to Cross-Site Scripting via passing of user input direct both sourced with JavaScript, Apple Safari vulnerable to XSS attacks via the processing of JavaScript URLs, Adobe Reader and Acrobat customDictionaryOpen() and getAnnots() JavaScript vulnerabilities found within their tools, Mozilla products vulnerable to memory corruption in the JavaScript engine, Microsoft Windows Media Player ActiveX control allows execution of JavaScript in “already open” frames, Apple Safari contains a memory corruption issue in the handling of JavaScript arrays by WebKit and on and on. Most times, the fix is to be cautious about where you travel on the web, disable scripting and/or upgrade your browser.
Adobe Flash Related Risks
Flash is by far a staple in the modern web browsing environment and one can expect any browser of consequence to support this technology (except ones used on the iPhone and iPad as an example). Flash has offered a diverse range of capabilities including interactivity, media support, and the creation of web applications of various types. While Flash has offered tremendous benefits to the web client it has also introduced many security vulnerabilities including buffer overflows, adware, spyware, rogue content, and many others. Probably one of the bigger concerns in the security arena is the fact that users expect to have support for Flash content and want the content that is created with it such as streaming video and other media. Users on the client side may in fact ignore the security risks presented even if prompted by Flash that there is a danger involved because they wish to view whatever content is present.
Just like the other technologies mentioned like JavaScript, its difficult to turn off Flash because it’s so widely used and helpful as an enable of active content, however its riddled with problems none the same. It’s also patched constantly and comes with a flurry of its own security tools combined with constant updates to the base application. Yes, it will and can prompt you for use, however its tedious and unfriendly. As well, prompting can also be thwarted fairly easily.
Securing Adobe Flash
Some advanced steps that can be taken to protect Flash are to configure it securely. As seen in Figure 6.9, there are ways to secure Flash by clearing caches, configuring updates and controlling ActiveX.
Figure 6.9 Configuring Adobe Flash Security Settings
Warning
Flash although used in all supported browsers is seemingly the same application, its actually quite different from browser to browser even when all installed on the same system. For example, Internet Explorer uses an ActiveX version of Flash, while Firefox and others do not. Also, you should be continuous of the fact that when Flash updates are installed, you most times have to go back in to put your security settings back in place so be aware that any time you update it, you need to also reconfigure it.
Also, be aware that ActionScript is another component of Adobe Flash, the scripting language that produces Flash-based solutions. In particular, there was an exploit where Adobe Flash 10.1 ActionScript AVM1 ActionPush had a vulnerability which allowed a remote attacker to execute arbitrary code. This was a problem associated with the Virtual Machine used with Flash and could only be solved with an update of Flash, another problematic issue to the security professional. How do you fix this type of problem when Flash is embedded into multiple applications and browsers on a single client system and multiple versions of Flash are in use? The answer is clear, we must be vigilant.
VBScript Related Risks
VBScript is yet another scripting language designed to carry out tasks and actions within the browser. While Microsoft developed this language with the intention that it would become cross-browser it never really became that and is now unique to the Microsoft Windows Internet Explorer browser. VBScript shares many similarities with JavaScript, but does not enjoy the wide use and support that the latter has mostly due to its limited compatibility, or non-existent compatibility with other browsers. While the ability to support and run a scripting language such as JavaScript or VBScript allows web designers to add a significant amount of features and interactivity to a web page it also adds to the security risks. In most web browsers the default configuration enables scripting support, which can introduce multiple problems, such as Cross-Site Scripting (XSS) attacks, buffer overflows and elevated privileges.
Securing VBScript
VBScript is a derivative of Visual Basic, much like JavaScript is a derivative of Java. Scripting languages are commonly just as difficult to secure as their full-blown software counterparts. With VBScript, much like JavaScript, the same proprietary nature is found with ties to its owner, in this case Microsoft. Because Microsoft is in tune with keeping their products and tools updated and security holes patched, you will find the same level of problems and fixes involved. For example, Internet Explorer had a VBScript Windows Help arbitrary code execution vulnerability that allowed access to information on your system. As documented (and fixed) by Microsoft, the vulnerability could allow remote code execution when a malicious website displayed a specially crafted dialog box on a Web page and the affected user pressed the F1 key, causing the Windows Help System to be started with a Windows Help File provided by the attacker. If the logged in user had administrative rights, the attacker who successfully exploited this vulnerability could take complete control of the system. This was patched with an update.
The point of this is, even if you locked down everything in your path, your system could still be taken over completely by asking for help from the Microsoft help system.
Did You Know?
Stay Vigilant
Most web browsers employ security models to prevent scripts in a web site from accessing data in a different domain. These security models are primarily based on the Netscape Same Origin Policy. Internet Explorer also has a policy to enforce security zone separation. Vulnerabilities that violate these security models can be used to perform actions that a site could not normally perform. The impact can be similar to a cross-site scripting vulnerability. However, if vulnerabilities allow for an attacker to cross into the local machine zone or other protected areas; the attacker may be able to execute arbitrary commands on the vulnerable system. Technically you will have to rely on a combination of security applied to the system, the applications, keeping everything as up to date as possible and staying on top of security updates from every vendor and user education. Even then, every single defense in depth application you have tried can still be thwarted. It should be very clear to anyone in the security profession that this is not an easy challenge, and one that we continue to embark on solving to this day.
Browser-Based Defenses
So how do we deal with these security risks and the others introduced through the use of dynamic content? One possible solution is to lean on the creators of the various browsers which have provided technologies and features designed to provide protection to the client and thwart or at least mitigate the dangers posed by web content. Is the answer to force standardization? Open-source versus closed-source solutions? What about attempting to stay on top of every solution in use with teams of engineers and developers to combat every attempt at the client… there simply is no easy answer to these questions.
In this section we will examine what we can do and that is to harden the systems and use the features each browser provides and how these features provide a much needed defense in the war between client and the web.
Internet Explorer
Internet Explorer has evolved dramatically over the last several years and part of this evolution has included the inclusion and improvement of security features. Microsoft has dedicated a serious amount of resources towards making their browser safer and has succeeded to a great degree; some of the features that improve security include sandboxing, privacy control and policy control.
Sandboxing
Starting with Internet Explorer 7 on Windows Vista Microsoft introduced a robust sandboxing model designed to limit the access that browser based content has to the system. This feature, known as Protected Mode, limits browser based content’s access to the temporary folder used to cache Internet content and a virtualized part of the registry. When protected mode is in effect it limits the access dynamic content has to the host system to include all the content types covered so far including JavaScript, ActiveX, Java, Silverlight, and others.
The User Account Control (UAC) settings in Windows 7 as seen in Figure 6.10, is the underlying operating system tool used to make sure that things stay in their place.
Figure 6.10 Configuring User Account Control (UAC) Settings
The UAC functions by limiting applications privilege levels and when an administrative function is called (like installing software as an example), it requests these specific privileges before continuing. Installing ActiveX controls is a major trigger for UAC to validate the request via the UAC.
With the limited access provided via this mode several attacks designed to steal information from the host system are severely curtailed. It is recommended that you keep the UAC on and do not turn it off, as that would turn off the sandboxing features.
Warning
In Microsoft Windows Vista and Microsoft Windows 7 users have been known to shut off the UAC or User Account Control. This feature was almost universally despised by users of the Windows Vista operating system because of its perceived and very real intrusiveness into the operation of the computer. Users wishing to eliminate or reduce the “nagging” nature of the UAC frequently shut it off to eliminate its invasive nature. The downside of this action however was the fact that shutting off the UAC also resulted in Protected Mode not being functional therefore reducing the security of the system all around.
Privacy Settings
One of the biggest targets of client-side attacks is the personal information that is present on a client system. To protect this information Microsoft, along with other vendors, has provided a suite of privacy settings designed to reduce the possibility of this information getting taking from a client system. The sensitivity of these mechanisms and what they block can be adjusted through a series of controls present in the Internet Explorer browser. Figure 6.11 shows how privacy settings are adjusted in Windows 7.
Figure 6.11 Configuring Internet Explorer Privacy Settings
With these settings a user can determine what types of cookies and other information are stored on a client system and the types of circumstances that will allow their storage. With these settings active information that would identify the user, name and version of operating system, system preferences, DLL versions, e-mail address, and other types of information.
A user can adjust their privacy settings in Internet Explorer to enhance privacy by selecting which sites can be visited, adjusting overall security that will allow cookies to be blocked, disallow location verification, configure InPrivate browsing settings and adjusting the Pop-up Blocker.
Note
Users can also override the cookie handling for individual websites, and allow or block the websites to use a cookie’s information.
Automatic Crash Recovery
In the past when a browser crashed the result was always very similar which meant that data was lost regarding a browsing session and in a number of cases, reboots. In today’s browsing environment this crash could result in the loss of data from multiple tabs making the situation even worse than before. In newer versions of the Internet Explorer content, such as dynamic content, that destabilizes a session and crashes a tab it only affects that tab. In the event that a browser crashes completely (which is still very much possible) the information about each session or sessions are saved and the browser restarts restoring the sessions as before. While this feature does not eliminate the dangers posed by malicious or poorly designed content it does have the advantage of at least increasing availability of the browser.
SmartScreen Filter
Starting with Internet Explorer 8 Microsoft introduced a new feature known as SmartScreen designed to stop the distribution of some types of malicious software. The goal of this feature is to block fake or malicious sites from distributing questionable or downright malicious software to the victim’s system. While this feature can be disabled by the user if they so choose doing so would actually lower the security profile of a system by some amount. With this feature enabled visiting a site that is recognized as being unsafe (as designated by Microsoft) a page with a warning will appear warning the user that continuing on to the site could be risky and lead to their system being compromised. The user can choose to disregard this advice and continue on, but the warning lets them know that doing so would be inadvisable; this option can be disabled in corporate environments if desired. This feature probably represents one of the biggest improvements in security in Internet Explorer mainly because it provides real protection against situations where users may visit a site and not recognize it as being unsafe. You can turn on this feature in the Tools menus by selecting to turn on the SmartScreen filter.
Cross-Site Scripting Filter
As we have discussed in Chapters 3 and 4, cross-site scripting (XSS) attacks are some of the most common and dangerous exploits against Web users. XSS allows malicious code to be injected into Web pages that can lead to information disclosure and identity theft. With this feature present in Internet Explorer 8 and above these attack are rendered impotent and therefore less of a threat to the user themselves.
Certificate Support
While not exactly a new feature in Internet Explorer it is worth mentioning as it does provide some important security features.
There are two types of certificates that can be configured and used within the browser:
Personal Certificates: This type of certificate provides verification of an individual’s identity over the Internet. This certificate can be used to provide information which is used when a user sends personal information over the Internet to a website that requires a certificate, verifying their identity.
Website Certificate: These types of certificates are used to assert that a website is safe, secure, and genuine. Through use of these types of certificates a website can be positively identified as the certificate ensures that the presenter is who they claim to be. Use of these certificates ensures that no other website can assume the identity of the intended, secure site. In this way when a user submits personal information over the Internet, they must check the certificate of that website to ensure that it will protect his personally identifiable information. When users download software from a website, they can use the certificates to verify that the software is coming from a reliable source. Additionally these types of certificates are integral in assuring the security of submitted content through the use of Secure Sockets Layer or SSL.
InPrivate Browsing
This mode is a new feature in the Internet Explorer product line that allows for a level of security not previously seen in the Microsoft browser line. Through the use of this mode information collected during browsing sessions is highly restricted and safely handled. Through the use of this mode information on your browsing habits are protected from others who may use the computer after you. By extension if information is not left behind after a browsing session it also means that potential attackers or malicious code cannot retrieve it as readily. The downside of this mode is that tabs not opened in the current browser session will not be protected by InPrivate Browsing and may indeed be accessible by unintended processes. During the surfing process Internet Explorer does store information such as cookies and temporary Internet files—so that the web pages visited will work correctly. However, at the end of the InPrivate Browsing session, this information is purged from the system. This function can be turned on within the Tools menu of Internet Explorer.
Security zones
A feature available since the early versions of Internet Explorer is one that is used to control or modify the behavior of the browser when visiting specified websites. Security zones are designed to empower users on the client-side to establish different levels of security based on the perceived level of confidence regarding a site. Each zone can have sites assigned to it which will either restrict or allow content to run based on the individual settings. By placing sites as desired in each zone the client can prevent different types of active and other content from running therefore preventing a security risk. Content that can be controlled through the use of security zones include content such as ActiveX, Java, JavaScript, and other dynamic or active content. You can configure Security Zones in the Internet Options Security tab as seen in Figure 6.12.
Figure 6.12 Configuring Internet Explorer Security Zones
Here, you can adjust the Internet, Local Intranet, Trusted Sites and Restricted Sites zones and configure them independently with specific settings such as disabling scripts, enabling functionality specific to each zone and security to each zone.
By default there exist four different security zones present in Internet Explorer: Internet, Local Intranet, Trusted Sites, and Restricted Sites. Each of the four zones have been assigned default security settings by Microsoft such as (Low, Medium-Low, Medium, and High) which determine the types of content that can be downloaded and/or executed and what a user can do on a website. A user may elect at any time to alter the security levels and modify the security defaults for any of the zones. Any action that a user carries out such as opening files or performing downloads will be screen against the settings for the applicable zone and will be allowed or denied based on the situation.
The settings for these zones are as follows, per Microsoft:
Internet: By default, the Internet zone includes anything that is not on a user computer, on an intranet, or which is not assigned to any other zone. The default security level for this zone is Medium.
Local Intranet: It typically includes the trusted content inside the company’s firewall, such as sites on the company’s network. The default security level for this zone is Medium. A user can change it as per his or her requirement.
Trusted Sites: It consists of sites that are trusted by the user. A user can place such sites to this zone. The default security level for this zone is Low.
Restricted Sites: The sites that a user does not trust or trust less than the rest of the Internet are placed in this zone. The default security level for this zone is High.
Did You Know?
These zone settings may be adjusted per zone based on individual user needs and requirements. However in some corporate or enterprise environments it may not be desirable to allow this to happen, in these cases it is possible to use features such as Active Directory’s Group Policy feature to enforce the settings organization wide.
Content Advisor
Probably one of the least understood and used features in Internet Explorer is a feature known as the Content Advisor. This feature, available in many later versions of Internet Explorer, can regulate the types of content and sites that can be viewed and visited by a browser successfully. Through use of this feature a client can configure which websites are able to be viewed and which are not. This screening of content is based on the guidelines of the Internet Content Rating Association (ICRA). When Content Advisor is enabled, a user can view only Web content that is rated and meets or exceeds the specified criteria. A user can adjust the settings by moving the slider left and right to reflect what they believe to be appropriate content based on their desires such as language, nudity, sex, and violence.
Internet Explorer has clearly evolved over the years and offers many features designed to stop many of the well-known attacks, plus other features designed to protect the user from those lesser known attacks as well.
One of the biggest problems with Microsoft’s Internet Explorer (IE) is that the web browser is integrated directly into the Microsoft Windows operating system. Due to this tight integration removal of this application is not practical or even possible in most cases. Therefore anything Internet Explorer is vulnerable to may very easily be something that weakens the operating system itself.
Note
While it is true that Internet Explorer is integrated into every version of the operating system since Windows 98 there are some exceptions. In geographies such as Europe it is possible, however unlikely, to encounter versions of the Windows operating system without Internet Explorer. In these versions, which add the suffix “N” to their name, Internet Explorer and Media Player have been excised from the operating system due to a legal ruling by the European Union. However it is unlikely that you will ever run into these versions “In the Wild” due to the fact that most individuals that bought a computer did not want nor even know about these versions and therefore they never propagated all that much. These versions are mentioned here just for the sake of completeness, but they are not considered in the discussion as they are so rare as to be inconsequential.
One of the other issues with Internet Explorer is its broad support of active content of so many types. The browser’s ability to support many scripting languages and development languages such as Java, ActiveX, Silverlight, and JavaScript is in line with other browsers on the market. While any application of any level of complexity is potentially vulnerable to attack, it is possible to mitigate or eliminate some of the more serious weaknesses by using a web browser that does not support ActiveX controls.
Of course using a different browser can affect the functionality of a great number of sites due to the fact that ActiveX controls are very common and some sites may not function without them. Note that using a different web browser will not remove IE, or other Windows components from the system.
Mozilla Firefox
Since Mozilla Firefox was initially released in 2004 it has seen a tremendous amount of upgrades and improvements due in no small part to its rabid developer community. Firefox has been hailed by many to be one of the most secure browser available, while this may be a matter of opinion there is no debating that the browser does offer many security features that make it safer than it would be otherwise.
In this section we will explore the features that make Firefox a secure browser and how these features make for a safer browsing experience.
Sandboxing
Much like Internet Explorer on Windows, Firefox utilizes a robust sandboxing model designed to limit the access that browser based content has to the system. This feature is inherent in Firefox and does not require and special settings on the host system to be in effect. While it is active however it limits the access browser based content’s to the temporary folder used to cache Internet content. This protection, much like what is in Internet Explorer, limits the access dynamic content has to the host system to include all the content types covered so far including JavaScript, ActiveX, Java, Silverlight and others. With the limited access provided via this mode several attacks designed to steal information from the host system are severely curtailed.
Did You Know?
Sandboxing in Firefox is integrated much more tightly and is arguably more robust than in Internet Explorer. In Firefox the sandbox model has been present from the very beginning whereas in Internet Explorer this was not present until version 7 with Windows Vista. In versions of the IE prior to version 7 it was possible to achieve a sandboxed state, but third-party software was required to make this happen.
Crash Protection
Similar to Automatic Crash Protection in Internet Explorer is the Crash Protection feature in Firefox. The objective of this feature is to provide an uninterrupted browsing experience across platforms such as Windows and Linux, for users when a crash occurs in any plugin such as Adobe Flash, Apple QuickTime or Microsoft Silverlight. In the event that one of these or any other plugin crashes the browser will isolate the problem and usually prevent the loss of data and information. Through the use of this feature disruptions caused by poorly designed, implemented, or malicious plugins can be substantially reduced or eliminated in many cases.
Instant Web Site ID
This feature is designed to counter the dangers posed by visiting bogus or malicious sites that are masquerading as legitimate ones. With the increasing presence and threat posed by fake or malicious sites this feature can verify a site and ensure that the location being visited is what it presents itself to be.
Improved Phishing Prevention
Newly introduced in later versions of the Firefox browser is this feature that also mitigates the attacks caused by Phishing. This feature is designed to display a warning message within the browser informing the client that they are visiting a site that may be of a questionable nature. The intention here is that the client receives a much more obvious and “aggressive” warning as to the nature of the website they are visiting and therefore, hopefully, avoid the theft of information.
Improved Malware Protection
This feature is targeted towards those attacks that may be enacted when a client visits a location that may attempt to install malware on their system. The idea is that when a user visits a site they will receive a very visible warning informing them as to why they should not proceed on to the intended website. Mozilla uses this feature to scan and identify the components of a website looking for any item or feature that may be in place to steal information from the client.
Forget this Site
This feature in versions of FireFox 3.5 and higher is designed to allow the user to remove as much or as little information from the browsing session as is desired. In its most aggressive configuration this feature can remove literally every shred of evidence left behind from a browsing session. Users will find this feature helpful for covering their tracks, but it is also useful as it eliminates the “tracks” that are left behind that may be gathered by malicious software or sites.
Clear Recent History
In Chapters 2 and 3 we observed how it was possible to use scripting to extract information regarding a user’s browsing history from a system. Using this feature it is possible to remove as much information from a system as is desired. This feature even has the ability to move beyond just removing browsing history and moving toward removing private data including cookies and other items.
Note
Of course no security feature is infallible and even with the best of planning they can be circumvented or overridden. In the past, a Trojan was analyzed by Webroot (www.webroot.com) was said to rely on retrieving web page passwords from a browser’s password storage, rather than logging a user’s keyboard inputs. To make sure it would find all the interesting passwords in Firefox, the malware, called PWS-Nslog, made some changes to manipulate the browser. A few manipulations in a JavaScript file prompted Firefox to store log-in information automatically and without requesting the user’s consent. The malware would then, for instance, simply comment out Firefox’s confirmation request in the nsLoginManagerPrompter.js file and add a line with automatic storage instructions. The manipulation worked on all platforms on which the Trojan had the rights to modify the nsLoginManagerPrompter.js file. In tests, this worked on Windows XP, Windows 7, and Ubuntu 10.04. However, on Windows 7 and Ubuntu the user was usually working with limited privileges by default, and under these circumstances the malware was unable to manipulate the file. According to Webroot, the malware author did not put any effort into covering his tracks, as the malware contained a name as well as a Gmail address. Furthermore, Webroot soon found the Facebook page of the allegedly Iranian developer who claimed he develops crimeware for fun. This is further proof that a dedicated mind with the knowledge to perpetrate an attack (whether malicious or not) can thwart any type of security you are engaged in providing, whether it be baked into the application itself or something you specifically attempt to mitigate using other means.
Add-ons
The browser will require a secured session before downloading any add-on or other similar types of third-party software to download onto a client system. Add-ons are one of the extremely popular benefits and features of the Firefox browser, but the feature does have its downside in that illegitimate add-ons may be downloaded and installed. Figure 6.13 shows the add-on manager within Firefox.
Figure 6.13 Configuring Firefox Add-ons
By using this feature some of these downloads of untrustworthy software may be thwarted by ensuring that the source is legitimate. When using the add-on manager, remember that the browsers security can be enhanced by specific security extensions, but could also potentially be put at risk by others. Make sure that you choose wisely from trusted publishers and limit what you install on your system based on need and functionality.
Note
It is worth noting that over the past couple years there have been at least two cases where add-ons were downloading and installed by a large number of the users of Firefox only to later discover that the software was spyware. In both cases the add-ons were downloaded from Mozilla’s own website by developers that were not properly vetted.
Anti-virus Integration
Much like Internet Explorer, newer versions of Firefox have addressed a weakness that exists in previous versions which is the potential downloading of malicious software by a user. Scenarios where a user visited a site and downloaded a piece of software that was questionable at best could be made worse when the software was not screened during the download process. In newer versions of Firefox this software is screened by integrated anti-virus software present on the user’s system. If malicious or questionable software is detected it is blocked and the user warned.
Note
Users may still render themselves vulnerable if they choose not to install an anti-virus package in which case this feature will not help. Firefox, like most browsers, does not actually have any anti-virus capabilities built in, but relies on the system itself to provide these capabilities and integrate with them where appropriate.
Mozilla Firefox has enjoyed great success because of its cross platform support and robustness, something that Internet Explorer cannot offer. Due to its Open Source nature and robust developer community Firefox has been able to emerge as a secure platform for web browsing.
Google Chrome
Google Chrome has quickly become a popular choice in the browser “wars” with its lightweight design and innovative feature set. Chrome is rapidly appearing on more and more desktops and as such the security features are something you must consider.
Sandboxing
This feature offers the same protection here as in the other browsers mentioned in this chapter so process-wise it is operating the same way. However, much like Firefox, sandboxing is built into and working natively with Chrome instead of the way it works with Internet Explorer which is dependent on the operating system itself. Ideally with sandboxing in effect in Chrome the risk of malicious software being installed on the host is reduced.
Safe Browsing and Content Control
Much like the feature in Firefox the Safe Browsing feature in Chrome presents a warning that is very visible to the user. The idea is the same as with Firefox where the warning is meant to inform the user that they are visiting a site that is risky at best. The user can opt to continue on if they so wish, but they must actually approve the action by checking in a box and moving forward. Of course this feature is not foolproof as a user can opt to continue on to the site much like with the other browsers; however it does inform them of the risk they may be assuming. This feature is intended to reduce the threats presented by malware and phishing and because of the obvious warnings presented to the user (which hopefully they heed).
Content control is also critical to security your browser as seen in Figure 6.14. Here, you can see how content can be enabled or disabled based on what type of content you want to see or use. For example, you can enable or disable JavaScript to protect your system.
Figure 6.14 Setting Security Settings on Google Chrome
ClickJacking Protection with X-Frame-Options
This feature allows web browsers to defend themselves against clickjacking attacks. These types of attacks are designed to get the user to reveal confidential information by clicking on seemingly harmless links on innocent looking web pages only to have those links appropriate confidential information. This feature allows savvy developers to use what is known as the deny HTTP header, to make sure that the webpage will not get loaded inside a frame, making it difficult if not impossible for attackers to conceal malicious links within legitimate ones.
Reflective XSS Protection
Cross-site Scripting (XSS), as we have explored in Chapters 2 and 3, is still a very real and dangerous attack against clients. To reduce the level of risk associated with XSS Google Chrome, much like other browsers, Google Chrome has introduced robust XSS filtering mechanisms designed to check and address these attacks. In practice Google Chrome checks a page or piece of content when it is downloading and looks for evidence of any script that may be running from a location other than where the page was retrieved from.
CSRF Protection via Origin Header
This feature is designed to eliminate or mitigate cross-site request forgery attacks, making it difficult or near impossible to subvert the server and fool the server into executing an action “requested” by a malicious site.
Strict-Transport-Security
Empower the browser by allowing to go beyond requesting and actually force a secure session between the client and server. When operating the browser will always use HTTPS to connect to a site and will treat any and all HTTPS errors as hard stops and not merely prompt the user to “click through” any certificate errors.
Cross-Origin Communication with PostMessage
PostMessage provides a richer interaction and more secure communication between frames, and enables the creation of more secure versions of existing gadgets.
Supporting the Browser
Of course the features inside the browser are not the only defenses that are available nor should they be relied upon as such. The browser should, and must, be supported by robust and well placed security measures to provide total and complete protection against threats. While there is not enough space here to discuss all the possible defenses available with every browser and every operating system we can focus on at least a couple of the major defenses available to protect the client, namely anti-viruses and anti-spyware.
The Role of Anti-virus Software
One of the best defenses against client-side, and other attacks for that matter, is the anti-virus package. Anti-viruses have been around the computer and technology world for quite a long time and have provided protection against the many types of malicious code present online and off. If working correctly a properly installed, configured and maintained anti-virus package can prevent, detect and remove all types of malware and malicious code. Modern anti-virus packages even add the ability to scan downloads, installations, and integrate with the host operating system and application applications running on it which provides a tremendous benefit to the client. The key to using anti-virus is to make sure you positively ensure that it’s up to date and running the most current virus definitions used to scan to problematic software. You must also make sure that its running as you need it to, for example running and scanning current memory usage and when running scans, scanning the entire system and not just a subset of it.
Did You Know?
Anti-viruse packages have been present in some shape or form since the late 1980s and have evolved dramatically since that time. New techniques and technologies have been introduced that have made detection and removal of malware more complete.
For an anti-virus package to properly protect a system from a client-side attack it should possess a few key features (in no particular order):
Regular Updates: Any anti-virus package that does not regularly provide updates to its database or scanning engine will quickly become worthless.
Operating System Integration: While not exactly vital, it is advantageous to have close integration between the anti-virus application and the operating system. Such integration allows for the more accurate detection, monitoring and removal of malicious code.
Application Integration: Applications and anti-virus applications that can more closely integrate such as email clients and web browsers can allow for early detection and prevention of infections in a number of situations.
Of course the one item that makes an anti-virus effective against client-side attacks is actually having one installed and using it. In fact it is still common to come across systems that do not have any anti-virus application installed on them at all. It could probably be successfully argued that a much smaller percentage actually keeps their package updated.
The Role of Anti-Spyware
One of the attack vectors that has come up repeatedly in this chapter is malware, well malware is not just viruses and worms it is adware and spyware of all types as well. To stop this malware not only is a good anti-virus (AV) required, but so is a good anti-spyware application. Anti-spyware is an application that can come bundled as part of a security suite or as a standalone, but in either case it provides the same function which is to detect, remove and prevent spyware infestations on a client system. It’s different in the sense that it specifically looks for spyware and adware, which is software that is installed on computer system and collects specific information about the end user and their computer use habits. Malware like viruses and worms tend to cause issues, harm or damage, not spy on a user’s habits.
No matter the anti-spyware application is can prevent or deal with attempted or successful infiltrations in one of two ways:
Prevention: An anti-spyware package will attempt to thwart an infection of a system by monitoring internet access and the installation of software looking for and preventing the installation of suspicious software. In this mode the application operates in real time monitoring the system activities and looking for suspect behavior.
Detection: Packages can also be used to detect the presence of spyware on a system and use a range of technologies and techniques to remove the infestation. In this mode it is quite common to have the package offer scheduling and be able to routinely update and look for activity.
Note
Although Apple Safari, Opera and other browsers are not covered in detail in this chapter does not mean they should be forgotten about. As we covered with Internet Explorer, Firefox and Chrome, the other browsers you may use should also be locked down and updated as we did with the ones we covered and learned about here. For example, as you can see, Java problem can extend from browser to browser and behave differently, and/or affect the target browser differently. Since this is not a book soley based on learning the details about every single application available today, take the lessons learned here and apply them to all other applications you use in your environment. And not only web browsers, every application is at risk if it interacts with active web content. As we learned with Adobe products, everything is at risk and in most cases has been altered throughout time to be able to secure against client-side attack.
Summary
In this chapter we learned how specific active web content can be used against your browsers. We also discussed what browsers can offer in the way of protective mechanisms to prevent client-side attacks. While there are a seemingly endless number of client-side attacks that are possible it is also worth noting that there are also a large number of defenses available that can thwart an attack. Each of the defenses a browser and host system offers can provide a layer of protection that may make the difference between a successful and a failed attack.
One of the lessons that should have become evident within this chapter is that browsers not only are an ideal method for an attack to start, but an ideal tool in thwarting these attacks. In Chapter 5 we saw several ways through which a browser could be compromised and allow a system to be attacked. In this chapter some of the defenses that the mainstream browsers Internet Explorer, Firefox and Chrome offer were presented and a concise look into each browser was taken to show the features it has available to mitigate attacks.