OAuth 2.0 is a widely adopted authorization framework enabling secure, delegated access to resources on behalf of a user. While the protocol is robust when implemented correctly, real-world deployments often exhibit vulnerabilities due to misconfigurations, incomplete mitigations, or misunderstandings of its intricacies. (Semi-)automated testing is therefore essential to identify and address these security flaws. Among available tools, OAuch offers the most comprehensive benchmark for assessing OAuth IdP implementations by identifying potential threats based on the OAuth threat model and related standards. However, OAuch has notable limitations, including an incomplete threat model, ambiguous threat classifications, and a lack of support for multi-vulnerability attack scenarios. This paper presents enhancements to OAuch that improve the tool's usability, including enriched metadata, the introduction of attack scenarios for multi-threat analyses, and a likelihood assessment to prioritize mitigation efforts.

The OAuth 2.0 protocol is a widely adopted standard for online authorization. Given its widespread use, it has received substantial attention from the research community towards assessing its security. Earlier research has primarily focused on the security of the protocol itself, or the implementation quality of popular online OAuth-based services. However, despite the numerous flaws that have been discovered in public OAuth services, there has only been limited research that directly studied the underlying OAuth middleware. In this study, we address this gap by conducting a systematic evaluation of eight popular open-source identity providers. In our analysis, we identified ten important types of security flaws among these providers. We further explore the root causes of these problems and discuss why certain parts of the OAuth standard are poorly implemented. Our findings reveal an alarming reality: we uncovered security weaknesses and vulnerabilities in seven out of eight examined middle-wares, with an average of three security issues per provider. While these weaknesses have been addressed, resulting in two CVEs, our results emphasize the importance of continued research efforts to improve the security of OAuth implementations.

Software developers use web application vulnerability scanners to automatically identify security weaknesses in their web applications. The scanners inspect source code or analyze the running application, and look for specific vulnerability types. While it can be expected that a scanner will not discover every vulnerability, no information is available on the expected efficacy of currently available vulnerability scanners for a given vulnerability type. We present an analysis of 24 web vulnerability scanners and determine their effectiveness on 11 vulnerability types. Our study offers insights into the trade-offs when selecting a specific type of scanner. We show that for some vulnerability types, most vulnerability scanners perform poorly.

Trusted execution environments (TEEs) gained significant traction in recent years. They have become the foundation of Confidential Computing in cloud services, where certain security properties can be guaranteed on untrusted servers. Despite this adoption, writing code to target TEEs remains challenging. The SDKs for popular TEE implementations, like Intel SGX, are aimed at low-level languages like C/C++. Previous research has introduced support for developing and running programs written in managed programming languages in a TEE environment. However, in these works, the language runtime is embedded into the TEE, increasing the Trusted Computing Base (TCB) and thus inherently reducing trust into the TEE itself. To solve this problem, we propose a new approach to integrate the development of TEE code in managed languages, without the need to embed the full language runtime inside the TEE. It allows developers to write the TEE logic as part of their program in a managed programming language. Using the existing compiler infrastructure, the TEE logic is extracted and passed to a source-to-source compiler that transforms it into a low-level unmanaged equivalent. The resulting low-level code is then compiled by the compiler toolchain targeting the TEE platform. This paper reports on the design and the first results of our work-in-progress implementation of SecSharp, a tool to enable TEE development in C#.

The OAuth 2.0 protocol is a popular and widely adopted authorization protocol. It has been proven secure in a comprehensive formal security analysis, yet new vulnerabilities continue to appear in popular OAuth implementations.

Code Pointer Masking (CPM) is a novel countermeasure against code injection attacks on native code. By enforcing the correct semantics of code pointers, CPM thwarts attacks that modify code pointers to divert the application’s control flow. It does not rely on secret values such as stack canaries and protects against attacks that are not addressed by state-of-the-art countermeasures of similar performance. This article reports on two prototype implementations on very distinct processor architectures, showing that the idea behind CPM is portable. The evaluation also shows that the overhead of using our countermeasure is very small and the security benefits are substantial.

Buffer overflows are still a significant problem in programs written in C and C++. In this paper we present a bounds checker, called PAriCheck, that inserts dynamic runtime checks to ensure that attackers are not able to abuse buffer overflow vulnerabilities. The main approach is based on checking pointer arithmetic rather than pointer dereferences when performing bounds checks. The checks are performed by assigning a unique label to each object and ensuring that the label is associated with each memory location that the object inhabits. Whenever pointer arithmetic occurs, the label of the base location is compared to the label of the resulting arithmetic. If the labels differ, an out-of-bounds calculation has occurred. Benchmarks show that PAriCheck has a very low performance overhead compared to similar bounds checkers. This paper demonstrates that using bounds checkers for programs or parts of programs running on high-security production systems is a realistic possibility.

Code injections attacks are one of the most powerful and important classes of attacks on software. In such attacks, the attacker sends malicious input to a software application, where it is stored in memory. The malicious input is chosen in such a way that its representation in memory is also a valid representation of a machine code program that performs actions chosen by the attacker. The attacker then triggers a bug in the application to divert the control flow to this injected machine code. A typical action of the injected code is to launch a command interpreter shell, and hence the malicious input is often called shellcode.