As a developer, I want the Referrer-Policy in the response header from the tasker to be strict-origin-when-cross-origin #392
Comments
|
I'd like to piggy back on this ticket for two more changes. We want to add Please handle all three of these changes in this ticket... whoever ends up addressing it. Hank |
|
We're going to get more information on Hank |
|
The code to change for all HTTP request headers is this in ResourceHandler resourceHandler = new ResourceHandler()
{
@Override
public boolean handle( Request request,
Response response,
Callback callback )
throws Exception
{
response.getHeaders()
.add( "X-Frame-Options", "DENY" );
response.getHeaders()
.add( "strict-transport-security", "max-age=31536000; includeSubDomains; preload;" );
return super.handle( request, response, callback );
}
};Adding The Hank |
|
Finally able to get Eclipse to work, it appears that simply calling Bottom line, pending a value for //Static handler for index.html. This also impacts the dynamic resources
//by being chained in setHandler, below.
ResourceHandler resourceHandler = new ResourceHandler()
{
@Override
public boolean handle( Request request,
Response response,
Callback callback )
throws Exception
{
response.getHeaders()
.add( "X-Frame-Options", "DENY" );
response.getHeaders()
.add( "strict-transport-security", "max-age=31536000; includeSubDomains; preload;" );
response.getHeaders()
.add( "Content-Security-Policy", "TBD");
response.getHeaders()
.add( "Referrer-Policy", "strict-origin-when-cross-origin" );
response.getHeaders()
.remove( "Server" );
return super.handle( request, response, callback );
}
};As James said in the meeting, handling this through configuration would be preferred, but I'm not sure we have time to work that out right now. The above would require testing in -dev and -ti, obviously, before being sure it will work. Hank |
|
I'm giving this one a shot. For testing purposes, I'm going to use Hank |
|
OpenJDK and unzip needed updating. I removed the versions for the purposes of this ticket after my first attempt to update (using Hank |
|
Here are the headers currently returned when calling a I'm going to make the change to the tasker, deploy, and see what happens, Hank |
|
The attempt to remove Need to step away and then have a meeting with Jeff. I'll try to figure out what to do about the Hank |
|
As expected, if I add an empty Hank |
|
Found this: https://stackoverflow.com/questions/15652902/remove-the-http-server-header-in-jetty-9 Code snippet: HttpConfiguration httpConfig = new HttpConfiguration();
httpConfig.setSendServerVersion( false );
HttpConnectionFactory httpFactory = new HttpConnectionFactory( httpConfig );
ServerConnector httpConnector = new ServerConnector( server,httpFactory );
server.setConnectors( new Connector[] { httpConnector } );I need to figure out where the call to Hank |
|
I added the call to HttpConfiguration httpConfig = new HttpConfiguration();
// Remover Server from the response headers.
httpConfig.setSendServerVersion( false );The header is now: Last thing to figure out is what to set the Hank |
|
Here is a Python code snippet Arvin provided: add_header Content-Security-Policy "
default-src 'self' https: data: blob:;
script-src 'self' 'unsafe-inline' 'unsafe-eval' https: data: blob:;
style-src 'self' 'unsafe-inline' https: data: blob:;
img-src 'self' data: https:;
font-src 'self' data:;
connect-src 'self' https:;
object-src 'none';
" always;I'm going to use that in the tasker, Hank |
|
Here is the header now: I'm going to check various aspects of the COWRES to make sure everything still works, Hank |
|
Everything looks good. I was able to post a smoke test, check its status, check stdout, list and download output, visit the broker, and see the expected number of connections and queues. Only the tasker responses should be affected, but I figured I would look at nearly everything. Bottom line, I think we are good here. I'm going to create a pull request and get this code into master. Here are all of the changes to //Static handler for index.html. This also impacts the dynamic resources
//by being chained in setHandler, below.
ResourceHandler resourceHandler = new ResourceHandler()
{
@Override
public boolean handle( Request request,
Response response,
Callback callback )
throws Exception
{
response.getHeaders()
.add( "X-Frame-Options", "DENY" );
response.getHeaders()
.add( "strict-transport-security", "max-age=31536000; includeSubDomains; preload;" );
response.getHeaders()
.add( "Content-Security-Policy", "default-src 'self' https: data: blob:;"
+ " script-src 'self' 'unsafe-inline' 'unsafe-eval' https: data: blob:;"
+ " style-src 'self' 'unsafe-inline' https: data: blob:;"
+ " img-src 'self' data: https:;"
+ " font-src 'self' data:;"
+ " connect-src 'self' https:;"
+ " object-src 'none';");
response.getHeaders()
.add( "Referrer-Policy", "strict-origin-when-cross-origin" );
return super.handle( request, response, callback );
}
};
... SNIP ...
HttpConfiguration httpConfig = new HttpConfiguration();
// Remover Server from the response headers.
httpConfig.setSendServerVersion( false );Thanks, Hank |
Fixing vulnerabilities; refs GitHub #392
|
Changes are in. Hopefully, I did that right. Closing and marking for UAT, Hank |
|
I'm reopening this issue. To test this change, I need it in staging. To get it in staging, I need to update the Dockerfiles with the new OpenJDK and unzip. I tried to make that change earlier and failed. Let me try it again. Once I have the Dockerfiles updated, I'll do another PR/merge. This will be a minor dependency updates solely to get it working, which is why I don't want to create a full blown dependency update ticket. If anyone has any concerns about that approach, let me konw. Thanks, Hank |
|
I've got the correct versions now in the Images appear to build, but I can't deploy to development at the moment due to a long running evaluation. It should be safe enough, however, to push the I'm going to prep and pull request and merge to master, Hank |
Updated Dockerfiles for openjdk and unzip; refs GitHub #392
|
The merge completed. I need to no force a deploy to staging so that I can double check if the header parameters look right through the proxy. Hank |
|
After some difficulties, I was able to get the COWRES deployed to staging and confirmed that the headers look fine when accessed via internal URL or proxy. Closing this ticket once again and marking ready for UAT. Hank |
|
Just deleted a partial comment. The scanner, when pointed at the staging proxy, complained about the script-src and style-src options of the content security policy for the WRES GUI. Though it did not complain about the COWRES, perhaps because this parameters don't apply since its not a web interface (???), I'm still going to remove the Thanks, Hank |
|
The change is in development and the -dev COWRES looks good. I'll create the branch and pull request now. Hank |
|
The pull request is still in process, but I deployed the tasker image to staging. What I thought was a fluke was actually real: modifying the So something in the display of the front-end API is getting screwed up by the change. I'll do a bit more research on Hank |
|
So our front-end API requires Is there any way to adjust the Still investigating, Hank |
|
Next attempt: manually specifying the number of columns and rows for the text area. Hank |
|
Nope. Adding Hank |
|
So this seems to work: I had to add the I need to step away. If no one sees any issues with that, I'll create the pull request and merge when I return. Thanks, Hank |
|
You could try in a couple of browsers and screen configurations, but I don't see this being an issue. It's not that important, anyway, as it's just the landing page for the backend. There may be some folks using this as a convenience, but it isn't the entry point for software, which is the main purpose of the backend. |
|
As an aside, you can keep a PR open indefinitely, pushing incrementally as normal - it's really just a marker of intent and you can start one when you start a new ticket/activity that encompasses many future pushes. |
|
Thanks, James, for that piece of information. I'll try to reopen the previous pull request, then, if that's a thing. If so, I'll push the I'll test the API in the two browsers to which I have access and confirm it looks okay in both. Testing the change in staging now, Hank |
|
When the cache is cleared, the text area looks fine and the COWRES works fine based on smoke tests. This was tested using staging. I'll leave it in staging so that the WRES GUI can post some scheduled evaluations as further confirmation that everything is okay. Adding the Hank |
|
The pull request picked up the change immediately and tests are running again. If all goes well, I'll merge, Hank |
Removed unsafe options from content security policy; refs Github #392
|
I think that marks the end of the work for COWRES, at least based on a scan using staging. In fact, the scanner didn't even pickup on the problem with the COWRES endpoint, so I only made the changes to Closing this out and then moving it to UAT, just a reminder to check and make sure all scheduled evaluations through the staging COWRES and any UAT during deployment all succeed. Thanks, Hank |
|
Evan: I ask that you perform the UAT for this one in staging. You should see the following changes if you
If you would like the exact value to expect in for the CSP, let me know. It basically covers everything an only uses Thanks, Hank |
|
I don't think this is blocking, but noticed that the screen we have for checking validity of declarations does shrink (The main page text area looks fine though)
|
|
Think this looks good otherwise: |
|
I forgot about that page. We should create another ticket for that fix, and it should just require a change to its HTML matching what I did for the front-end HTML. If you don't do this today, I'll do it tomorrow (unless my memory fails me). Hank |
|
Created the ticket for it |
EDIT: Also, we want to add Content-Security-Policy: none to the response header and remove Server: Jetty(12.0.16) from the header if possible.
ORIGINAL DESCRIPTION:
See VLab ticket 142394. It identified a medium-risk vulnerability that the tasker was not returning a
Referror-Policyin the response header. We need to add that to the header, and, based on review of the recommended fix in the document attached to that VLab ticket, ensure the value is set tostrict-origin-when-cross-origin.Thanks,
Hank
The text was updated successfully, but these errors were encountered: