CorbFuzz: Checking Browser Security Policies with Fuzzing

Many Web sites embed third-party content in frames, relying on the browser's security policy to protect against malicious content. However, frames provide insufficient isolation in browsers that let framed content navigate other frames. We evaluate existing frame navigation policies and advocate a stricter policy, which we deploy in the open-source browsers. In addition to preventing undesirable interactions, the browser's strict isolation policy also affects communication between cooperating frames. We therefore analyze two techniques for interframe communication between isolated frames. The first method, fragment identifier messaging, initially provides confidentiality without authentication, which we repair using concepts from a well-known network protocol. The second method, <code>postMessage</code>, initially provides authentication, but we discover an attack that breaches confidentiality. We propose improvements in the <code>postMessage</code> API to provide confidentiality; our proposal has been standardized and adopted in browser implementations.

The source code of a web application executed on the web browser has been exposed to leakage, and it is difficult to implement various web functions compared with other general applications. Therefore, in practical web applications, web plug-in technologies are used. However, web plug-in technology has a platform dependency and is attacked by malicious codes which resulting in a damage of the system. On the other hands, the web-based emulator is independent of platforms as well as web browsers. Recently, various web emulators were introduced, and users can use it as the virtual machine environment of diverse platforms on the web browser. However, these web-based emulator doesn’t provide an interface API to access other web application. In this paper, we propose the modified web-based emulator with the interface module and API, called as the web emulator-based execution engine. Using the proposed system, a native code in a web application is easily written by C, and C++ and compiled. Furthermore it can be distributed and executed directly on the emulator-based web application execution engine. Therefore it solves the leak problem of source codes that is the vulnerability of web applications. The proposed emulator-based web application execution engine is a new concept combined web plug-in and emulator. In the experiment we developed an interface module and an API for the proposed emulator-based web application execution engine. The experimental emulator-based web application was implemented and tested to evaluate the overall system.KeywordsWeb applicationObfuscationEmulatorJavaScriptNative binary

We present an approach to write web applications in the programming languages Haskell [8] and Curry [6]. The web applications we propose are directly based on the Hypertext Transfer Protocol (HTTP) – no additional protocol on top of HTTP is necessary. Although the main ideas are not new and already applied using other programming languages, we believe that features present in modern declarative languages – especially algebraic datatypes – serve well to represent resources on the web. 1 TRANSFER OF RESOURCE REPRESENTATIONS A resource is any piece of information named by a Uniform Resource Identifier (URI). A web application provides access to internally stored information over the Internet or accesses such information provided by other web applications. Usually, (a representation of) this information is transferred using the Hypertext Transfer Protocol (HTTP) [3] – possibly employing some protocol on top of it. Note that we do not primarily consider applications running inside a web browser like [4, 7, 9]. HTTP provides different methods to access resources from which the most important are the GET and the POST method. GET is used to retrieve some information, e.g., web browsers use GET to ask for the content of web pages. POST is used to send information to be processed by a server, e.g., entries in a web form can be sent to the server using POST. While processing the request, the server can update its internally stored information and usually sends back a result of this process. Web applications differ in their use of these two HTTP methods: RPC-style web applications are accessible through a single URI and communication is performed using the POST method. A representation of a procedure call is transferred to the server, which returns a representation of the result of this call as answer to the POST request. Note that both retrieval and update operations are performed using the POST method in RPC-style web applications and the interface of such applications is determined by the procedure calls that are understood by the server. Fielding [2] proposes another architectural style for web applications: He proposes to use the POST method only to update the internal state of the server and to use the GET method to purely retrieve information. Consequently, everything that should be available for retrieval by clients needs to be identified by an own URI. This is a big difference to RPC-style web applications that are usually accessible ?This work was partially supported by the German Research Council (DFG) grant Ha 2457/5-1. through a single URI. In the architectural style proposed by Fielding, a client sends an HTTP GET request to an URI to retrieve a representation of the resource identified by this URI corresponding to the current state of the server. To change this state, the client sends a POST request to the URI of the resource he wants to update. Fielding calls this architectural style Representational State Transfer (REST). The interface of a RESTful web application is given by the methods of HTTP and the URIs identifying the applications resources. In this work, we show how the interface given by the most important HTTP methods can be made available to Haskell or Curry programmers, hiding the details of HTTP communication.

As mentioned in the previous chapter, a server control is an object that is displayed on an ASP.NET Web page. When a Web page is requested from a server via an HTTP request, the server processes the page request (as described in Chapter 1 , titled "Web Application Development") and then sends the client the resulting HTML code via an HTTP response. When the Web browser receives the HTTP response, it renders the page and displays it for the end user. In the context of an ASP.NET Web application, the term render refers to the process of creating a visual representation of the page, including all of its associated server controls, based on the HTML code received from the server in its HTTP response. In that chapter, we looked at six basic server control classes: the Label class, the TextBox class, the Button class, the Table class, the TableRow class, and the TableCell class. Although these six classes provided us with enough ASP.NET functionality to get started, there are many other server control classes in the .NET Framework Class Library.

Web applications typically interact with a back-end database to retrieve persistent data and then present the data to the user as dynamically generated output, such as HTML web pages. However, this interaction is commonly done through a low-level API by dynamically constructing query strings within a general-purpose programming language, such as Java. This low-level interaction is ad hoc because it does not take into account the structure of the output language. Accordingly, user inputs are treated as isolated lexical entities which, if not properly sanitized, can cause the web application to generate unintended output. This is called a command injection attack , which poses a serious threat to web application security. This paper presents the first formal definition of command injection attacks in the context of web applications, and gives a sound and complete algorithm for preventing them based on context-free grammars and compiler parsing techniques. Our key observation is that, for an attack to succeed, the input that gets propagated into the database query or the output document must change the intended syntactic structure of the query or document. Our definition and algorithm are general and apply to many forms of command injection attacks. We validate our approach with SqlCheckS , an implementation for the setting of SQL command injection attacks. We evaluated SqlCheckS on real-world web applications with systematically compiled real-world attack data as input. SqlCheckS produced no false positives or false negatives, incurred low runtime overhead, and applied straightforwardly to web applications written in different languages.

Web applications typically interact with a back-end database to retrieve persistent data and then present the data to the user as dynamically generated output, such as HTML web pages. However, this interaction is commonly done through a low-level API by dynamically constructing query strings within a general-purpose programming language, such as Java. This low-level interaction is ad hoc because it does not take into account the structure of the output language. Accordingly, user inputs are treated as isolated lexical entities which, if not properly sanitized, can cause the web application to generate unintended output. This is called a command injection attack, which poses a serious threat to web application security. This paper presents the first formal definition of command injection attacks in the context of web applications, and gives a sound and complete algorithm for preventing them based on context-free grammars and compiler parsing techniques. Our key observation is that, for an attack to succeed, the input that gets propagated into the database query or the output document must change the intended syntactic structure of the query or document. Our definition and algorithm are general and apply to many forms of command injection attacks. We validate our approach with SqlCheckS, an implementation for the setting of SQL command injection attacks. We evaluated SqlCheckS on real-world web applications with systematically compiled real-world attack data as input. SqlCheckS produced no false positives or false negatives, incurred low runtime overhead, and applied straightforwardly to web applications written in different languages.

The main issues of current web application is easily hacking the user information by unauthorized person. The development of entire web application depends on scripting languages that easily displays the user authentication code to the web browser. All code must be transferred through query string parameter (URL) of the web application. This kind of application security fails when verifying it by penetration testing which is based on XSS languages. This study overcomes the security issues by developing a web application based on cross site scripting technique which the user codes are encrypted using RSA algorithm and cookies, cross domain verification based on encrypted use code. XSS vulnerabilities come in different forms and may be categorized into two varieties: reflected and stored. Reflected is on type of attack which can be performed against applications that employ a dynamic page error message to users. Stored XSS vulnerability appears when data submitted by one user is store in the application or in the back-end database. The user cookies of the web browser store only the encrypted key values. These techniques applied in Enterprise web application it support multiple organization for processing product purchase order, sales order and invoice details.

Bugs in the authorisation logic of web applications can expose the data of one user to another. Such data disclosure vulnerabilities are common---they can be caused by a single omitted access control check in the application. We make the observation that, while the implementation of the authorisation logic is complex and therefore error-prone, most web applications only use simple access control models, in which each piece of data is accessible by a user or a group of users. This makes it possible to validate the correct operation of the authorisation logic externally, based on the observed data in HTTP traffic to and from an application. We describe FlowWatcher, an HTTP proxy that mitigates data disclosure vulnerabilities in unmodified web applications. FlowWatcher monitors HTTP traffic and shadows part of an application's access control state based on a rule-based specification of the user-data-access (UDA) policy. The UDA policy states the intended data ownership and how it changes based on observed HTTP requests. FlowWatcher detects violations of the UDA policy by tracking data items that are likely to be unique across HTTP requests and responses of different users. We evaluate a prototype implementation of FlowWatcher as a plug-in for the Nginx reverse proxy and show that, with short UDA policies, it can mitigate CVE bugs in six~popular web applications.

