Security stories

Hanno Böck
Twitter: @hanno

Story 1:

Do you use Javascript?

Do you include Javascript from third-party hosts?

How many Javascript domains?

Spiegel Online24



<script src='' async>

Who owns

I do.

It was unregistered in February.

Used by several large italian newspapers, soccer clubs and sports news sites.

Domain/Subdomain takeover

  • Code included from abandoned [subdomain].[servicedomain] (e.g. Azure, GithHb, AWS, ...).
  • Code included from unregistered domain.
  • Forgotten CNAME record to [subdomain].[servicedomain].
  • Forgotten NS record to DNS service.
  • Forgotten A record (difficult to exploit).

What to do?

  • Know your DNS records.
  • Know your Javascript includes.

Story 2:

The Password in the Screenshot

I got an email with a screenshot of my webpage.


How could that happen?


  new PDO("mysql:dbname=test;host=db.invalid",
          "dbuser", "verysecretpassword");

A combination of issues

  • MySQL server was down.
  • PHP shows error messages in webpage (this is the default).
  • PDO (supposed to be the safer option) uses exceptions, code didn't catch exceptions.
  • PHP exceptions - unlike other PHP errors - cause output of stack trace.
  • Stack trace includes function parameters.

I'm not alone

Is this PHP's fault?

Argument 1: This is the default

You have to do something extra (catch exception, disable error messages) to prevent it.

The most simple PDO code will have this problem.

Argument 2: This is unexpected

  • This does not happen with "normal" PHP errors.
  • Parameter values in stack traces are uncommon.

Argument 3: The documentation

It's only a "Note". I wouldn't read "this can leak your passwords" into it.

I never got as many hate messages as when I wrote about this (on

Part 3:

The private key that wasn't private

Web to localhost

Scenario: A web application wants to communicate with a locally installed software.

Solution: Open HTTP server on localhost, web server can access localhost (e.g. with CORS, JSONP).

But there's HTTPS...

If an HTTPS webpage accesses an HTTP origin this can cause browser warnings.

Some people had a great idea

  • Let a hostname point to via DNS.
  • Get a valid certificate for that hostname.
  • Let the application use HTTPS with a valid certificate.

Maybe that idea wasn't so great after all

If the local software can run an HTTPS server this means the private key must be part of the software.

Baseline Requirements

The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise

That means ...

... if you find such a software you can break it within 24 hours if you report it to the right people.

This has happened before to ...

beA, Blizzard, EA Origin, Torrents Time, Mega, ...

How to do it properly?

It's debatable whether a split web/local application is a good idea in the first place.

Installing a local root certificate works.

But make sure you make it a *custom* local certificate (beA used a shared one).

Newer W3C standard says HTTP can be considered secure if it's localhost.

Part 4:

My personal bug bounty program

I saw that some people created bug bounty programs on Hacker One for their personal projects and webpages.

So I created one for my projects, because why not?

No payouts, private / invite only for now.

Several high quality submissions, notably 2 XSS and 2 SQL injections in Serendipity (blog software).

Effectively Serendipity got a free security audit.


You get bogus submissions.

I now had two people warning me about the dangers of exposing my SSH public key.

Part 5:

Signing with Images