A strong coalition of Open Source community leaders, under the umbrella of the Open Web Application Security Project (OWASP), has released a valuable, thought-provoking report for all web application projects (including web integration and web services).
The OWASP’s “Ten Most Critical Web Application Security Vulnerabilities” is a detailed look at some of the most likely areas where web applications (XML, web services, Java-based application server) might suffer from security problems.
==========================================================================
OSCON Alert: OET wants to know if you or others in your firm are attending (Open Source Convention) in Portland, Ore. July 7-11. If you’ll be there, drop our editors a note to tell us what topic(s) you’re interested in, and if we can contact you about future stories looking at how devs are integrating Open Source into their web, Java, .NET and legacy systems. Email us at editor@oetrends.com. Thanks.
==========================================================================
By releasing this report, OWASP said they want to increase awareness of certain vulnerabilities developers and sysadmins may have exposed to their web-based applications (not simply static web pages). “The experts at OWASP have concluded these vulnerabilities represent a serious risk to [those] who have exposed their business logic to the Internet.”
The topics in the report run the gamut of a broad range of security concerns, including access control, session management, cryptographics, directory services, guarding against insertion of invalid data, and even insecure server-to-server scripting. More than just identifying these threats, OWASP has done an admirable job in not simply defining the problem, but also helps developers and sysadmins identify ways the problem might be introduced into their systems and techniques for securing web applications against the threat.
This OWASP comment intrigued us further: “These flaws are surprisingly common and can be exploited by unsophisticated attackers with easily available tools. When an organization deploys a web application, they invite the world to send HTTP requests. Attacks buried in these requests sail past firewalls, filters, platform hardening, SSL and IDS without notice because they are inside legal HTTP requests. Therefore, web application code is part of the security perimeter and cannot be ignored.”
OWASP is an Open Source community project staffed entirely by volunteers from across the world. The project is developing software tools and knowledge-based documentation that helps people secure web applications and web services. Much of the work is driven by discussions on the Web Application Security list at SecurityFocus.com. [Readers can learn more about the membership and agenda of the OWASP here.]
OWASP’s Top Web Apps Threats
Below, Open Enterprise Trends has included an overview of OWASP’s Top 10 bogeymen for web services. The first five (5) examples, with permission, provide readers with a drill-down of some recommendations for coping with the problem. Download the entire 27-page OWASP security report. (Simply select a “mirror,” and the report will be downloaded from that site. Approx. download time is less than 2 min.)
- Unavailable Parameters — Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application
Any part of an HTTP request can be “tainted,” the report said, and recommended that “the best way to prevent parameter tampering is to ensure that all parameters are validated before use” using a component review process. - Broken Access Control — Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users’ accounts, view sensitive files or use unauthorized functions. The most important step is to document — or whiteboard — your web applications’ access control and capture process. This documentation should include: types of users that can access an application; what functions and content each user types can access; retesting common threats including: insecure IDs, forced browsing; path transversal; file permissions; and client-side caching.
- Broken Account and Session Management — Account credentials and session tokens are not properly protected. Attackers who can compromise passwords, keys, session cookies or other tokens can defeat authentication restrictions and assume others’ identities.Strong authentication services and off-the-shelf session management tools can guard against many vulnerabilities that can arise from a broken session, but making sure that technology is properly implemented is the key to its effectiveness, the report said. To that end, OWASP recommended developers/sysadmins pay special attention to several key areas, including: password change control, strength and storage; protecting credentials while “in transit” to avoid credential theft/hijacking; blocking access to account lists from browsers; and using POST (never GET) for submitting authentication and session data.
- Cross-Site (XSS) Scripting Flaws — The web application can be used as a mechanism to transport an attack to an end user’s browser. A successful attack can disclose the end user’s session token, attack the local machine or spoof to fool the user (or target server/destination).XSS attacks comes in two flavors: “Stored attacks” permanently store injected code on target servers, databases, message forums and other areas. “Reflected attacks” inject code through secondary routes, such as e-mail, or through server-to-server communications. When a user (or a web service) uses a URL to check or submit data, the injected code travels to that target. The attack can also be “reflected” back to the originating user/service request because the target appeared to be a “trusted server,” which can cause the originating browser/server to execute the tainted injected code.The best way to tell if your system or web applications are vulnerable, OWASP said, is to review your code and search for all places where input from an HTTP request could possible make its way into HTML output. The reports also notes for J2EE app server users that a variety of HTML tags can be used to transmit “malicious JavaScript.” The report (on page 15) also suggests the most vulnerable HTML tags and suggest how they should be converted.
Other Web App Security Threats to Watch for
- Buffer Overflows — Web application components in some languages that do not properly validate input can be crashed and, in some cases, even used to take control of a web-based process. These components can include CGI, libraries, drivers and web application server components.
- Command Injection Flaws — Web application pass parameters when they access external systems or the local OS. If attackers can embed malicious commands in these parameters, the external system may execute those commands on behalf of a web application.
- Error-Handling Problems — Error conditions that occur during normal operations are not handled properly. If attackers can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail or crash the server.
- Insecure Use of Cryptography — Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.
- Remote Administration Flaws — Many web applications allow administrators to access the site using a web interface. If these administrative functions are not carefully protected, an attacker can gain full access to all aspects of the site.
- Web and Application Server Misconfiguration — Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not now secure out of the box.