Monthly Archives: October 2004

Applied XML Developer’s Conference Session Summary

Posted on by

Now that the conference is over, here’s a quick reference to my session-by-session posts:

  1. Applied XML Developer Conference
  2. AXDC – Chris Anderson – “Developers Hate XML”
  3. AXDC – Cauldwell and Hanselman – Legacy Financial Systems
  4. AXDC – Lunch
  5. AXDC – Don Box and WS-Why?
  6. AXDC – Whit Kemmey, XML for Naval Missile Systems
  7. AXDC – Sam Ruby, IBM
  8. AXDC – Daniel Cazzulino, Schematron
  9. AXDC – Kurt Cagle, XSLT2 and Saxon.Net
  10. AXDC – Tim Ewald, WS-Hope
  11. AXDC – Rich Salz, Tightly Coupled Security for Loosely Coupled Web Services
  12. AXDC – Doug Purdy – Versioning
  13. AXDC – Jeff Barr – Amazon Web Services
  14. AXDC – Neetu Raipal, XML in Visual Studio 2005
  15. AXDC – Blair McKay, EDI to XML
  16. AXDC – Keith Brown, Web Services Security Tips
  17. AXDC – Time to go

AXDC – Keith Brown, Web Services Security Tips

Posted on by

Keith Brown will talk about security in a web services context.

“Admins were right not to trust us; we wrote a bunch of really shitty code.” Audience member notes that we need to take pride in what we do. Amen!

Its a matter of getting in to the right mindset so that you can recognize (and repair) potential vulnerabilities.

  1. Less is more – less parts, less code, less privilege, less security code to have to write (as in more should be in the platform).
  2. Newer is often not better – In cryptography, new things are not trusted for a long time. Bruce Schneier’s Crypto-Gram newsletter was cited; I just suscribed.
  3. Trust no input – not from the user, not from a web service request, not from a web application request, not in a cookie. SQL injection, printf strings. Look at code and think “how could comebody break in?” Anytime you take input from the outside world, you absolutely need to think about this. Filter the data, accept only things that are in accord with rules and expectations. Attackers give you “finely crafted garbage.”
  4. You cannot authenticate remote software – It must have a secret, which can always be stolen or reverse engineered. It cannot be solved, so don’t try to!
  5. What your program knows, an attacker can discover. References Schneier’s book, Secrets and Lies : Digital Security in a Networked World. Detection countermeasures are very worthwhile.
  6. Understand trust – Federation, linking up companies.
  7. Wetware is unreliable. Kevin Mitnick’s book – The Art of Deception: Controlling the Human Element of Security. WS-Security and tokens; cleartext passwords and IPasswordProvider. One-way hash is one solution.
  8. You probably need a longer key – Creating an RSA key pair with a 4K key length takes a long time. 2K is the mininum. “Selecting Cryptographic Key Sizes” (Link to PDF), Lenstra & Verheul. To get 128 bits of security you need more than 128 bits of key, due to the birthday paradox. Record enough packets encrypted with the same key, and you can start to ascertain patterns. Keys get weaker, the longer you use them.
  9. Availability is the third pillar –
  10. Find the weakest link – Use threat modeling. New book from Microsoft press: Threat Modeling (Microsoft Professional)

Books referenced in this talk:

Secrets and Lies : Digital Security in a Networked World The Art of Deception: Controlling the Human Element of Security Threat Modeling (Microsoft Professional)

AXDC – Blair McKay, EDI to XML

Posted on by

Using XML to take the headaches out of EDI processing!

EDI was an early alternative to fax and email. Standards-based. VAN’s (Value Added Networks).

Text format, but not friendly to text editors. Could be one line with hundreds of thousands of characters.

Why move to XML? Data is already hierarchical, easier, and once it in XML you can go anywhere with it. Trade complex single-use tools for generic tools.

AXDC – Jeff Barr – Amazon Web Services

Posted on by

Here are the links from my presentation.

To use the AWS and AWIS links, you will need a Subscription Id. Get one by registering as an AWS Developer.

