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.
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
or perhaps its more efficient for certain data stores or large documents.
Anyway, here’s an example HTTP request from the RFC:
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.
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
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
the DNS to propagate, and then start issuing AJAX requests to
evilhacker.com. But now that
evilhacker.com is really
the requests are sent to the database servers running on the local
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!
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
So maybe you ship
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.