Book review: Software Security: Building Security in – Part I: Software Security Fundamentals

This is a review of the first part of the Software Security: Building Security in book.

Chapter 1: Defining a disciplineSecuritySoftwareBookCover

This chapter lands out the landscape for the entire book; the author presents his view on the today challenges in having secure holes free software.
In the today world, the software is everywhere, from microwaves oven to nuclear power-stations, so the “old view” of seeing the software applications as “black boxes” than can be protected using firewalls and IDS/IPS it’s not valid anymore.

And just to make the problem even harder, the computing systems and the software applications are more and more interconnected must be extensible and have more and more complex features.

The author propose a taxonomy of the security problems that can be affected the software applications:

  • defect: a defect is a problem that may lie dormant in software only to surface in a fielded system with major consequences.
  • bug: an implementation-level software problem; only fairy simple implementations errors. A large panel of tools are capable to detect a range of implementation bugs.
  • flaw: a problem at a deeper level; a flow is something that can be present at the code level but it can be also present or absent at the design level. What is very important to remark is that the automated technologies to detect design-level flows do not yet exist, through manual risk-analysis can identity flows.
  • risk: flaws and bugs lead to risk. Risk capture the chance that a flaw or a bug will impact the purpose of a software.

In order to solve the problem of the software security, the author propose a cultural shift based on three pillars: applied risk management, software security touchpoints and knowledge.

Pillar 1 Applied Risk Management

For the author under the risk management names there 2 different parts; the application of risk analysis at the architectural level (also known as threat modeling or security design analysis or architectural risk analysis) and tracking and mitigating risks as a full life-cycle activity (the author call this approach, the risk management framework – RMF).

Pillar 2 Software security Touchpoints.

Touchpoint it’s just a fancy word for “best practices”. Today there are best practices for design and coding of software system and as the security became a property of a software system, then best practices should also be used to tackle the security problems.Here are the (seven) touch points and where exactly are applied in the development process.

Security Touchpoints

Security Touchpoints

The idea is to introduce as deeply as possible the touch points in the development process. The part 2 of the book is dedicated to the touchpoints.

Pillar 3 Knowledge

For the author the knowledge management and training should play a central role in encapsulation and sharing the security knowledge.The software security knowledge can be organized into seven knowledge catalogs:

  • principles
  • guideline
  • rules
  • vulnerabilities
  • exploits
  • attack patterns
  • historical risks

How to build the security knowledge is treated in the part 3 of the book.

Chapter 2: A risk management framework

This chapter presents in more details a framework to mitigate the risks as a full lifecycle activity; the author calls this framework the RMF (risk Management Framework).

The purpose of the RMF is to allow a consistent and repeatable expert-driven approach to risk management but the main goal is to find, rank, track and understand the software security risks and how these security risks can affect the critical business decisions.

Risk Management Analysis steps

Risk Management Analysis steps

The RMF consists of five steps:

  1. understand the business context The goal of this step is describe the business goals in order to understand the     types of software risks to care about.
  2. identify the business and technical risks. Business risk identification helps to define and steer the use of particular technological methods for measuring and mitigating software risk.The technical risks should be identified and mapped (through business risk) to business goals.
  3. synthesize and rank the risks. The ranking of the risks should take in account which business goals are the most important, which business goals are immediately threatened and how the technical risks will impact the business.
  4. define a risk mitigation strategy. Once the risks have been identified, the mitigation strategy should take into account cost, implementation time, likelihood of success and the impact
  5. carry out required fixes and validate that they are correct. This step represents the execution of the risk mitigation strategy; some metrics should be defined to measure the progress against risks, open risks remaining.

Even if the framework steps are presented sequentially, in practice the steps can overlap and can occur in parallel with standards software development activities. Actually the RMF can be applied at several different level; project level, software lifecycle phase level, requirement analysis, use case analysis level.

Book review: Continuous Enterprise Development in Java

