Online cyber security "issues": Making custom JBrowse2 publicly available safely over the internet?...

[mickey-spongebob]

Hi all,

Sorry if this is a dumb question. I've successfully managed to setup a local genome browser for our genome of interest. I would now like to make the genome browser available online for anyone to access it. Naturally, our IT department is concerned about cyber security etc. They performed a 'vulnerability scan' and detected a number of things, which I've numbered/listed below. The question is, is it possible to fix this issue and how would I go about it safely without ruining the utility of the app? I realise this has very little to do specifically with JBrowse2, but would like to know if there's a way to 'fix' these issues :-)

1. Insecure HTTP Methods Allowed
   Issue description:

By calling the OPTIONS method, it is possible to determine which HTTP methods are allowed on each directory.

The following HTTP methods are considered insecure:

PUT, DELETE, CONNECT, TRACE, HEAD

Many frameworks and languages treat 'HEAD' as a 'GET' request, albeit one without any body in the response. If a security constraint was set on 'GET' requests such that only 'authenticatedUsers' could access GET requests for a particular servlet or resource, it would be bypassed for the 'HEAD' version. This allowed unauthorized blind submission of any privileged GET request.

Issue remediation:

Disable HTTP Methods PUT, DELETE, CONNECT, TRACE, HEAD

2. Clickjacking vulnerability
   Issue description

If a page fails to set an appropriate X-Frame-Options or Content-Security-Policy HTTP header, it might be possible for a page controlled by an attacker to load it within an iframe. This may enable a clickjacking attack, in which the attacker's page overlays the target application's interface with a different interface provided by the attacker. By inducing victim users to perform actions such as mouse clicks and keystrokes, the attacker can cause them to unwittingly carry out actions within the application that is being targeted. This technique allows the attacker to circumvent defenses against cross-site request forgery, and may result in unauthorized actions.

Note that some applications attempt to prevent these attacks from within the HTML page itself, using "framebusting" code. However, this type of defense is normally ineffective and can usually be circumvented by a skilled attacker.

You should determine whether any functions accessible within frameable pages can be used by application users to perform any sensitive actions within the application.

Issue remediation

To effectively prevent framing attacks, the application should return a response header with the name X-Frame-Options and the value DENY to prevent framing altogether, or the value SAMEORIGIN to allow framing only by pages on the same origin as the response itself. Note that the SAMEORIGIN header can be partially bypassed if the application itself can be made to frame untrusted websites.

I'm really sorry for the terribly long question.

I'm super grateful if anyone has inputs regarding sharing their custom genome browser app online :-)

Best wishes,
kevin

[cmdcolin]

to be clear, jbrowse 2 itself does not have any server side code, it is purely "client side" (it runs all it's code in the users web browser). all these concerns listed above are server side. what server are you using to run jbrowse 2?

[mickey-spongebob]

Hi Colin, Thank you so much for the reply. I’m using nginx server. Best, kevin

…

On 8. Nov 2022, at 17:16, Colin Diesh ***@***.***> wrote: to be clear, jbrowse 2 itself does not have any server side code, it is purely "client side" (it runs all it's code in the users web browser). all these concerns listed above are server side. what server are you using to run jbrowse 2? — Reply to this email directly, view it on GitHub <#3314 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMEBXCW3NPVSG7DIIVMSDRTWHJ4EHANCNFSM6AAAAAAR2FAECA>. You are receiving this because you authored the thread.

[rbuels]

Solving this just comes down to a little bit of nginx configuration. If it were me, for issue 1 I would respond to them that it is "not exploitable", because there is no application backend code, it is just a web server serving files.

For issue 2, I would add in the nginx configuration something like:

add_header X-Frame-Options "SAMEORIGIN";

and that would take care of it.