Analysis Framework to Detect Artifacts of Portable Web Browser

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.

WebWriter: A browser-based editor for constructing Web applications

Development of web browser prototype with embedded classification capability for mitigating Cross-Site Scripting attacks

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

Drive-by-download attacks are client-side attacks that originate from web servers that are visited by web browsers. While many web browsers are vulnerable to the drive-by-download attacks, the cost of detecting malicious web pages that launch drive-by-download attacks is expensive. High-interaction client honeypots are security devices capable of detecting malicious web pages; however, their slow and expensive operations in web page visiting have been considered as a problem. The high-interaction client honeypots employ a visitation algorithm to pinpoint which page has made an unauthorized change of system state when any unauthorized change of the system state occurred after visiting suspicious web pages. To improve the performance of the high-interaction client honeypots, we propose a new visitation algorithm, logarithmic divide-and-conquer (LDAC), for identifying malicious web pages. The LDAC algorithm is an enhanced version of the existing binary divide-and-conquer (BDAC) algorithm. If any system state is abnormally changed after having visited k suspicious web pages concurrently, our LDAC algorithm divides the buffer of k pages into [log2k] pieces and recursively visits the pieces until the malicious page or pages are identified, while the BDAC splits the buffer into k/2 portions. Experimental results show that the LDAC has improved performance of the system up to 15 percent compared to the BDAC algorithm.

Including JavaScript code from many different hosts is a popular practice in developing web applications. For example, to include a social plugin like the Facebook Like button, a web developer needs to only include a script from facebook.net in her/his web page. However, in a web browser, all the identifiers (i.e., variable names and function names) in scripts loaded in the same frame share a single global namespace. Therefore, a script can overwrite any of the global variables and/or global functions defined in another script, causing unexpected behavior. In this work, we develop a browser-based dynamic analysis framework, that monitors and records any writes to JavaScript global variables and global functions. Our tool is able to cover all the code executed in the run time. We detected 778 conflicts across the Alexa top 1K websites. Our results show that global name conflicts can indeed expose web applications to security risks.

Non-linear least squares fit of specific heat data within the Schotte–Schotte model using web page

Parallelized sub-resource loading for web rendering engine

E-commerce, e-mail, e-greeting, e-this, and e-that everywhere you turn there is a new "e" word for an internet or Web application. We, at the Cleveland Clinic Foundation, have been "e-nlightened" and will discuss in this report the implementation of a web-based radiology information system (RIS) in our radiology division or "e-radiology" division. The application, IDXRad Version 10.0 from IDX Corp, Burlington, VT, is in use at the Cleveland Clinic Foundation and has both intranet (for use in Radiology) and internet (referring physician viewing) modules. We will concentrate on the features of using a web browser for the application's front-end, including easy prototyping for screen review, easier mock-ups of demonstrations by vendors and developers, and easier training as more people become web-addicted. Project communication can be facilitated with an internal project web page, and use of the web browser can accommodate quicker turnaround of software upgrades as the software code is centrally located. Compared with other technologies, including client/server, there is a smaller roll out cost when using a standard web browser. However, the new technology requires a change and changes are never implemented without challenges. A seasoned technologist using a legacy system can enter data quicker using function keys than using a graphical user interface and pointing and clicking through a series of pop-up windows. Also, effective use of a web browser depends on intuitive design for it to be easily implemented and accepted by the user. Some software packages will not work on both of the popular web browsers and then are tailored to specific release levels. As computer-based patient records become a standard, patient confidentiality must be enforced. The technical design and application security features that support the web-based software package will be discussed. Also web technologies have their own implementation issues.

WWW has developed rapidly, and it is becoming easy to make personal web sites. In general, we create and edit web pages by using a HTML authoring software or writing HTML source codes in a text editor. Then, we need to upload them to a web server. When we make and build our own web pages by the existing tools, it takes a lot of time and effort to complete the necessary tasks. In this paper, we propose a home page authoring support system in which we directly edit and make web pages on a web browser. Current experimental results demonstrate that our system can effectively support novices to create their web pages. Also, we show two real-world applications that effectively utilize our system.

A Novel Approach to HTML Page Creation Using Neural Network

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.

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.

We present a way to run Objective Caml programs on a standard, unmodified web browser, with a compatible data representation and execution model, including concurrency. To achieve this, we designed a bytecode interpreter in JavaScript, as well as an implementation of the runtime library. Since the web browser does not provide the same interaction mechanisms as a typical Objective Caml environment, we provide an add-on to the standard library, enabling interaction with the web page. As a result, one can now build the client side of a web application with the standard Objective Caml compiler and run it on any modern web browser.

CHAPTER 1 - Cross-Site Scripting