<< What types of attacks do you need to be aware of when you're
building applications to SOA using Web Services? As it turns out, the
key aspects that make your SOA more successful - the ability for
developers across your departments and trading partners to be able to
find applications exposed as services, and the way that WSDL documents
define operations that can be invoked - may also make it appealing to
hackers.
Here are some potential vulnerabilities:
* Authentication/authorization. Without the appropriate mechanisms
in place, anyone can access a service, invoke it, and perform
sensitive operations even if he's not authorized. More often what
typically happens is that it takes a while to de-authorize entities
from accessing systems. In the meantime, they have free rein. Identity
Management and Web Services Management (WSM) solutions, and XML
firewalls can help.
* Spoofing. Gaining access to a system by using a stolen identity.
If you log and audit service interactions, operations employees can
identify who did what and when in the event of a spoof.
* Tampering. Unauthorized modification of data, such as header
information including WS-Addressing, as it flows over the network.
Digital signatures, which are based on the message, ensure message
integrity. Another form of tampering takes the form of JavaScript that
alters the contents of the XML document and can redirect the
communication from the Web browser.
* Repudiation. Users (legitimate or otherwise) may deny that they
made specific transactions. Logging and auditing capabilities address
this.
* Information disclosure. The unwarranted exposure of private data
when on the wire. Encryption helps ensure confidentiality but doesn't
ensure message integrity.
* Denial of service. Making an application unavailable by sending
a huge number of requests or very large XML payloads. (This is a
problem only if it breaks your application!) XML firewalls and
appliances let you protect your services from such attacks.
* Invalid messages. Certain XML messages can contain malicious
code such as SQL statements, viruses, or worms that can compromise or
corrupt data, applications, and systems, and potentially leave them
exposed. This code can appear in the body of the XML document or in
CDATA tags. Hackers tamper with the SOAP messages themselves to
disable the service through illegitimate or malformed requests.
* Replay attacks. If tokens/cookies are used for secure
conversation, the attackers can capture the tokens/cookies and re-use
them later by replaying the same.
* XML routing detours/external referencing. XML documents can
contain references to external structures.
You'll recognize many of these items, as they equally apply to both
Web Services and Web applications.
A Holistic Approach To Protecting Services
To protect against these potential vulnerabilities, you should take a
holistic approach to security that includes infrastructures, tools,
and software development practices:
* Protect services from the outside at deployment time by using
WSM solutions. This addresses issues related to identifying the
message sender, authentication, authorization, ensuring message
security, and verifying the structure of SOAP headers and XML
documents. Security policies can be applied to both inbound and
outbound service interactions. Don't worry about these: Your WSM
infrastructure sits outside your service and takes care of them for you.
* Protect services from the inside by building security into your
software development process. You must validate the input in your code
to protect yourself against attacks that result from invalid messages.
By validating the content of XML documents, you address attacks that
result from invalid messages, such as buffer overflow, SQL injection,
XML injection, and XPath exploits. Use static analysis tools to help
identify such vulnerabilities.
* Simulate known attack patterns and fix vulnerabilities before
going live by using dynamic analysis tools in a running deployment
during the QA process. By putting the attackers' hat on and
stress-testing your SOA applications, you can help uncover and resolve
vulnerabilities before deployment. Although you may have to work a
little harder during the QA process, you'll get fewer post-deployment
headaches, which more than makes up for it.
* Monitor post go-live using monitoring dashboards (part of WSM
solutions) that present data that's collected as security policies are
executed on services. These dashboards let administrators monitor
compliance with IT operational best practices in real-time, such as
audits on security violations on a per-Web Service, per-operation, and
per-client basis. To address vulnerabilities, administrators can
configure operational rules and propagate them to the appropriate
enforcement components across an application deployment of any scale
and complexity in real-time.
Let's look at all of these except monitoring (since the latter is more
operationally focused).
Protecting Services from the Outside
Most Web Services are based on the same technology as the Web, namely
HTTP. As a result, all common technologies used to secure the Web,
such as Web authentication and SSL, work equally well with Web
Services - for point-to-point security. With SSL alone, you can do
authentication (the communication is established between two trusted
parties); confidentiality (the data exchanged is encrypted); and,
message integrity (the data is checked for possible corruption).
However, solutions such as SSL are a little heavy-handed since they
secure the entire channel. Furthermore, for many message-based
interactions, intermediary steps are required before the messages
arrive at their target endpoint. This leaves XML messages unsecured at
each intermediary checkpoint - exposed to tampering, information
disclosure, and message altering.
To get a finer level of control and avoid intermediary security
issues, it's best to secure the message rather than the complete
transport. The idea is to replace SSL capabilities with message-level
security, where the security information is carried in the message
itself. This way, unless the intermediary or endpoints have the
correct security infrastructure in place and are trusted, the message
will remain secure and unreadable and can be forwarded to the next
endpoint.
So how do you secure the message rather than the transport?
WS-Security defines a mechanism for adding three levels of security to
SOAP messages:
1. Authentication tokens. WS-Security authentication tokens let the
client provide a user name and password or X509 certificate for the
purpose of authentication headers.
2. XML encryption. WS-Security's use of W3C's XML encryption
standard enables the XML body or portion of it to be encrypted to
ensure message confidentiality.
3. XML digital signatures. WS-Security's use of W3C's XML digital
signatures lets the message be digitally signed to ensure message
integrity. The signature is based on the content of the message itself
(by applying the hash function and public key), so if the message is
altered en route, the signature becomes invalid.
A final thought on this - don't forget that you can use transport and
message-level security together, e.g., use a WS-Security Username
token without encryption and use SSL to encrypt the transaction.
There are two ways to implement this: You can embed the logic for
processing tokens, handling encryption, and applying hash functions
and digital signatures in the service implementation itself, or you
can use a WSM solution. The first option is shown in Figure 1.
WSM solutions intercept incoming and outgoing service communications
and apply a set of policies in a pipeline fashion, including
authentication, authorization, decryption, signature validation, and
XML schema validation. They move the active enforcement of the
policies and agreements to the boundaries of an application, letting
the application developer concentrate on the business logic. These
solutions typically provide a policy management tool for building new
security and operations policies, storing policies, and managing
distribution and updates to runtime policy enforcement points. In this
way, policies are defined and changed centrally but enforced locally.
If you have to authenticate to an Identity Management System that's
not supported by the WSM solution out-of-the box, such as a JAAS login
module, Oracle Web Services Manager, as well as many WSM products,
provides an SDK for developing policy steps. They provide operational
dashboards for monitoring policies as they execute to ensure service
levels, incorporating alerts so corrective actions can be taken in a
timely fashion.
WSM solutions typically provide two types of enforcement components
and policy enforcement points: Gateway and Agents. Gateways are
deployed in front of a group of applications or services. They can
intercept inbound requests to these applications to enforce policy
steps, adding application security and other operation rules to
applications that are already deployed. They also allow (or deny)
inside users access to predetermined outside services. Agents provide
an additional fine-grained level of security by plugging directly into
an application or service.
Service virtualization is also a key capability. Typically an Internet
user makes a service request using a username and password
combination, but the service may be expecting a SAML assertion. With a
WSM solution, you can have a gateway on the requester side that
intercepts the request, authenticates the user with the username/
password combination, and inserts a SAML assertion that can be
validated at the service by a WSM agent. In effect, the user calls a
service in a virtual way through the credentials that he knows, not
the credentials that the Web Service is expecting.>>
You can read the article in full at:
http://java.sys-con.com/read/232071.htm
Gervas
------------------------ Yahoo! Groups Sponsor --------------------~-->
You can search right from your browser? It's easy and it's free. See how.
http://us.click.yahoo.com/_7bhrC/NGxNAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