This is a very short review of the Continuous Enterprise Development in Java book.

The book can be easily split in two parts.

The first part of the book from chapter 1 to chapter 4 javaArguillian contains general information about the difficulty of testing the JEE applications, about the software development cycles, the types of testing and some more technical details about the testing frameworks (JUnit and TestNG), about build tools like Maven and (JBoss) Forge, about version control (only Git deserves a paragraph) and (finally) about the Arquillian which is presented as “an innovative and highly extensible testing platform for the JVM”.

A very nice introduction is done to the ShrinkWrap  which is an API to create programmatically deployable JEE archives (jars, wars, ears).

An entire chapter (Chapter 3) is dedicated to write and deploy some business code and the associated Arquillian tests. Almost all the tools used in this chapter are JBoss or RedHat tools; Forge for the build of the application, JBoss Application Server to deploy the application, JBoss Developper Studio to deploy on the (Red Hat) OpenShift cloud service.

The second part of the book from chapter 4 to chapter 12 contains the implementation of the http://geekseek.continuousdev.org/app/root/show application, which is the JEE application. Every chapter is treating one aspect of the application: chapter 5  treats the persistence layer, chapter 6 the integration with NoSql data bases, chapter 7 the services layer, chapter 8 the REST services, chapter 9 the security, chapter 10 the user interface and chapter 11 the deployment on live.

Every chapter follow the same pattern, it starts with an introduction to the technology that will be used within the chapter, then the use cases and the business requirements are presented then it follows the implementation of the requirements and lastly the testing of the implementation using Arquillian.

I will conclude my ticket with a few points about what i like and what i don’t like about this book.

What i like about this book:

  • The author clearly masters the different JEE components; the technology introduction paragraphs of each chapter of the second part of the book are very clear and easy to understand.
  • The author knows the Arquillian framework inside out; all the examples are well explained and the introduction to ShrinkWrap is very well done.
  • Some of the chapters contains very valuable external references, like PicketLink for the security or Richardson Maturity Model for REST.

What i do not like about this book:

  • Too much marketing of the RedHat/JBoss products; I would have preferred to have more vendor agnostic examples of use for the Arquillian framework.
  • The subtitle of the book is “Testable Solutions with Arquillian” so it suppose to focus more on the testing part of the applications. Unfortunately, for me the book is not focusing on testing the applications but rather tries to  present how to continuously develop (JEE) applications and integration testing is only one part of this.
  • Nothing is said about the integration of Arquillian with other Java (non JEE) projects/frameworks like Spring and Guice and how Arquillian could ease (if it it can) the testing of the applications using these frameworks.

Book review: Basics of Web Hacking (Tools and Techniques to Attack the Web)

This is a review of The Basics of Web Hacking: Tools and Techniques to Attack the Web.

Chapter 1: The basics of Web Hacking

basicsOfWebHacking

The chapter starts with a quick introduction to some fundamental notions of web development like web applications, web servers, http protocol and a quick presentation of 2 penetration testing methodologies: The Open-Source Security Testing MethodologyManual (OSSTM) and Penetration Testing Execution Standard (PTES).

Then the author explains how the book is structured; the book will present attack vectors  around three type of targets: web server, web application and the web user and for every  type of target the same steps will be followed:

  1. Reconnaissance
  2. Scanning
  3. Exploitation
  4. Fix

The last part of the chapter is dedicated to the creation of the testing environment. As testing environment the author uses the BackTrack 5 distribution on which Damn Vulnerable Web Application (DVWA)  is installed.
The installation procedure is slightly outdated, for a newer version you can check this blog entry.

Chapter 2: Web Server Hacking

This chapter is dedicated to the hacking of the first type of target: the web server; the chapter is constructed arround the 3 steps (actually 4, but the Fix step have a dedicated chapter) that should be follow in order to sucesfully attack a web server.

