OWASP Java Project. Main The OWASP Java Project's goal is to enable Java and J2EE developers to build secure applications efficiently.
See the OWASP Java Project Roadmap for more information on our plans. Java Security Overview While Java and J2EE contain many security technologies, it is not easy to produce an application without security vulnerabilities. Most application security vulnerabilities apply to Java applications just like other environments. There is a wealth of information about vulnerabilities that apply to Java and JavaEE application in the Vulnerability articles here at OWASP. The goals of this project are to provide information about building, configuring, deploying, operating, and maintaining secure Java applications.
J2EE Security for Architects Provides information about the design and architectural considerations for a Java web application. J2EE Security for Developers J2EE Security for Deployers These articles cover topics specifically related to the J2EE environment. Resources. Top 10 2010-A8-Failure to Restrict URL Access. Cross-site request forgery. History[edit] CSRF vulnerabilities have been known and in some cases exploited since 2001.[3] Because it is carried out from the user's IP address, some website logs might not have evidence of CSRF.[2] Exploits are under-reported, at least publicly, and as of 2007[4] there are few well-documented examples.
About 18 million users of eBay's Internet Auction Co. at Auction.co.kr in Korea lost personal information in February 2008.[5] Customers of a bank in Mexico were attacked in early 2008 with an image tag in email. The link in the image tag changed the DNS entry for the bank in their ADSL router to point to a malicious website impersonating the bank.[6] Example and characteristics[edit] The attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have been authenticated.[1] For example, one user, Alice, might be browsing a chat forum where another user, Mallory, has posted a message.
Top 10 2007-Insecure Communications. Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
Encryption (usually SSL) must be used for all authenticated connections, especially Internet-accessible web pages, but backend connections as well. Otherwise, the application will expose an authentication or session token. In addition, encryption should be used whenever sensitive data, such as credit card or health information is transmitted. Applications that fall back or can be forced out of an encrypting mode can be abused by attackers. The PCI standard requires that all credit card information being transmitted over the internet be encrypted. Top 10 2010-A7-Insecure Cryptographic Storage. Broken Authentication and Session Management. Description Authentication and session management includes all aspects of handling user authentication and managing active sessions.
Authentication is a critical aspect of this process, but even solid authentication mechanisms can be undermined by flawed credential management functions, including password change, forgot my password, remember my password, account update, and other related functions. Because “walk by” attacks are likely for many web applications, all account management functions should require reauthentication even if the user has a valid session id.
User authentication on the web typically involves the use of a userid and password. Top 10 2007-Information Leakage and Improper Error Handling. Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems.
Applications can also leak internal state via how long they take to process certain operations or via different responses to differing inputs, such as displaying the same error text with different error numbers. Web applications will often leak information about their internal state through detailed or debug error messages. Often, this information can be leveraged to launch or even automate more powerful attacks. Environments Affected All web application frameworks are vulnerable to information leakage and improper error handling.
Vulnerability Applications frequently generate error messages and display them to users. Top 10 2010-A4-Insecure Direct Object References. Top 10 2007-Malicious File Execution. Malicious file execution vulnerabilities are found in many applications.
Developers will often directly use or concatenate potentially hostile input with file or stream functions, or improperly trust input files. On many platforms, frameworks allow the use of external object references, such as URLs or file system references. When the data is insufficiently checked, this can lead to arbitrary remote and hostile content being included, processed or invoked by the web server. Injection Flaws. Description Injection flaws allow attackers to relay malicious code through a web application to another system.
These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL (i.e., SQL injection). Whole scripts written in perl, python, and other languages can be injected into poorly designed web applications and executed. Any time a web application uses an interpreter of any type there is a danger of an injection attack.
Many web applications use operating system features and external programs to perform their functions. SQL injection is a particularly widespread and dangerous form of injection. Injection attacks can be very easy to discover and exploit, but they can also be extremely obscure. Environments Affected Every web application environment allows the execution of external commands such as system calls, shell commands, and SQL requests. Examples. Cross-site scripting. Background[edit] Security on the web is based on a variety of mechanisms, including an underlying concept of trust known as the same origin policy.
This essentially states that if content from one site (such as is granted permission to access resources on the system, then any content from that site will share these permissions, while content from another site ( will have to be granted permissions separately. [citation needed] Cross-site scripting uses known vulnerabilities in web-based applications, their servers, or plug-in systems on which they rely. Exploiting one of these, they fold malicious content into the content being delivered from the compromised site. XSS vulnerabilities have been reported and exploited since the 1990s.