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.