The reconnaissance step is made firsly manually using commands like host and  analysis of the robots.txt file. Once some basic data about the web server is gathered, the automatic step of the reconnaissance is fulfilled using the Nmap port scanner. The authors explains how the Nmap can be updated (in case your BackTrack distribution do not have the version 6 or later) and some basic scan commands are performed (some of the flags used by the nmap command like -O, -sV, -p are explained in detail).

The scanning step is fulfilled using the Nessus tool. For Nessus, the authors explains how to install the free version, configure, run a basic scan and interpret the results. The Nikto open-source scanning tool is also very briefly presented.

The exploitation step is fulfilled using the (well known) Metasploit framework. The author starts by introducing some basic terminology like vulnerability, exploit and payload and then he presents the use of Metasploit framework in  7 easy commands: search, use, show payloads, set payload, show options, exploit. In order to explain the Metasploit commands, the author uses a hunting game analogy; for example the search command is like reviewing all possible animals that you could target, the use command is like deciding what kind of animal to hunt, the show payload is like reviewing all possible gun types, etc…

Chapter 3: Web Application Recon and Scanning

The chapter is dedicated to the web application reconnaissance and scanning. The recon part have as goal to build a map of the target web site using a web proxy. A web proxy is a application that stands between the client browser and the web application and intercepts the . The recon part can be done using automated spidering (the application starts from a page and automatically finds and requests links, submits forms, and performs any allowed action) and a manual spidering (the human operator browse through the web site). The recon is handled using the Burp Suite.

The scanning part have as goal to discover vulnerabilities. A web proxy is capable to find vulnerabilities that are detectable by inspecting the clients requests and server responses like input-based vulnerabilities targeting the server side of the application (SQL injection, OS command injection and path traversal) or input-based vulnerabilities that target the client side (XSS). The scanning part is handled using the OWASP Zed Attack Proxy (ZAP) and the author also presents briefly the Burp Scanner which is only available in the pro version of Burp Suite.      

Chapter 4: Web Exploitation with Injection

This chapter is mainly dedicated to the SQL injection vulnerabilities and Operating System Command vulnerabilities. For the SQL injection the author explains in great detail what is the SQL and how this class of  vulnerabilities can affect the target web application. To find and expose this kind of vulnerabilities the author uses the Burp Proxy, Burp Repeater and the sqlmap tool (which is a SQL injection command line tool).

The second part of the chapter is dedicated to the Operating System Command vulnerabilities.  These types of vulnerabilities are  covered in less detail compared to the SQL injection. In order to demonstrate these types of vulnerabilities the DVWA application is used but no tools that are capable to find (or to help the user to find) this kind of vulnerabilities are presented. One interesting detail for this chapter is this page containing one-liner reverse shells.

Chapter 5: Web Exploitation with Broken Authentication and Path Traversal

The author tries to broke the (web application) authentication using 2 methods: a brute force attack and an attack on the cookies generated by the web application.

For the brute force attack, a normal authentication attemp is initially intercepted  using Burp Intercept in order to find the parameters (username name and password) used for the authentication. Once this parameters have been found, the Burp Intruder product is configured to execute (repetitively) the authentication with different usernames and passwords; these usernames and passwords (called payloads) are read from external files.  The attack on the cookies it’ around the randomness of the session identifiers and the test it’s done using the Burp Sequencer product.

The last part of the chapter is dedicated to the path traversal attacks. The theorethical  part of this kind of attacks is very good covered but (as for the OS command vulnerabilities) no tool that can discover this kind of vulnerbilities is presented.

Chapter 6: Web User Hacking

This chapter is a (very) light introduction to the Cross-Site Scripting (XSS) vulnerabilities, Cross-Site Request Forgery (CSRF) vulnerabilities and to the social engineering vulnerabilities.

