Bachelor- and Master Seminar

Dear All,
 

Great that you found the new semesters page :)
The next seminar(s) take place on 28.4. at 14:00.

Session A 14:00-15:00:
Muhammad Bilal Latif - John Schmitt

https://cispa-de.zoom.us/j/96786205841?pwd=M3FOQ3dSczRabDNLb3F1czVXVUpvdz09

Meeting-ID: 967 8620 5841
Kenncode: BT!u5=

Session B 14:00-15:00:
Peter Stolz - Marc Katz

https://cispa-de.zoom.us/j/99025989421?pwd=cWJIM29LYktsbStxTXlKUStZRi9MUT09

Meeting-ID: 990 2598 9421
Kenncode: 3mZyE$

Session A:

14:00-14:30 

Speaker: Muhammad Bilal Latif.
Type of talk: Master Intro.
Advisor: Dr. Ing. Cristian-Alexandru Staicu.
Title: Empirical Study of Full-Stack JavaScript Web Applications.
Abstract: Traditionally, most web applications were using Java or PHP on the server-side and JavaScript on the client-side. However, in recent years, we have seen a rise of interest in running JavaScript on the server-side as well, i.e., full-stack JavaScript web applications. The reason for this shift is multifold, e.g., uniform tools usage, easier skills transfer across the stack, etc. Recent work warns about the security practices in server-side JavaScript and in particular in its package manager, npm, supposedly the largest software ecosystem in the world.
However, judging the security of a given dependency in isolation is hard and it often leads to over-reporting security vulnerabilities. For example, let us consider the CVE-2019-1010266 vulnerability, which affects the method camelCase of the popular lodash package. In the associated bug report, it is speculated that an attacker can take advantage of the input to this method, without providing any empirical evidence, e.g., a GitHub project in which this is indeed possible. As a result of the issued CVE, all the clients of lodash were warned that they are at risk and that they should upgrade to the newest library version, independent of whether in their particular case, user input can reach the vulnerable method or even the package. To provide a more realistic view of the security of full-stack JavaScript web applications, one should consider the entire code of the application, i.e., client-side and server-side code together with third-party code.
The goal of this project is to perform an empirical study of open-source, full-stack JavaScript web applications. To this end, a testing infrastructure should be developed that allows both dynamic and static program analysis of realistic web applications. The infrastructure should be used to answer various research questions about (the security of) the analyzed web applications.

14:30-15:00

Speaker: John Schmitt
Type of talk: Bachelor Intro
Advisor: Sven Bugiel
Title: Implementing Certificate Transparency Into Android Open Source Project

Abstract: To verify the identity of a web server, a web client has to rely on the validity of the provided certificate. As a result, web clients blindly trust in the integrity of the certificate authority to properly issue certificates. But what happens if a certificate authority is compromised, goes rogue, or issues flawed certificates? In case of such a certificate misissuance, certificate transparency helps by providing a secure append-only log that documents every certificate issuance and thus enforces accountability for certificate authorities. Mobile devices are a major source of network traffic to web servers. Additionally, Android currently holds the biggest market share of mobile operating systems but does not present any solution to a certificate transparency implementation. Our goal is to provide a proof of concept for an implementation of certificate transparency in the Android Open Source Project and make use of its benefits to protect Android users from certificate misissuance and thus man-in-the-middle attacks.

15:00-15:30

No talk this week.

Session B:

14:00-14:30

Speaker: Peter Stolz
Type of talk: Bachelor Intro
Advisor: Ben Stock
Title: To hash or not to hash
Abstract:
Content Security Policy (CSP) is a great way to mitigate Cross-site scripting (XSS) if used correctly. CSP has the experimental directive "unsafe-hashes" to whitelist certain inline event handlers and style attributes.
Before more browsers than chromium add support for it we want to analyse how many event handlers can be abused to trigger XSS if an attacker reuses them on a malicious tag.
This allows us to determine if it is a useful feature or if it should be abandoned because it implies a false sense of security for the most part.
How would the results change if we add a none to each tag, so an attacker can't inject arbitrary tags.

14:30-15:00

15:00-15:30