websecurity@lists.webappsec.org

The Web Security Mailing List

View all threads

CFP:: CyberSec2013- Kuala Lumpur:: Malaysia

TS
The Second International Conference on Cyber Security, Cyber Warfare and Digital Forensic (CyberSec2013)
Fri, Oct 26, 2012 7:53 AM

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:

  • Cyber Security
  • Privacy issues
  • Formal Methods Application in Security
  • Incident Handling and Penetration Testing
  • Operating Systems and Database Security
  • Security in Cloud Computing
  • Security in Social Networks
  • Multimedia and Document Security
  • Hardware-Based security
  • VOIP, Wireless and Telecommunications Network Security
  • Security of Web-based Applications and Services
  • Enterprise Systems Security
  • SCADA and Embedded systems security
  • Distributed and Pervasive Systems Security
  • Secure Software Development, Architecture and Outsourcing
  • Security for Future Networks
  • Security protocols
  • Legal Issues
  • Digital Forensic
  • Data leakage, Data protection and Database forensics
  • Forensics of Virtual and Cloud Environments
  • Network Forensics and Traffic Analysis Hardware Vulnerabilities and
    Device Forensics
  • Information Hiding
  • File System and Memory Analysis Multimedia Forensic
  • Executable Content and Content Filtering
  • Anti-Forensics and Anti-Anti-Forensics Techniques
  • Malware forensics and Anti-Malware techniques
  • Evidentiary Aspects of Digital Forensics
  • Investigation of Insider Attacks
  • Cyber-Crimes
  • Large-Scale Investigations
  • New threats and Non-Traditional approaches
  • Information Assurance and Security Management
  • Corporate Governance
  • Laws and Regulations
  • Threats, Vulnerabilities, and Risk Management
  • Business Continuity & Disaster Recovery Planning
  • Critical Infrastructure Protection
  • Digital Rights Management and Intellectual Property Protection
  • Security Policies and Trust Management
  • Identity Management
  • Decidability and Complexity
  • Economics of Security
  • Fraud Management
  • Cyber warfare and Physical Security
  • Surveillance Systems
  • Cyber Warfare Trends and Approaches
  • Social engineering
  • Authentication and Access Control Systems
  • Biometrics Applications
  • Electronic Passports, National ID and Smart Card Security
  • Template Protection and Liveliness detection
  • Biometrics standards and standardization
  • New theories and algorithms in biometrics

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.

Important Dates

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

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: * Cyber Security - Privacy issues - Formal Methods Application in Security - Incident Handling and Penetration Testing - Operating Systems and Database Security - Security in Cloud Computing - Security in Social Networks - Multimedia and Document Security - Hardware-Based security - VOIP, Wireless and Telecommunications Network Security - Security of Web-based Applications and Services - Enterprise Systems Security - SCADA and Embedded systems security - Distributed and Pervasive Systems Security - Secure Software Development, Architecture and Outsourcing - Security for Future Networks - Security protocols - Legal Issues * Digital Forensic - Data leakage, Data protection and Database forensics - Forensics of Virtual and Cloud Environments - Network Forensics and Traffic Analysis Hardware Vulnerabilities and Device Forensics - Information Hiding - File System and Memory Analysis Multimedia Forensic - Executable Content and Content Filtering - Anti-Forensics and Anti-Anti-Forensics Techniques - Malware forensics and Anti-Malware techniques - Evidentiary Aspects of Digital Forensics - Investigation of Insider Attacks - Cyber-Crimes - Large-Scale Investigations - New threats and Non-Traditional approaches * Information Assurance and Security Management - Corporate Governance - Laws and Regulations - Threats, Vulnerabilities, and Risk Management - Business Continuity & Disaster Recovery Planning - Critical Infrastructure Protection - Digital Rights Management and Intellectual Property Protection - Security Policies and Trust Management - Identity Management - Decidability and Complexity - Economics of Security - Fraud Management * Cyber warfare and Physical Security - Surveillance Systems - Cyber Warfare Trends and Approaches - Social engineering - Authentication and Access Control Systems - Biometrics Applications - Electronic Passports, National ID and Smart Card Security - Template Protection and Liveliness detection - Biometrics standards and standardization - New theories and algorithms in biometrics 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. Important Dates ============== 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
PL
Pete Lindstrom
Thu, Nov 1, 2012 1:50 PM

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

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
PL
Pete Lindstrom
Wed, Nov 7, 2012 3:02 PM

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

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
PJ
Paul Johnston
Sun, Nov 11, 2012 12:02 AM

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

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