Just-in-Time Detection of Protection-Impacting Changes on Wordpress and Mediawiki

Les mecanismes de controle d’acces bases sur les roles accordes et les privileges predefinis limitent l’acces des utilisateurs aux ressources sensibles a la securite dans un systeme logiciel multi-utilisateurs. Des modifications non intentionnelles des privileges proteges peuvent survenir lors de l’evolution d’un systeme, ce qui peut entrainer des vulnerabilites de securite et par la suite menacer les donnees confidentielles des utilisateurs et causer d’autres graves problemes. Dans ce memoire, nous avons utilise la technique “Pattern Traversal Flow Analysis” pour identifier les differences de protection introduite dans les systemes WordPress et MediaWiki. Nous avons analyse l’evolution des privileges proteges dans 211 et 193 versions respectivement de WordPress et Mediawiki, et nous avons constate qu’environ 60% des commits affectent les privileges proteges dans les deux projets etudies. Nous nous referons au commits causant un changement protege comme commits (PIC). Pour aider les developpeurs a identifier les commits PIC en temps reel, c’est a dire des leur soumission dans le repertoire de code, nous extrayons une serie de metriques a partir des logs de commits et du code source, ensuite, nous construisons des modeles statistiques. L’evaluation de ces modeles a revele qu’ils pouvaient atteindre une precision allant jusqu’a 73,8 % et un rappel de 98,8 % dans WordPress, et pour MediaWiki, une precision de 77,2 % et un rappel allant jusqu’a 97,8 %. Parmi les metriques examines, changement de lignes de code, correction de bogues, experience des auteurs, et complexite du code entre deux versions sont les facteurs predictifs les plus importants de ces modeles. Nous avons effectue une analyse qualitative des faux positifs et des faux negatifs et avons observe que le detecteur des commits PIC doit ignorer les commits de documentation uniquement et les modifications de code non accompagnees de commentaires. Les entreprises de developpement logiciel peuvent utiliser notre approche et les modeles proposes dans ce memoire, pour identifier les modifications non intentionnelles des privileges proteges des leur apparition, afin d’empecher l’introduction de vulnerabilites dans leurs systemes. ----------ABSTRACT: Access control mechanisms based on roles and privileges restrict the access of users to security sensitive resources in a multi-user software system. Unintentional privilege protection changes may occur during the evolution of a system, which may introduce security vulnerabilities, threatening user’s confidential data, and causing other severe problems. In this thesis, we use the Pattern Traversal Flow Analysis technique to identify definite protection differences in WordPress and MediaWiki systems. We analyse the evolution of privilege protections across 211 and 193 releases from respectively WordPress and Mediawiki, and observe that around 60% of commits affect privileges protections in both projects. We refer to these commits as protection-impacting change (PIC) commits. To help developers identify PIC commits justin-time, i.e., as soon as they are introduced in the code base, we extract a series of metrics from commit logs and source code, and build statistical models. The evaluation of these models revealed that they can achieve a precision up to 73.8% and a recall up to 98.8% in WordPress and for MediaWiki, a precision up to 77.2% and recall up to 97.8%. Among the metrics examined, commit churn, bug fixing, author experiences and code complexity between two releases are the most important predictors in the models. We performed a qualitative analysis of false positives and false negatives and observe that PIC commits detectors should ignore documentation-only commits and process code changes without the comments. Software organizations can use our proposed approach and models, to identify unintentional privilege protection changes as soon as they are introduced, in order to prevent the introduction of vulnerabilities in their systems.

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.