A Targeted Assessment of Cross-Site Scripting Detection Tools

Cross-Site Scripting (XSS) attacks are among the most exploited vulnerabilities in web applications. As a countermeasure, various open-source XSS detectors have been released over the years, but none of such tools has been significantly tested to verify their effectiveness. In this paper, we propose an assessment of five of the most employed XSS detectors in the wild. The purpose of this analysis is two-folded: (i) to understand their efficacy in well-known and customized vulnerable environments; (ii) to provide a better comprehension of their detection mechanisms. We performed our evaluation by testing the detectors against one publicly available test bench. Additionally, we created two customized test benches that contain less trivial XSS vulnerabilities. The attained results show how, while most detectors show good accuracy at detecting trivial XSS vulnerabilities, they could fail as the XSS complexity increases

Cross-Site Scripting (XSS) Detection Integrating Evidences in Multiple Stages

As Cross-Site Scripting (XSS) remains one of the top web security risks, people keep exploring ways to detect such attacks efficiently. So far, existing solutions only focus on the payload in a web request or a response, a single stage of a web transaction. This work proposes a new approach that integrates evidences from both a web request and its response in order to better characterize XSS attacks and separate them from normal web transactions. We first collect complete payloads of XSS and normal web transactions from two databases and extract features from them using the Word2vec technique. Next, we train two Gaussian mixture models (GMM) with these features, one for XSS transaction and one for normal web transactions. These two models can generate two probability scores for a new web transaction, which indicate how similar this web transaction is to XSS and normal traffics respectively. Finally, we put together these two GMM models in classification by combining these two probabilities to further improve detection accuracy

Spartan Web Application Firewall

Computer security is an ongoing issue and attacks are growing more sophisit- cated. One category of attack utilizes cross-site scripting (XSS) to extract confiden- tial data such as a user’s login credential’s without the knowledge of either the user nor the web server by utilizing vulnerabilities on web pages and internet browsers. Many people develop their own web applications without learning about or having good coding practices or security in mind. Web application firewalls are able to help but can be enhanced to be more effective than they currently are at detecting re- flected XSS attacks by analyzing the request and response data sent between the web application by a user’s browser to more quickly determine if a reflected XSS attack is being attempted. Spartan Web Application Firewall is designed to do this efficiently without being limited to requiring users to be using a specific web browser or web browser plug-in

How to deploy security mechanisms online (consistently)

To mitigate a myriad of Web attacks, modern browsers support client-side secu- rity policies shipped through HTTP response headers. To enforce these policies, the operator can set response headers that the server then communicates to the client. We have shown that one of those, namely the Content Security Policy (CSP), re- quires massive engineering effort to be deployed in a non-trivially bypassable way. Thus, many policies deployed on Web sites are misconfigured. Due to the capability of CSP to also defend against framing-based attacks, it has a functionality-wise overlap with the X-Frame-Options header. We have shown that this overlap leads to inconsistent behavior of browsers, but also inconsistent deployment on real-world Web applications. Not only overloaded defense mechanisms are prone to security inconsistencies. We investigated that due to the structure of the Web it- self, misconfigured origin servers or geolocation-based CDN caches can cause unwanted security inconsistencies. To not disregard the high number of misconfigurations of CSP, we also took a closer look at the deployment process of the mechanism. By conducting a semi-structured interview, including a coding task, we were able to shed light on motivations, strategies, and roadblocks of CSP deployment. However, due to the wide usage of CSP, drastic changes are generally considered impractical. Therefore, we also evaluated if one of the newest Web security features, namely Trusted Types, can be improved.Um eine Vielzahl von Angriffen im Web zu entschärfen, unterstützen moderne Browser clientseitige Sicherheitsmechanismen, die über sogenannte HTTP Response- Header übermittelt werden. Um jene Sicherheitsfeatures anzuwenden, setzt der Betreiber einer Web site einen solchen Header, welchen der Server dann an den Client ausliefert. Wir haben gezeigt, dass das konfigurieren eines dieser Mechanismen, der Content Security Policy (CSP), einen enormen technischen Aufwand erfordert, um auf nicht triviale Weise umgangen werden zu können. Daher ist jenes feature auf vielen Webseiten, auch Top Webseiten, falsch konfiguriert. Aufgrund der Fähigkeit von CSP, auch Framing-basierte Angriffe abzuwehren, überschneidet sich seine Funktionalität darüber hinaus mit der des X-Frame-Options Headers. Wir haben gezeigt, dass dies zu inkonsistentem Verhalten von Browsern, aber auch zu inkonsistentem Einsatz in realen Webanwendungen führt. Nicht nur überladene Verteidigungsmechanismen sind anfällig für Sicherheitsinkonsistenzen. Wir haben untersucht, dass aufgrund der Struktur desWebs selbst, falsch konfigurierte Ursprungsserver, oder CDN-Caches, die von der geographischen Lage abhängen, unerwünschte Sicherheitsinkonsistenzen verursachen können. Um die hohe Anzahl an Fehlkonfigurationen von CSP-Headern nicht außer Acht zu lassen, haben wir uns auch den Erstellungsprozess eines CSP-Headers genauer angesehen. Mit Hilfe eines halbstrukturierten Interviews, welches auch eine Programmieraufgabe beinhaltete, konnten wir die Motivationen, Strategien und Hindernisse beim Einsatz von CSP beleuchten. Aufgrund der weiten Verbreitung von CSP werden drastische Änderungen allgemein jedoch als unpraktisch angesehen. Daher haben wir ebenfalls untersucht, ob eine der neuesten und daher wenig genutzten,Web-Sicherheitsmechanismen, namentlich Trusted Types, ebenfalls verbesserungswürdig ist

Web-based Secure Application Control

