The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software. Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license.

Saturday, April 24, 2010

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.

Tuesday, April 6, 2010

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.

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.