The good part about this chapter is that the author gives very good explanations about how this kind of attacks are triggered by the bad guys: it gives very good explanation about the difference between the XSS and CSRF vulnerabilities, it explains what is the different between a reflected and a stored XSS attack, it also gives good (web sites) references  http://XSSed.org , OWASP XSS Filter Evasion Cheat Sheet , http://www.social- engineer.org/).

On the less good part, the author do not explains how the attacker can exploit the info gathered from an XSS attack (he just says that the attacker can retrieve the user cookie using a Java script call like document.cookie).

Chapter 7: Fixes

This chapter is about how to fix the vulnerabilities presented in the previous chapters. The chapter is articulated around the same 3 possible targets: web serverweb application and the web user.

For the web server, the author proposes some strategies for server hardening: develop a repeatable hardening process, develop a process for deploying all new software updates and patches in a timely manner to the live systems, running scans and doing audits.

For the web application and the web user, the author proposes some sort of “to do” list for almost every kind of vulnerability (for example for the “Injection vulnerabilities” here is the list of things to do: Use parameterized queries, Escape malicious syntax, Make use of stored procedures, Remove unnecessary functionality on your database server, Encrypt sensitive dat).

Chapter 8: Next Steps

This small chapter contains some ideas in order to extend your knowledge regarding the security topics; what are the security grouse and events, what are the existing (security)certifications and some titles of security books.

(My) Conclusion

If you have no prior knowledge, this is very good introductory book in the web security topics; the writing style is clear and easy to follow.

Book review: Hacking – the art of exploitation, 2-end edition

This is a review of the Hacking – the art of exploitation, 2-end edition book.hck2ed

Chapter 0x100 Introduction

Very short chapter (2 pages and 1/2) in which the author gives his definition of a hacker; person that find unusual solutions to any kind of problems, not only technical problems. The author also expresses very clearly the goal of his book: “The intent of this book is to teach you the true spirit of hacking. We will look at various hacking techniques, from the past to the present, dissecting them to learn how and why they work”.

Chapter 0x200 Programming

The chapter is an introduction to C programming language and to assembler for Intel 8086 processors. The entry level is very low, it starts by explaining the use of pseudo-code and then very gradually introduces many of the structures of the C language: variables, variables scopes, control structures, structs, functions, pointers (don’t expect to have a complete introduction to C or to find advanced material).

The chapter contains a lot of code examples very clearly explained using the GDB debugger. Since all the examples are running under Linux, the last part of the chapter contains some basics about the programming on Linux operating system like file permissions, uid, guid, setuid.

Chapter 0x300 Exploitation

This chapter it builds on the knowledge learned in the previous one and it’s dedicated to the buffer overflow exploits. The most part of the chapter treats the stack-based buffer overflow in great detail using gradual complexity examples. Overflow vulnerabilities on other memory segments are also presented, overflows on the heap and on the BSS.

The last part of the chapter is about format string exploits. Some of the string vulnerabilities use specific GNU C compiler structures (.dtors and .ctors). In almost all the examples, the author uses the GDB to explain the details of the vulnerabilities and of the exploits.

One negative remark is that in some of the exploits the author use shell codes without explaining how these shell codes have been crafted (on the other side an entire chapter is devoted to shell codes).

Chapter 0x400 Networking

This chapter is dedicated to the network hacking(s) and can be split in 3 parts. The first part is rather theoretical, the ISO OSI model is presented and some of the layers (data-link layer, network layer and transport layer) are explained in more depth.

The second part of the chapter is more practical; different network protocols are presented like ARP, ICMP, IP, TCP; the author explains the structure of the packets/datagrams for the protocols and the communication workflow between the hosts. On the programming side, the author makes a very good introduction to sockets in the C language.

The third part of the chapter is devoted to the hacks and is build on the top of the first two parts. For the  package sniffing hacks the author introduces the libpcap library and for the package injection hacks the author uses the libnet library (ARP cache poisoning, SYN flooding, TCP RST hijacking). Other networking hacks are presented like different port scanning techniques, denial of service and the exploitation of a buffer overflow over the network.  In most of the hacks the authors it’s crafting his own tools but sometimes he uses tools like nemesis and nmap.

