7.OutlookandFutureWork.tex

\epigraph{I'm not afraid of storms, for I'm learning to sail my ship}%
{\textsc{Aeschylus}}

\section{Final Conclusion}
\label{sec:final_conclusion}

In this thesis we introduced a novel approach of website protection techniques based on a client-side DOM-based library delivering the foundations for a JavaScript RBAC/IDS/IPS -- after giving an overview on the work already contributed by fellow researchers on this specific field in Chapter~\ref{sec:1.introduction}. To underline the necessity of such a technique and framework, we introduced and discussed existing website and browser protection mechanisms focusing on preventing scripting attacks in Section~\ref{sec:4.current_mitigation_approaches} and further outlined their design and implementation flaws. A comprehensive overview on the current state of browser security in scope for this thesis and the resulting proposal has been provided in Chapter~\ref{sec:2.browser_security} -- to provide the basic knowledge necessary to follow our discussions on the security of components using those implementations. We demonstrated how the lack of visibility for protection tools residing on different layers than the attacks taking lace heavily impacts detection and thereby protection performance. The attacks we (co-)developed and introduced in Section~\ref{sec:5.attacking_existing_mitigation_approaches} underline that threat potential for arbitrary web applications.\\

We dedicated our focus on those attack techniques bypassing server-side XSS detection and client-side XSS filters that utilize mutation features to be of seemingly harmless appearance until finally reaching the layout engine and being rendered by the browser and thereby unfolding the malicious payload. The problem class we derived from this behavior can be considered hard to impossible to be solved comprehensively. Only libraries receiving constant maintenance and refinement can step by step keep up the defense against novel attacks and filter bypasses utilizing browser bugs. Without a user agent free of implementation flaws, no server-side filtering library can deliver seamless and comprehensive scripting attack protection. Therefore, our novel approach shifts the XSS and scripting attack defense into the layer the attack is being executed at the DOM itself. This is the only location for a defense library providing capability to overcome the visibility problem discussed in Section~\ref{subsec:5.5.the_visibility_problem}. \\

In Chapter~\ref{sec:6.rethinking_client_side_web_security} we described the necessary setup for a tamper resistant DOM library capable of detecting and preventing attacks, managing access to potentially sensitive DOM properties. After introducing our novel design, we discussed the prototypic implementation, described the evaluation an test setup we created and discussed the results focusing benefits as well as weaknesses and limitations; especially in regards of upcoming browser features and specification drafts specifically concerning the current ECMA Script 6 (ES6) development. We concluded in stating the feasibility of a DOM-based protection, filtering, IDS/IPS and RBAC solution; Those are capable of detecting attacks invisible for server-side libraries. This includes the DOMXSS attacks mentioned in Section~\ref{subsubsec:5.4.4.domxss}, among others the \textit{innerHTML} based attacks mentioned in Section~\ref{subsubsec:5.4.6.bypassing_server_side_xss_protection} and ultimately the bypasses against browser based XSS filters in their current stages of development (Consider the mutation attacks mentioned in Section~\ref{subsubsec:5.4.7.bypassing_client_side_xss_protection} and following). \\

\section{Future Work}
\label{sec:future_work}

Left to be detailed is the description of the upcoming tasks and the future work, accompanying the development of our prototype while becoming a mature and usable defense library. Current development tendencies for the upcoming release of ECMA Script 6 -- specifically the Direct Proxies allowing effective wrapping and access control for host objects -- promises more robust and less improvised implementations available in all relevant user agents in the near future. Our future work will be directed into contributing to discussion groups and mailing lists to help finding the right ways in specifications and implementations to enable developers writing secure and \textit{securable} browsers and web applications. Nevertheless, one major problem has yet to be discussed: There needs to be a robust yet easy to implement and transparent way to define policies and privilege rule-sets for the underlying DOM-based RBAC system. T. Oda et al. presented an approach in 2011, capable of delivering a strong and comprehensive way for defining and enforcing possible DOM protection and accessor policies. The proposal leverages a system labeled Security Style Sheets (SSS)~\cite{oda2011securitystylesheets}.\\ 

Oda noted a lack of granularity in the CSP specification and similar website protection techniques, effectively disallowing complex websites to define authoritative rules for certain HTML elements in regards of their capabilities to execute scripts or allow usage of external resources. While CSP can block inline scripts and event handler usage for a full web document, a developer cannot permit parts of the document to contain active code, while other parts can only contain static content and might reflect user generated data. His approach to solve this problem involves using CSS like selectors and rule-sets. Beneficiary with this proposal is the fact, that the CSS selector engine provides sufficient flexibility to select and de-select any page-existent element, their child nodes and other more abstract selections. The selector engine is already implemented in user agents and additionally the syntax is very well known to developers and allows easy selector testing by applying graphical indicators to elements applied with arbitrary security rules. Dynamic changes to the markup can either be covered by existing SSS rules or be covered by a DOM API comparable to the currently installed CSSOM (CSS Object Model) and DOM interfaces to dynamically adjust style sheets. SSS is to our knowledge the most feasible way for granular security rule definitions at the time of writing and will hopefully by the foundation for the selector and policy engine for upcoming prototypes and release versions of our library.\\

