Problem solve Get help with specific problems with your technologies, process and projects.

The differences in data validation

Web services security expert, Andrew Nash, explains the difference between data validation and Web services and Web applications.

How does data validation differ between Web services and Web applications?

The normal data validation for Web Applications is still required for Web Services. Buffer overflows and correct data type handling and matching along with all of the other forms of data validation problems are still a consideration. However, these have all been essentially quality issues for developers.

In the case of Web Services and XML we are dealing with a much more significant set of issues. At a low level we need to handle attacks based on XML schemas such as unbounded entity expansions or poor definition of the XML schema - these require smart XML analysis and parsers to detect such errors or attacks. The classic content based attacks such as SQL command injection require content based filtering and a range of attack signatures that allow these to be recognized.

Data privacy is an interesting special case here. As reuse occurs through our SOAs the challenge will be to control the final disposition of information and recognition of the origin. Passing personal identifying information from a new Web Service client located in the European Union has all sorts of privacy and governance issues associated with it, that the write of a Web Service may never have considered. To deal with such a case, content based filters that can distinguish what types of information may not cross particular internal boundaries are required. This is in fact exactly the type of filtering that an XML Security Gateway provides at a network level.

At a much higher level though are issues such as state modification attacks, transaction injection attacks or replay attacks. These are all specific issues that arise from a message driven architecture. Web Services using XML documents as idempotent messages store the transaction processing history and next processing step as state within the document - an unsigned message allows the state to be modified and therefore the next processing steps of the application to be modified. A well formed message with a correct identity that is signed may be captured in its entirety and replayed or re-injected in a different sequence in the form of an ordering attack. To deal with these issues, message signatures, sequence numbers, validity periods and state validation may all be required.

Dig Deeper on Topics Archive

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.