The world wide web today serves as a distributed application platform. Its origins, however, go back to a simple delivery network for static hypertexts. The legacy from these days can still be observed in the communication protocol used by increasingly sophisticated clients and applications. This thesis identifies the actual security requirements of modern web applications and shows that HTTP does not fit them: user and application authentication, message integrity and confidentiality, control-flow integrity, and application-to-application authorization. We explore the other protocols in the web stack and work out why they can not fill the gap. Our analysis shows that the underlying problem is the connectionless property of HTTP. However, history shows that a fresh start with web communication is far from realistic. As a consequence, we come up with approaches that contribute to meet the identified requirements. We first present impersonation attack vectors that begin before the actual user authentication, i.e. when secure web interaction and authentication seem to be unnecessary. Session fixation attacks exploit a responsibility mismatch between the web developer and the used web application framework. We describe and compare three countermeasures on different implementation levels: on the source code level, on the framework level, and on the network level as a reverse proxy. Then, we explain how the authentication credentials that are transmitted for the user login, i.e. the password, and for session tracking, i.e. the session cookie, can be complemented by browser-stored and user-based secrets respectively. This way, an attacker can not hijack user accounts only by phishing the user's password because an additional browser-based secret is required for login. Also, the class of well-known session hijacking attacks is mitigated because a secret only known by the user must be provided in order to perform critical actions. In the next step, we explore alternative approaches to static authentication credentials. Our approach implements a trusted UI and a mutually authenticated session using signatures as a means to authenticate requests. This way, it establishes a trusted path between the user and the web application without exchanging reusable authentication credentials. As a downside, this approach requires support on the client side and on the server side in order to provide maximum protection. Another approach avoids client-side support but can not implement a trusted UI and is thus susceptible to phishing and clickjacking attacks. Our approaches described so far increase the security level of all web communication at all time. This is why we investigate adaptive security policies that fit the actual risk instead of permanently restricting all kinds of communication including non-critical requests. We develop a smart browser extension that detects when the user is authenticated on a website meaning that she can be impersonated because all requests carry her identity proof. Uncritical communication, however, is released from restrictions to enable all intended web features. Finally, we focus on attacks targeting a web application's control-flow integrity. We explain them thoroughly, check whether current web application frameworks provide means for protection, and implement two approaches to protect web applications: The first approach is an extension for a web application framework and provides protection based on its configuration by checking all requests for policy conformity. The second approach generates its own policies ad hoc based on the observed web traffic and assuming that regular users only click on links and buttons and fill forms but do not craft requests to protected resources.Das heutige World Wide Web ist eine verteilte Plattform für Anwendungen aller Art: von einfachen Webseiten über Online Banking, E-Mail, multimediale Unterhaltung bis hin zu intelligenten vernetzten Häusern und Städten. Seine Ursprünge liegen allerdings in einem einfachen Netzwerk zur Übermittlung statischer Inhalte auf der Basis von Hypertexten. Diese Ursprünge lassen sich noch immer im verwendeten Kommunikationsprotokoll HTTP identifizieren. In dieser Arbeit untersuchen wir die Sicherheitsanforderungen moderner Web-Anwendungen und zeigen, dass HTTP diese Anforderungen nicht erfüllen kann. Zu diesen Anforderungen gehören die Authentifikation von Benutzern und Anwendungen, die Integrität und Vertraulichkeit von Nachrichten, Kontrollflussintegrität und die gegenseitige Autorisierung von Anwendungen. Wir untersuchen die Web-Protokolle auf den unteren Netzwerk-Schichten und zeigen, dass auch sie nicht die Sicherheitsanforderungen erfüllen können. Unsere Analyse zeigt, dass das grundlegende Problem in der Verbindungslosigkeit von HTTP zu finden ist. Allerdings hat die Geschichte gezeigt, dass ein Neustart mit einem verbesserten Protokoll keine Option für ein gewachsenes System wie das World Wide Web ist. Aus diesem Grund beschäftigt sich diese Arbeit mit unseren Beiträgen zu sicherer Web-Kommunikation auf der Basis des existierenden verbindungslosen HTTP. Wir beginnen mit der Beschreibung von Session Fixation-Angriffen, die bereits vor der eigentlichen Anmeldung des Benutzers an der Web-Anwendung beginnen und im Erfolgsfall die temporäre Übernahme des Benutzerkontos erlauben. Wir präsentieren drei Gegenmaßnahmen, die je nach Eingriffsmöglichkeiten in die Web-Anwendung umgesetzt werden können. Als nächstes gehen wir auf das Problem ein, dass Zugangsdaten im WWW sowohl zwischen den Teilnehmern zu Authentifikationszwecken kommuniziert werden als auch für jeden, der Kenntnis dieser Daten erlangt, wiederverwendbar sind. Unsere Ansätze binden das Benutzerpasswort an ein im Browser gespeichertes Authentifikationsmerkmal und das sog. Session-Cookie an ein Geheimnis, das nur dem Benutzer und der Web-Anwendung bekannt ist. Auf diese Weise kann ein Angreifer weder ein gestohlenes Passwort noch ein Session-Cookie allein zum Zugriff auf das Benutzerkonto verwenden. Darauffolgend beschreiben wir ein Authentifikationsprotokoll, das vollständig auf die Übermittlung geheimer Zugangsdaten verzichtet. Unser Ansatz implementiert eine vertrauenswürdige Benutzeroberfläche und wirkt so gegen die Manipulation derselben in herkömmlichen Browsern. Während die bisherigen Ansätze die Sicherheit jeglicher Web-Kommunikation erhöhen, widmen wir uns der Frage, inwiefern ein intelligenter Browser den Benutzer - wenn nötig - vor Angriffen bewahren kann und - wenn möglich - eine ungehinderte Kommunikation ermöglichen kann. Damit trägt unser Ansatz zur Akzeptanz von Sicherheitslösungen bei, die ansonsten regelmäßig als lästige Einschränkungen empfunden werden. Schließlich legen wir den Fokus auf die Kontrollflussintegrität von Web-Anwendungen. Bösartige Benutzer können den Zustand von Anwendungen durch speziell präparierte Folgen von Anfragen in ihrem Sinne manipulieren. Unsere Ansätze filtern Benutzeranfragen, die von der Anwendung nicht erwartet wurden, und lassen nur solche Anfragen passieren, die von der Anwendung ordnungsgemäß verarbeitet werden können