Chapter 0x500 Shellcode

This chapter is an introduction to the shellcode writing. In order to be injected in the target program the shelcode must be as compact as possible so the best suitable programing language for this task is the assembler language.

The chapter starts with an introduction to the assembler language for the Linux platform and continues with an example of a “hello word” shellcode. The goal of the “hello word” shellcode is to present different techniques to make the shellcode memory position-independent.

The rest of the chapter is dedicated to the shell-spawning(local) and port-binding (remote) shellcodes. In both cases the same presentation pattern is followed: the author starts with an example of the shellcode in C and then he translates and adapts (using GDB)  the shellcode in assembler language.

Chapter 0x600 Countermeasures

The chapter is about the countermeasures that an intruder should apply in order to cover his tracks and became as undetectable as possible but also the countermeasures that a victim should apply in order reduce or nullify the effect of an attack.

The chapter is organized around the exploits of a very simple web server. The exploits proposed are increasingly complex and stealthier; from the “classical” port-biding shellcode that can be easily detected to more advanced camouflage techniques like forking the shellcode in order to keep the target program running, spoofing the logged IP address of the attacker or reusing an already open socket for the shellcode communication.

In the last part of the chapter some defensive countermeasures are presented like non-executable stack and randomized stack space. For each of this hardening countermeasures some partial workarounds are explained.

Chapter 0x700 Cryptology

The last chapter treats the cryptology, an subject very hard to explain to a neophyte. The first part of the chapter contains information about the algorithmic complexity, the symmetric and asymmetric encryption algorithms; the author brilliantly demystifies the operation of the RSA algorithm.

On the hacking side the author presents some attacks linked to the cryptography like the man-in-the-middle attack of an SSL connection (using the mitm-ssh tool  and THC Fuzzy Fingerprint) and cracking of passwords generated by Linux crypt function (using dictionary attacks, brute-force attacks and rainbow tables attacks).

The last part of the chapter is quite outdated in present day (the book was edited in 2008) and is dedicated to the wireless 802.11 b encryption and to the weaknesses of the WEP.

Chapter 0x800 Conclusion

As for the introduction chapter, this chapter is very short and as in the first chapter the authors repeats that the hacking it’s state of mind and the hackers are people with innovative spirits.

(My) Conclusion

The book it’s a very good introduction to different technical topics of IT security. Even if the author tried to make the text easy for non-technical peoples (the chapter about programming starts with an explanation about pseudo-codes) some programming experience is required (ideally C/C++) in order to get the best of this book.

Book review: Foundations of Security (Part 3 Introduction to Cryptography)

Chapter 12:  Symmetric Key Cryptography

The chapter starts with an introduction to cryptography that consists in explaining some notations and terminology. Then the block ciphers are explained and the following algorithms are introduced:

The second part of the chapter introduce the stream cyphers and as examples the One Time Pad and RC4.

Chapter 13: Asymmetric Key Cryptography

This chapter explains how the asymmetric key cryptography algorithms are working and briefly explains the RSA and Elliptic Curve Cryptography (ECC) algorithms; it also highlights one of the most important problem of the asymmetric key algorithms which is the public key creation and exchange.

Chapter 14: Key Management and Exchange

Key management refers to the process by which keys are generated, stored, agreed upon and revoked. The chapter is structured on 3 parts:

  • Key generation (how should new keys be created). For the key generation the authors focus on securely generating random numbers by using the C rand() function, using the Random APIs (CryptGenKey library or java.security API) or random device files.
  • Key Storage (how should keys be securely stored so that they cannot be easily stolen). The authors propose some solutions and starts from non secure storage “platforms” (as storing the keys into the compiled code or to a disk) until more secure “platforms” as external devices like smart cards, Hardware Security Modules (HSM).
  • Key agreement and exchange (how should to or more parties decide on a session key used to protect the confidentiality of their conversation). The authors present two ways that can be used to initiate a conversation:
    • generate a cryptographically random conversation key and  encrypt it with a public key
    • use Diffie-Hellman key exchange protocol

