OWASP Top Ten and Risk

There are *several* risks in the new OWASP Top 10 which have the technical impact of disclosing sensitive information, including Injection, Insecure Direct Object References, and Failure to Restrict URL Access. The T10 isn't organized by attack or impact (such as information leakage), because it leads to a combinatorial explosion of risks. Instead, we've organized the T10 around the missing or broken security control involved with each risk. We believe that this is the simplest thing to measure and manage, and is to most directly applicable to software developers.

Specifically with regard to information leakage, the traditional use of this term (see e.g. http://projects.webappsec.org/Information-Leakage) focuses on implementation details, such as IP addresses and stack traces -- not sensitive business or personal information. While the release of such implementation details isn't good, and it is very common, in most cases it is not a risk by itself, but simply makes another risk worse. Based on the risk factors we were able to determine from the data we received, information leakage (as defined above) didn't make the top ten.

Hopefully that helps explain why it's not in the list, but remember that the T10 is by necessity a generalization, and what's important to your organization may differ.

--Jeff Williams

OWASP Ireland AppSec Conference

OWASP will hold its annual Ireland Application Security conference in Trinity College, Dublin on September 17 2010.

The "Who's Who" in application security for Ireland.

The Conference will consist of one day of training sessions, followed by a one-day conference with 2 tracks.

In 2009, we attracted a large number of delegates from across Europe, Middle East and the USA and expect even greater international representation in 2010.

We are seeking presentations on any of the following topics:

• Web Services and Application Security
• Common Application related Threats and Risks
• Business Risks with Application Security
• Vulnerability Research in Application Security
• Web Application Penetration Testing
• OWASP Tools and Projects
• Secure Coding Practices
• Technology specific presentations on security such as AJAX, XML, etc.
• Anything else relating to OWASP and Application Security.

Other suggestions welcome.

The call for papers/presentations is out.!!

The official closing date for receiving a synopsis of the presentation is June 10th, 2010.

Complete presentations will need to be submitted by the 10th of August 2010.

This year as per last year any presenter will receive a free invitation to the conference.

Sponsorship opportunities are currently available.

Please submit your presentation topics and an abstract of up to 500 words to Eoin Keary eoin.keary@owasp.org

Kate Hartmann
OWASP Operations Director
9175 Guilford Road
Suite 300
Columbia, MD 21046

301-275-9403
kate.hartmann@owasp.org
Skype: kate.hartmann1

OWASP JBroFuzz 2.1

Hi all,

Here is the follow up 2.1 release of JBroFuzz:

• Ctrl + M to load your own fuzzers from a .jbrf file
• Removed the default addition of line feeds at the end of each request, make sure you know what you are fuzzing!
• On The Wire: Right-click, clear & also option to select to see requests and/or responses
• Added ASCII 85 (045-A85-RFC) & printable ASCII 94 (046-A94-CHR) fuzzers.
• Base32 and zBase32 Encode/Decode functionality added
• JBroFuzz now logs into daily log (thnx Ranulf!)
• You can load your custom payloads by placing a file called fuzzers.jbrf within your working directory.
• Added 3 new file extension fuzzers in the /fuzzers directory (thnx Adam)

http://www.owasp.org/index.php/Category:OWASP_JBroFuzz

Hope that this focus on new fuzzers is of use to everyone.

Thank you,

Yiannis

AppSec Research 2010 program published!

Dear OWASP leaders,

The two committees are thrilled to announce the conference program of OWASP AppSec Research 2010! Go check it out, and be sure to register within 24 hours to get a free leader's ticket. Abstracts of all talks will be published within a few days.

http://www.owasp.org/index.php/OWASP_AppSec_Research_2010_-_Stockholm,_Sweden

Tweet it:

#OWASP AppSec Research 2010 conference program is finally published!

24 hrs left of early bird registration. http://bit.ly/cOa4Oz

Free registration for leaders, trainers, speakers etc until April 7th:

http://guest.cvent.com/i.aspx?4W%2cM3%2c2bbf460c-ccd6-4e49-acfe-7a5f29105873

Kind regards, John

--

John Wilander

Chapter leader OWASP Sweden

Conference chair OWASP AppSec Research 2010

http://owasp.se

OWASP AIR + Flash Security Projects

I saw this response to a question on the OWASP-Leaders mailing list and I thought that the information was worth re-posting.

- Jim Manico

***

The OWASP AIR Security Project http://www.owasp.org/index.php/Category:OWASP_AIR_Security_Project and the OWASP Flash Security Project

http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project are useful resources for developers who want to create secure AIR applications. If desktop administrators have questions regarding AIR, Adobe provides resources at: http://www.adobe.com/products/air/it_administrators/.

With regards to file access, desktop applications based on the AIR runtime follow the same security model as any other desktop application. The application will inherit the privileges of the user who launched it and the application will be able to access any file or resource that the user has permission to access. You are trusting the author of the desktop application not to misuse their privileges which is why all AIR applications must be digitally signed by the author.

Although, sometimes trustworthy authors make mistakes during development that could allow unauthorized access of local files or resources by untrusted content. To help reduce those types of vulnerabilities, the AIR runtime restricts sensitive APIs and implements secure defaults. As an example, any content that was not contained within the signed install package is considered to be untrusted and it is placed in a restricted sandbox by default. If the developer wants to grant the restricted content additional privileges, then the runtime provides APIs where developers can specifically choose what functionality or data is exposed. Therefore, file access is never granted to remote content by default and the developer can selectively choose what, if any, files or data are exposed.

Let me know if you have any further questions.

------------

Peleus Uhley

Senior Security Researcher

Adobe Systems, Inc.