WAVES: Automatic Synthesis of Client-Side Validation Code for Web Applications

Abstract

The current practice of web application development treats the client and server components of the application as two separate but interacting pieces of software. Each component is written independently, usually in distinct programming languages and development platforms -a process known to be prone to errors when the client and server share application logic. When the client and server are out of sync, an "impedance mismatch" occurs, often leading to software vulnerabilities as demonstrated by recent work on parameter tampering. This paper outlines the groundwork for a new software development approach, WAVES, where developers author the server-side application logic and rely on tools to automatically synthesize the corresponding client-side application logic. WAVES employs program analysis techniques to extract a logical specification from the server, from which it synthesizes client code. WAVES also synthesizes interactive client interfaces that include asynchronous callbacks whose performance and coverage rival that of manually written clients while ensuring no new security vulnerabilities are introduced. The effectiveness of WAVES is demonstrated and evaluated on three real-world web applications.

Systematic identification of threats in the cloud: A survey

“…For this category, we concern only the attacks manipulating the operations specific to authentications. Such attacks include service engine exploitation (Saripalli and Walters, 2010), stealing unprotected authentication data (e.g., credentials or session tokens) (Saripalli and Walters, 2010), forgery of URL to expose authentication data (Yu et al, 2011), and exploitation and bypass credential validations (Skrupsky et al, 2012). Also, exposed administration and management interfaces, redundant user profiles, and improper authentication and authorization can allow attackers to exploit backdoor vulnerabilities (Jansen, 2011;Modi et al, 2013b).…”

“…jected, without having the user to execute applications to trigger the malicious code execution. Such attacks include "cross-site scripting" (XSS for short) (Yusof and Pathan, 2016) (Yu et al, 2011), malware injection (Khalil et al, 2014), SQL injection (Gruschka and Jensen, 2010;Dessiatnikoff et al, 2011), Javascript injection (Provos et al, 2009), OS commanding (Dessiatnikoff et al, 2011), XPATH injection (Saripalli and Walters, 2010;Dessiatnikoff et al, 2011), LDAP injection (Modi et al, 2013a;Skrupsky et al, 2012).…”

“…The attacker can exploit weak cryptographic systems using various statistical and analytical approaches (Yu et al, 2011). Such attacks include Bruteforce attack (Ristenpart et al, 2009), "man in the middle attack" (Subashini and Kavitha, 2011), Side-channel attack (Zhang et al, 2012a), and misconfiguration of the client side validation to bypass authentication (Saripalli and Walters, 2010;Skrupsky et al, 2012).…”

Feral Concurrency Control

“…Rails has been the subject of study in the verification of cross-site scripting attacks [32], errors in data modeling of associations [68], and arbitrary, user-specified (non-validation) invariants [25]. Rails-style ORM validations have been used to improve systems security via client-side execution [58,76]. Our focus here is on the concurrency control requirements and usages of applications written in Rails.…”

“…On the other hand, more recent proposals for invariant-based concurrency control [17,65] and a litany of work from prior decades on rulebased [82] and, broadly, semantics-based concurrency control [79] appear immediately applicable and worth (re-)considering. Recent advances in program analysis for extracting invariants [73] and subroutines from imperative code [33] may allow us to programatically suggest new invariants, perform correspondence checking for existing applications, and apply a range of automated optimizations to legacy code [34,76]. Finally, clean-slate language design and program analysis obviate the need for explicit invariant declaration (thus alleviating concerns of specification completeness) [11,12,84]; while adoption within the ORM community is a challenge, we view this exploration as worthwhile.…”