Chapter 15: MACs and Signature

This chapter presents Message Authentication Codes (MACs) and digital signatures. A MAC is  sequence of bits that can be attached to a message to verify where is originated and that is has not been tampered with. For MACs construction the authors present the following algorithms CBC-MAC and HMAC.

Chapter 16: Exercises for Part 3

As usually this chapter contains some questions and problems in order to test the comprehension of the notions discussed in the chapters 12-15.

(My) Conclusion

For me the book fulfill his goal: to present in a (rather) clear and concise way the fundamental notions about the security but what I disliked to this book is the writing style which I find it rather difficult to follow sometimes.

Book review: Foundations of Security (Part 2 Secure Programming Techniques)

Chapter 5: Worms and other malware

This chapter present some “famous” worms that had major impact on the security industry.  Every worm presented in the chapter had used one of the security holes that will be presented in the following chapters: Morris worm (buffer overflow of the finger daemon server), the Code Red worm ( buffer overflow of the II Server), the Nimda Worm (buffer overflow of the II Server and infection using the web browser), the Blaster worm (buffer overflow of the DCOM), the SQL Slammer (buffer overflow of the SQL Server).  The authors also presents definitions of another types of malware like rootkits, botnets, spywares, keyloggers, adware, trojan horses, clickbots.

Chapter 6: Buffer Overflows

This chapter threats the buffer overflow vulnerabilities; a very small example (written en C) is presented and explained then the possible solutions to this problem are enumerated and explained :

The end of the chapter presents another types of memory corruption vulnerabilities:

Chapter 7: (Web)Client-State Manipulation

The goal of this chapter is to present how a malicious user can pass to a web server modified requests. The example used as example is a pizza ordering web site which accepts GET requests containing sensitive information as the price of pizzas or the number of bought pizzas.  The attack scenario consists in modifying the values of the parameters sent to the server (ex: by 10000 pizzas at the price of 0 $).  The possible solutions to this kind of attack would be :

  • sensitive information stays on the server. Don’t send sensitive information to the client, send only an id (session id) identifying the client sensitive informations. Another technique is to send to the client a signature of the session in order to prevent the tampering of the session if by a (malicious) client.
  • do not use HTTP GET but use HTTP POST. The HTTP POST use can be combined with the use of cookies and or use of JavaScript.

The main idea of this chapter is  web application should never trust the clients and should always validate the clients input.

Chapter 8: SQL Injection

Using the same example as in the previous chapter (the pizza ordering web site) the authors explains the anatomy of a SQL injections attack and then they propose various solutions to this kind of attacks. The proposed solutions are:

Chapter 9: Password Security

This chapter goal is to present some of the techniques used by a password management system in order to reduce the impact of an attack. The authors will prove some of these techniques by implementing a mini-password manager that can be plugged-in into the toy web server (presented in Chapter2 :Secure Systems Design) for authenticate the users . The mini-password manager implementation starts by a straw man proposal, the users and passwords are stored into a property file. The following state is to replace the passwords by hashed versions. In order to mitigate the dictionary attacks a “salt” is added at every password. At the end of the chapter, the authors briefly presents additional security techniques :

  • password filtering (if a user choose a password that is in the dictionary or identified as easy to guess then must require to the user to choose another one).
  • limited logging attempts (the user have a limited number of login attempts before the account is locked or disabled)
  • aging passwords (the users are forced to change the passwords after a certain time)
  • one time passwords

Chapter 10: Cross-domain Security in Web Applications

