Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security aspects of using an HTTP Server #17

Open
rkwright opened this issue Nov 3, 2016 · 3 comments
Open

Security aspects of using an HTTP Server #17

rkwright opened this issue Nov 3, 2016 · 3 comments

Comments

@rkwright
Copy link
Member

rkwright commented Nov 3, 2016

In the past, there have been several discussions of the relative security of using an internal HTTP server in Readium-1. The point was made (originally by @ryanackley - Ryan Ackley) that using common tools like WireShark, one can intercept the stream and grab its contents. This can happen whether the original content was encrypted or not. This is because the stream can be intercepted after the content has been decrypted by the DRM engine.

Before we try to determine the seriousness of this and/or try to determine ways to block such actions, it would be good if someone on the team would verify this exploit is possible. I am pretty sure Ryan is correct, but in any case, we need a way to verify if any proposed blocking action actually works.

@HadrienGardeur
Copy link
Contributor

If the connection is to a local web server, how do you intercept the request using WireShark?

@HadrienGardeur
Copy link
Contributor

In order to limit the ability for another app to intercept what's going on, I'd like to suggest two things:

Random port or URI for the manifest

Instead of always using something like http://localhost:8080/manifest.json we could instead assign a random port number or calculate a hash for the manifest.

This could for example return: http://localhost:8204/cn389ncoiwuencr.json

Sign each request to a resource

We could also sign each request with a short-lived token to limit replay attacks (token is intercepted and used in another context).

A JWT (http://jwt.io) could work very well for that:

  • the payload contains the URI that we'd like to access and the expiration date for the token
  • the secret to sign the JWT is shared between server & client

The client would simply include this token as a bearer token in its HTTP headers: Authorization: Bearer <token>

Tricky part, is that I'm not entirely sure if we'll be able to intercept each and every request initiated from the webview to do that.

@llemeurfr
Copy link
Contributor

Alternative solution:
1/ use https in the MVP
2/ later (after a hackaton?), check if additional protection is needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants