It's important you report a security vulnerability you may have found in the Seam framework in a responsible fashion. For more information, see this page.

Current web applications are exposed to a variety of attack vectors. This and the linked pages are providing

• the necessary background information for application developers to understand these issues

• the general solution or best defense against an attack

• implementation details that particularly apply to applications created with the Seam framework.

Throughout the development cycle, significant effort is dedicated to securing all or parts of an application from unauthorized access. Any mature framework offers infrastructure for defining the security policies and cross-referencing them against the user's credentials. For instance, Seam offers a wide variety of ways to express these restrictions through roles, declarative rules, and access control lists (ACLs). But there is more to security than just access control. The focus of this document is not on these obvious security concerns, but rather on those that are harder for the developer to recognize. Some security experts consider these vulnerabilities far more dangerous than front door security holes since they are often exploited without the user's knowledge...until they realize that funds are missing from their account.

Although frameworks such as Seam and JSF offer basic protection against most of these attacks, you as an application developer nevertheless should have a good understanding of the issues. Many security holes in web applications today are the result of developers unknowingly disabling some protection their frameworks offer or careless application design and conceptual flaws in the software that no framework or library can protect you from.

Furthermore, it is important to understand that security is not a design pattern that can be applied once. Maintaining security and protecting yourself and your users against web vulnerabilities is an ongoing process and a natural part of the life cycle of your software. You have to stay informed and alert, and react to any new vulnerabilities and exploits as they are discovered.

Attack Vectors and Countermeasures

Security measures break down when the negotiation of trust between the user and the application is compromised. In other words, the application must ask, Did the user intend for the browser to make this request? It's entirely possible that the browser is being remotely controlled in a malicious manner, an attack referred to as Cross Site Request Forgery (CSRF) or session riding. CSRF is closely tied to cross-site scripting (XSS), which often enables this type of attack. Both issues are covered in the linked documents.

An attack vector is a technology that does not attack a system itself, but which transmits an attack by conveying a request from one site to another. The technology in this case is tremendously benign. It's nothing more than a request. But that request can be issued by sources such as an image tag, an iframe, or an XMLHttpRequest (XHR), which is where the abuse comes into play.

Read background on attack vectors and examples of countermeasures...

Cross Site Scripting

The cross site scripting (XSS) attack vector results from missing or incomplete sanitization of directives that are passed to web applications. From the OWASP Top 10 description: “XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.“

Read more about Cross Site Scripting...

Cross Site Request Forgery

The cross site request forgery (CSRF) attack sends requests to a web application without the user knowing or noticing these requests. From the OWASP Top 10 description: “A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks. “ This attack vector is also known as Session Riding (see Session Riding by Thomas Schreiber).

Read more about Cross Site Request Forgery...

Injection Flaws

OWASP: Injection flaws, particularly SQL injection, are common in web applications. There are many types of injections: SQL, LDAP, XPath, XSLT, HTML, XML, OS command injection and many more. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query and attackers trick the interpreter into executing unintended commands via supplying specially crafted data.

Read more about Injection Flaws...

Other common vulnerabilities

The OWASP Top 10 is a good place to starting point to learn more about these and other web vulnerabilities. -----