AXDC – Rich Salz, Tightly Coupled Security for Loosely Coupled Web Services

Posted on by

Rich of Datapower will give them a Non-Microsoft perspective (as will I).

Protecting XML and web service servers at the network level by creating an XML-aware network. You can’t bolt-on security, you need to design it in.

XML/SOAP bypasses firewalls, by design.

Managing keys is a foreign concept for more people. Security resides in the key. These 56 or 124 bits are the most important part of the application.

Poor SSL performance without hardware acceleration.

Input validation errors — SQL injection buried inside of a SOAP call. “DROP FROM *”. Command execution, buffer overflows, directory traversals.

Asymetric denial of service. Use an HREF that points to itself.

SOAP traceroute with mustUnderstand set. Send these to a gateway and use it to map internals.

Interesting attack: Suppose that SoapAction is “foo.php”. Send “foo.php|ls -l” as the action. Perl SOAP used to be susceptible to this.

Perl package loading hole: :HTTP::Daemon::ClientConn::send_file(“|/etc/passwd”) !

Apache nuSOAP holes.

OS written by “local company” that was not designed to be hooked up to the internet (the audience totally missed this reference).

All written by engineers who know better!

XML External Entity Attack. Turn off DTDs or can retrieve local file contents.

All of these things work really well when there are no bad people around.

WSDL gives out a lot of information; .Net auto discovery and ability to guess service names are issues.

Outlined a multi-level stack of infrastructure components to guard against all of these attacks and vulnerabilities. XML-Aware Security Gateway, XML-Aware Proxies, Stateful Firewall, Layer 4 / Circuit Firewalls, IP Firewalls.

XML firewall should be a box, sitting on top of IP firewall. Should enforce XML well-formedness constraints, SOAP messaging schemas, application schemas, security policy, content-based routing. He notes that all of this firewalling should be done at the network level before the application sees a single byte!

Interesting to note that crypto is very expensive, and that digital signatures turn all other attacks into denial-of-service since the processing load is 5-20 times higher than for an unsigned message.

Firewall should be carrier grade, purpose-built, no attackable OS resources on the device to exhaust, easy to integrate.

Watch out for single-sign-on solutions. Shims are a bad idea. Watch for one-vendor total end-to-end solutions.

Create an XML security ecosystem.

AXDC – Tim Ewald, WS-Hope

Posted on by

At last night’s post-dinner speaker panel we pretty much heard from the audience and from the other panelists that things in the XML and web services world still kind of suck. An outsider looking in would certaintly wonder if anything worked all.

Tim is pointing out that things do actually work pretty well. I will do the same in my talk later today.

XML over HTTP vs. SOAP, the difference is not all that big, as once demo’ed by Sam Ruby. If we do things right then we can be ready for the future, and leverage the protocols. The cost to use SOAP is just an envelope and a body. The technologies overlap 98%. The tools do not overlap.

Some advice from his step-father: “Make it easy for people to pay you.”

His brother can build a house with a broadaxe and a forest, but that doesn’t mean its the best way to do it.

SOAP is the extensibility point, lots of it there for the future — addressability, security, etc.

In REST, the URI alone specifies what is to be done. In SOAP it is the action URI, or is it the action URI + message + endpoint? All of these can influence the interpretation of what is supposed to happen. Where are the semantics?

Establish contracts for services before starting on the implementation. Toolkit is an implementation detail. None of the schema languages are adequate yet.

People choose REST because it is easy, not because they believe in REST or in Fielding’s thesis.

Toolkits have to provide easy access to raw XML, and easy access to the wire. Consume XML in a stream for big documents (e.g. MSDN). Buffering and using a DOM can be very painful for big documents. Pay only for what you need.

With versioning, description is in the eye of the beholder.

Interoperability — a floor (base to build on), a ceiling (some limits), four walls, and no doors (no options). Tools don’t support much in the way of choice. Subsetting schema is like this.

Hope springs eternal, we are sooooo close. Just need reliable messaging and MTOM.