Web Application Security Blog

This FAQ (in the form of a living document, being updated once in a while) covers some questions I've been asked after talking about Java deserialization vulnerabilities at conferences during the last months.

After the major rise in awareness in 2015, the well-known topic of remote code execution (RCE) during deserialization of untrusted (Java) data has received many new aspects and facets, as new research was performed. Consequently this deepened research led to new findings (gadgets, endpoints, protection attempts, bypass techniques, etc.).

As this fast-paced development in the last months might have left some peoples' questions unanswered, I try to shed some more light on this by providing some sort of FAQ - mainly focussed at developers.

This blog post covers my talks about Security DevOps in general and a maturity model to define steps in reaching more automation of certain security checks. The main idea is to define a roadmap of how projects can reach a level of automation (preferably with OpenSource tools) to check for certain security aspects during the CI (Continuous Integration) build chain.

This first part covers my talk at the OWASP AppSecEU 2015 conference held last week in Amsterdam. I had the chance to present best practices of how OpenSource tools (used in the DevOps and security communities) can be properly chained together to form a framework that can - as part of an agile software development CI chain - perform automated checking of certain security aspects. This does not remove the requirement for manual pentests, but tries to automate early security feedback to developers. My talk introduced a SecDevOps Maturity Model (SDOMM) of different stages of automated security testing and presented concrete examples of how to achieve each stage with open source security tools.

This is a short writeup about my SOP (Same-Origin Policy) bypass with SVG images I've found in Chrome, so that other security researchers can benefit from it. I reported the Chrome vulnerability to Google's security team in 2014 and they did a very good job at fixing it in Chrome's M36 release. At around Q4 2014 the bug ticket (#380885) was opened to public, so that I'm allowed to publish this writeup (as soon as I find time to write)...

Basically all kinds of SOP bypasses are rather critical, since they completely lift one of the important protection mechanisms in browsers (the SOP) against malicious websites doing nasty stuff while we're surfing. But this (rather hidden and not so easy to find) one only allowed the attacker to successfully exfiltrate images from other sites - not the site's textual content. Therefore it was only of medium severity, though depending on the application even this could be abused heavily, as I did in a PoC to steal victim's images/photos as an example.

In this article I present some thoughts about generic detection of XML eXternal Entity (XXE) vulnerabilities during manual pentests supplemented with some level of automated tests. The ideas in this blog post (derived from experiences of several typical and untypical XXE detections during blackbox pentests) can easily be transformed into a generic approach to fit into web vulnerability scanners and their extensions.

This is done by demonstrating an example of where service endpoints that are used in a non-XML fashion can eventually be accessed with XML as input format too, opening the attack surface for XXE attacks.

Since modern authentication frameworks (like JAAS in combination with current JavaEE application servers) try to mitigate the Session Fixation attack scenario out-of-the-box, one might assume that this attack vector is mostly relevant for custom developed login schemes. Unfortunately during my pentests of applications, which properly change the session identifier upon login, I still find Session Fixation attack scenarios. These often arise from the misconception that the login process is the only workflow of an application that adds (from an attacker's point of view) significant value to a shared anonymous session.

In this article I showcase typical scenarios regularly found during pentests where unauthenticated Session Fixation attacks occur and how they can be exploited by targeting application workflows aside from the login process.

The relatively new HTML5 WebSocket technique to enable full-duplex communication channels between browsers and servers is retrieving more and more attention from developers as well as security analysts. Using WebSockets developers can exchange text and binary messages pushed from the server to the browser as well as vice versa.

During some experiments and pentests with WebSocket backed applications in the last few months I came across a scenario where developers might use WebSockets in a way to open up their applications to a vulnerability I call Cross-Site WebSocket Hijacking (CSWSH), which I will present in this short blog post.

During penetration tests CSRF (Cross-Site Request Forgery) vulnerabilities are typical findings, although proper protection concepts with tokens are well known. But even when protected with tokens these concepts often fail as soon as XSS (Cross-Site Scripting) vulnerabilities exist in the same domain/port combination, since the script executing via XSS in the victim's browser is capable of reading the CSRF protection token and thus can execute CSRF attacks.

In this short blog post I will present some tips on protecting against CSRF attacks even when XSS vulnerabilities exist in other applications running same-origin with the targeted application.

In this blog post I analyze methods of user tracking which are performed by popular social network websites such as Facebook, Twitter, Xing, and recently Google+.

Each of these social networks have buttons (called Like, Tweet, Visitors, and +1 buttons) which are installed on numerous websites. I try to put some light on the actions performed by those buttons and how they track users around the web, even when they don't click those buttons.