Yet another beneficial development for being able to weave a robust and wholesome protective net around is the development regarding DOM4 mutation observers. DOM4 mutation observers provide a new API to monitor mutation events occurring on DOM elements and nodes. Proposed by Klein et al. in 2011, Mutation Observers provide a simple API for simple change and mutation tracking on DOM elements and node groups~\footnote{Klein, A. et al., \textit{Mutation Observers: a replacement for DOM Mutation Events}, \url{http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1622.html} (Sep 2011)}. Mutation observers are represented by a new interface residing in \textit{DOMWindow} and provide to specify a callback and a set of options of what to observe: Subtree or child lists, attributes and character content of the node. Current Webkit builds already contain prototypic mutation observer implementation. This and other technical developments are highly beneficial for the development of further prototypes and ultimately release versions of our DOM-based security library.\\

While this thesis was made possible by funding from the Ministry of Economic Affairs and Energy of the State of North Rhine-Westphalia (Grant 315-43-02/2-005-WFBO-009) and the MAKE project, the upcoming work on JS Agents, DLR Grant 01BY1205A will allow us to continue our work and research and lead the proposed and so far prototypically implemented code to become a production ready software deployable via website scripts, browser extension, user scripts or even content added by ISP proxies and infrastructure. \\

\section{Impact, Benefits and Final Words}

The impact on and benefits for real-life applications and the general development of web security related projects implied by a purely DOM-based protection library are many -- as the following list outlines. Note that some of the benefits may introduce additional risks if implementation and infrastructural flaws are present; this includes possible Man-In-The-Middle (MITM) attacks and others. This is nevertheless independent of our implementation and prone to occurs in other real-life situations as well. The list can further be extended depending on the usage and deployment scenario. We therefore simply mention the most important benefits visible from an agnostic point of view.

% again show how awesome we are
\begin{itemize}
  %
 \item \textbf{Low-cost protection for existing websites} No complicated rewriting of existing code has to be performed. Unlike with CSP, the DOM-based protection library can fit itself to the website's conditions, adapt information about elements to be protected and, depending of the sophistication level of the implementation, automatically generate SSS policy sheets and settings.
  %
 \item \textbf{Small entry barrier for developers} Developers do not need to adapt to a new configuration language or dialect or commit changes to existing applications. SSS allows them to reuse they knowledge on CSS and our DOM-based protection tool simply needs to be installed in a manner be the first deployed JavaScript code on the website. A more advanced version can even check if the deployment was done correctly by determining and validating their own position in the DOM and issuing an alert message, if other script is being deployed earlier in the DOM tree.
  %
 \item \textbf{Usage of already implemented APIs/Standardized Features} We make use of the ES5 and ES6 functionalities and avoid non-standardized techniques and code. Therefore the library will benefit from the robustness of those implementations and mature alongside with the features of the browser. The SSS API will be able to make use of already installed CSS APIs and the CSSOM and therefor benefit of the robustness of the components and interfaces already in place as well.
  %
 \item \textbf{CPU load delegated to client UAs} A website owner or application service provider will not have to fully rely on server-side IDS and filter libraries anymore and therefore not be depending on their often CPU and load heavy algorithms. The load caused by pattern matching, sanitation and filtering and well as the RBAC enforcement will be outsourced to the client CPU(s) and not generate additional costs for the provider. With drastically increasing performance of end user hardware and mobile devices, the CPU load necessary for even complex versions of our tool should be almost not noticeable.
  %
 \item \textbf{Extensibility and other attacks} With the possibilities of central and API-based deployment of our protection library, the update of detection signatures and novel attack defenses will we possible for a vast range of clients in no time. Picturing for instance a large content provider network to be a way for deploying the library, changing a single file and updating its caching headers can update millions of clients and browsers without any noticeable effort. This nevertheless also bears the risk of centralized compromise -- but in our opinion outweighs this threat for being just one of many possible deployment vectors.
  %
\end{itemize}

The research we contributed aims to mark a turning point in web application security and the defense against scripting web attacks. We strongly believe that a client-side and DOM-based protection library is necessary for holistic website protection. Tendencies of modern operating systems to thrive towards a larger focus on HTML-based applications support this claim -- no server can easily protect against DOMXSS and operating system level script injections. Similar implications exist for off-line applications, complex mash-ups, chat clients and other browser like instrumentations processing complex and active markup submitted by users and potentially attackers. Future projects, security aware development trends from browser vendors, reasonable specification work from W3C, WHATWG and ECMA and ultimately continued and thorough research will help thriving further towards the elimination of XSS and scripting web attacks as we know them today.

% amen brother!