Steve Ansari just sent the below to me:
From:
https://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
Potential Security Concerns with COR
Universal Allow:
Site-level Cross Origin Access:
Access-control decision based on Origin header:
Prolonged caching of Preflight responses:
Misplaced-trust
Processing rogue COR
Universal Allow:
This is the most common and obvious mistake that implementers can be make.
The ‘Access-Control-Allow-Origin’ header should contain the list of Origins
that can make COR. This header also takes a wildcard value – *. This value
would allow any website to make a COR to that page and read the response.
This can be abused in some cases:
If a part of an intranet website which is not accessible from outside has
an universal allow option and if an internal user visits an attacker
controlled website, the attacker’s site can make COR to this internal
resource, read the response and steal it.
A variation of this is when a website is accessible on the internet but has
a slightly different behavior when accessed from the intranet. For example,
if you make a Google search from within the Google intranet then apart from
the features available to external users, there might be some new
experimental extra features. And if Google had a universal allow option, to
allow any website to access its search then an outsider can also access
these internal features from the browser of an internal employee.
The earlier two scenarios showed how this can be used to attack the server,
while this one is about the attack on the user. Let’s say the attackers
have identified a SQL Injection vulnerability on your ‘productsearch.php’
page that is accessible universally. Instead of mining the database from
their system, they might write a data miner in JavaScript and insert it on
their website or on a website containing persistent XSS. When a victim
visit’s that website containing this malicious JavaScript, his browser will
perform SQL Injection attack against ‘productsearch.php’, mine all the data
and send it back to the attackers. Inspection of the server logs would
indicate that the victim was performing this attack, since HTTP headers
apart from Referrer generally don’t get logged. The victim cannot claim his
system was compromised because a forensic examination would not show any
traces of malware or system compromise.
On Thu, Apr 25, 2013 at 1:57 PM, Tom Kunicki <tkunicki@xxxxxxxx> wrote:
>
> 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/
>
>
>
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
--
Glenn K. Rutledge
Meteorologist/Physical Scientist
NOMADS Team Leader
National Climatic Data Center
Asheville, NC 28801
(828) 271-4097
nomads.ncdc.noaa.gov
