2.BrowserSecurity.tex

\epigraph{In theory, one can build provably secure systems. In theory, theory can be applied to practice but in practice, it can't.}%
{\textsc{M. Dacier, Eurecom Institute}}


%\section{On Browser Security}
\label{sec:2.browser_security}

  Next pages will be dedicated to an overview of the field of browser security. Ranging from history and development to current threats and challenges, the discussion will encompass today's most important boundaries between user's sensitive data and linked attacks. Later chapters will elaborate on how to cross these boundaries regardless of how well they are protected and hardened. Consequently, this thesis will introduce and propose a novel approach regarding security for browsers, websites and their users towards shielding them from threats based on scripting attacks.

  \section{Introduction and Overview}
  \label{subsec:2.1.introduction_and_overview_bro_sec}

  The web and its purposes have drastically changed in shape and magnitude since the first web browser called WorldWideWeb~\footnote{Berners-Lee, \textit{The WorldWideWeb browser}, \url{http://www.w3.org/People/Berners-Lee/WorldWideWeb.html} (Nov 2004)} was written and put to use in the early 1990s. Today a web browser has to be able to not only request and process documents from arbitrary domains using HTTP and several other protocols, but it serves as an extremely versatile operating-system-like instance, allowing file system access, printing, and using hardware acceleration to display videos and three-dimensional content. Modern browsers are offering mail client functionality, providing integrated Peer-To-Peer (P2P) and BitTorrent clients, Internet Relay Chat (IRC) software, download managers, and storage instances for bookmarks, personal data, passwords and much more. Browser vendors face tough competition, which we can observe by looking at percentile market share figures, and then  with apparent 
attempts to implement numerous and improved features in comparison to other user agents. Extensible architectures allow external developers to enlarge browser functionality and add novel features and customizations. Most modern user agents are supplied with multiple layout engines to enable switching to legacy and compatibility modes in case a website relies on older and deprecated functionality. \\

  User agents like Netscape, Mozilla Firefox as well as Google Chrome and the Internet Explorer allow operating system level access via proprietary interfaces such as ActiveX (MSIE) or NPAPI~\footnote{Mozilla Wiki, \textit{NPAPI}, \url{https://wiki.mozilla.org/NPAPI} (Dec 2011)}, XPConnect~\footnote{MDN, \textit{XPConnect}, \url{https://developer.mozilla.org/en/XPConnect} (Dec 2011)} or LiveConnect~\footnote{MDN, \textit{LiveConnect}, \url{https://developer.mozilla.org/en/LiveConnect} (Dec 2011)} for Webkit and Gecko-based user agents. Additionally, plug-ins can be used to further extend one browser's set of features as users can install various viewers and players such as the Adobe Reader plug-in, the Flash Player and other software. The Java plug-in deserves a special mention because several browsers provided deeply nested Java applet support even without a Java Runtime Engine (JRE) installed. Microsoft embedded a Java Virtual Machine (JVM) called MSJVM~\footnote{Microsoft Corp., \textit{Microsoft Java 
Virtual Machine Support}, \url{http://www.microsoft.com/About/Legal/EN/US/Interoperability/Java/Default.aspx} (Sep 2003)} in Internet Explorer 3, Firefox allowed Java code execution via LiveConnect even if Java support was disabled in the settings. Bugs relating to the Java plug-in, its security settings and Same Origin Policy (SOP) interpretation will be described in later sections of Chapter~\ref{ch:3:mitigation-and-bypass} and Chapter~\ref{ch:4:novel-defense-approaches}.\\ 

  Users nowadays outsource more and more tasks to the WWW and thus to their browser of choice. This applies for desktop and laptop PCs and it is of special gravity for mobile devices with their usually less up-to-date browser software. News' consumption, social interaction and networking, shopping, product research and e-commerce as well as banking and financial activities constitute the usual browser tasks. The results of research on average day Internet usage are published annually by Pew Internet \& American Life Project~\footnote{Pew Internet, \textit{Trend Data}, \url{http://www.pewinternet.org/Trend-Data/Online-Activities-Daily.aspx} (June 2011)} and on a more regular basis by Nielsen Online~\footnote{Nielsen Online, \textit{Internet Audience Metrics}, \url{http://nielsen-online.com/press.jsp?section=pr_netv&nav=3} (Dec 2011)}. Interestingly, the majority of identified activities either include storage, limited publication and selective sharing of sensitive personal information or usage of credentials 
to perform financial transactions including credit card numbers, online banking data and PINs, as well as smart-card sessions.  The browser is constantly used as mediator between the platforms providing services and the end user, often serving multiple needs at once, as several windows or tabs are opened simultaneously. One tab may contain a bank's website form initiating a money transaction, while parallel ones might be dedicated to a chat session with a stranger, or a website of doubtable origin and intent, for example showing ladies in swimsuits. \\

  Browser vendors, web application developers and other parties and stakeholders put significant effort on securing their applications. Communication with other applications and layers is also a priority. The stacked layers of communication a usual HTTP request by a user agent to the targeted web server and back make the approaches in delivering holistic security complicated -- and raise the question on where best to defend against which kind of attack pattern. 
  The following sections will attempt to outline key issues pertaining to the security threats against browsers, their users and protection mechanisms installed in modern user agents. The justification and limits of our documentation can be found in Section~\ref{subsec:2.2.bro_sec_scope} below.

  \section{Browser Security Scope}
  \label{subsec:2.2.bro_sec_scope}

  The following sections on browser security aspects will be strictly kept within indicated coverage context of this thesis. We will discuss security aspects, vulnerabilities and attacks against browser components using JavaScript or scripting techniques, but we will not be elaborating further on exploitation of crash bugs, overflows, UAF (use-after-free) bugs and alike. Some of the discussed security aspects will  include operating system-level compromise; otherwise, we mainly focus on scripting bugs attacking users of web applications and conducting attempts to steal login credential and sensitive data of similar prominence. These aspects will not be evolving around the aforementioned crash bugs, but will be clearly restricted to vulnerabilities, context mismatches between zones like websites and the local file system or internal browser components such as the Firefox Chrome window execution context. On that note, let us point out research on how to find crash bugs in browsers and similar software 
published by C. Holler in 2011~\cite{holler2011grammar}.

%TODO where are subsections 2.3-2.3.5

%   \subsection{The History of Browser Security}
%   \label{subsec:2.3.the_history_of_browser_security}
% 
%     \subsubsection{The Birth of Browser Security}
%     \label{subsubsec:2.3.1.the_birth_of_browser_security}
% 
%     \subsubsection{Features versus Security}
%     \label{subsubsec:2.3.2.features_versus_security}
% 
%     \subsubsection{The Browser Wars}
%     \label{subsubsec:2.3.3.the_browser_wars}
% 
%     \subsubsection{W3C Features and Proprietary Interfaces}
%     \label{subsubsec:2.3.4.w3c_features_and_proprietary_interfaces}
% 
%     \subsubsection{Plugins and Extensions}
%     \label{subsubsec:2.3.5.plugins_and_extensions}

  \section{Current State of Browser Security}
  \label{subsec:2.4.the_history_of_browser_security}

    The current state of browser security has over the last decade come a long way. Primarily, it has experienced incremental gains in maturity. From simple rich text parsers and layout engines towards full stack operating system like mediators between almost any user's arbitrary forms of content, browsers have become one of the most frequently used pieces of software of contemporary every day computing. Over the years, several browser vendors attempted to create APIs allowing access to different resources aside from regular web documents: This includes videos, applets, communication interfaces of other software such as Microsoft Office, databases and messaging clients. As mentioned in Section~\ref{subsec:2.1.introduction_and_overview_bro_sec}, these interfaces and features were often targeted by attackers and forced browser vendors to deploy mitigations and fixes. At the same time, they were pressured by the necessity of publishing novel features in order to compete with other vendors. \\

    The first ``browser wars'' were fought by Microsoft and Netscape, which were the dominant browser vendors in the late 1990s and several years to follow, has caused an explosion in features, APIs and implementation overkill. Those have had tremendous negative consequences that the modern web is suffering from until today. Several sources describe the state of browser core development and security as catastrophically uncoordinated, going as far as calling it a hasty assembly of no comparison~\footnote{Sink, \textit{Memoirs From the Browser Wars}, \url{http://www.ericsink.com/Browser_Wars.html} (April 2003)},~\footnote{Wikipedia, \textit{Browser Wars}, \url{http://en.wikipedia.org/wiki/Browser_wars} (Dec 2011)}. For the users of the browsers in question, a high amount of easy to spot vulnerabilities was an apparent and unsolicited side-effect. The statistics collated by Secunia Research for Microsoft Internet Explorer 5 - 9 and Netscape Navigator 4 - 9.x are shown in Table~\ref{tbl:ua-vuln-stats}. They 
clearly indicate a peak for the browser versions released during various phases of the browser wars~\footnote{Secunia, \textit{Secunia Advisories by Product}, \url{http://secunia.com/advisories/product/} (Dec 2011)}.\\

\begin{table}
  \centering
    \begin{tabular}{| l | l | l | l |}
    \hline
    UA & Advisories & Vulnerabilities & Unpatched  \\ \hline
    MSIE 5.01 & 92 & 161  & 9 \\ \hline
    MSIE 5.5  & 69 & 39  & 7 \\ \hline
    MSIE 6.0  & 155 & 260  & 23 \\ \hline
    MSIE 7.0  & 58 & 186  & 13 \\ \hline
    MSIE 8.0  & 26 & 112  & 7 \\ \hline
    MSIE 9.0  & 4 & 26  & 0 \\ \hline \hline
    Overall   & 404 & 784 & 59 \\ \hline\hline
    NN 4  & 2 & 0  & 1 \\ \hline
    NN 4.7  & 6 & 0  & 1 \\ \hline
    NN 4.8  & 3 & 0  & 0 \\ \hline
    NN 6.x  & 12 & 2  & 0 \\ \hline
    NN 7.x  & 31 & 19  & 4 \\ \hline
    NN 8.x  & 13 & 42  & 6 \\ \hline
    NN 9.x  & 4 & 24  & 0 \\ \hline \hline
    Overall & 71 & 87 & 12 \\ \hline
    \end{tabular}
    \label{tbl:ua-vuln-stats}
    \caption{User Agent vulnerability statstics by numbers (Advisories/Vulnerabilities/Unpatched). Source: Secunia.com}
\end{table}

    One can look at the significant difference between the overall number of vulnerabilities between Internet Explorer and Netscape Navigator with surprise. The explanation lies in the fact that Microsoft attempted to push for new features in a rather aggressive way in order to gain ground on Netscape and win the market over~\footnote{Craig, D., \textit{The Browser Wars -- and the collateral damage}, \url{http://strum.co.uk/webbery/browser.htm} (Jan 2002)}. Despite the frightening amount of security problems, this strategy paid off and Netscape had been continuously loosing market share and was eventually ousted. As a result, the Mozilla foundation was invoked in 2003, recycling the existing Netscape source code and creating a new browser ultimately called Firefox. In its early stages, Firefox was haunted by similar problems as Internet Explorer, that is, a large legacy code base and the lack of possibility to remove deprecated and, especially the non-standard features because of a large quantity of websites 
and applications relying on them. Thus, a transition towards a browser secure by design, moving away from patching an existing broken code-base, and creating new secure parser routines and APIs has been severely hindered in the past, and is still in process today.\\

    Change was introduced by academic research focusing on design models and implementation techniques allowing browsers to maintain a decent level of compatibility with legacy web applications and ``bad HTML''. Reis et al. describe three factors marking the pillars of browser security, which in their opinion include: Severity of vulnerabilities, window of vulnerability and frequency of exposure~\cite{reis2009browser}. Shortly afterwards, Wang et al. have introduced Gazelle, referencing Reis' work on the proposed Google Chrome architecture as they outlined their thoughts on a secure browser built. The Gazelle browser security model is constructed through isolating security principles and goes even further than the system once introduced for Google Chrome; One aspect of this security model is the attempt of isolating different sub-domains on the same domain in separate site instances~\cite{wang2009multi}.\\ 

    Today user agents have changed in a way of giving higher priority to standards-conforming behavior rather than providing proprietary interfaces designed to win over users and market share via presenting exclusive features. Nevertheless, the legacy code-base hindering more drastic steps towards secure design and implementation is still present. The Microsoft Internet Explorer has been actively deprecating and removing major features from its version 9. This trend continues with version 10 -- including HTML+TIME, Scriptlets, Data Islands and XML Script. Firefox and other Gecko-based user agents attempt to abandon technologies such as E4X, legacy getter and setter syntax. They are issuing first considerations for removing support for technologies such as LiveConnect. Persistently problematic is not the amount of websites using legacy features, but rather the browser extensions relying on them. Even so, Webkit and Google Chrome have started implementing several proprietary features not present in any 
standard, attempting to brute-force those features into the specifications by adoption figures. Among them, one can pinpoint ``stylable'' scrollbars, drag\&drop downloads and other features covered in Chapter~\ref{ch:3:mitigation-and-bypass}. Critics view these approaches as a new dawn of browser wars and they fear that history will repeat itself on the battlefield of HTML5~\footnote{The Economist, \textit{The second browser war}, \url{http://www.economist.com/node/12070730} (Sep 2008)}. All modern browser we tested have implemented novel parser and layout engines capable of handling the challenges announced by HTML5 and its dissimilar structure, when one looks and compares it to HTML4 and XHTML in particular ~\footnote{W3C, \textit{HTML5 differences from HTML4}, \url{http://www.w3.org/TR/html5-diff/} (May 2011)}.\\

    Conclusion from this section should read that browsers and browser vendors have successfully performed major leaps in terms of browser security, standards conformity and reduction of legacy code. They now clearly favor modern, faster, and more reliable parsers and APIs. The succeeding sections shall teach us more about protection mechanisms and designs employed by modern user agents, hopefully demonstrating that the attack window for former threats is getting smaller with every release. Security zone models limit execution privileges, plug-in code is being sand-boxed and, in combination with memory protection techniques, the consequences of access violations, buffer overflows and general memory corruption are not as severe as they once have been for all the affected systems. It is our belief though that this will cause a shift in attackers' paradigms and targets, pushing the field towards web applications and the DOM. These notions have received comparably less attention in the key years of developments. 
To fill this void, they need similar reconsiderations, in terms of design and implementation, as the browser core implementations from the late nineties have enjoyed and benefited from. The following chapters, including Chapter~\ref{ch:3:mitigation-and-bypass}, will discuss the attacks against web applications, the user agents script engines and the DOM.

    \subsection{Browser Applied Security Models}
    \label{subsubsec:2.4.1.browser_applied_security_models}

    Let us now turn the attention to browser-applied security models relevant for scripting attacks. Given the scope of our research, we will not elaborate on memory protection techniques utilized by user agents and several browser plug-ins such as DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization)~\footnote{Miller, \textit{On the effectiveness of DEP and ASLR}, \url{http://blogs.technet.com/b/srd/archive/2010/12/08/on-the-effectiveness-of-dep-and-aslr.aspx}, (Dec 2010)}. Instead, we will focus on the Same Origin Policy (SOP), the Internet Explorer zone model and its influence on script execution and privileges, as well as the extension security model used by gecko-based browsers and Google Chrome and Opera. Furthermore, we will add detail to the privileges for locally executed HTML documents. We will then scrutinize the possibility for scripts initiating a zone transfer from restricted zones to less restricted zones or protocol handlers and analyze the impact of such behaviors.

      \subsubsection{Same Origin Policy}
      \label{subsubsubsec:2.4.1.1.same_origin_policy}

      The concept of the Same Origin Policy (SOP) was first implemented in Netscape Navigator 2.0 in the year 1996~\footnote{MDN, \textit{Same origin policy for JavaScript}, \url{https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript} (Jan 2012)}. It was a reaction to the rise of security and privacy problems caused by frames and frame-sets. Frames were meant to provide a way to display two different websites inside a single view port -- these included different websites residing on different domains and using different ports and protocols. With the increased presence of applications displaying personalized information, the concept of frames yielded privacy and security problems. The DOM of the surrounding page was formerly capable of accessing the data. As soon as one of the framed websites contained sensitive information bound to login credentials or similar tokens, the surrounding frame must not have been able to read this information any more. To find a generalist approach to this privacy 
problem, Netscape developed the Same Origin Policy. This policy enforced access controls depending on three easy to determine aspects of a web document:

	\begin{itemize}
	  %
	 \item \textbf{The Protocol} As soon as a framed website uses a different protocol that the framing website, communication possibilities between frame and framed document are limited. Example: \texttt{http://example.com/} cannot read content from\\
 \texttt{https://example.com/}
	  %
	 \item \textbf{The Domain} Differences in sub-domain, domain and top-level domain (TLD) confine the possibilities for communication between frame and framed document. Example: \texttt{http://subdomain1.example.com/} cannot read content from\\
 \texttt{http://subdomain2.example.com/}. Note that the DOM property \textit{document.domain} can be employed to allow those website to communicate regardless. This is obtained via setting document.domain in both frames to example.com, making it possible for a developer to  allow communication as if there were no SOP restrictions. This is only operational when sub-domains are being ``down sampled'' -- meaning \textit{sub1.sub2.example.com} can be set to \textit{sub1.example.com} while \textit{sub1.example.com} cannot be set to \textit{sub1.sub2.example.com} for security and privacy reasons. The Browser Security Handbook by Zalewski et al. presented this case in a more detailed manner~\footnote{Zalewski et al., \textit{Same-origin policy for DOM access}, \url{http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_DOM_access} (Dec 2011)}.
	  %
	 \item \textbf{The Port} Different ports of framing and framed website restrict communication possibilities. Example: \texttt{http://example.com:80} cannot read content from\\
 \texttt{http://example.com:81}. It has to be noted that Internet Explorer does not feature this part of the SOP and allows full access between frames that reside on the same protocol and domain yet utilize different ports. This remains persistent in latest Internet Explorer 10. According to a blog-post by E. Lawrence, the lack of port restrictions happens due to a security zone related dependency and the simple lack of relevancy~\footnote{Lawrence, E., \textit{Same Origin Policy Part 1: No Peeking}, \url{http://blogs.msdn.com/b/ieinternals/archive/2009/08/28/explaining-same-origin-policy-part-1-deny-read.aspx} (Aug 2009)}.
	  %
	\end{itemize}

	The compound of the listed determining factors -- protocol, domain and port -- is being referenced to as origin. Several user agents still support transmission of HTTP basic authentication data via URL -- as a colon separated \textit{username:password} combination delimited by the \@ (U+0040) character: \texttt{http://user:password@example.com/}. In case all other prerequisites are met properly, the SOP has no impact on the communication of websites framing documents. Usually the SOP does not affect a website framing another document residing in a different directory. An exception exists with the file protocol. Most user agents do not allow frame communication from a documented loaded via file URI with documents located in parent directories which indicates that only child directories and same directory files are considered legitimate for access. Utilizing browser plug-ins such as Java via LiveConnect and applets, can steer bypasses of that restrictions. We will elaborate on those kinds of local SOP bypass 
in Section~\ref{subsubsubsec:2.4.3.2.java_plugin_security} as well as Section~\ref{subsubsec:5.4.5.attacking_sop_weaknesses}. The Java plug-in has a long history of vulnerabilities, effectively undermining browser attack mitigations and security models by employing a different security paradigm and SOP. At present, a CVE search for the term ``JRE'' returns an overall of 241 findings -- mostly bugs related to Java applets and improper content handling. Bear in mind that a search for the term ``Adobe Flash'' returns a similarly alarming value of 209 entries~\footnote{National Vulnerability database, \textit{Search Results for ``JRE''}, \url{http://web.nvd.nist.gov/view/vuln/search-results?query=JRE} (Nov 2011) }. \\

	Aside from exceptions with JavaScript URIs and data URIs, other protocol handlers implemented in modern user agents follow the SOP restriction as well. Once a document contains a link to a JavaScript/data URI, several user agents will follow the link but stick to the domain context the link originated from, which essentially means the referrer's domain. This is necessary for JavaScript URIs to work properly, especially concerning bookmarklets and other interactive code snippets and user scripts. Data URIs should nonetheless create a fresh DOM and operate in the context of \textit{about:blank}. Note that \textit{about} scheme URIs and similar integrated protocol handlers mark yet another fringe case for the SOP. Older versions of Internet Explorer allowed content injections via about URIs delivering prerequisites for a successful SOP bypass, while others browsers, such as Opera, know the proprietary \textit{opera} protocol handler and uses it for displaying internal, browser- relevant information. Di Paola 
reported a XSS problem on the \textit{opera} scheme in 2008, leading to a full stack remote code execution vulnerability~\footnote{Di Paola, S., \textit{Minded Security Labs: Advisory \#MSA01111108}, \url{http://www.mindedsecurity.com/MSA01111108.html} (Oct 2008)}. A similar issue was reported by Liverani in that same year, capable of extracting a user's sensitive history information~\footnote{Liverani, R. S., \textit{Opera Stored Cross Site Scripting Vulnerability}, \url{http://seclists.org/fulldisclosure/2008/Oct/394} (Oct 2008)}. Firefox is equipped with a whole set of internal and non-public URI schemes and protocol handlers such as \textit{wyciwyg}, \textit{resource} and many others -- the SOP applies to whole range of them. Actual SOP weaknesses based on URI schemes, DOM properties and user agent design decisions will constitute our considerations of Section~\ref{subsubsec:5.4.5.attacking_sop_weaknesses}\\

	Similarly to the frame communication, the SOP is being used for XML HTTP Requests (XHR) ~\footnote{W3C, \textit{XMLHttpRequest}, \url{http://www.w3.org/TR/XMLHttpRequest/} (Aug 2010)}. First implementations of the \textit{ActiveXObject} instantiated with the \textit{MSXML2.XMLHTTP} parameter in Internet Explorer 5.5. and Internet Explorer 6 did not validate requests against the restrictions defined by the SOP -- thereby opening a large attack window for a short amount of time. Later versions nevertheless validated properly; XHR was before that a less well known yet fully working bypass of the SOP in any way. Until the patch has been delivered, any given website could read data from any other domain via XHR. This behavior was mentioned in Kouzemtchenko's publication on SOP weaknesses back in 2008~\footnote{Kouzemtchenko, \textit{Same-Origin-Policy Weaknesses}, \url{http://www.slideshare.net/kuza55/same-origin-policy-weaknesses} (2008)}. Since developers did not necessarily embrace the fact that XHR cannot 
work across 
domain borders, several tricks were being used to bypass the limitations of the SOP for many years. These include techniques discussed in Section~\ref{subsubsec:5.4.5.attacking_sop_weaknesses} as well as techniques called JSONP (``JSON with padding''), tricks with Iframe exposing \textit{location.hash} and other fragile methods. To stratify these approaches, the XMLHttpRquest Level 2 was designed and meanwhile implemented by the majority of all relevant user agents. 
	The requesting domain will send a regular XHR preceded by a preflight request. This performs a verification of whether the request either satisfies the SOP restrictions or targets a server delivering proper access control headers. If the responding server communicates permission for the requesting server to initiate communication, the XHR succeeds and data can be exchanged~\footnote{MDN, \textit{HTTP Access Control}, \url{https://developer.mozilla.org/En/HTTP_access_control} (Dec 2011)}. The Microsoft Internet Explorer implemented an alternative approach called \textit{XDomainRequest} (XDR), which is essentially accomplishing the same goal and is just differently labeled~\footnote{MSDN, \textit{XDomainRequest Property}, \url{http://msdn.microsoft.com/en-us/library/cc288060(v=vs.85).aspx} (Dec 2011)}.

	A general problem of SOP enforcement is derived from the fact that several of HTTP server messages from the range of 300 to 307 will cause a user agent to initiate an automatic redirect. For that reason, the browser needs to follow any redirects until the final redirection target has been reached before a resource can be evaluated. Only upon this evaluation it can be deemed as either satisfying the SOP restrictions or causing an exception and limiting communication capabilities. In the past, redirection tricks have been frequently used by attackers to trick the user agent into assuming the SOP restrictions are satisfied and thereby enabling bypasses. In like manner, the Java applet SOP has been bypassed by using HTTP redirects~\footnote{MITRE, \textit{CVE-2008-5506}, \url{http://cve.mitre.org/cgi-bin/cvename.cgi?name=2008-5506} (Dec 2008)}. \\

	The SOP restrictions implemented for cookies are slightly divergent to those framed by the aforementioned rules. Unlike with the HTTP-based SOP, cookies can be restricted for a certain directory. The term origin is thereby extended to another level of granularity. Additionally, cookies allow domain wild-cards -- defining the cookie domain as \texttt{.example.com} (note the dot preceding the domain name) will allow \textit{example.com}, as well as any arbitrary sub-domain of \textit{example.com}, to gain access to that cookie. In a security context, this can be relevant for second-level domain websites. A two-part TLD-like domain structure is utilized by these websites, one example would be \textit{bbc.co.uk}. In case a developer accidentally sets the cookie domain to \textit{.co.uk}, a privacy problem for that website could occur. Most user agents prevent these kinds of accidents with an integrated blacklist of second-level domains. Esser at al. published work on TLD wide cookies in 2008~\footnote{Esser, \textit{Lesser Known Security Problems in PHP Applications}, \url{http://www.suspekt.org/wp-content/uploads/2008/09/lesserknownsecurityproblemsinphpapplications.pdf} (Sept 2008)}. \\

	It is also worth to mention that included scripts and stylesheets are being executed in the context of the hosting domain -- as well as most plug-in containers. In case an attacker managed to inject a script element pointing to the domain \textit{evil.com}, the domain context the script is being executed in is still the one from the hosting website instead of \textit{evil.com} -- contrary to Iframes. The diagram in Figure~\ref{fig:sop} illustrates that. Depending on browser model and implementation details, redirects to non HTTP URIs are also being executed in the domain context of the hosting website.\\

\begin{figure}[htb]
\centering
\includegraphics[width=0.9\textwidth]{./img/sop.pdf}
\caption{Illustration of domain context for included resources: Iframes executing in a different context than included script or style data}
\label{fig:sop}
\end{figure}


	Browsers use the SOP for numerous other purposes such as, for example, resources in CSS. Firefox allows to include behavior files and attach those behaviors to groups of DOM elements via CSS. The CSS property is called \textit{-moz-binding} and is majorly used by browser extensions. In earlier Firefox versions those bindings could be used to execute JavaScript from within CSS files, style elements and style attributes. After several security advisories and bug reports in 2006, the property was set to be restricted to conforming SOP resources, thus efficiently mitigating and handling the problem~\footnote{Thomas, \textit{CVE-2006-0496 Do something about the XSS issues -moz-binding introduces}, \url{https://bugzilla.mozilla.org/show_bug.cgi?id=324253} (Jan 2006)}. Same goes for SVG filters added to HTML elements in Firefox 7 and later releases. Unless those filter-file references reside on the same domain, they will fail to load and execute. Still, our research showed that CSS SVG filters can be used in 
combination with data URIs, which effectively bypasses the SOP restriction and will be discussed later on in Section~\ref{subsubsec:5.4.10.attacks_using_svg}.\\

	A feature called Data Islands is supported by Internet Explorer. It permits to apply XML behaviors to elements by using a XML element and a set of HTML attributes~\footnote{MSDN, \textit{XML Data Islands}, \url{http://msdn.microsoft.com/en-us/library/windows/desktop/ms766512(v=vs.85).aspx} (Dec 2011)}. External XML Data Islands have to satisfy the SOP to be able to be loaded and used. Within our testing scheme and aside from the already mentioned examples, almost every other user agent shipped proprietary features borrowing restrictive behavior rules from the SOP. Once the SOP, being a fundamental security control mechanism, breaks on layers the user agent cannot control anymore, consequences for security and privacy in the WWW might be severe. In 2009, Jackson et al. published on DNS Pinning attacks and mitigation, which is just one illustration of many low-level attacks against the SOP~\cite{jackson2009protecting}.
      

      \subsubsection{Internet Explorer Zone Model}
      \label{subsubsubsec:2.4.1.2.internet_explorer_zone_model}

	The Microsoft Internet Explorer zone model can be seen as an approach enabling privileges' separation for a document loaded in the browser based on its origin.  An overall of four zones is present in recent versions of Internet Explorer (including version 9 and 10). Depending on either the origin's nature or a user decision, the browser will decide which document to place and execute in its matching zone. Each zone's security permission set can be refined within a range of about 30 detailed options or, alternatively, chosen from a list of predefined setups labeled high, medium-high, medium, medium-low and so on. Hinging on the chosen security zone, different presets are available, and each of them can be loosened further by disabling Internet Explorer protected mode. An extra security layer requiring additional user confirmation is created by the protected mode. This is vital in case a website attempts to install or run a program, interactive object or any other executable file possibly capable of 
compromising the user's operating system~\footnote{MSDN Help \& Howto, \textit{What does Internet Explorer protected mode do?}, \url{http://windows.microsoft.com/en-US/windows-vista/What-does-Internet-Explorer-protected-mode-do} (Dec 2011)}. Prior to that, discussion of weaknesses in the security zone model can be found in a presentation document by  Medina et al., dated 2010~\cite{medina2010abusing}. Several research papers by CORE Security have elaborated on other security zone bypasses back in 2008~\footnote{Core Security, \textit{Internet Explorer Zone Elevation Restrictions Bypass and Security}, \url{http://www.coresecurity.com/content/internet-explorer-zone-elevation} (Aug 2008)}~\footnote{Core Security, \textit{Internet Explorer Security Zone restrictions bypass}, \url{http://www.coresecurity.com/content/ie-security-zone-bypass} (June 2009)}.

	We will now enumerate the Internet Explorer Zone Models mentioned below and provide description of their usability features, parameters and security implications: 

	\begin{itemize}
	  %
	  \item \textbf{Internet Zone} This zone can be considered the default zone for most URI and domain schemes. The restrictions applied by this zone match the restrictive behavior of most other relevant user agents. The browser behavior, once a website is loaded in the Internet Zone,  matches the regulations and permissions enforced by the SOP; this was mentioned in Section~\ref{subsubsubsec:2.4.1.1.same_origin_policy}. Except for some tricks, discussed in Section~\ref{subsubsec:5.4.13.miscellaneous_bypasses}, utilizing Windows Universal Naming Convention conform URIs (UNC), no access from the Internet zone to local file system is enabled. Furthermore, all ActiveX objects that have not been marked safe for scripting, cannot be created nor activated~\footnote{MSDN, \textit{Safe Initialization and Scripting for ActiveX Controls}, \url{http://msdn.microsoft.com/en-us/library/aa751977(v=vs.85).aspx} (Dec 2011)}.
	  %
	  \item \textbf{Local Intranet Zone} The local Intranet zone allows the user agent to access resources beyond the untrusted sites in the Internet Zone. This is especially interesting for corporate networks that require access to calendars, databases and similar tools. The Internet Explorer attempts to determine the zone automatically by analyzing the URL. This zone will be automatically selected if the URL structure indicates a document being located on an Intranet resource~\footnote{MSDN, \textit{Intranet site is identified as an Internet site when you use an FQDN or an IP address}, \url{http://support.microsoft.com/kb/303650} (Aug 2011)}. Most ActiveX objects will be operated without any form of prompt such as the ``gold bar'' -- meaning a orange-yellow confirmation bar displayed in the bottom of the user agent view port.
	  %
	  \item \textbf{Trusted Sites} The Trusted Sites zone allows a website to load and execute most signed ActiveX objects without a prompt. This zone is meant for websites considered trusted by user or network policy administrator. Uploads initiated from this zone contain local directory information and the barriers between the file system and websites are lower, usually requiring user confirmation before being fully functional. Websites loaded in the trusted zone allow launching applications such as HTA (HTML Application). In essence, putting a website into the trusted zone removes most SOP restrictions and allows website administrator to perform almost arbitrary code execution. It should be pointed out that a trusted website being victim of an XSS attack allows an attacker to use that website's privileges to compromise a user's system. 
	  %
	  \item \textbf{Restricted Sites} This zone essentially disables all permissions enabling websites to execute any active content, send any potentially sensitive data. It also wraps any of the still enabled features into a required user confirmation before activating the feature or executing the action. Serving as a dump for websites that are considered harmful and need to be restricted in any possible way is a main purpose of this zone. The reasons behind the existence of this zone come down to redirects and frames. In case a victim navigates a website in the Internet zone that is containing a frame to a restricted site, the content from the restricted site cannot execute script or plug-in content and for instance bust the frame and replace the top frame with itself. The protection delivered by this zone works on top of other similar restrictions. One example would be that sand-boxed Iframes pointing to restricted sites and allowing them script access cannot override this zone's restrictions. An Iframe 
equipped with a \texttt{security="restricted"} attribute will automatically run in the restricted zone, even if it is white-listed in the zone settings.
	\end{itemize}

	Aside from the above explicit zones, there is another implicit zone that cannot be activated for websites manually. We are referring here to the Local Machine Zone. This is a zone that is being used once a document is being loaded from a file URI or UNC resource pointing to the local file system. Similar restrictions to the Internet zone, including a SOP-like permission system, are imposed by this zone. Additionally, most recent versions of Internet Explorer block scripts by default and require user confirmation. Note that older versions of the Internet Explorer did not apply harsh security restrictions for local HTML files and script content, thus, allowing privilege escalation within locally stored content~\footnote{Microsoft TechNet, \textit{Internet Explorer Local Machine Zone Lockdown}, \url{http://technet.microsoft.com/en-us/library/cc782928(WS.10).aspx} (Jan 2009)}. \\

	Further areas of SOP exist in modern browsers but are rather out of scope for this thesis. These are, among others, the local storage SOP, the SOP enforcements for non HTTP URLs such as \textit{about:blank}, and specific SOP restrictions vital for working on URLs including localhost prefixes as mentioned in ``The Tangled Web'', a book by Zalewski~\footnote{Zalewski, \textit{The Tangled Web}, \url{http://nostarch.com/tangledweb.htm} (Sept 2011)}. Further documentation on SOP implementations and their security pitfalls can be obtained in the Browser Security Handbook~\footnote{Zalewski, M. et al., \textit{Browser Security Handbook}, \url{http://code.google.com/p/browsersec/wiki/Main} (Sept 2010)}.
      
      
      \subsubsection{Firefox Security Models}
      \label{subsubsubsec:2.4.1.4.firefox_security_models}

	Firefox and Gecko-based user agents do not feature a zone model resembling the one deployed by Internet Explorer. Instead, Firefox has a slightly more restrictive SOP that is considering the port to be a limiting aspect and a reason for disallowing communication between two documents. Unlike on Internet Explorer, \textit{example.com:80} cannot communicate with \textit{example.com:81}. Further restrictions exist for local HTML files. Embedded JavaScript code cannot request resources from different directories except for child directories of the resource the document resides on. By enforcing this, the Gecko engine makes sure a local XSS, as described in Section~\ref{subsubsec:5.4.4.domxss}, cannot read and exfiltrate arbitrary files from the victim's file system; it only allows to access data from the very same directory and its child nodes. Substantial additions to the Firefox and Gecko security model are contributed by the NoScript extension created and maintained by Maone. This extension significantly 
enhances this browser's security by incorporating an XSS filter, a white-list based system to define domain trust policies, a defense system to mitigate Intranet attacks, as well as Clickjacking and ultimate protection against attack vectors exploiting JavaScript and data URIs. Latest versions of NoScript go as far as support protection against timing based history stealing attacks provision, as showcased by Zalewski in 2011~\footnote{Zalewski, \textit{Rapid history extraction through non-destructive cache timing (v8)}, \url{http://lcamtuf.coredump.cx/cachetime/} (Dec 2011)} and Self-XSS attacks becoming popular in social networks such as Facebook~\footnote{Jones, \textit{Self-XSS attack explained}, \url{https://www.facebook.com/photo.php?v=956977232793} (Nov 2011)}.\\

	The reason for NoScript being able to provide such powerful and holistic security enhancements can be attributed to a very permissive Gecko extension security model. In fact, any extension has the capability to run code in the same privilege context as the browser itself. Contrary to the Chrome extension security model described in Section~\ref{subsubsubsec:2.4.1.5.webkit_and_chrome_security_extensions}, Firefox extension does not require any manifests or policy files. It can execute arbitrary code and write-in content to the hard-disk accessing arbitrary folders that the browser itself has access to, consequently reading files and directory listings and even interacting with other extensions. In 2009, NoScript author Maone abused this liberty and unauthorizedly modified the settings of yet another Firefox extension following a similar cause regarding privacy and security. The AdBlock Plus extension maintained by Palant is a widely used tool designed to block online advertisements' loading and display. 
Maone, using advertisements on his website to refinance the NoScript development, has deployed illegitimate modifications to assure that those specific ads cannot be blocked by AdBlock Plus. The result was a short arms race between NoScript, AdBlock Plus and the filter developers, who all wanted to make sure that ads are being blocked again. The conflict ended in a series of articles~\footnote{Palant, \textit{Attention NoScript users}, \url{http://adblockplus.org/blog/attention-noscript-users} (May 2009)} and apologetic postings~\footnote{Maone, \textit{Dear Adblock Plus and NoScript Users, Dear Mozilla Community}, \url{http://hackademix.net/2009/05/04/dear-adblock-plus-and-noscript-users-dear-mozilla-community/} (May 2009)}. The criticism extracted from this unnecessary escapade mainly evolved around the overly permissive extension security model and a lack of sand-boxing and SOP-like approach between extensions and their settings. Ultimately, it came down to the absence of marketplace space where extension 
developers could incentivate their efforts. Note that NoScript can be prone to spoofing attacks, hiding script sources once too many of them are in place to be displayed in the available view-port. A user would have to decide to allow all scripts for that website and thereby allow those originating from unlisted resources as well. Glitches like this are nevertheless not in the scope of this thesis.\\

	The aforementioned privilege for Firefox extensions to essentially do anything the browser can do causes yet another threat to emerge. Once a Firefox extension is vulnerable against XSS or allows markup injections, the attacker can easily turn the XSS into a Remote Code Execution (RCE) and fully compromise the attacked system. During our reserach, we have discovered and reported a large number of XSS vulnerabilities in existing Firefox extensions. Among them the was the popular library management tool Zotero, used for references and citations management by academic community and beyond, and employed even during research for and authoring of this thesis. The Zotero extension allowed to create a rich-text comment for any library item. An attacker could trick the filters in place into avoiding the usage of active markup, injecting JavaScript code and thereby executing arbitrary code on that particular system. While this can be considered as rather uncritical -- the attacker can essentially attack himself -- we 
found that the shared library feature of Zotero can be used to spread the attack and allow actual remote code execution. A patched version was released by the maintainers of Zotero in October 2010, as they have addressed and fixed this problem~\footnote{Zotero, \textit{Zotero 2.0 Changelog}, \url{http://www.zotero.org/support/2.0_changelog} (Dec 2011)}. Besides Zotero, many other Firefox extensions were and still are vulnerable to XSS attacks, effectively exposing their users to getting their systems persistently infected with malware. The code snippet shown in Listing~\ref{lst:xul-js-file-exec} illustrates how an attacker executes code from privileged JavaScript using a base64 encoded string containing the actual file payload.

\begin{lstlisting}[captionpos=b,label=lst:xul-js-file-exec,caption=Example for privileged JavaScript executing code; A file is being created from a string and executed - write access to the hard-disk is being obtained]
<script>
  // executing existing files
  function runFile(f) {
    var file = Components.classes["@mozilla.org/file/local;1"]
      .createInstance(Components.interfaces.nsILocalFile);
    file.initWithPath(f);
    file.launch();
  }
  runFile('c:\\WINDOWS\\system32\\calc.exe');

  // writing and executing a file from string
  function writeFile(filename, ext) {
    var data = atob('TVqQAAMAAAAEA//8AALgAA ... AAAAAAAAAA=');
    var file = Components.classes["@mozilla.org/file/local;1"]
      .createInstance(Components.interfaces.nsILocalFile);
    var stream = Components.classes["@mozilla.org/network/file-output-stream;1"]
      .createInstance(Components.interfaces.nsIFileOutputStream);
    file.initWithPath(filename + '.' + ext);	
    file.create(Components.interfaces.nsIFile.NORMAL_FILE_TYPE, 0777);
    stream.init(file, 0x02 | 0x08 | 0x20, 0777, null);
    stream.write(data, data.length);
    stream.close();
    file.launch();
  }
  writeFile('c:\\test', 'exe');
</script>
\end{lstlisting}

      Firefox further provides a sandbox object, available for extensions and scripts running with high privileges. We discovered a way to expose this sandbox object for the website scope to be used as a scripting sandbox. It's security features for website JavaScript sand-boxing can easily be bypassed though, by simply using it to render JavaScript strings containing active markup and tricking a user into double-refreshing the website. A public proof of concept of the sandbox object leak and its methods and properties has been made available~\footnote{Heiderich, \textit{Firefox [object Sandbox]}, \url{http://html5sec.org/sandbox/} (Jan 2012)}. Aside from the Gecko-engine, the security model provided by Chrome browser engine is far more restrictive and will be discussed in Section~\ref{subsubsubsec:2.4.1.5.webkit_and_chrome_security_extensions}. 

      \subsubsection{Chrome Sandboxing and Extension Handling}
      \label{subsubsubsec:2.4.1.5.webkit_and_chrome_security_extensions}

      The developers of the Google Chrome browser have invested many efforts into design and implementation of several sand-boxing approaches. Most importantly, each tab and document rendering process is always kept isolated in a sand-boxed environment. Chrome uses a two-process-scheme to implement the sandbox. The first process is called broker and it is running with higher privileges and manages 1-\textit{n} low privileged processes called targets. The broker process defines the policies for the target processes, spawns them and further hosts sandbox engine service for its policy enforcement. To sustain integrity, the broker process must outlive the spawned target processes -- a target process living longer than its broker could compromise the security model. To some extent, plug-in processes can be sand-boxed as well. However, in regards to the scope of this thesis, the handling of inter-process communication (IPC) and process management is less relevant than the extension security system. More detailed 
information on this sand-boxing approach can be found in the Chromium developer wiki~\footnote{Google Inc., \textit{Sandbox}, \url{http://www.chromium.org/developers/design-documents/sandbox} (Dec 2011)}.\\

      The Google Chrome extension system relies on a rather restrictive and isolation-driven model. The reasons for this are clearly connected to a kind of lax, or even non-existing, security model operating Firefox extensions and increasing the likeliness of attacker's discoveries pertaining to exploitable vulnerabilities in an extension authored by a random user. Once a Firefox extension is vulnerable against XSS attacks or HTML injections, the probability for successful escalation to a full stack Remote Code Execution (RCE) becomes dangerously high. Section~\ref{subsubsubsec:2.4.1.4.firefox_security_models} elaborates on this and supplies exemplary code showing how an attacker can execute arbitrary code via privileged JavaScript code. When no actual RCE is there to grant a possibility of being conducted by the attacker, Firefox extension vulnerabilities can often be abused in a manner of accessing information from arbitrary domains, reading local files or ex-filtrating similarly sensitive data. On the 
other hand, Firefox extensions are outstandingly powerful and allow developers to modify and extend almost any properties and features the user agent provides. The challenge for the Google Chrome extension system developers was therefore to initially create a design allowing browser extensions to be powerful, yet with having a provision of a reasonable level of security in mind. This specific level was to assure that a vulnerable extension cannot compromise the browser or the underlying operation system.\\

      Barth et al. proposed a novel browser extension system capable of providing a rich feature set for browser extensions to chose from. This occurs without exposing the user to similar security risks that a Firefox extension would cause in case of being injectable~\cite{barth2010protecting}. Their approach is essentially based on isolation. Namely, the DOM the extension has access to and the DOM the website's client-side logic accesses are fully isolated from each other. An extension's content script can for instance interact with the website DOM, but it cannot access the powerful extension API and vice versa to avoid higher-order script code execution by malicious and infected websites. The Google Chrome browser implements a system comparable to this approach. Scripting attacks against a Google Chrome extensions do not necessarily mean full operating system access, but luckily only compromise a small subset of security assets. Chrome extensions can further make use of a CSP implementation and allow 
developers to apply the same rules for an extension as for a website when it comes to resource inclusion, inline scripting and location control. An extension displaying user generated HTML can therefore easily restrict the capabilities of the rendered data. Script execution, as well as inclusion of resources from domains other than the white-listed ones, can be prohibited effectively. The CSP rules can be found in the extension manifest~\footnote{Google Inc., \textit{Formats: Manifest Files}, \url{http://code.google.com/chrome/extensions/manifest.html} (Dec 2011)}.

    \subsection{DOM and JavaScript Security}
    \label{subsubsec:2.4.2.dom_and_javascript_security}

      One of the most important DOM security features is the possibility to loosen the restrictions applied by the SOP by modifying the property \textit{document.domain} which has been mentioned in Section~\ref{subsubsubsec:2.4.1.1.same_origin_policy}. A developer can enable Iframes and frames to communicate across sub-domain borders by down-sampling both domains to a shared value, that is, a mutually shared \textit{super}-domain. It is thus possible to enable communication between \textit{test1.sub.example.com} and \textit{test2.sub.example.com}, by setting both their \textit{document.domain} properties to \textit{sub.example.com}. Figure~\ref{fig:doc-dom} illustrates this process and its effects. It is not possible to modify document.domain to traverse upwards in the domain hierarchy and enable communication between \textit{test1.sub.example.com} and \textit{test2.sub.example.com} by setting \textit{test1.sub.example.com} to \textit{sub.example.com} and then to \textit{test2.sub.example.com}. In terms of 
DOM security are cross domain leaks based on race conditions are gaining interest. Several vulnerabilities in Safari and Webkit browsers were related to redirects in pop-ups, header-less \textit{XMLHttpRequest} calls, Iframes and other resources. Those were reported in 2007 and 2009, and referenced in numerous CVE entries: CVE-2009-1684, CVE-2009-1685, CVE-2009-1688, CVE-2009-1689, CVE-2009-1691, CVE-2009-1695, CVE-2009-1697, CVE-2009-1702, CVE-2009-1714, CVE-2009-1715. \\

\begin{figure}[htb]
\centering
\includegraphics[width=0.5\textwidth]{./img/doc-dom.pdf}
\caption{Illustration of document.domain down-sampling}
\label{fig:doc-dom}
\end{figure}

      The instance when a user agents redirects a user agent from an origin to a different domain can be considered a critical moment regaring successful SOP enforcement. At that point in time, the DOM must assure no JavaScript calls can happen in that tiny temporal window of the origin's unloading. A new domain context is being entered and can be used to obtain sensitive data and channel out cross domain. Used together with Safari 5, the Java plug-in had similar problems. Once an applet initiated a loop accessing DOM properties, a redirect triggered via JavaScript caused the applet to keep running and enabled it to migrate into the new domain context. Ultimately, it resulted in a universal XSS affecting websites that are not vulnerable against Cross-Site Scripting at all.\\

      DOM and JavaScript security is not only defined by SOP regulations but also depends on the trustability of certain properties -- especially regarding those properties' content and capabilities.  Several Firefox extensions utilize the \textit{location} property, assuming it cannot be controlled by a potentially malicious JavaScript. Since this assumption has been falsified within modern Firefox versions (8.0-12.0a1), which actually allow overwriting accessor methods for \textit{location} and \textit{location} properties, many scripts and extensions are now potentially vulnerable against spoofing attacks and worse. Similar problems exist for JavaScript-based frame-busting code that relies on the bulletproof integrity of methods such as \textit{location.reload()}. A typical JavaScript frame-buster would call \textit{top.location.replace(location)} -- assuming that the top frame cannot spoof the replace method and therefore trust its originality. On several browsers, including Opera, older Internet 
Explorer versions and Firefox, spoofing and overwriting \textit{location.replace()} is possible. This renders a frame-buster relying on this method useless. Rydstedt et al. elaborated on the topic of ``busting frame-busters'' in more detail in 2010~\cite{rydstedt_busting_2010}.\\

      Moving forward, the main challenge for the user agents could be spelled out as finding a proper split between security and performance. This becomes vital especially when one considers the rise of applications using heavy DOM activity and thriving away from page reloads but AJAX-based content retrieval and desktop like event handling. A user agent incapable of delivering a fast usage experience will fall behind on the market and loose shares. Thus, performance must, and most likely will, remain an important priority. On the other hand, several security relevant checks require a proper amount of time. Changes in the JavaScript language specifications, a shift from supporting ECMA Script 5 (ES5) over ES3 (and older) versions, and constant addition of new features with every minor release forces the authors of the DOM and the JavaScript engines to quickly adapt and implement often substantial changes in a short amount of time. Cross-domain leakage bugs and race conditions are hard to detect 
via automated test suites and often require a complex setup, which is hard to predict and reconstruct and might turn out to be an entirely impossible task. Our research has generated the discoveries of several DOM bugs allowing a developer, and for that matter - an attacker as well, to bypass the freezing capabilities provided by the ES5 object capability additions. We identified Webkit as prone to a double-freezing attack. Given an access to \textit{Object.defineProperty()}, attacker will be allowed to freeze an \textit{already frozen} object for a second time, and thereby overwrite the protected value. Aside from race conditions and SOP checks, a user agent must handle the integrity of those object state modifications properly to provide a safe DOM. Similar problems arise from improper exception handling and Unicode bugs with decoding functions. On several of the tested user agents, the decoding of an ``urlencoded'' yet invalid multi-byte character caused an exception to be thrown. Potential consequence 
was a disabling of the following code inside a loop and similar constructs, thereby bypassing protective code. Section~\ref{subsubsec:6.6.3.javascript_and_dom_based_rbac} will introduce further DOM and JavaScript bugs and implementation flaws hindering our research thriving towards a secure and trusted DOM. We will present occurrences that needed to be reported as bugs and quick-fixed to allow our current prototype implementations to work reliably.

    \subsection{Browser Plug-In Security}
    \label{subsubsec:2.4.3.plugin_and_extension_security}

      One simple way to vastly extend a browsers capabilities is to employ plug-ins as one's tool of choice. Since Netscape 2.0 allowed using Java applets in web documents, the popularity of applets rose. Just few years later the Flash plug-in was created by a company back then known as PenPoint -- initially labeled ``FutureSplash''. Later on it was acquired by Macromedia and the software was effectively renamed to ``Flash''. Currently, it is being developed and maintained under Adobe Systems after their purchase of Macromedia in 2005. Both Java applets and Flash content provided web developers with possibilities that a web browser could not deliver. Among them, one can pinpoint the highly interactive and powerful applications, games, videos, and other multimedia content. Java and Flash were the most prominent applications for providing this type of content for years~\footnote{StatOWL, \textit{Web Browser Plugin Market Share}, \url{http://www.statowl.com/plugin_overview.php} (Feb 2012)}. Those two plug-ins 
have accordingly become a center of attention for attackers and security researchers. The power of plug-ins to bypass browser-enforced security restrictions makes attacks against them even more promising and often profitable for online criminals.

      \subsubsection{Flash Plug-In Security}
      \label{subsubsubsec:2.4.3.1.flash_plugin_security}

      During the last years, the Flash plug-in and its close relative -  Flash player -  have constituted frequent targets for attackers for a variety of reasons. First and foremost, the Flash player has a significant market share and penetration saturation. According to StatOWL, from July 2011 to November 2011, 95.51\% of all Internet users utilized a browser equipped with the Flash plug-in~\footnote{StatOWL, \textit{Flash Usage Stats}, \url{http://www.statowl.com/flash.php} (Dec 2011)}. A vast percentage - 89.22\% were, and probably still are, using Flash player version 10. The remaining percentage is split into users browsing with Flash 11.x or legacy versions, such as Flash 9 or even Flash 6. What is more, Flash was not equipped with ASLR and DEP protection up until version 10. Even on operating systems and browsers using these memory protection techniques, the Flash player marks a promising entry point for remote code execution exploits carried out via an infected website. The result of this is an 
overall of 456 CVE entries available at the time of writing in December 2011~\footnote{National Vulnerability Database, \textit{Search Results for ``Flash''}, \url{http://web.nvd.nist.gov/view/vuln/search-results?query=Flash} (Dec 2011)}. Flash supports a mostly ECMA Script-compliant JavaScript engine and facilitate implementation of interactive features by developers, as it pertains to a dialect - labeled ActionScript. At present, we are witnessing the ActionScript 3.0 as the most recent version, crucial for providing interfaces to embed website's DOM, aside from other powerful features.\\

      Observed from the web security perspective, the Flash player offers a lot of interesting possibilities to conduct scripting attacks in rather unusual ways. Jagdale addressed Flash-related web security problems in a conference talk in 2009~\footnote{Jagdale, \textit{Blinded By Flash}, \url{www.blackhat.com/presentations/bh-dc-09/Jagdale/BlackHat-DC-09-Jagdale-Blinded-by-Flash.pdf} (July 2009)}. The general SOP model the Flash player enforces is based on the exact domain matches, similarly to the SOP-implemented in most modern user agents. Each domain resides in a sand-boxed environment forbidden to communicate with any other domain unless this other domain explicitly allows this particular communication with the exact requesting domain. A central policy file residing in the web-root of the requested domain, namely a file called \textit{crossdomain.xml}~\footnote{Adobe Inc., \textit{Cross-domain policy for Flash movies}, \url{http://kb2.adobe.com/cps/142/tn_14213.html} (Dec 2011)} operates as a control 
feature for this enforcement. This cross domain XML definition file is enabling a developer to prepare a white-list of domains allowed to access the content residing on the targeted domain. The notation allows domain entries' wild-cards. It is furthermore possible to enable all domains by just setting the necessary XML attribute values to the asterisk character (U+002A). The code shown in Listing~\ref{lst:crossdomain-xml} displays a classic setup for a \textit{crossdomain.xml} file -- the domains \textit{example.com} and \textit{www.example.com} would be allowed to communicate with the protected domain-- whereas \textit{www2.example.com} would be prohibited because of not being explicitly white-listed. If the attribute value would have read \textit{*.example.com}, then \textit{www2.example.com} would have been permitted to read content from the protected domain too.

\begin{lstlisting}[captionpos=b,label=lst:crossdomain-xml,caption=A typical crossdomain.xml implementation; it allows two origins to request data from the deploying domain]
<?xml version="1.0"?>
 <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
  <cross-domain-policy>
   <allow-access-from domain="www.example.com" />
   <allow-access-from domain="example.com" />
</cross-domain-policy> 
\end{lstlisting}

      In essence, a server deploying Flash files attempting to request data from other servers providing configuration files, binaries or other flash files has to initially request the \textit{crossdomain.xml} file, receive its contents and check whether the permission to read those files is granted or not. If the \textit{crossdomain.xml} file delivers matching data, further requests to the targeted resource will be permitted. By default, the information stored in the \textit{crossdomain.xml} is cached by the Flash player. However, this setting can be overridden by a security-aware developer. Interestingly, a lot of the Flash files deployed on live and production servers accept numerous parameters to receive configuration and other relevant data from. This includes videos, images, XML data and of course other flash files. Flash allows using GET-like parameters to attach additional parameter data. A typical example for a video player requesting an external configuration file would be: \texttt{http://www.
example.com/player.swf?config=/videos.xml}. An attacker can now attempt to tamper with the configuration parameter and try to include a different XML file coming from an alternative domain containing malicious data causing an XSS vulnerability or worse. The URL would be kept in accordance with the preceding and be: \texttt{http://www.example.com/player.swf?config=http://attacker.com/evil.swf}.\\
 To make sure that the request does not appear in any log files, the attacker can also manipulate parameters via location hash: \texttt{http://www.example.com/player.swf\#?config=\\
http://attacker.com/evil.swf}. 
      The additional as well as spoofed parameters are now completely invisible for server-side logging mechanisms (Similarly to DOMXSS attacks, mentioned in Section~\ref{subsubsec:5.4.4.domxss}). Luckily, before requesting a file containing the attacker controlled payload, the Flash SOP comes into place and applies restrictions. Without further permission from the attacker's server, the assaulted Flash file cannot load the content. Ironically, the attacker has to provide a \textit{crossdomain.xml} file on his domain and permit the attacked script to request and receive malicious payload. So far this inversion of what the SOP is supposed to mean caused millions of websites to be vulnerable against XSS attacks. What is more, it is still the case because fixing this SOP glitch would cause existing applications to break. A thrifty attacker can easily enumerate public Flash files residing on the targeted server via Google by using the \textit{ext:} and \textit{inurl:} parameters. \\

      Aside from the already described problems, Flash plug-in provides many possibilities to execute JavaScript in often undesired ways. the APIs \textit{getURL()} and \textit{ExternalInterface.call()} are crucially important in the context of this thesis. These interfaces can both be used to execute JavaScript in the currently loaded DOM of the browser, doing so by redirecting to a JavaScript URI or simply delegating calls to the browser DOM via \textit{ExternalInterface.call()}. The \textit{getURL()} API has been deprecated in ActionScript 3.0 and is now called \textit{navigateToURL()} but essentially features similar capabilities. In the context of a secure DOM, problems may arise once the \textit{getURL} API is being called with a JavaScript URI and a second parameter defining a target window. Upon the target window string being set to \textit{\_blank} or a non-existing frame name, the user agent will in most cases open a new tab and thereby generate a fresh and unprotected DOM. Later sections of this 
thesis will elaborate on these problems  (Section~\ref{subsubsubsec:6.6.4.2_event_control}). A similar functionality can be utilized via \textit{fscommand} for LiveConnect enabled user agents~\footnote{Adobe Inc., \textit{Create pop-up browser windows | Flash}, \url{http://kb2.adobe.com/cps/141/tn_14192.html} (Dec 2011)}. A test-case to see which user agents are capable of using \textit{fscommand} to execute JavaScript is available online~\footnote{Moock, \textit{LiveConnect Testcase}, \url{http://www.moock.org/webdesign/flash/fscommand/flash-to-javascript.html} (June 2011)}.\\

      In 2010, Oftedal published an article on Flash security in the context of XSS and script execution, elaborating on the notions of Flash, getURL() usage and the unsanitized user-controlled input, which often is a root cause for XSS on otherwise secure websites~\footnote{Oftedal, \textit{Cross Site Scripting (XSS) in flash files}, \url{http://erlend.oftedal.no/blog/?blogid=99} (Feb 2010)}. Note that the XSS vulnerabilities are mainly caused by external third party content embedded in the website to display advertisements or similar content.\\


      \subsubsection{Java Plug-In Security}
      \label{subsubsubsec:2.4.3.2.java_plugin_security}

      The Java plug-in has had a similarly winding path in terms of security. This is due to the Flash plguin mentioned in Section~\ref{subsubsubsec:2.4.3.1.flash_plugin_security}. As of now, the term-search for  \textit{applet} yields an overall of 219 mostly Java applet and browser security specific CVE entries in the National Vulnerability Database~\footnote{National Vulnerability Database, \textit{Search Results for ``Applet''}, \url{http://web.nvd.nist.gov/view/vuln/search-results?query=applet} (Dec 2011)}. Most of the times those security problems do not originate from issues caused by the executed code in terms of memory corruptions and buffer overflows, but can rather be attributed to SOP and security manager bypasses.\\

      Java applets are usually enabled by the use of the \textit{applet} tag. This tag can be applied with a variety of parameters, permitting an inclusion and execution of external applets and class files, Java archives (JAR files) and serialized Java objects. Once the user agent parses an applet tag, the Java plug-in is activated and will call on the necessary libraries from the Java Runtime Engine (JRE) to execute the applet code. The Gecko-based browser family, including Firefox, supports an additional API called LiveConnect. Usage of Java functionality directly in the DOM, done by a proprietary DOM object constructor called \textit{Packages}, is enabled by LiveConnect. Our research showed that \textit{Packages} can be enabled to delegate JavaScript calls to the internal Rhino JavaScript engine the JRE ships, initiating requests and redirects and emulating applet behavior without using the applet tag. In case an attacker abuses an XSS vulnerability, the full Java applet feature-set can be utilized for 
post-exploitation without injecting further HTML. A DOM-based security tool must be aware of the fact that the \textit{Packages} object exists and provides a lot of possibilities for bypassing DOM-based security restrictions. Therefore, it should be overwritten or wrapped. It must be noted that the term LiveConnect is not exclusively used in connection with Java, but also with Flash and \textit{fscommand}, as mentioned in Section~\ref{subsubsubsec:2.4.3.1.flash_plugin_security}\\

      About a decade ago, yet another way of executing Java code in the browser existed for a limited period of time. On 30th of September 2009, the MSJVM -- a Microsoft JRE implementation reached the end of its life. Microsoft attempted to create their own version of a Java Runtime Engine / Java Virtual Machine to avoid dependency from Sun's JRE to display Java applets in Internet Explorer. In April 2004, an agreement settled the dispute between Microsoft and Sun over the MSJVM. Note that SVG Tiny 1.2 provides yet another interface to potentially execute Java code in the browser context~\footnote{W3C, \textit{15 Scripting}, \url{http://www.w3.org/TR/SVGTiny12/script.html} (Dec 2008)}. Up till now, no user agents support this interface.\\ 

      The most important problem, in terms of browser and web security, is the completely different SOP the Java plug-in enforces when combined with Java applets. While SOP restrictions regarding, protocol, domain and port indeed apply, the JRE will consult an additional check in case a URL request from a domain occurs and causes a SOP violation. This check will consider the IP address the domain is pointing to. If the IP address of the requesting host and the requested target match, the formerly checked SOP aspects will be ignored and the request  permission will be granted, subsequently returning the response body. Our tests showed that while it was not possible with recent versions of the version 1.6.x of the Java Runtime Engine (JRE) and its browser plug-in, it has been re-enabled with version 7 -- or 1.7.x of the JRE. This, as one may call it, 'regression bug' has caused a plethora of different problems to emerge. One example is a bypass of the protection delivered by HTTPOnly cookies~\footnote{OWASP, \
textit{HTTPOnly}, \url{https://www.owasp.org/index.php/HttpOnly} (Dec 2011)}. We developed a simple script requesting a resource and afterwards displaying the header data by using the \textit{getHeaderFields()} method. The code shown in Listing~\ref{lst:java7-httponly} illustrates the simple yet effective cookie leakage, which takes place despite the HTTPOnly cookies being activated on the server-side. The code sample can be trialled with Java 7 on modern Firefox browsers be means of the website \footnote{v.d. Stock, \textit{HTTPOnly Testcase}, \url{http://greebo.net/owasp/httponly.php} (Dec 2011)}.

\begin{lstlisting}[captionpos=b,label=lst:java7-httponly,caption=Bypassing HTTPOnly with Java 7; The getHeaderFields() method extracts the sensitive data without considering httpOnly]
<script>
 var jurl = new Packages.java.net.URL(document.URL);
 var c = jurl.openConnection();
 alert(c.getHeaderFields());
</script>
\end{lstlisting}

      Further security risks and bypasses are yielded by yet another Java feature which can be used via applets or LiveConnect: the \textit{JEditorPane} object and its methods. The \textit{JEditorPane} object is meant to provide a integrated way to edit rich text and HTML data~\footnote{Oracle, \textit{JEditorPane}, \url{http://docs.oracle.com/javase/6/docs/api/javax/swing/JEditorPane.html} (Dec 2011)}. Therefore, the JRE provides a minimal browser object capable of rendering basic HTML -- excluding CSS, scripting and similar interactive elements. Along with the lack of features, an absence of security enforcements can be observed. By employing this editor feature, an attacker can load a website inside an applet and assign a link handler to the existing hyper-links. Since the editor supports neither JavaScript nor \textit{X-Frame-Options} header, an adversary can utilize the tool to conduct Clickjacking attacks. While thanks to the SOP the attack window is not that large, several websites can be attacked by 
means of abuse directed at non-exploitable XSS vulnerabilities: The mentioned Java SOP deviation ultimately considers a domains IP address to be an ultimately sufficient criterion to prohibit or permit cross-domain requests and response evaluation (still respecting protocol borders though). Summing up, an insecure website residing on the same server with the same IP address as a secure website can be click-jacked, as demonstrated by the code in Listing~\ref{lst:java7-clickjack}. Nevertheless, since more severe attacks are possible in the same-IP scenario, this attack technique might usually be disregarded. That said, providing an alternative browser inside JRE bears countless and diverse security risks. Same goes for exposing a different script engine via JavaScript and LiveConnect -- as a security challenge proved we published in late 2011~\footnote{Heiderich et al., \textit{So you think you can dance?}, \url{http://kotowicz.net/java/java.html} (Nov 2011)}.\\

\begin{lstlisting}[captionpos=b,label=lst:java7-clickjack,caption=Clickjacking and X-Frame-Options bypass with Java 7; The JEditorPane object does not respect X-Frame-Options header settings]
<script>
  with(new Packages.javax.swing.JFrame())
    add(new Packages.javax.swing.JEditorPane(
      location.href
    )),
    setSize(200, 200), setVisible(true)
</script>
\end{lstlisting}

      To close with one final example, we put forward yet another way to interact with Java-related data provided by Firefox and Gecko-based user agents: the JAR URI scheme. Firefox is capable of directly navigating into compressed Java archive files and render contained content. Therefore a URI handler scheme named \textit{jar:} is prepended before a standard HTTP URI. The navigation inside the JAR file is being initiated by the exclamation mark (U+0021). A full JAR URI presents itself as: \texttt{jar:http://html5sec.org/test.jar!/\\
test.html}. The \textit{jar:} initiates the JAR URI and the \textit{!/test.html} part of the URI navigates to the root folder of the Java archive and then triggers display of the file \textit{test.html}. Files displayed via JAR URIs are equipped with a stripped DOM, which means that for instance the property \textit{document.cookie} is empty. Moreover, polling the property document.domain returns null. At the same time, Firefox allows usage of the \textit{XMLHttpRequest} object and supports a SOP bypass: A JAR URI can request resources from its underlying HTTP URI. Those requests send cookies and thereby potentially expose sensitive data in spite of document.cookie being empty. A bug has been filed to address this issue.

%    \subsubsection{Plugin Integration and Sand-Boxing}
%    \label{subsubsec:2.4.4.plugin_integration_and_sandboxing}

%    \subsubsection{Extension Integration and Sand-Boxing}
%    \label{subsubsec:2.4.5.extension_integration_and_sandboxing}

%    \subsubsection{Extended Separation Attempts}
%    \label{subsubsec:2.4.6.extended_separation_attempts}

  \section{Current Security Challenges \& Conclusion}
  \label{subsec:2.5.current_security_challenges_conclusion}

    One of the most pressing current security challenges are browser extension and plug-in architectures. The simple yet powerful interfaces that Firefox extensions can use, allow both a benign developer and a determined attacker to execute arbitrary code and access documents across domain and protocol borders. The Chrome extension model provides better isolation and privilege management. Unfortunately, in its current state it will not provide sufficiently powerful interfaces to support a security suite as the one that NoScripts guarantees to Firefox. While indeed, a similar script-blocking extension exists for Chrome (called NotScripts~\footnote{Google Inc., \textit{NotScripts}, \url{http://goo.gl/vkT9x} (Dec 2011)}), it only provides a small subset of NoScript's features and is known to be bypassable with rather trivial attacks and techniques~\footnote{Maone, \textit{NoScript for Google Chrome?}, \url{http://forums.informaction.com/viewtopic.php?f=10&t=1676&start=60} (Aug 2010)}. While NoScript is very 
potent, a bug in its implementation can cause a RCE vulnerability and compromise its users' systems with malware. A feature request has been created, asking for changes in the Chrome extension system to allow NoScript-like behavior~\footnote{Google Inc., \textit{The absence of synchronous message API...}, \url{http://code.google.com/p/chromium/issues/detail?id=54257} (Sept 2010)}. Same-level vulnerability in NotScripts would probably just affect the users visited domains and possibly impact privacy and security on those, favorably leaving the operation system's integrity intact. For both vendors, Google and Mozilla, drastic changes in their extension systems would potentially break significant percentages of existing extensions. Even more importantly so, it would frustrate similarly large numbers of extension authors and users, inevitably resulting in shifting market shares and financial loss of indeterminable scale. For that reason, any change to these systems has to be well-thought and considered from many 
different angles before a way into specification, ultimate implementation and roll-out can be found.\\

    Browser plug-ins like Java and Flash bring forth even more critical large-scale effect and pose the security challenges of all-important state. The multitude of discrepancies between browser security features and security policies of plug-ins provide easy to exploit vulnerabilities and bypasses for attackers. They also weaken the effect of security efforts taken on by vendors and developers. Aside from the SOP differences between browsers and the Java plug-in, a wide range of features of the JRE can be used to carry out attacks regardless of a well configured and up-to-date user agent being in place. We have discussed this in detail in Section~\ref{subsubsubsec:2.4.3.2.java_plugin_security}. Consequently, Google Chrome implemented several defense mechanisms attempting to mitigate the security impact of improperly written, maintained and updated browser plug-ins. The Flash player and the PDF reader are meanwhile bundled in Google Chrome, and are therefore being updated silently alongside browser updates. 
Not requiring confirmation or awareness, the browser updates happen in the background, hidden from the users view -- but also enabling wide-spread code execution attacks once the Google download servers are compromised. Most plug-in content is further being executed in a sand-boxed context, mitigating the effect of possible vulnerability and exploit~\footnote{Google Inc., \textit{Sandbox}, \url{http://www.chromium.org/developers/design-documents/sandbox} (Dec 2011)}. In 2009, Reis et al. published on the topic of security implications, effects and learnings resulting from first Chrome sandbox implementations~\cite{reis2009browser}. Running Java applets categorically requires a per-domain permission by the user for security reasons. Internet Explorer running on Windows 8 will not allow usage of any form of plug-in when run in ``Metro-Mode'' including ActiveX controls and Browser Helper Objects (BHO)~\footnote{IEBlog, \textit{Browsing Without Plug-ins}, \url{http://blogs.msdn.com/b/ie/archive/2011/08/31/
browsing-without-plug-ins.aspx} (Aug 2011)}. Once run in regular desktop mode, which is outside the new Metro UI, plug-in support will be available -- to retain compatibility for experienced users operating outside the Metro UI. \\

    Most modern browsers support mixed content documents. This means, a HTML document can as well consist of HTML5 and XML code -- for instance by using inline SVG, inline MathML and other dialects that require to be well-formed. While this is not novel -- Internet Explorer for instance supported XML data islands inside HTML documents since version 5.5 -- it imposes novel risks, since the well-formed XML enclosed by the rather unstructured and ``frowsy'' HTML has to follow different parsing and processing rules. We will introduce several attack vectors in Section~\ref{subsubsec:5.4.8.attacks_using_innerhtml} demonstrating the damage potential of mixed content documents and the resulting security challenges the user agents are confronted with. During our research we submitted several bug reports to browser vendors relating to the flawed markup processing of in-line XML content. Section~\ref{sec:5.attacking_existing_mitigation_approaches} will go into further detail on those.\\

    Aside from the aforementioned aspects, we have noticed a few other important challenges for modern browser security. One is the split between parser performance and security. In Section~\ref{subsubsec:5.4.8.attacks_using_innerhtml} we elaborate on mutation attacks, in which attack vectors make use of internal decoding and markup transformation done by browser engines in order to speed up parsing and layout generation. These transformations allow an attacker to inject code capable of slipping past server-side IDS and WAF detection rules, and next deploying malicious payload once the browser receives and transforms the data. Any browser engine we tested -- except for the Opera Presto engine -- was prone to these mutation attacks and allowed bypassing server-side XSS filters. Similarly dangerous is the overdue support of legacy features potentially compromising website and browser security. In Section~\ref{sec:5.attacking_existing_mitigation_approaches}, we will provide an in-depth walk-through designated 
for introducing and discussing several attack techniques making use of legacy features. Ultimately, the exact opposite of legacy features -- meaning freshly implemented, often half-standardized feature drafts, cause security problems as well. Especially novel approaches to client-side markup-only interactivity utilizing HTML5 and CSS3 bring about interesting side effects and allow attackers to exfiltrate data, bypassing browser and server-side XSS filters as well as similar defense installations. We will cover those attacks in later sections, for instance Section~\ref{subsubsec:6.6.9.security_considerations}.

  %\subsection{Conclusion}
  %\label{subsec:2.6.conclusion}