Friday Links 0.0.12 - JSON Patch, LibLog, and Stealing Developers Databases

This is based on an email I send my .NET team at work

Happy early Friday,

Today is another hodgepodge of unrelated links I found interesting.

JsonPatch

https://github.com/KevinDockx/JsonPatch

Apparently there is a specification for describing mutations to data in a JSON payload. I’ve never heard of this before, but it’s intriguing.

The idea is that for APIs with a PATCH method, you might send a sequence of operations to apply to the resource, rather than a new copy or a copy with only the modified properties.

Maybe this feels more semantically correct for a PATCH instead of a PUT, or perhaps its more efficient for certain data stores or large documents.

Anyway, here’s an example HTTP request from the RFC:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
PATCH /my/data HTTP/1.1
Host: example.org
Content-Length: 326
Content-Type: application/json-patch+json
If-Match: "abc123"

[
 { "op": "test", "path": "/a/b/c", "value": "foo" },
 { "op": "remove", "path": "/a/b/c" },
 { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
 { "op": "replace", "path": "/a/b/c", "value": 42 },
 { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
 { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
]

JsonPatch implements the pattern in C# so that you can log the modifications on the client, send the patch JSON over the wire, and replay them against a server-side object.

How to steal any developer’s local database

http://bouk.co/blog/hacking-developers/

The title is a little over the top, but the vulnerability is fascinating because it goes to show just how hard security really is.

The premise is that some databases like Redis, Memcached, or ElasticSearch use a text based line protocol for control. For example, in Redis, you open a connection and send SET key value to set a value in the database. Any other text, like HTTP headers for example, are ignored if they don’t match existing commands.

All you have to do then is trick a website into sending an AJAX request to well known ports running on localhost. You can also use a form element to submit data, though you won’t be able to get back the results.

To retrieve the results, you have to use AJAX and trick the browser into violating its same origin policy. Normally, you can’t make AJAX requests to servers on a different domain than the originating page. But the author describes a trick called DNS Rebinding to get around it.

DNS rebinding works by first having your domain, say evilhacker.com point to your main server. But you’ve configured DNS to have a really short TTL on the name to IP address mapping. So after you serve the main page, you change the DNS for evilhacker.com to point to 127.0.0.1. You have some javascript wait 60 seconds or something for the DNS to propagate, and then start issuing AJAX requests to evilhacker.com. But now that evilhacker.com is really localhost, the requests are sent to the database servers running on the local machine.

He’s got a demo page that can read the versions of those databases if they’re running on your local machine. Open the chrome dev tools and see how it works!

LibLog

https://github.com/damianh/LibLog

If you’re a library author, you may want to use internal logging and provide it to your users. But your users may already have a preferred logging framework, and may resent you taking a direct dependency on Serilog when they are using Nlog or whatever. Now they have to configure both!

You might then think to provide some ICustomLogger interface, and force your users to implement it with their logging framework. But that’s more boilerplate and work for them. Ideally, you want your library to just drop in.

So maybe you ship MyLibrary.Nlog and MyLibrary.Serilog plugins. But the user still may have to wire them up, or they might be using a different version causing NuGet dependency conflicts.

LibLog solves for these problems by using Reflection. It’s implemented as a single file you can drop into your library (so to avoid another NuGet dependency), and automatically discovers what logging framework is in use, and implements its internal interface using an adapter for that framework.

Is it slower? Probably only a little bit. Once it resolves a logging framework, it dynamically creates a delegate to actually execute the logger. The reflection process (which is probably the slowest part) only runs during initialization. The real runtime cost is just the overhead of virtual method calls and delegate invocation which is fine for the vast majority of applications.

I think its excellent idea, and I appreciate that it helps library authors avoid foisting dependencies on their users.

Comments