Tomáš Petříček · Digital Repository (National Repository of Grey Literature) · 2007
"Ajax" programming is becoming a de-facto standard for certain types of web applications, but unfortunately developing this kind of application is a difficult task. Developers have to deal with problems like a language impedance mismatch, limited execution runtime in web browser on the client-side and no integration between client and server-side parts that are developed as a two independent applications, but typically form a single and homogenous application. In this work we present the first project that deals with all three mentioned problems but which still integrates with existing web technologies such as ASP.NET on the server and JavaScript on the client. We use the F# language for writing both client and server-side part of the web application, which makes it possible to develop client-side code in a type-safe programming language using a subset of the F# library, and we provide a way to write both server-side and client-side code as a part of single homogeneous type defining the web page logic. The code is executed heterogeneously, part as JavaScript on the client, and part as native code on the server. Finally we use monadic syntax for the separation of client and server-side code, tracking this separation through the F# type system.
Cited by 1
Michael Mendez · 2014
Cited by 0
Estifanos Tilahun Mihret · 2021
Cited by 0Open access
Abu Hamada, Haider Ali Mohammed · 2013
Cited by 3
Stock, Benjamin · 2015
Cited by 0
José Carlos Pazos, Jean‐Sébastien Légaré, Ivan Beschastnikh · Empirical Software Engineering · 2023
Cited by 1
Dr Kavita Patil, Kailas Patil · International Journal of Computer Applications · 2015
Web applications are useful for various online services. These web applications are becoming ubiquitous in our daily lives. They are used for multiple purposes such as e-commerce, financial services, emails, healthcare services and many other captious services. But the presence of vulnerabilities in the web application may become a serious cause for the security of the web application. A web application may contain different types of vulnerabilities. According to OWASP TOP 10 vulnerability report, Cross-site Scripting (XSS) is among top 5 vulnerabilities. So this research work aims to implement effective solution for the prevention of cross-site scripting vulnerabilities. In this paper, we implemented a novel client-side XSS sanitizer that prevents web applications from XSS attacks. Our sanitizer is able to detect cross-site scripting vulnerabilities at the client-side. It strengthens web browser, because modern web browser do not provide any specific notification, alert or indication of security holes or vulnerabilities and their presence in the web application.
Cited by 15Open access
Stock, Benjamin · OPUS FAU (Kooperativer Bibliotheksverbund Berlin-Brandenburg (KOBV), on behalf of the Universitätsbibliothek Erlangen-Nürnberg) · 2015
The Web's functionality has shifted from purely server-side code to rich client-side applications, which allow the user to interact with a site without the need for a full page load. While server-side attacks, such as SQL or command injection, still pose a threat, this change in the Web's model also increases the impact of vulnerabilities aiming at exploiting the client. The most prominent representative of such client-side attacks is Cross-Site Scripting, where the attacker's goal is to inject code of his choosing into the application, which is subsequently executed by the victimized browsers in the context of the vulnerable site. This thesis provides insights into different aspects of Cross-Site Scripting. First, we show that the concept of password managers, which aim to allow users to choose more secure passwords and, thus, increase the overall security of user accounts, is susceptible to attacks which abuse Cross-Site Scripting flaws. In our analysis, we found that almost all built-in password managers can be leveraged by a Cross-Site Scripting attacker to steal stored credentials. Based on our observations, we present a secure concept for password managers, which does not insert password data into the document such that it is accessible from the injected JavaScript code. We evaluate our approach from a functional and security standpoint and find that our proposal provides additional security benefits while not causing any incompatibilities. Our work then focuses on a sub-class of Cross-Site Scripting, namely Client-Side Cross-Site Scripting. We design, implement and execute a study into the prevalence of this class of flaws at scale. To do so, we implement a taint-aware browsing engine and an exploit generator capable of precisely producing exploits based on our gathered data on suspicious, tainted flows. Our subsequent study of the Alexa top 5,000 domains shows that almost one out of ten of these domains carry at least one Client-Side Cross-Site Scripting vulnerability. We follow up on these flaws by analyzing the gathered flow data in depth in search of the root causes of this class of vulnerability. To do so, we first discuss the complexities inherent to JavaScript and define a set of metrics to measure said complexity. We then classify the vulnerable snippets of code we discovered according to these metrics and present the key insights gained from our analysis. In doing so, we find that the reasons for such flaws are manifold, ranging from simple unawareness of developers to incompatibilities between, otherwise safe, first- and third-party code. In addition, we investigate the capability of the state of the art of Cross-Site Scripting filters in the client, the XSS Auditor, finding that several conceptual issues exist which an attacker to subvert of its protection capabilities. We show that the Auditor can be bypassed on over 80% of the vulnerable domains in our data set, highlighting that it is ill-equipped to stop Client-Side Cross-Site Scripting. Motivated by our findings, we present a concept for a filter targeting Client-Side Cross-Site Scripting, combining taint tracking in the browser in conjunction with taint-aware HTML and JavaScript parsers, allowing us to robustly protect users from such attacks.
Cited by 0Open access
José Carlos Pazos, Jean‐Sébastien Légaré, Ivan Beschastnikh · 2021
We present XSnare, a client-side Cross-Site Scripting (XSS) solution implemented as a Firefox extension. The client-side design of XSnare can protect users before application developers release patches and before server operators apply them.XSnare blocks XSS attacks by using previous knowledge of a web application’s HTML template content and the rich DOM context. XSnare uses a database of exploit descriptions, which are written with the help of previously recorded CVEs. It singles out injection points for exploits in the HTML and dynamically sanitizes content to prevent malicious payloads from appearing in the DOM. XSnare displays a secured version of the site, even if is exploited.We evaluated XSnare on 81 recent CVEs related to XSS attacks, and found that it defends against 93.8% of these exploits. To the best of our knowledge, XSnare is the first protection mechanism for XSS that is application-specific, and based on publicly available CVE information. We show that XSnare’s specificity protects users against exploits which evade other, more generic, XSS defenses.Our performance evaluation shows that our extension’s overhead on web page loading time is less than 10% for 72.6% of the sites in the Moz Top 500 list.
Cited by 5
Kindred, Andrew · 2018
Cited by 0
Hauser, Andrea · Zenodo (CERN European Organization for Nuclear Research) · 2017
DOM stands for Document Object Model. XSS stands for cross-site scripting. The main difference between DOM based XSS and other XSS vulnerabilities is that the payload is embedded on the client side rather than the server side. DOM based XSS vulnerabilities therefore have to be prevented on the client side.
Cited by 0Open access
2008
I present an implementation of Scheme embedded within a Web browser for wireless terminals. Based on a port of TinyScheme integrated with RocketBrowser, an XHTML-MP browser running on Qualcomm BREW-enabled handsets. In addition to a comparison of the resulting script capabilities, I present the changes required to bring TinyScheme to Qualcomm BREW, including adding support for BREW components as TinyScheme data types. The resulting application supports the same kinds of dynamic client-side scripted behavior as a traditional Javascript-enabled Web browser in environments too memory constrained for a Javascript implementation.
Cited by 0
Zahra Behfarshad, Ali Mesbah · Lecture notes in computer science · 2013
Cited by 13Open access
Grégory Blanc, Ruo Ando, Youki Kadobayashi · 2011
Ensuring users with a safe web experience has become a critical problem recently as fraud and privacy infringement on the Internet are becoming current. Web-scripting-based malware is also intensively used to carry out longer-term exploitation such as XSS worms or botnets, and server-side countermeasures are often ineffective against such threats while client-side ones seldom deal with the problem of obfuscation. In order to provide a sounder and more complete analysis, we propose to carry out deobfuscation of web-scripting-language-based malware. In this paper, we study the possibility of automating the deobfuscation process using a term rewriting system based on automated deduction. Such static approach intends to evade anti-analysis techniques and unknown obfuscation schemes. With some preliminary experiments in JavaScript, we show evidence that this is actually possible and highlight several challenges we need to tackle in order to implement an effective script-based malware deobfuscator. This approach can be generalized to web scripting languages other than JavaScript such as ActionScript or VBScript. Applications encompass script-based malware static analysis or malware distribution website crawling. This paper is included in a wider project that aims to provide a client-based defense against Web 2.0 malware.
Cited by 12
Engin Kirda, Christopher Kruegel, Giovanni Vigna et al. · 2006
access to on-line services. At the same time, web application vulnerabilities are being discovered and disclosed at an alarming rate. Web applications often make use of JavaScript code that is embedded into web pages to support dynamic client-side behavior. This script code is executed in the context of the user's web browser. To protect the user's environment from malicious JavaScript code, a sandboxing mechanism is used that limits a program to access only resources associated with its origin site. Unfortunately, these security mechanisms fail if a user can be lured into downloading malicious JavaScript code from an intermediate, trusted site. In this case, the malicious script is granted full access to all resources (e.g., authentication tokens and cookies) that belong to the trusted site. Such attacks are called cross-site scripting (XSS) attacks.
Cited by 0
Mamoru Mimura, Takumi Yamasaki · Lecture notes in networks and systems · 2021
Cited by 2
Aditya Kappagantula · INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING & TECHNOLOGY · 2024
This article comprehensively analyzes enterprise-scale serverless data processing compute platforms -AWS EMR Serverless, Google Cloud Dataproc Serverless, and Azure Synapse Serverless -going beyond traditional static resource compute jobs and lightweight serverless computing to address large-scale data analytics needs.The article examines how these specialized platforms enable complex batch processing, near real-time streaming jobs, ETL operations, and distributed machine learning workloads on petabyte-scale datasets while maintaining serverless benefits of dynamic scaling and consumption-based pricing.Through a systematic evaluation of enterprise
Cited by 0Open access
Engin Kirda, Christopher Kruegel, Giovanni Vigna et al. · 2009
Web applications are becoming the dominant way to provide access to on-line services. At the same time, web application vulnerabilities are being discovered and disclosed at an alarming rate. Web applications often make use of JavaScript code that is embedded into web pages to support dynamic client-side behavior. This script code is executed in the context of the user’s web browser. To protect the user’s environment from malicious JavaScript code, a sandboxing mechanism is used that limits a program to access only resources associated with its origin site. Unfortunately, these security mechanisms fail if a user can be lured into downloading malicious JavaScript code from an intermediate, trusted site. In this case, the malicious script is granted full access to all resources (e.g., authentication tokens and cookies) that belong to the trusted site. Such attacks are called cross-site scripting (XSS) attacks. In general, XSS attacks are easy to execute, but difficult to detect and prevent. One reason is the high flexibility of HTML encoding schemes, offering the attacker many possibilities for circumventing server-side input filters that should prevent malicious scripts from being injected into trusted sites. Also, devising a client-side solution is not easy because of the difficulty of identifying JavaScript code as being malicious. This paper presents Noxes, which is, to the best of our knowledge, the first client-side solution to mitigate cross-site scripting attacks. Noxes acts as a web proxy and uses both manual and automatically generated rules to mitigate possible cross-site scripting attempts. Noxes effectively protects against information leakage from the user’s environment while requiring minimal user interaction and customization effort. 1.
Cited by 0
Ray Rischpater · 2006
I present an implementation of Scheme embedded within a Web browser for wireless terminals. Based on a port of TinyScheme integrated with RocketBrowser, an XHTML-MP browser running on Qualcomm BREW-enabled handsets. In addition to a comparison of the resulting script capabilities, I present the changes required to bring TinyScheme to Qualcomm BREW, including adding support for BREW components as TinyScheme data types. The resulting application supports the same kinds of dynamic client-side scripted behavior as a traditional Javascript-enabled Web browser in environments too memory constrained for a Javascript implementation.
Cited by 0
Gordon Chiu, Bernice Chan · 2006
Web applications have become the dominant method for implementing and providing access to on-line services. As the use of web applications increases, a greater focus on web security is needed. In recent years, there has been a significant increase in the number of web-based attacks [1]. One key technology used in interactive web applications is JavaScript [2]. Embedded into the HTML of a web page, it is dynamically executed at the client,
Cited by 0