This chapter starts by explaining some concepts linked to the web application security; same policy origin, Http Request Authentication, lifetime of the cached cookies and the the HTTP Authentication credentials. Then, some attack patterns are presented in detail:

The last part of the chapter presents the solutions for preventing each of the attack patterns.

The proposed solutions for the XSRF are:

  • inspecting the Http referrer headers (not a complete solution since the Http headers can be modified on the fly )
  • validation of the Http user forms via a user-provided secret (every Html form contains an additional field representing the user password; not very user friendly)
  • validation of the Http forms using an Action Token (in order to distinguish “genuine” instances of forms from ones that were forged by a third party, a token is included as a hidden field in the form. The main difficulty is to find a generation schema in order to be impossible for a third party site to generate valid tokens)

Solutions for preventing the XSSI are:

  • use an Acton Token (s in the case of XSRF)
  • restrictions to form submission only using Http POST

Solutions for preventing XSS are :

  • HTML escaping (any string that is possibly derived from untrusted data and is inserted into an HTML document must be HTML-escaped).
  • HTML tag attributes (form fields attributes, URL attributes, JavaScript-valued attributes) must be quoted.
  • use of HTTP-only cookies (cookies that will no be exposed to client-side scripting)
  • bind Session cookies to IP address

Chapter 11: Exercises to part 2

As for the first part, this chapter contains questions and exercises in order to “walking the walk not just talking the talk”.

Book review:RESTful Web Services (chapters 1-5)

While I reading a book, I like to make a summary of every chapter, it force me to find and highlight the main ideas.  This post is about RESTful Web Services book.

Chapter 1: The Programmable Web and Its Inhabitants

This chapter is a global introduction to web services. The author introduce 3 types of web services architectures using the following criteria:

  • how the web service clients send to the server the action that should be done. This kind of information is called “method information”
  • how the web service clients send to the server on which data the server must work to compute an answer.This kind of information is called “scoping information”.

Using these two criteria, the web services can be of three types:

  • Remote Procedure Call (RPC) web services. In this case the “method information” and the “scoping information” are stored into a SOAP envelope and the HTTP envelope is used only to transport the SOAP request/response.
  • Resource Oriented (RESTful) web services. In this case the “method information” goes into the HTTP method. If the client wants to retrieve some information the GET HTTP method is used, the DELETE HTTP method is used if it wants to delete some infornation, etc.. The “scoping information” goes into the URI path.
  • Hybrid web services. Some parts of hybrid web services are RESTful (in most cases, the parts that implies the retrieving of the information from the server) and some other parts are RPC style.

Chapter 2: Writing Web Service Clients

The goal of this chapter is to write web service clients in different programming languages against the del.icio.us web service.
So, any basic web service client must follow the next steps for fulfill his mission:

  • create the HTTP request containing the request for the server.
  • parse the response of the server.

