Web Application Security Blog

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.