Analysis of attacks on content security policies

Cross-site scripting attacks are a major threat to web applications. Such attacks are used to inject undesirable content into web pages. The Content Security Policy is an approach to mitigate content injection and secure websites. The security mechanism is added to the HTTP header and prohibits the execution of inline scripts, whitelists resources and bans dangerous JavaScript functions. CSP is a client side protection and is enforced by the browser. The real-world adoption of the Content Security Policy is investigated due to the promising protection of CSP against cross-site scripting, having an adoption rate of 2.5% for the one million most popular sites in 2018. Unfortunately, the effort to make websites CSP compatible is high and results in a trade-off between security and functionality. Additionally, the security of CSP against content injection cannot keep its promises. In literature 94.72% of all investigated real-world policies are bypassed due to unsafe endpoints in the whitelist and other vulnerabilities. Finally, these numbers require changes in the use and concept of CSP.Cross-Site-Scripting Attacken sind eine große Bedrohung für Webapplikationen. Solche Angriffe werden genutzt, um unerwünschte Inhalte in Webseiten einzuschleusen. Die Content Security Policy ist ein Ansatz um die Auswirkung von Content Injection abzuschwächen und Website sicherer zu machen. Der Sicherheitsmechanismus wird dem HTTP Header hinzugefügt und blockiert die Ausführung von Inlineskripten, fügt Ressourcen einer Whitelist hinzu und verbietet gefährliche JavaScript Funktionen. CSP ist ein Schutz auf Seite des Clients und wird vom Browser ausgeführt. Die Adaptionsrate der Content Security Policy wird anhand echter Zahlen untersucht, da der Schutz von CSP gegenüber Cross-Site-Scripting als vielversprechend gilt und bereits von 2.5% von den ein Million meistbesuchtesten Websites in 2018 implementiert ist. Leider führt der hohe Aufwand eine Website CSP kompatibel zu machen zu einem Kompromiss zwischen Sicherheit und Funktionalität. Zusätzlich kann das Sicherheitsversprechen, das CSP als Schutz gegen Content Injection bietet, nicht eingehalten werden. In der Fachliteratur werden 94.72% aller untersuchten Policies durch unsichere Endpunkte in der Whitelist und andere Lücken ausgehebelt. Schlussendlich fordern solche Zahlen Veränderungen in der Anwendung und im Konzept von CSP

Does the online card payment system unwittingly facilitate fraud?

PhD ThesisThe research work in this PhD thesis presents an extensive investigation into the security settings of Card Not Present (CNP) financial transactions. These are the transactions which include payments performed with a card over the Internet on the websites, and over the phone. Our detailed analysis on hundreds of websites and on multiple CNP payment protocols justifies that the current security architecture of CNP payment system is not adequate enough to protect itself from fraud. Unintentionally, the payment system itself will allow an adversary to learn and exploit almost all of the security features put in place to protect the CNP payment system from fraud. With insecure modes of accepting payments, the online payment system paves the way for cybercriminals to abuse even the latest designed payment protocols like 3D Secure 2.0. We follow a structured analysis methodology which identifies vulnerabilities in the CNP payment protocols and demonstrates the impact of these vulnerabilities on the overall payment system. The analysis methodology comprises of UML diagrams and reference tables which describe the CNP payment protocol sequences, software tools which implements the protocol and practical demonstrations of the research results. Detailed referencing of the online payment specifications provides a documented link between the exploitable vulnerabilities observed in real implementations and the source of the vulnerability in the payment specifications. We use practical demonstrations to show that these vulnerabilities can be exploited in the real-world with ease. This presents a stronger impact message when presenting our research results to a nontechnical audience. This has helped to raise awareness of security issues relating to payment cards, with our work appearing in the media, radio and T