For every step of the work flow, the author presents code samples for the following languages (Ruby, Python, Java, PHP, C# and JavaScript).

For the first step of the work flow (the creation of the HTTP request) a detailed explanation of external libraries that are used by the web service client is made. For the Ruby language, the rest-open-uri is used; for the Python the httplib2 (http://bitworkin.org/projects/httplib2/) is used; for the Java the Jakarta HttpLib (http://jakarta.apache.org/commons/httpclient/) is used; for C# the standard System.Web.HTTPWebRequest is used; for PHP the libcurl is used.

For the parsing part (the second step of the work flow) the different kinds of parsers are explained: DOM parsers, SAX parsers and “pull” parsers.

Chapter 3: What Makes RESTful Services Different?

In this chapter the author creates a client for a real REST web service. The REST service used is the S3 Amazon web service. S3 is based on two concepts: S3 “buckets” and S3 “objects”.An object is a named piece of data with some accompanying metadata. A bucket is a named container for objects.
To prove that S3 is a RESTful web service here are the resources and their method:

  • the bucket list(/); use GET
  • a bucket(/{bucket}); – use GET to list he bucket objects
  • use POST to create the bucket
  • use DELETE to delete the bucket
  • an object(/{bucket}/{object}); – use GET to list the object metadata and value
  • use HEAD to get the object’s metadata
  • use PUT to set the object’s values and   metadata
  • use DELETE to remove the object from the bucket

Chapter 4: The Resource-Oriented Architecture

For the author the ROA (Ressource Oriented Architecture) is an architecture that follow the RESTful criterias applied the world wide web. So, ROA is REST for WWW.
The ROA contains four concepts:

  • resources
  • resources names (URIs)
  • resource representations
  • the links between resources

and four properties:

  • addressability
  • statelessness
  • connectedness
  • a uniform interface

The heart of ROA are the resources, a client will create, read, update and delete resources.A resource can be anything, with the condition to be addressable by Web, so any ROA resource must have at least one URI. The relation between resources and URIs is one to many, a resource can be addressable by many URIs but a URI addresses only one resource. The statelessness is quite easy to assure because the HTTP protocol is stateless by default and every state needed should be handled by the application not by the REST service.
The resources can be presented in multiple forms, “simple” information (i asked a photo from a service or a text file) or “complex” information that can contains HTTP forms and, or HTTP links.

As in the case of a programming API, the way of working with the resources should be universally accepted. On a resource it is possible to execute 4 actions, CRUD (Create Read Update Delete). ROA uses the HTTP basic methods as an interface for the actions to execute on the resources:

  • HTTP GET is used to retrieve a representation of a resource
  • Create a new resource: HTTP PUT to a new URI and HTTP POST to an existing URI
  • Modify an existing resource: HTTP PUT to a existing URI
  • Delete an existing resource: HTTP DELETE

Chapter 5: Designing Read-Only Resource-Oriented Services

The procedure of creating a read-only resource-oriented service contains the following steps:

  • Analyze the data set to be exposed s read-only resource
  • Split the data set into resources

For each resource:

  • Name the resources with URIs
  • Design the representation served to the client
  • Link the resource with other resources using hyper links and forms
  • Consider the typical course of events
  • Consider the error conditions: what to send to the client when the things goes wrong.

To show how all this criterias can be applied the author takes as example a service that serves informations about maps. The main difference between this service and the real world web application is that this service main clients will be other web services not only a human user.

The data set of the service will be maps, points of the maps, points having specific properties (name, description, place type).Basically the service will expose 2 kinds of resources: predefined data set (the USA country, the Paris city, any point an a map by the coordinates) and algorithmically-generated resources(towns in France with population less than 10 000, pizza restaurants near Mount Rushmore).
Now that we have the resources that we want to expose,it must find a way of naming the resources in order to be accessible by the clients. As we already said, the ROA use the WWW to make available the resources (see the review of the previous chapter) so the names will be based on URIs.
The organize the resource as URIs the following rules are used:

  1. To encode an hierarchy the path variables will be used. ex: /parent/child
  2. To encode resource that are not hierarchical the punctuation characters are used. ex: /parent/child1;child2
  3. For the algorithmically-generated resources the query variable are used. ex: /search?query=country=france&population=1000

The sources are represented as XHTML documents that can be very easy interpreted by a browser in order to be used by a human and also by another web service. When a client is asking for a resource, the service sends an XHTML document containing more than the URI of the resource; the response can contains another URIs (places that are around the resource) or another type of informations like the description of the resource. In the case of algorithmically-generated resources, a HTML form is used to send to the service the parameters needed to compute the resource.

To inform the client about the state of the resource that he asked the standard HTTP headers are used. A 200 (“OK”) code response code means the resource was found, codes like 500 (“Internal Server Error”) will inform the client that the server have a problem, 404 (“Not Found”) code will inform the client that a place does not exist and a 400 code. The main idea is that it is possible to ‘play’ with the variety of HTTP response codes to send to a client a “business tailored” responses.