|
|
 |
May 2006
By Nitin Bharti, Frank Cohen, Rich Seeley and Doug Bateman
Day 1 | Day 2
| Day 3
Twelve Java Technology Security Traps and How to Avoid Them
Security In Java Is Still Difficult
JCP Panel Discussion
There's More to JBoss Seam Than It Seems
Nice Backpacks Don't Make Up for Long Lines and No WIFI Service
JavaOne News from Day 4
Brian Chess, Chief Scientist of Fortify Software delivered a session titled "Twelve Java Technology Security Traps and How to Avoid Them." Brian began the session by discussing, that
as programmers, we are trained from the very beginning to value simplicity through encapsulation and reuse and to value performance through algorithms which optimize time (speed) and space
(memory).
However, during our early training, programmers are rarely taught how to value security, considering security problems as mere bugs to be fixed in the next release. For example, open the
documentation for any API, and you often see a set of specifications describing what external interface the encapsulation meets and description of the time and space used by the algorithms,
but seldom do you see a clear documentation of the security assumptions made by the package or a set of proper security idioms. Making matters worse, Java programmers are often lulled into
the belief that Java is intrinsically more secure than C and that the software we write is therefore "secure enough".
During the session, Brian argued that to properly secure a system, security must be considered as a first class concern with it's own "customer" or "actor" in the software development
process responsible for ensuring security requirements are met. Security, he says, "Cannot simply be handled as a sequence of bugs to be patched." Getting security right requires policy,
process, and tools. To illustrate this, Brian presented 12 common examples of security vulnerabilities in Java software, complete with code examples. (The full slides, including code
examples, can be downloaded from https://www28.cplan.com/cb_export/PS_TS-1660_277660_124-1_FIN_v2.pdf).
The 12 discussed common security vulnerabilities include:
- Injection Attacks. SQL Injection Attacks occur when an attacker includes raw SQL as input to a text field in an application. If the application then uses that input to
dynamically generate an SQL statement without first applying proper input validation and representation, the attackers SQL may be executed as written in the database. Most experienced
Java programmers know to avoid this vulnerability through the use of Bind Variables in SQL Prepared Statements. But as Brian pointed out, Injection Attacks can also occur as "Filename
Injection," writing to critical system files (often we might overlook ../../ included in a filename), "Command Injection," "XML Injection" or fundamentally in any string which may be
interpreted by any part of the system at any time. In fact, it doesn't even have to be a String at all to be vulnerable to injection attacks. Therefore input validation which only allows
inputs in a specified range of values is a MUST for any system.
- Cross Site Scripting. Anytime a user can input data which at some later point will be returned to a browser, there is an opportunity for Cross-Site Scripting. This occurs when a
user includes malicious JavaScript in a data input field (such as "First Name" or "Address")...when the data is then later displayed to another user, the embedded JavaScript is interpreted
and run by the unwitting user.
- Bad Credential Management. Keeping usernames and passwords in code or files as PLAIN TEXT or using trivial Base64 encodings. (Very common for JDBC connections.)
- Bad Error Handling. Displaying exception stack traces in his browser window, providing the attacker with the tools to "debug" your program.
- Test Code Goes into Production. Often programmers include hooks to support debugging into their applications. However, if the programmer fails to then later remove ALL the logic
at a later date, it can accidentally go into production, making it vulnerable to attack.
- Native Methods. All the security guarantees of Java are lost once Java calls Native code. Buffer-overflows and the entire set of vulnerabilities commonly exposed in C and C++
programs are also possible in Java as a result of Native Method calls.
- Concurrency/Synchronization. Improperly written shared caches, or even simple member variables in servlets, can result in one user's data being displayed to another user. And if
this occurs once by accident, an attacker may latch onto the vulnerability until it exposes critical data, such as a credit card number.
- Missing Access Control. Often programmers secure their JSP pages by including security checks at the top of each page. Such a scheme is highly vulnerable because the security
checks are sprinkled throughout the code rather than being centralized in 1 central location. And even if access control is done in a filter, the vulnerability can still occur if the
Web.XML fails to include the filter during deployment. The development process needs hooks to ensure that access checks are continually verified and audited.
- Bad Session Management. Session hijacking occurs anytime an attacker can obtain data from another user's session. Best practices for protecting a session from hijacking include:
- Issuing a new session ID when transitioning from an unauthenticated session to an authenticated session (or back).
- Truly invalidating the current session upon logout. If the session isn't invalidated, the attacker can "login" again by simply clicking the back button.
- Ensuring sufficient randomness of session IDs to reduce the risk of an attacker "guessing" another user's session ID.
- Cookies and Other Headers. Cookies and Headers are just as vulnerable to "injection" attacks as text field in forms. Often, programmers and frameworks remember to validate form
input, but may overlook validation of headers and cookies. Cookies, headers, text fields, and hidden form variables all represent data sent by the browser and cannot be trusted by the
server without proper validation.
- Logging Sensitive Data. The programmers mantra of "log everything" can result in disasters if credit card numbers or other sensitive data accidentally make their way into log
files.
- Trusting the Configuration. The configuration files from the local file system count as input data too. These files should be checked for vulnerabilities and invalid inputs too.
Otherwise an attacker can modify an input file and inject malicious behavior into an application. (Brian cited an example of Apache reading a config file as root prior to transitioning to
user "nobody").
During the session, Brian presented a number of "bonus" rounds as well, displaying a number of interesting security vulnerabilities one wouldn't necessarily expect or spot easily.
Brian's concluding message was that "security cannot be considered as simply a sequence of bugs to be fixed. It requires changes to the way software is developed, using policy, process,
and tools to effectively tackle the challenge."
Although Sun scheduled many session on SOA security at JavaOne, I left with the feeling that not much has changed in the last five years. Building secure interoperating services is still
difficult.
Instead of talking about Liberty, Passport, SAML, and PKI, the current security talk is about Project Tango in Glassfish and its interoperability with Microsoft Windows Vista. Sun
representatives told developers about their work in the OASIS standards body on WS- Security 1.1 to define security metadata in SOAP headers and the gap that exists in implementing a
standard for policy, protocols (mechanisms for establishing trust) and the notion of a secure session. One presenter told developers you do not need to share tokens with each message as
this is inefficient. He proposed a security token service that Sun and others are working towards.
Presentors at sessions today and a Birds of a Feather (BOF) last night pointed to work in the WS-SX working group at OASIS. Sun integrates WS-Trust, WS-Security, and WS-SecurityPolicy
and provides a framework for building Security Token Services. They are basically leveraging the Sun Access Manager and Federation Manager to provide a token service and identity provider
for Web services.
Session attendees asked if Sun is seeing performance and security problems when using WS-Security with multiple message exchanges. Sun responded that the OASIS WS-SX TC is working to
define WS Secure Conversations. The concept is similar to SSL, IPSec and others. The standard intends to define security session in terms of a security context and Key Derivation mechanism.
WS Secure Conversation has three components: a token to represent the context, a means to establish and manage security context based on the WS-Trust framework, and a key derivation
mechanism.
I attended three security sessions and one BOF and left with the impression that SOA security is difficult, error prone, and half baked.
The JCP panel, held at the Argent hotel, was a chance for members of the community and press to catch up on the latest news from the standards body charged with defining the future of
the Java platform.
The panel was moderated by Frank Sommers, editor at Artima.com and Onno Kluyt, senior director, JCP Program at Sun Microsystems, Inc. and chair of the JCP.
Sommers asked the panelists what the relationship of the JCP is to other Java communities like TheServerSide.com (TSS), Artima.com and java.net - online communities not only discussing
Java, but fostering change and innovation in the platform.
Geir Magnusson Jr., representative of the open source Apache foundation, and lead on the Harmony project, kicked off the discussion by describing the importance of balancing innovation
with standards compatibility.
"Apache has a very large number of Java projects," said Magnusson. "We're good at passing the TCKs and certifying our software to ensure that it works both in a standard way and in a JCP
implementation."
Graham Hamilton, Vice President and Fellow within the Java platform team at Sun Microsystems, pointed out how the latest iteration of the enterprise Java platform combines a lot of the
innovations happening in open source projects, even those technologies that haven't been as widely adopted, such as JDO.
"We like to use ideas that work well," Hamilton said. "EJB 3 is a culmination of innovation from the JDO and Hibernate communities. You have to be cutting edge." At the same time, "you
can't wait 5 years for an idea to mature" before incorporating aspects of it into the specification.
On the subject of how the JCP standards process measures up against other standards efforts, Hani Suleiman, JCP executive committee member, said that "JCP standards have more weight.
People used to think there was no transparency in the JCP, but that has changed a lot. There is quite a bit of process transparency and aspects of this formalized process is leaking into
other communities."
One of the issues discussed was the relationship between standards and innovation happening in the field. As a standards body, the JCP provides specifications which product vendors
implement and innovate around. However, some of the standards could be described as 'reactive' to the unbridled innovation already occurring throughout the industry. This introduces the
need to create a standard around a technology or space that doesn't necessarily have any governing rules.
"It depends where innovation happens," said Asko Komsi, Director, Industry Relations, Nokia Inc. "In the mobile space, many of the features were already in the handset."
The mobile space is a prime example of where the JCP often looks to de facto standards and widely deployed technologies to help guide its standards, such as the Mobile Services
Architecture (MSA) specification (JSR 248), led by mobile giants Nokia and Vodafone.
"3G America has different needs, but they didn't know how to create specs and drive compatibility, which the JCP does," said one of the panelists.
But while the JCP often looks to open source communities and the corporate world for guidance around standards, Hamilton assured the audience that these two worlds have not affected the
actual JCP process. "The executive committee is a provision to prevent vendors from having their specs 'rubber-stamped'."
Earlier in the week, the JCP Program Management Office announced winners of the 4th JCP Program Annual Awards.
Participants included Kluyt, JCP executive committee members, spec leads and other Java technology experts involved with the JCP.
This year's winners included:
- JCP Member of the Year: Sony Ericsson
- Most innovative Java ME JSR: JSR 272, Mobile Broadcast Service API for Handheld Terminals
- Outstanding Java ME Spec Lead: Asko Komsi and Mark Duesner for JSR 248, MSA on CLDC
- Most innovative Java SE/EE JSR: JSR 292, Supporting Dynamically Typed Languages on the Java Platform
- Outstanding Java SE/EE Spec Lead: Linda DeMichiel, for JSR 220, EJB 3.0
At JavaOne, Pierre Fricke, director of product management for JBoss Inc., could not talk about the pending merger with Red Hat Inc. because of the quiet period before the deal closes at
the end of this month. But he could talk about the first release of JBoss Seam, the Web-application framework that supports the new Java EE5. And he could talk about Seam's possible future
with Ajax and the JBoss announcement that it is joining the NetBeans community.
Can you give us an overview of Seam and what exactly is it, is it a lightweight Web development framework?
Pierre Fricke: No, it's more than that. Seam is a Web application framework but it's more than that. It's the next level of simplifying EE5. In EE5, you've still got to do a lot of code to
bridge the EJB3 model over to the Java Server Faces model. And you don't have a meta construct for workflow. So, you still have a lot of disparate programming models to deal with to do full
applications. What our crew has done is basically brought together in a more integrated fashion EJB3 and Java Server Faces. Then they've incorporated jBPEL [Java Business Process Execution
Language], which is our Java environment to go with workflow, as opposed to BPEL, which is an XML Web services environment. But what would make sense in a Java environment would be, of
course, jBPEL, not BPEL. So, you can do page flow and basically you can do process type automation within this programming framework.
How does Seam compare to Spring?
Fricke: People talk about Spring being sort of the thing that's been hot in this area. Spring is a simplified, lightweight model and we certainly are lightweight and we can be quite simple,
but they stopped at a kind of like stateless type of application. Whereas we do stateless applications, we do stateful applications, we do transactional applications and we do workflow
applications. We actually build a much broader set of the mainstream type of applications and we go much further than Spring does and the architecture is much different to handle those
types of scenarios. So I would say while we certainly have all the characteristics of a lightweight Web application framework and are as simple to program in as that, we take that model a
lot farther.
What are you doing in Seam with Ajax?
Fricke: You can do a lot of interactive apps with Seam now and we've still got some work to do to figure out how much Ajax adds value to what we've already done. We haven't done that work
yet. So, with Ajax it might just be a matter of being standards compliant or model compliant. But I don't think we're really ready to get into an Ajax discussion yet with Seam. It's just
shipping now and it adds a lot of value for interactive applications already. And so now, you have to take a look at Ajax and see what kind of value it may add or may not add and then it's
just a matter of figuring out how we go beyond that. We're certainly not going to be left out if it makes sense. But we think the Seam programming model goes a long way in what really is
the intent of Web 2.0, these more robust, transactional, stateful, interactive applications.
Do you have a definition you like for Web 2.0?
Fricke: No. I think it's just a terminology to describe this new, more interactive world, you know, improvements to the Web environment. That's a one-liner and I'll leave it at that.
At JavaOne, JBoss announced that you're joining the Netbeans open source community. What made you guys pick NetBeans over Eclipse?
Fricke: We didn't pick Netbeans over Eclipse. We've added NetBeans to our community and our community to the NetBeans community. So, it's an additive thing, not an either/or. I want to
emphasize that Eclipse is a very strategic play for us. The JBoss IDE is based on Eclipse, the rules contributions for the IDE are all Eclipse plug-ins. So, Eclipse is still very important.
That being said, NetBeans is also an important community. It's got neat technology in there, particularly as it revolves around some of the Web services stuff. We're an open community and
we welcome all comers and the more development tools the better. So, I believe that it's a matter of choice and the fact that we can bring the JBoss ecosystem and open it, have that
available to Eclipse or NetBeans developers, that's great news. It's a win, win deal.
For a conference of 8,000 or more software developers and gear-heads I would think that conference producers would be better prepared.
Entry to the meeting rooms is now controlled with an identity card scanner that seemed to need fairly frequent software engineering maintenance. In years past the only line was for the
opening morning keynote. At JavaOne 2006 attendees had to wait in long and ill-managed lines for every popular session. I found little or no WIFI coverage in the sessions. Not good for a
conference that costs $2000 to attend.
Last year's JavaOne hosted many sell-out sessions on the Java Business Integration (JBI, JSR 208.) This year Sun is hosting the
"Horizons Summit," in parallel to JavaOne. As a consequence I have heard little if no discussion from developers about JBI,
SeeBeyond, or the Sun Composite Application Platform Suite (Sun CAPS) at JavaOne.
Schwartz told reporters at a press conference that Sun does not expect to market vertical applications built with the Sun CAPS.
Schwartz told reporters that Sun is in the business of creating the programming interfaces and underlying platform and it expects developers to build the applications.
PRINTER FRIENDLY VERSION
|
