The servlet filter in the demo I sent out earlier can be included at the
container level.
https://github.com/tkunicki-usgs/thredds-cors
Tom
On Apr 25, 2013, at 12:03 PM, Dennis Heimbigner <dmh@xxxxxxxxxxxxxxxx> wrote:
> I do not know, but it may be possible to
> implement at the Tomcat level using the
> same policy for all files.
> =Dennis Heimbigner
> Unidata
>
> tom cook wrote:
>> My understanding from one of the documents you sent was that CORS
>> works on a per-file basis, as compared to crossdomain.xml which is a
>> site wide thing.
>> On Thu, Apr 25, 2013 at 9:40 AM, Dennis Heimbigner <dmh@xxxxxxxxxxxxxxxx>
>> wrote:
>>> Speaking unofficially, I can imagine
>>> that Unidata could support CORS on an
>>> opt-in basis. That is, there would be
>>> a configuration option to turn it on,
>>> but it would be off by default. That way
>>> any malicious behavior would be on the head
>>> of the person who turned it on.
>>>
>>> I frankly would be happier if it was possible
>>> to enable this at the Apache/Tomcat level
>>> so that the thredds and other software providers
>>> would be completely out of the loop. If this is possible,
>>> can someone describe in detail who to do this for,
>>> say, Tomcat?
>>>
>>> =Dennis Heimbigner
>>> Unidata
>>>
>>>
>>> Gerry Creager - NOAA Affiliate wrote:
>>>> Jon, Roy,
>>>>
>>>> If there are no sensitive data on the server, it's a non-issue, or I at
>>>> least feel I could successfully make that argument. Where we'd run into
>>>> problems is in a case where there might be data residing on the system
>>>> that
>>>> ARE restricted. Even if the DAP server didn't access those, the
>>>> consideration for potential exploits has to be considered. Unless you can
>>>> demonstrate that the data are so well embargoed from the OpENDAP server
>>>> side that they could never escape that way.
>>>>
>>>> And, it's not always just the government worried about these things.
>>>> There's a "major university" I used to work for, and by the time I'd left,
>>>> I was answering questions about my TDS installations on a regular basis
>>>> because A) the administration had out-sourced the scanning systems, with
>>>> only reports coming into administration/management. Thus, the security
>>>> folks I'd dealt with were out of the loop and couldn't readily help
>>>> interpret the scans until things were already mired in "investigations";
>>>> B)
>>>> said scanning organization, external to the university, was engaged in
>>>> penetration testing and would flag any system they couldn't gain access to
>>>> as "infected". Yes. If the security was sufficient they couldn't actively
>>>> snoop, they claimed the machine was a problem and it had to be opened up
>>>> more.
>>>>
>>>> The degree of security theatre we're engaged in is sufficiently dense that
>>>> we do have to worry about even the silly little unlikely things. 10 years
>>>> ago, CORS would have looked like a great idea, and if it'd been
>>>> implemented
>>>> then, it probably would have been grandfathered in with things like SOAP
>>>> and REST-ful services as the norm.
>>>>
>>>> However, to put a point on things, while javaScript is gaining popularity
>>>> again, it's also a significant threat vector for attacks on users via
>>>> browser access. From that perspective, and on its face, this proposal
>>>> worries me.
>>>>
>>>> gerry
>>>>
>>>>
>>>> On Thu, Apr 25, 2013 at 10:09 AM, Roy Mendelssohn - NOAA Federal <
>>>> roy.mendelssohn@xxxxxxxx> wrote:
>>>>
>>>>> Hi Gerry:
>>>>>
>>>>> Thanks for the example. So if there are no restricted data, then there
>>>>> wouldn't be a problem, is that correct? This is why I posted - I want to
>>>>> gain an understanding of the issues, and am hoping that others have a
>>>>> better hold on them than I do.
>>>>>
>>>>> What would help me understand this better also is if someone
>>>>> knowledgeable can review what my options are for implementing Rob's
>>>>> request. I would prefer not to alter THREDDS directly, so that i can
>>>>> easily undo the change if I needed to.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Roy
>>>>>
>>>>> PS - Just to give some more background, we have a server called ERDDAP,
>>>>> and for some agencies to deploy it has required that it undergo a scan.
>>>>> That is not necessarily my preference, but that is the reality, So i
>>>>> would rather anticipate and deal with these issues up front, rather than
>>>>> after the scan finds shortcomings.
>>>>>
>>>>>
>>>>> On Apr 25, 2013, at 8:00 AM, Gerry Creager - NOAA Affiliate <
>>>>> gerry.creager@xxxxxxxx> wrote:
>>>>>
>>>>>> Jon -- A big concern from our point of view (note: some mental
>>>>> gemnastics may be involved in following this) is that a site accessed
>>>>> from
>>>>> another "trusted" site via cross-origin credentials, may serve sensitive
>>>>> data to an unprivileged user. That constitutes a data breach and as such,
>>>>> tends to cause alarms to go off around here. Speaking as someone who just
>>>>> endured over 2 months of bureaucratic wrangling to gain access to a
>>>>> "restricted" dataset, if the work to get those data got worse because
>>>>> someone had made this same set publicly accessible, even inadvertently,
>>>>> it
>>>>> would start approaching "useless" within my organization.
>>>>>> Benno -- tell me you don't expect Microsoft to conform to a standard
>>>>> they don't either own, or have claimed to own?
>>>>>> gerry
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 25, 2013 at 9:46 AM, Jon Blower <j.d.blower@xxxxxxxxxxxxx>
>>>>> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> An honest (and perhaps innocent) question - if a server is already
>>>>> public and read-only, what is there to lose by enabling CORS? The
>>>>> cross-origin security constraints exist for the security of the client
>>>>> (browser), not the server. You could after all be accessing the server
>>>>> through something that isn't a browser at all.
>>>>>> However, if a server requires logins, and/or allows changes to the
>>>>> server to be made through the web interface, then CORS is perhaps more of
>>>>> an issue (most of the examples in the website Dennis quotes are around
>>>>> these use cases).
>>>>>> >From that same website, the risk of allowing CORS for a public
>>>>> read-only site appears to be that an attacker could use users' web
>>>>> browsers
>>>>> to perform a distributed denial-of-service attack, which is surely
>>>>> already
>>>>> possible anyway (and is why many sysadmins implement throttling or some
>>>>> other strategy).
>>>>>> Cheers,
>>>>>> Jon
>>>>>> (not a security expert or a sysadmin!)
>>>>>>
>>>>>> _______________________________________________
>>>>>> thredds mailing list
>>>>>> thredds@xxxxxxxxxxxxxxxx
>>>>>> For list information or to unsubscribe, visit:
>>>>> http://www.unidata.ucar.edu/mailing_lists/
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Gerry Creager
>>>>>> NSSL/CIMMS
>>>>>> 405.325.6371
>>>>>> ++++++++++++++++++++++
>>>>>> “Big whorls have little whorls,
>>>>>> That feed on their velocity;
>>>>>> And little whorls have lesser whorls,
>>>>>> And so on to viscosity.”
>>>>>> Lewis Fry Richardson (1881-1953)
>>>>>> _______________________________________________
>>>>>> thredds mailing list
>>>>>> thredds@xxxxxxxxxxxxxxxx
>>>>>> For list information or to unsubscribe, visit:
>>>>> http://www.unidata.ucar.edu/mailing_lists/
>>>>>
>>>>> **********************
>>>>> "The contents of this message do not reflect any position of the U.S.
>>>>> Government or NOAA."
>>>>> **********************
>>>>> Roy Mendelssohn
>>>>> Supervisory Operations Research Analyst
>>>>> NOAA/NMFS
>>>>> Environmental Research Division
>>>>> Southwest Fisheries Science Center
>>>>> 1352 Lighthouse Avenue
>>>>> Pacific Grove, CA 93950-2097
>>>>>
>>>>> e-mail: Roy.Mendelssohn@xxxxxxxx (Note new e-mail address)
>>>>> voice: (831)-648-9029
>>>>> fax: (831)-648-8440
>>>>> www: http://www.pfeg.noaa.gov/
>>>>>
>>>>> "Old age and treachery will overcome youth and skill."
>>>>> "From those who have been given much, much will be expected"
>>>>> "the arc of the moral universe is long, but it bends toward justice" -MLK
>>>>> Jr.
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> thredds mailing list
>>>> thredds@xxxxxxxxxxxxxxxx
>>>> For list information or to unsubscribe, visit:
>>>> http://www.unidata.ucar.edu/mailing_lists/
>>>
>>> _______________________________________________
>>> thredds mailing list
>>> thredds@xxxxxxxxxxxxxxxx
>>> For list information or to unsubscribe, visit:
>>> http://www.unidata.ucar.edu/mailing_lists/
>
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
