The Second International Conference on Cyber Security, Cyber Warfare and
Digital Forensic (CyberSec2013)
The Asia Pacific University of Technology and Innovation (APU), Kuala
Lumpur, Malaysia
March 4-6, 2013
http://www.dcmrf.net/Malaysia3
---======
The proposed conference on the above theme will be held at The Asia
Pacific University of Technology
and Innovation (APU), Kuala Lumpur, Malaysia, From March 4-6, 2013 which
aims to enable researchers
build connections between different digital applications
The conference welcomes papers on the following (but not limited to)
research topics:
Researchers are encouraged to submit their work electronically. All papers
will be fully
refereed by a minimum of two specialized referees. Before final
acceptance, all referees
comments must be considered.
Submission Date : Dec 15, 2012
Notification of acceptance: Jan 01, 2013
Camera Ready submission : Jan. 15, 2013
Registration : Jan. 15, 2013
Conference dates : March 4-6, 2013
I am looking for someone to help me with a research project to determine the
adoption/extent/usage of HTML5 (family) functions on the Web. If interested,
please send me a direct email. Thanks.
Pete Lindstrom
Principal, VP of Research
Spire Security
@SpireSec
Thanks to those that responded to my request for research collaboration.
Still working with a handful of folks to see what makes the most sense.
In the meantime, I neglected to point out the excellent work done by
Sebastian Lekies and Martin Johns et.al. at SAP. Good data.
Just yesterday, Veracode published some related research here:
http://www.veracode.com/blog/2012/11/security-headers-report/.
Here's how I evaluate the data Isaac Dawson of Veracode got on CORS:
80% of sites using CORS explicitly allow all (the "promiscuous asterisk"
that I first encountered with Banyan Vines email). If, prior to CORS* the
sites were using anonymous server-side proxy (or other technique?) to allow
similar access, then net impact is 0. If pre-CORS* the sites were not
explicitly defining any privileges, then the sites were governed by
same-origin and therefore the net impact is risk increasing.
20% of sites using CORS explicitly define a single origin (presumably their
own). If these sites were susceptible to XSS pre-CORS (a good assumption)
then the impact is risk reducing. If the sites were not susceptible to XSS
then the impact is 0.
I would appreciate feedback if anyone feels this logic is faulty. I am sure
there are more nuances so would appreciate those as well.
Thanks,
Pete
-----Original Message-----
From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On Behalf
Of Pete Lindstrom
Sent: Thursday, November 01, 2012 9:51 AM
To: websecurity@lists.webappsec.org
Subject: [WEB SECURITY] Wanted: HTML5 Web Security Researcher
I am looking for someone to help me with a research project to determine the
adoption/extent/usage of HTML5 (family) functions on the Web. If interested,
please send me a direct email. Thanks.
Pete Lindstrom
Principal, VP of Research
Spire Security
@SpireSec
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Hi,
I haven't played around with CORS, but just from reading the article and
generally, I don't agree with your conclusions.
80% of sites using CORS explicitly allow all (the "promiscuous asterisk"
that I first encountered with Banyan Vines email). If, prior to CORS* the
sites were using anonymous server-side proxy (or other technique?) to allow
similar access, then net impact is 0. If pre-CORS* the sites were not
explicitly defining any privileges, then the sites were governed by
same-origin and therefore the net impact is risk increasing.
The article mentions that with a wildcard, a request can be sent with
cookies, but JavaScript can't read the response. I think we only need to
really worry about requests with cookies - without this (and knowing the
URL) the attacker could just make that request themselves directly
(although this may be a way to bypass IP based restrictions). The status
quo, is that you can send such a request anyway, using something like an
image tag or a form target - but the cross origin model prevents reading
the response. So I think the risk for these sites is quite minor.
Probably biggest risk is that some clients may incorrectly implement
CORS, and having this header exposes you to related bugs.
20% of sites using CORS explicitly define a single origin (presumably their
own). If these sites were susceptible to XSS pre-CORS (a good assumption)
then the impact is risk reducing. If the sites were not susceptible to XSS
then the impact is 0.
If the site is susceptible to XSS without CORS, then I don't think
having a CORS header greatly reduces the risk. For a simple XSS, like
getting a user to click a link to
http://vuln/vuln?id=<script>alert(1)</script> - CORS will make no
difference.
I think CORS is not intended as a security mechanism, more as new
functionality to allow cross-domain requests. It seems to me to be
designed to do this reasonably securely - although looking for
implementation bugs would be interesting. There is the more general
trust issue of allowing an external site to access response bodies with
cookies, but that's not greatly different to existing trust issues
around JSONP and <script> tags with external links. Bottom line is it
gives the administrator the option to trust something external - and
it's down to them to make sure the external party really is trustworthy.
Paul
--
Pentest - When a tick in the box is not enough
Paul Johnston - IT Security Consultant / Tiger SST
Pentest Limited - ISO 9001 (cert 107029) / ISO 27001 (cert 558982)
Office: +44 (0) 161 233 0100
Mobile: +44 (0) 7817 219 072
Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy
Registered Number: 4217114 England & Wales
Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK