CGISecurity Logo

Article: Be aware of SOA application security issues

"Extensible Markup Language (XML), Web services, and
service-oriented architecture (SOA) are the latest craze in the
software development world. These buzzwords burn particularly bright in
large enterprises with hundreds or thousands of systems that were
developed independently. If these disparate systems can be made to work
together using open standards, a tremendous amount of time, money, and
frustration can be saved. Whether or not we are on the verge of a new
era in software, the goal alone is enough to make security people
cringe. It might be easy to glue System A and System B together, but
will the combination be secure?

Today, most discussions about Web services security focus on standards: from WS-Security and SAML down to SOAP
and even XML. While the standards are important, measuring the security
of a Web service requires looking past the standards and considering
all of the ways the system might fail. Attackers focus on a system’s
weak points, and a security assessment should do the same. Consider the
following:

  • Complex protocols might seem bloated or redundant.
    Skipping or changing steps might not create any problems for normal
    operation, but it could but jeopardize the security guarantees the
    protocol offers.
  • Application platforms that support Web services are
    incredibly flexible. In practice, that means they have incredibly
    complex configurations. Mistakes in these configuration files become
    vulnerabilities in the service.
  • Services are often built on top of legacy software that was
    not originally designed to operate as a service. Vulnerable code that’s
    never been exposed to the network before offers attackers new
    opportunities."

"Most people know better than to make up their own
cryptography, but a surprising number of programmers are still willing
to try their hand at a home-brewed authentication protocol. Last month
Google found out just what a bad idea that is. The single sign-on
protocol they used for Google Applications was derived from SAML, but
it left out a few seemingly unnecessary pieces of information from two
protocol messages. The result was a severe security flaw
that allowed a dishonest service provider to impersonate a user at
another service provider. The moral to this story is if you adopt a
standard, don’t stop at "good enough." Subtle vulnerabilities creep in
where standards compliance falls off.

Web service containers such as WebSphere, WebLogic, or .NET WSE are
amazingly versatile when it comes to Web services support, but what at
first might seem a blessing quickly turns into a nightmare for the
people who have to configure these systems. People stitch together
configurations from sample projects or flail until somehow their
service starts working. The result is service configurations that don’t
do exactly what the author intended." – TechTarget

Read More: http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1336174,00.html