Web applications service a gamut of users with a mix of static and dynamic resources: requests come from different devices running different Web agents (typically, Web browsers) with different capabilities. In a majority of such interactions, services are embedded in an HTML page and displayed on a Web browser. Consequently, Web application development has been tightly coupled with the platforms that a particular site intends to support; application developers have been asked to decide where to run what at design time to develop services using location-specific technologies and interweave them with static resources. Such difficulties stem from lack of adequate infrastructural support for platform-agnostic development and deployment framework. This paper presents the design and implementation of a framework for Web application development which hides the heterogeneity of the Internet and the underlying interaction model. It has been meticulously designed such that it is non-intrusive and requires little change to the existing Web infrastructure. The framework is built on top of a programming model that provides a uniform view across different platforms and thus hides the heterogeneity and distributivity of the Internet. Adaptive deployment involves placement specification and compiler translation. The uniformity gives rise to rapid prototyping and development, thereby reducing costs and improving productivity. The adaptiveness enables QoS aware service provisioning.

With conventional regression test tools for Web applications, it is difficult to specify the values to be verified that are repeated output inside loop statements. We need to select each of these values displayed in Web pages with the mouse. This paper presents a method that automates regression testing of Web applications on the server side. This method makes it easy to specify values to be verified and enables us to specify them when we develop Web applications. We can directly check the verification results on the Web pages that are shown in the Web browser. If we find a fault, we can even directly modify a part of the server program in the Web browser that corresponds to the currently displayed Web page.

A Web application is an application that is invoked with a Web browser over the Internet. Ever since 1994 when the Internet became available to the public and especially in 1995 when the World Wide Web put a usable face on the Internet, the Internet has become a platform of choice for a large number of ever-more sophisticated and innovative Web applications. In just one decade, the Web has evolved from being a repository of pages used primarily for accessing static, mostly scientific, information to a powerful platform for application development and deployment. New Web technologies, languages, and methodologies make it possible to create dynamic applications that represent a new model of cooperation and collaboration among large numbers of users. Web application development has been quick to adopt software engineering techniques of component orientation and standard components. For example, search, syndication, and tagging have become standard components of a new generation of collaborative applications and processes. Future developments in Web applications will be driven by advances in browser technology, Web Internet infrastructure, protocol standards, software engineering methods, and application trends.

Web applications are evolving to a decentralized, client-centric architecture in which browsers need to be able to put the user back in control of their personal data, need to be able to operate in disconnected settings, and need to offload the web server as much as possible. This paper presents a set of key application scenarios and trends in different business domains that require a more client-centric and data-centric web middleware for decentralized, peer-to-peer web applications in the edge. We define a set of key requirements for data operations in such middleware and motivate them with the application cases. This paper further discusses the current state and limitations of the browser as a platform for peer-to-peer communication and complex decentralized applications with shared data. We conclude with a performance assessment of our first prototype middleware for client-centric and data-centric peer-to-peer web applications.

Abstract. As web applications become more popular, 3D city models would greatly benefit from a proper web-based solution to visualise and manage them. CityJSON was introduced as a JSON encoding of the CityGML data model and promises, among several benefits, the ability to be integrated with modern web technologies. In order to provide an implementation of a web application for CityJSON data, that can be used as a reference for other applications, we developed ninja. It is a web application that allows the user to easily load and investigate a CityJSON model through a web browser. In addition, it offers support for a complex feature of CityJSON: the experimental versioning mechanism. In this paper, we describe the motivation, requirements, technical aspects and achieved functionality of ninja. We believe that such a web application can facilitate the adoption of 3D city models by more practitioners and decision makers.

A single-page application is a web application which is retrieved with a single page load, and has become popular recently. In such web applications, real-time interaction is offered by long polling of HTML requests, typically the Comet model. However, such communication between a client and a server is inefficient because of the TCP handshake and HTTP header overhead. In order to improve this kind of inefficiency, WebSocket is proposed as a web technology providing full-duplex communications between web browsers and servers. In this paper, we design and implement a load balancer suitable for Web applications using the WebSocket protocol, which enables us to get improved performance with respect to simultaneous connectability. Usually, load balancers handle TCP packets in the transport layer, or L4, of the network. Our load balancer is designed as a relay in the application layer, or L7, in order to provide a finer distribution of the network load. We implement the load balancer on an event-driven web application framework, Node.js. We evaluate the implementation of efficiency of the load balancer.KeywordsLoad BalancerConnection RequestServer PoolSession ObjectLoad Balancer ProcessThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Web Workers is a specification that defines an API which allows Web application developers to use background workers running scripts in parallel. Web Workers is used with JavaScript and is platform-independent. Hence, Web applications written in JavaScript can be used for a wide variety of purposes. There are many Web applications and some of them, for instance Internet election campaign and real-time broadcasting, need secure communications. We can include digital signatures with such Web applications to guarantee their security of communications. In this demonstration proposal, we assess the performance of parallel implementations of public key cryptosystems on several Web browsers (Internet Explorer, Google Chrome, Opera, and Firefox). With our implementation, it is possible to verify a message in 1.03 milliseconds on a Windows PC and 5.49 milliseconds on an Android tablet (Nexus 7). We also propose cryptography applications for Web browsers.