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/
