OWASP - User contributions [en]

Guide to Authorization

2007-06-09T16:55:11Z

Mylene: /* Best Practices */ typo

[[Guide Table of Contents]]__TOC__

Authorization ensures that the authenticated user has the appropriate privileges to access resources. The resources a user has access to depend on his/her role.

==Objectives ==

• To ensure only authorized users can perform allowed actions within their privilege level

• To control access to protected resources using decisions based upon role or privilege level

• To prevent privilege escalation attacks, for example using administration functions whilst only an anonymous user or even an authenticated user.

==Environments Affected ==

All applications.

==Relevant COBIT Topics ==

DS5 – All sections should be reviewed. This section covers nearly all COBIT detailed control objectives.

==Best Practices ==

If your application allows users to be logged in for long periods of time ensure that controls are in place to revalidate a user’s authorization to a resource. For example, if Bob has the role of “Top Secret” at 1:00, and at 2:00 while he is logged in his role is reduced to Secret he should not be able to access “Top Secret” data any more.

Architect your services (i.e., data source, web service) to query a user’s role directly from the credential store instead of trusting the user to provide accurate listing of their roles.

==Best Practices in Action ==

Continuing with the previous code, the following extends the code in the dbLogin method of the auth.cfc to return the user’s roles. The roles are passed to the <cfloginuser> to provide authentication to ColdFusion’s built-in login structure. The roles are also used to provide authorization to ColdFusion Components.

Auth.cfc

<cffunction name="dblogin" access="public" output="false" returntype="struct">

<cfargument name="strUserName" required="true" type="string">

<cfargument name="strPassword" required="true" type="string">

<cfset var retargs = StructNew()>

<cfif IsValid("regex", strUserName, "[A-Za-z0-9%]*") AND IsValid("regex", strPassword, "[A-Za-z0-9%]*")>

<cfquery name="loginQuery" dataSource="#Request.DSN#" >

SELECT userid, hashed_password, salt

FROM UserTable

WHERE UserName =

<cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">

</cfquery>

<cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>

<cfset retargs.authenticated="YES">

<cfset Session.UserName = strUserName>



<cfquery name="authQuery" dataSource="#Request.DSN#" >

SELECT roles.role

FROM roles INNER JOIN (users INNER JOIN userroles ON users.userid = userroles.userid) ON roles.roleid = userroles.roleid

WHERE (((users.usersid)='<cfqueryparam value=“#loginQuery.userid#” cfsqltype=”CF_SQL_INTEGER”>'))

</cfquery>

<cfif authQuery.recordCount>

<cfset retargs.roles = valueList(authQuery.role)>

<cfelse>

<cfset retargs.roles = “user”>

</cfif>

<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfelse>

<cfset retargs.authenticated="NO">

</cfif> ---><cfset retargs.authenticated = true><cfset retargs.roles = "Admin">

<cfreturn retargs>

</cffunction>

==Principle of least privilege ==

In security, the Principle of Least Privilege encourages system designers and implementers to allow running code only the permissions needed to complete the required tasks and no more. When designing web applications, the capabilities attached to running code should be limited in this manner. This spans the configuration of the web and application servers through the business capabilities of business logic components.

Far too often, web and application servers run at too great a permission level. They execute using privileged accounts such as root in UNIX environment or LOCALSYSTEM in Windows environments. When web and application servers run as root or LOCALSYSTEM, the processes and the code on top of these processes run with all of the rights of these users. Malicious code will execute with the authority of the privileged account, thus increasing the possible damage from an exploit. Web and application servers should be executed under accounts with minimal permissions.

The database accounts used by web applications often have privileges beyond those actually required or advisable. Allowing web applications to use sa or other privileged database accounts destroys the database server’s ability to defend against access to or modification of unauthorized resources. Accounts with db_owner equivalent privileges such as schema modification or unlimited data access typically have far more access to the database than is required to implement application functionality. Web applications should use one or more lesser-privileged accounts that are prevented from making schema changes or sweeping changes to or requests for data.

The J2EE and .NET platforms provide developers the ability to limit the capabilities of code running inside of their virtual machines. Often web applications run in environments with AllPermission (Java) or FullTrust (.NET) turned on. This limits the ability of the virtual machine to control the actions of code running under its control. Implementing code access security measures is not only useful for mitigating risk when running untrusted code – it can also be used to limit the damage caused by compromises to otherwise trusted code.

Finally, the business logic of web applications must be written with authorization controls in mind. Once a user has authenticated to the running system, their access to resources should be limited based on their identity and roles. In addition, users’ attempts to perform actions should also be authorized. Both the J2EE and ASP.NET web application platforms provide the ability to declaratively limit a user’s access to web resources by their identity and roles (as configured in web.xml and web.config respectively). The J2EE platform provides controls down to the method-level for limiting user access to the capabilities of EJB components. By designing file resource layouts and components APIs with authorization in mind, these powerful capabilities of the J2EE and .NET platforms can be used to enhance security.

===How to determine if you are vulnerable ===

• Do the web and application server processes run as root, Administrator, LOCALSYSTEM or other privileged accounts?

• Does the web application access the database via sa or other administrative account?

• Does the web application access the database via accounts using more privileges than required?

• In J2EE and .NET environments, do the application server virtual machines run with AllPermission or FullTrust security capabilities?

• Are platform capabilities being used to limit access to web resources?

• Are platform capabilities being used to limit what users can make calls to component methods?

===How to protect yourself ===

• Development, test and staging environments must be set up to function with the lowest possible privilege so that production will also work with lowest possible privileges.

• Ensure that system level accounts (those that run the environment) have privileges limited to the greatest degree possible. Web and application servers should never execute as “Administrator”, “root”, “sa”, “sysman”, “Supervisor”, or any other privileged account.

• User accounts should possess just enough privileges within the application to perform their assigned tasks. These user accounts should be created unprivileged and be given permissions incrementally until they have the full capabilities required. They should not be created with high privileges and then arbitrarily limited.

• Business user accounts should not be administrator accounts and vice versa. Separate accounts should be used to perform these different sets of tasks even if the same user needs to be able to perform tasks in both realms.

• Web application should access the database through one or more limited accounts that do not have schema-modification privileges unless required. If the web application requires the ability to modify the database schema then the design should be analyzed to determine if and why functionality must be implemented in such a potentially hazardous manner.

• Database access should be performed through parameterized stored procedures (or similar) to allow all table access to be revoked (i.e. select, drop, update, insert, etc). This should be done using a low privilege database account. This account should not hold any SQL roles above “user” (or similar)

• Code access security should be evaluated and implemented if possible. If a component only needs the ability to perform DNS queries, it should only be granted the code access permissions to permit this. That way if the code attempts to read from the file system or make arbitrary network connections, this will not be allowed and an error will be raised.

==Centralized authorization routines ==

A common mistake is to perform an authorization check by cutting and pasting an authorization code snippet into every page containing sensitive information. Worse yet would be re-writing this code for every page. Well written applications centralize access control routines, so if any bugs are found, they can be fixed once and the results apply throughout the application immediately.

===How to determine if you are vulnerable ===

• Does the application implement authorization controls by including a file or web control or code snippet on every page in the application?

===How to protect yourself ===

• Minimize the use of custom authorization code

• Use built-in platform or framework authorization facilities.

==Authorization matrix ==

Access controlled applications must check that users are allowed to view a page or use an action before performing the rendering or action. If these checks are not performed then users who are able to learn or guess the URLs of sensitive resources will be able to view these resources without proper controls being applied.

===How to determine if you are vulnerable ===

• Does each non-anonymous entry point have an access control check?

• Is an authorization check at or near the beginning of code implementing sensitive activities?

===How to protect yourself ===

Either use the built in authorization facilities of the framework, or place the call to a centralized authorization check at the beginning of sensitive resource views or actions.

==Controlling access to protected resources ==

Some applications check to see if a user is able to undertake a particular action, but then do not check if access to all resources required to complete the requested action is allowed. For example, forum software may check to see if a user is allowed to reply to a previous message, but then fails to check that the requested message is not within a protected or hidden forum or thread. Another example would be an Internet Banking application that checks to see if a user is allowed to transfer money, but does not validate that the “from account” is one of the user’s accounts.

===How to determine if you are vulnerable ===

• Does the application verify all resources required to complete a user-requested action should be accessible to the user?

• Is your application divided into distinct logical tiers? Code that uses resources directly, such as dynamic SQL queries, are often more at risk than code that uses a model-view-controller or other separation-of-responsibilities paradigm. It is easier to implement consistent authorization controls in logically tiered systems versus systems making ad hoc SQL queries and other resource requests.

===How to protect yourself ===

• Use logical tier separation and patterns such as Model View Controller instead of directly accessing protected resources from the web tier.

• Ensure that Model code checks to ensure that the requesting user should have access to the protected resource.

• Ensure that the code requesting the resource has adequate error checking and does not assume that access will always be granted. Failure cases should be accounted for.

==Protecting access to static resources ==

Some applications generate static content such as a PDF transaction report and allow the underlying static web server to provide access to these files. Often this means a confidential report may be available to unauthorized access if a malicious user is able to determine a valid filename for a sensitive yet static resource.

===How to determine if you are vulnerable ===

• Does the application generate or allow access to static content that also contains sensitive information?

• Is access to the static content controlled based on the current authenticated user?

• Could an anonymous user with knowledge of resource naming retrieve that protected content?

===How to protect yourself ===

• Ideally generate sensitive content on the fly and send directly to the browser rather than saving to the web server’s file system.

• If protecting static sensitive content, implement authorization checks to prevent anonymous access.

• If you have to save to disk (not recommended), use random filenames (such as a GUID) and clean up temporary files regularly.

• Do not store sensitive static content in web-accessible directory paths. Rather, store this content in non-web accessible directories and proxy access to this content through a handler that will implement proper authorization, logging, and other security functions. On the ASP.NET platform, the HTTPResponse.WriteFile() method can be used to implement this functionality. NOTE: Whenever accessing the file system from web-facing code be sure to guard against potential injection attacks.

==Reauthorization for high value activities or after idle out ==

===How to determine if you are vulnerable ===

===How to protect yourself ===

==Time based authorization ==

===How to determine if you are vulnerable ===

===How to protect yourself ===

==Be cautious of custom authorization controls ==

Most of the major application frameworks have a well developed authorization mechanism (such as Java’s JAAS or .NET’s built in authorization capabilities configured in web.config).

However, many applications contain their own custom authorization code. This adds complexity and potentially creates flaws where attackers are able to bypass ad hoc authorization controls. Unless there is a specific reason to override the built in functionality, web applications should leverage the framework support.

===How to determine if you are vulnerable ===

• Does the code leverage the build in authorization capabilities of the framework?

• Could the application be simplified by moving to the built in authentication / authorization model?

• If custom code is used to provide authorization controls, consider positive authentication issues and exception handling. Does the system fail in a closed manner or can a user be “authorized” if an exception occurs?

• What coverage is obtained by the use of the custom authentication controls? Are all code and resources protected by this mechanism? If the authorization capabilities are implemented as a file or web control that must be included in every page do all pages contain this control? Are there process measures in place to ensure that all new pages include this feature?

===How to protect yourself ===

• Always prefer to write less code in applications, particularly when frameworks provide presumably high quality and well-tested alternatives.

• If custom code is required to perform authorization functions, consider fail-safe authentication and exception handling – ensure that if an exception is thrown, the user is logged out or at least prevented from accessing the protected resource or function.

• Ensure that coverage approaches 100% by default.

==Never implement client-side authorization tokens ==

Many web application developers wish to avoid server-side session storage. Instead, they rely on client-side state maintenance mechanisms such as cookies, hidden form fields, or request/response headers. Often this is misguided when applied to access control and secrets because any information transmitted from the client is open to manipulation unless properly secured using cryptographic techniques.

===How to determine if you are vulnerable ===

• Does the application retrieve security-sensitive data such as user identification or user role information from client-controlled facilities such as cookies, hidden form parameters, or request headers?

===How to protect yourself ===

When your application is satisfied that a user is authenticated, associate the session ID with the authentication tokens, flags or state. For example, once the user is logged in, a flag with their authorization levels is set in the session object.

Java

if ( authenticated ) {

request.getSession(true).setValue(“AUTHLEVEL”) = X_USER;

}

.NET (C#)

if ( authenticated ) {

Session[“AUTHLEVEL”] = X_USER;

}

PHP

if ( authenticated ) {

$_SESSION[‘authlevel’] = X_USER; // X_USER is defined elsewhere as meaning, the user is authorized

}

Check your application:

• Do not trust any client-side authentication or authorization tokens in headers, cookies, hidden form fields, or in URL arguments unless they have been cryptographically secured via signing or encryption.

• If your application uses an SSO agent, such as IBM’s Tivoli Access Manager, Netegrity’s SiteMinder, or RSA’s ClearTrust, ensure your application validates the agent tokens rather than simply accepting them, and ensure these tokens are not visible to the end user in any form (header, cookie, hidden fields, etc). If the tokens are visible to the end user, ensure that all the properties of a cryptographically secure session handler as per chapter 12 are taken into account.

==Further Reading ==

• ASP.Net Authorization:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconaspnetauthorization.asp

• J2EE Authorization:

http://www.devarticles.com/c/a/Java/JAAS-Securing-J2EE-Applications-Securing-Web-Components/

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Access Control]]

Ajax and Other "Rich" Interface Technologies

2007-06-09T16:09:01Z

Mylene: typo

[[Guide Table of Contents]]
__TOC__

'''''Style is time’s fool. Form is time’s student – Stewart Brand '''''

Ajax applications, often styled as “Web 2.0”, are not a form of magic security pixie dust. Instead, there are two classes of applications: secure and insecure. This is independent of the use of Ajax or similar technologies that preceded it, such as Flash, applets, or ActiveX. With some effort, Ajax applications can be secure. Unfortunately, many are not, which is the '''''raison d’être''''' of this chapter.

The acronym AJAX stands for Asynchronous JavaScript and XML. Whilst these technologies underpinning Ajax are not new – they first appeared in 1998 with Microsoft Outlook Web Access in Exchange Server 5.5, “Web 2.0” was defined by Tim O’Reilly to mean highly peer-to-peer dynamic applications. Such applications include del.icio.us library that allows users to share their libraries’ details, or flickr that allows users to share their photos in a highly interactive way. We define “Ajax applications” as those that use the XMLHttpRequest object to asynchronously call the server and receive replies, regardless of how they handle or display the received data, or if they are public peer-to-peer low value applications such as forum software or highly sensitive private data, such as a tax return lodgment application.

Ajax enabled applications aim to increase the interactivity and richness of the web interface. Secure Ajax applications are achievable at minimal cost increase as long as security is considered during design and tested throughout development.

Compliance with disability laws is mandatory for all government and most corporate organizations. Ajax framework developers who wish to be used by these types of organizations must ensure their code supports common accessibility aides. Ajax framework users should select frameworks that produce accessible output and design their applications to be accessible and test regularly. In most countries, to do otherwise is simply deliberate negligence, and is often harshly punished by the courts.

Ajax applications face '''''exactly the same '''''security issues as all other web applications, plus they add their own particular set of risks that must be correctly managed. By their complex, bidirectional, and asynchronous nature, Ajax applications increase attack surface area.

Use of Ajax (or any rich interface) requires careful consideration of architecture, server-side access control, state management, and strong validation to prevent attacks. Without considering these basic controls, even brochure-ware websites, such as car manufacturer websites, can be a hazard to both the user and the web site owner’s reputation and thus sales.

At the time of writing, there is a multitude of Ajax frameworks and add-ons, and many more being written every day. Users of Ajax frameworks should ensure that their chosen framework meets the security risks of their particular application, and does not impose an unsecurable architecture upon them.

Developers of Ajax frameworks should investigate the controls presented in this chapter, and associated controls documented throughout the rest of this book to ensure that their approach is simple, accessible, and secure.

==Objective ==

To ensure that AJAX (and all “rich” interactive interfaces, such as Flash and Shockwave) have adequate:

* Secure Communications

* Authentication and Session Management

* Access Control

* Input Validation

* Error Handling and Logging

To prevent applications from being attacked using known attack vectors, such as unauthorized access, injection attacks, and so on.

==Platforms Affected ==

* All Server Platforms

* Web applications which use Ajax, ActiveX, Flash or Shockwave

* Clients which are required to use such applications

==Architecture ==

Appropriate security architecture should be considered when implementing Ajax front ends. Some Ajax frameworks will proudly display that they are 100% client based, with no server side controls, such as Tibco and Atlas (an Ajax framework for .NET).

Strong security architecture provides adequate defense in depth, and architecturally correct placement of key security controls. For more details, see the Security Architecture chapter.

For some types of applications, such as brochure-ware and non-interactive applications, such as stock tickers, this is acceptable security architecture as the risks are low – it would be hard to obviate the security controls to lose actual money. However, as the risk of the application increases, the threats and countermeasures required also increase.

'''Architecture by example '''

For the purposes of this section, irs.gov.ex, a taxation department of a fictitious country, has decided to implement an Ajax enabled electronic lodgment and tracking service for all of its 100 million taxpayers. A key reason to move to the new system is to reduce the workload on existing staff for the 90+% of tax returns that could be processed automatically … as long as the taxpayers do not deliberately lie, deceive, or cheat the system. Which of course, they do regularly.

They bought a fancy new Enterprise Service Bus (ESB), to which they hooked up their old but incredibly reliable mainframe backend, their SAP R/3 implementation that writes the checks and tax invoices, and several other key systems.

This particular ESB, like many on the market today, has no data validation, authentication, or authorization controls of its own; it is a simple web-service integration layer. The ESB expects that the underlying systems will perform adequate validation and authorization to prevent abuse, as the software company that wrote the ESB expected that all calling systems would be trusted, internal systems. Hooking up a dynamic web site where the users are known to be relentless, eager, and motivated tax avoiders changes the risk profile of a previously internal system with trusted staff.

The tax department does not want to change existing systems as they are in production and stable. More to the point, they cannot change their mainframe code easily - their skilled mainframe programmers either were promoted to senior management or retired 15 years ago, and it would be extremely costly to hire new mainframe developers, and impossible to change how the third party systems work, like SAP or their anti-fraud system.

Old code, such as COBOL CICS transactions, or previously internal only systems such as SAP R/3, have a different trust model than highly dynamic Internet connected websites. It is highly likely such systems have never been tested against now common attacks, such as HTML injection (XSS), DOM injection, XML query attacks, or similar. Without any intermediate code to protect these older systems, they are at immense risk.

The tax department selected a simple solution in the belief it will save money. In this first example, the bulk of the business logic is contained in deployed JavaScript applications. All of the business logic, validation, and state are contained in the client’s browser, and it makes direct calls to the enterprise service bus.

However, this model is simply broken: the previously generic process orchestration service will need to become far more aware of the caller’s identity (to provide authentication and enforce authorization), maintain secure state, and provide validation services that have previously been performed on the client.

[[Image:Insecure Security and state maintained on the client.gif]]

This security model is akin to leaving the keys to the Reserve Bank at the train station notice board. There is no method of protecting this model without significant replication of the business logic and re-validating all the state at the enterprise service bus, or similar web service endpoints.

Many enterprises, including irs.gov.ex, have taken to service oriented architecture (SOA), which uses web services enabling re-use of pre-existing transactions and systems, such as SAP or Siebel, or custom transactions running on mainframes. If an Ajax framework is connected to such SOA endpoints, such as an enterprise service bus, or directly to a backend data warehouse or other persistent store, there is no ability to validate the calling identity, authorize the transaction, validate the data, or any other normal security activity. So this model will not do.

In the next model, which is how most PHP application frameworks work today, the Ajax xmlrpc endpoint is not necessarily well integrated with the main application.

[[Image: Insecure Ajax Web Service Endpoint separate from the main application.gif]]

In this model, if the Ajax endpoint cannot or does not access secure state, or associate the call with the active session, a hostile caller could emulate an active session and call protected resources with minimal skills or tools. This vulnerability has already been demonstrated with several popular Ajax PHP toolkits on Bugtraq, and probably applies to other less well-known toolkits for other languages and platforms.

The best way to protect both of these models is to bring them back to the normal three-tier application model:

[[Image: Better Shared business logic in the middle tier with different front ends.gif]]

In this model, which is akin to how GMail works, the application is still significantly Ajax enabled, and provides a rich experience to the user. However, this code is backed by:

* A solid session management scheme to ensure that authentication and authorization is performed in a trusted part of the architecture

* Data validation is performed in both directions on the server-side at various layers to limit or prevent injection and other attacks

* All calls to the backend services are performed by trusted server-side business logic

* The layered architecture allows reasonable trust of the caller at the ESB level as the data has been significantly authorized and validated

This means that the ESB and its published services, such as 40 year old COBOL code, do not need to be particularly aware of the implications of being made available to the Internet. This enables higher levels of re-use and reduces costs.

Although more complex to the project implementing the Ajax enabled application, to the funding business, this architecture is the cheapest way of maintaining security whilst avoiding updating or maintaining ancient or third party code.

Selecting the correct architecture is unfortunately not a checklist – it is a balance of risk versus cost. However, as demonstrated in this section, client-side heavy architecture models are completely untrustworthy for transactional systems and should be avoided.

==Access control: Authentication and Authorization ==

Ajax code uses the XMLHttpRequest object, which will send the cookies of the current browser context through with each request. For applications which have user sessions, it is vital that normal authentication paths are used to ensure that the caller is known to the application. Brochure-ware applications can skip this section as they allow anonymous calling.

'''How to determine if you are vulnerable '''

If you have transactions or calls that are not to be used by anonymous callers, check that client-side code cannot call them without an established user context.

To do this:

* Fire up your favorite proxy tool, such as WebScarab

* Generate an authenticated XMLHttpRequest using the browser

* Right click on the resulting entry in WebScarab, click “Re-send”

* Edit out the cookie

See if a valid result is returned. If yes, you are vulnerable. Repeat for every Ajax enabled server-side service.

'''Countermeasures '''

Ensure that every Ajax callable function, whether XMLRPC, custom code, or a web service verify the session and authorization.

For example, in typical Ajax style, CPaint uses this insecure example:

''<?php? ''

''function calculate_tax($sales_amount)''

''{''

''return($sales_amount * 0.075);?''

''}?''

''?>''

Let’s add some session authentication, authorization and data validation, and business rule validation:

''<?php? ''

''function calculate_tax($sales_amount)''

''{''

''// check that the session is logged in ?''

'' assert_login();''

'' // check that the user has the USER role to prevent ''

''// guest and admin access''

'' assert_role(‘USER’);''

''// Validate data and business rules''

''if ( is_numeric($sales_amount) && $sales_amount > 0 )''

''{''

''// Perform the calculation and return''

''return($sales_amount * 0.075);?''

''}''

''// Data failed validation and business rules''

''return -1;''

''}''

''?>''

With these simple changes, we ensure that:

* (Authentication) Enforce that the user is logged on

* (Authorization and Compliance) Enforce role authorization and provide SOX-compliant segregation of duties

* (Data Validation) Ensure that the data is safe to perform our calculation

* (Business Rule Validation) Lastly, check the data is within acceptable business rule boundaries as it is not a good idea to calculate tax for negative and zero values

Obviously, performing a tax rate calculation is not that important, but if it was an insurance premium calculator (which uses highly sensitive actuary data) this is the minimum you would expect to see for sensitive code.

==Silent transactional authorization ==

Any system that silently processes transactions using a single submission is dangerous to the client. For example, if a normal web application allows a simple URL submission, a preset session attack will allow the attacker to complete a transaction without the user’s authorization. In Ajax, it gets worse: the transaction is silent; it happens with no user feedback on the page, so an injected attack script may be able to steal money from the client without authorization.

'''How to determine if you are vulnerable '''

Determine if the application:

* Is vulnerable to DOM injection and can run arbitrary Javascript

* If the browser allows execution of loaded Javascript via URL entry, by navigating to the transaction submission page, and then typing in javascript:function(args). If the Javascript is executed, it is likely that spyware will also be able to execute this code via the DOM model

'''Countermeasures '''

Ensure that all transactions are conducted with appropriate authorization, including transaction signing as necessary

==Untrusted or absent session data ==

A common mis-implementation with Ajax is the desire to call a second server.

[[Image:Ajax Second Server.gif]]

Session data on the first server usually contains relatively trustworthy authentication and authorization information, as well as sensitive state, but in general, the second server cannot access this information in a timely or safe fashion.

An example includes running an Ajax application on http://www.example.com, and the Ajax code is able to directly process share trades on http://market.somebiginvestmentfirm.com/ via the use of embedded trust or embedded credentials.

Attackers will be able to fraudulently perform transactions if there is no shared state between the two systems. This attack only requires that the attackers can tamper with embedded state on the client and if market.somebiginvestmentfirm.com foolishly trusts calls from Ajax callers without first checking with example.com. However, if example.com is simply one of hundreds of brokers, then this scenario is very unlikely to be secure no matter how it’s sliced or diced. This particular scenario requires federated identity, which is discussed further in the Authentication chapter.

'''How to determine if you are vulnerable '''

You are vulnerable to this issue if:

* Sensitive state is passed through the client to the second server in the foolish hope it will be trusted by the second server

* The Ajax endpoints are hosted on a different server with unsharable session state

* The second server is addressed by a URL that would prevent the cookies from the first session being used by the second server. Most browsers do not allow an application running on ws.example.com to read cookies from www.example.com. However, browsers will allow cookies to be read from http://example.com but you should not rely on this as an attacker may spoof another URL such as attack.example.com and set cookies for example.com.

* If the web service or other endpoint cannot obtain data from the first server’s session state for any other reason (such as incompatible technologies, like running a PHP web application and the Ajax application is trying to consume ASP.NET web services).

'''Countermeasures '''

There are at least three methods to get around this issue:

* Do not host the receiving end point on a different server; simply scale the entire application up (web services and all) on the same host. This allows trivially easy access to the trusted session state.

* Stash the state in a database, and pass a cryptographically strong random key from the first server to the second server via the client. This method is far slower, more code intensive, and less scalable than the first solution.

* Use federated authentication to provide a shared authorization context and verify it on the second server. This is usually very slow, but it is safe as long as the single sign-on (SSO) implementation is relatively secure and does not allow replay attacks.

A solution that will not work is to simply pass the sensitive state via the client. A hostile client can tamper with the username, role, or any other sensitive state, so it cannot be trusted to transmit such data safely.

==State management ==

The DOM is designed to be manipulated and visible within the browser. It was never designed to be a secure storage area, but rather as a method of controlling how the page looks and behaves. Therefore, secure applications need to take care with client side storage of secure state.

'''How to determine if you are vulnerable '''

'''Countermeasures '''

==Tamper resistance ==

If state is stored on the client, the attacker is able to easily manipulate this state using a DOM inspection tool, or simply by re-writing to their own API.

'''How to determine if you are vulnerable: '''

* Use DOM inspection tools like FireBug (https://addons.mozilla.org/firefox/1843/) – can you see client side state?

* Can you change the state?

* Use proxy tools, such as Paros, Spike Proxy, or WebScarab. When you see client-side state, can you modify it or inject interesting traffic? Does the server-side code detect the change in a reasonable way?

'''Countermeasures '''

* Do not obfuscate client side state for no purpose – this requires more code and is trivially bypassed by advanced attackers

* Applications should maintain a copy of all client-side state, and only accept back state that the user is authorized to change, such as a form fields or settings which they can change in the web UI

* Ensure that the action is authorized before performing any activity on submitted data

* Include server-side validation, preferring white listing to blacklisting.

==Privacy ==

Almost all Ajax clients use XMLHttpRequest with GET requests. These embed the data in the “URL”, and even though the data is generally not visible to the user, it is available in the browser history.

Phishers favor GET requests. They love to use links embedded in e-mails. If coupled with poorly written code that does not assert authorization, such code will allow the phisher to commit an unauthorized transaction.

Even if POSTs are used, private data can be cached in intermediate untrusted caches if the application uses HTTP rather than HTTPS connections.

Most browsers have GET data limits, which can be as little as 2 KB. POSTs do not have this limitation, allowing far more data to be sent in any one request.

'''How to determine if you are at risk '''

* Use a proxy tool, like Paros, Spike, or WebScarab to determine the mode of the Ajax interaction. If it is GET, you are potentially at risk.

* Look at the data – does it contain details such as usernames, passwords, names, addresses, medical history, bank account, tax or other private details? If so, you are at risk.

* If you are sending sensitive data, can you access the Ajax endpoint via HTTP? If so, you are at risk from privacy breaches.

'''Countermeasures '''

Generally, regardless of data value, use only POST requests.

''CPaint POST transfer mode client example''

''var cp = new cpaint();''

''cp.set_transfer_mode(‘POST’);''

''…''

''cp.call(‘processCreditCard.php’, ‘setCCDetail’, document.getElementById(‘creditcardnumber’), document.getElementById(‘creditcardexpiry’),''

''document.getElementById(‘ccv’));''

''CPaint POST transfer mode server example''

''<?php? ''

''function setCCDetail($cc, $expiry, $ccv)''

''{''

''// check that the session is logged in ?''

'' assert_login();''

'' // check that the user has the USER role to prevent ''

''// guest and admin access''

'' assert_role(‘USER’);''

''// Validate data and business rules''

''if ( is_credit_card($cc) && is_expiry_date($expiry) && is_numeric($ccv) )''

''{''

''// Set the credit card details''

''$this->cc = $cc;''

''$this->exp = $expiry;''

''$this->ccv = $ccv;''

''return true;''

''}''

''// Data failed validation and business rules''

''return false;''

''}''

''?>''

Include server-side code that enforces the source of the data, so that it only comes from the POST, not from the request, GET, environment, or cookie data.

If data transiting Ajax endpoints is protected by the users’ privacy laws, ensure that the data transits only over HTTPS using SSLv3 or TLS 1.0 or better and block HTTP communications.

==Proxy Façade ==

Many toolkits, particularly PHP toolkits, allow you to register a class or file with the Ajax toolkit and thus call that method. CPaint for example works in this manner. However, some toolkits are worse than others – they allow '''any''' in context PHP function to be called, including system() and eval(). Others are not robust against PHP code injection – see below for more details.

'''How to determine if you are vulnerable '''

If your toolkit works by registering classes or functions, try:

* Calling a system call, such as system() or printf()

* Calling another function in your code, but one which has not been registered

* Try using some of the language features, such as ` for PHP for example

If any of these attacks work, your code (and any code using this framework) is vulnerable to attack.

'''Countermeasures '''

In general, such methods of calling server side code are fraught with danger. It’s better to provide a limited interface, called a proxy façade, to only allow access to permitted functions.

This would also allow authorization checks and basic validation to be performed before calling previously internal code.

==SOAP Injection Attacks ==

'''How to determine if you are vulnerable '''

'''Countermeasures '''

==XMLRPC Injection Attacks ==

'''How to determine if you are vulnerable '''

'''Countermeasures '''

==DOM Injection Attacks ==

'''How to determine if you are vulnerable '''

'''Countermeasures '''

==XML Injection Attacks ==

'''How to determine if you are vulnerable '''

'''Countermeasures '''

==JSON (Javascript Object Notation) Injection Attacks ==

'''How to determine if you are vulnerable '''

'''Countermeasures '''

==Encoding safety ==

Ajax applications are particularly prone to encoding attacks as JavaScript understands several encodings (depending on the browser, locale and code page), whilst the scripting language itself is primitive when it comes to providing robust encoding and decoding utilities.

'''How to determine if you are vulnerable '''

'''Countermeasures '''

Do not rely heavily upon Javascript processing the encoding or decoding capabilities for the client. Send data pre-encoded to the client, and receive data and handle it correctly.

For more details, see the Canonicalization chapter later in this book.

==Auditing ==

'''How to determine if you are vulnerable '''

'''Countermeasures '''

==Error Handling ==

'''How to determine if you are vulnerable '''

'''Countermeasures '''

==Accessibility ==

Almost all Ajax toolkits and applications are inaccessible. Rarely do they pass even basic W3C WAI validation, do not have accessible alternative paths. Some toolkits, such as Tibco General Interface, crash the browser if a larger text size is chosen. This is completely unacceptable and worse, completely preventable. Being a “rich” interface does not excuse disability requirements. Based upon the US Census conducted in 2000, around 19.1% of the total US population has a disability of some kind (with similar levels elsewhere on the planet). Locking out 20% of your potential users from using your application is unacceptable and is in fact, illegal in most countries.

Nearly all Western disability discrimination laws are the same – they require accessibility unless it is a justifiable hardship. They do not distinguish between open source or closed source, for profit or charitable, government or corporate – their application is universal.

The techniques for creating accessible applications are widely known and have been documented for more than ten years. Accessibility evaluation tools are included or available as an option in every web development environment. As it does not cost a great deal to write new software to be accessible (the primary cost is in the testing), it is never a justifiable hardship to be accessible.

Over the last few years, case law has firmly solidified upon the side of the disabled (see the references, particularly the SOCOG / IBM decision). If you now deliberately write inaccessible software, it would be negligent in the same way that building new buildings without accessibility aides such as ramps and lifts to allow wheelchair access. This stuff is not rocket science, it does not cost a lot of money to do, and lastly, you may need it one day.

'''How to identify if you are vulnerable '''

* Read the W3C WAI guidelines and ensure your application has alternate accessible paths, and adheres to basic accessibility guidelines

* Identify suitable evaluation tools for your development environment if it does not already contain them. Fix issues found by these tools and re-test

* Try using the basic accessibility tools built into your operating system to see if your code works in high contrast, different color schemes, resize the text elements in your browser (in Firefox use Control-+ key to do this, Text Size -> Larger in Internet Explorer 6.0 or use the zoom control on the bottom right of the screen in IE 7), (Windows specific) set the font resolution to high DPI to emulate large fonts, choose big default fonts in the browser, use the screen magnification tool, and test various basic screen readers. If your application fails any of these tests, you are vulnerable.

* Once you are satisfied your application should have a reasonable shot at passing full testing, identify a suitable accredited accessibility test firms or similarly qualified resources who can test your application using actual disability tools and provide qualified feedback. In general, unless your application is very simple, you should fix any issues found.

'''Countermeasures '''

* Develop with accessibility in mind. Just like security, the sooner you do it, the cheaper this activity becomes and the more likely your application will be accessible

* Test in house regularly. If possible, employ staff or volunteers who require such accessibility; they will let you know the best choices for full featured screen readers, Braille devices, and magnification and other accessibility aides. Let them test your application and provide feedback.

* If you are likely to sell to corporate or government organizations, ensure that all applications are tested by an accredited accessibility testing firm. Fix all the issues they identify.

==Further Reading ==

AJAX Spell Command Injection Vulnerability

http://www.securityfocus.com/bid/13986/discuss

CPaint Command Injection Vulnerability

http://www.securityfocus.com/bid/14565/discuss

XML-RPC Command Injection Vulnerability

http://www.securityfocus.com/bid/14088/discuss

Maguire vs SOCOG/IBM, Nublog

http://www.contenu.nu/socog.html

W3C, Existing accessibility tools

http://www.w3.org/WAI/ER/existingtools.html

US Census 2000: Disability Status 2000

http://www.census.gov/prod/2003pubs/c2kbr-17.pdf

==Reference==
[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:OWASP AJAX Security Project]]
[[Category:AJAX]]

Web Services

2007-06-09T16:01:29Z

Mylene: /* WS-Security Building Blocks */ stated that the Kerberos profile has been accepted

[[Guide Table of Contents]]
__TOC__

This section of the Guide details the common issues facing Web services developers, and methods to address common issues. Due to the space limitations, it cannot look at all of the surrounding issues in great detail, since each of them deserves a separate book of its own. Instead, an attempt is made to steer the reader to the appropriate usage patterns, and warn about potential roadblocks on the way.

Web Services have received a lot of press, and with that comes a great deal of confusion over what they really are. Some are heralding Web Services as the biggest technology breakthrough since the web itself; others are more skeptical that they are nothing more than evolved web applications. In either case, the issues of web application security apply to web services just as they do to web applications.

At the simplest level, web services can be seen as a specialized web application that differs mainly at the presentation tier level. While web applications typically are HTML-based, web services are XML-based. Interactive users for B2C transactions normally access web applications, while web services are employed as building blocks by other web applications for forming B2B chains using the so-called SOA model. Web services typically present a public functional interface, callable in a programmatic fashion, while web applications tend to deal with a richer set of features and are content-driven in most cases.

==Securing Web Services ==

Web services, like other distributed applications, require protection at multiple levels:

* SOAP messages that are sent on the wire should be delivered confidentially and without tampering

* The server needs to be confident who it is talking to and what the clients are entitled to

* The clients need to know that they are talking to the right server, and not a phishing site (see the Phishing chapter for more information)

* System message logs should contain sufficient information to reliably reconstruct the chain of events and track those back to the authenticated callers

Correspondingly, the high-level approaches to solutions, discussed in the following sections, are valid for pretty much any distributed application, with some variations in the implementation details.

The good news for Web Services developers is that these are infrastructure-level tasks, so, theoretically, it is only the system administrators who should be worrying about these issues. However, for a number of reasons discussed later in this chapter, WS developers usually have to be at least aware of all these risks, and oftentimes they still have to resort to manually coding or tweaking the protection components.

==Communication security ==

There is a commonly cited statement, and even more often implemented approach – “we are using SSL to protect all communication, we are secure”. At the same time, there have been so many articles published on the topic of “channel security vs. token security” that it hardly makes sense to repeat those arguments here. Therefore, listed below is just a brief rundown of most common pitfalls when using channel security alone:

* It provides only “point-to-point” security

Any communication with multiple “hops” requires establishing separate channels (and trusts) between each communicating node along the way. There is also a subtle issue of trust transitivity, as trusts between node pairs {A,B} and {B,C} do not automatically imply {A,C} trust relationship.

* Storage issue

After messages are received on the server (even if it is not the intended recipient), they exist in the clear-text form, at least – temporarily. Storing the transmitted information at the intermediate aggravates the problem or destination servers in log files (where it can be browsed by anybody) and local caches.

* Lack of interoperability

While SSL provides a standard mechanism for transport protection, applications then have to utilize highly proprietary mechanisms for transmitting credentials, ensuring freshness, integrity, and confidentiality of data sent over the secure channel. Using a different server, which is semantically equivalent, but accepts a different format of the same credentials, would require altering the client and prevent forming automatic B2B service chains.

Standards-based token protection in many cases provides a superior alternative for message-oriented Web Service SOAP communication model.

That said – the reality is that the most Web Services today are still protected by some form of channel security mechanism, which alone might suffice for a simple internal application. However, one should clearly realize the limitations of such approach, and make conscious trade-offs at the design time, whether channel, token, or combined protection would work better for each specific case.

==Passing credentials ==

In order to enable credentials exchange and authentication for Web Services, their developers must address the following issues.

First, since SOAP messages are XML-based, all passed credentials have to be converted to text format. This is not a problem for username/password types of credentials, but binary ones (like X.509 certificates or Kerberos tokens) require converting them into text prior to sending and unambiguously restoring them upon receiving, which is usually done via a procedure called Base64 encoding and decoding.

Second, passing credentials carries an inherited risk of their disclosure – either by sniffing them during the wire transmission, or by analyzing the server logs. Therefore, things like passwords and private keys need to be either encrypted, or just never sent “in the clear”. Usual ways to avoid sending sensitive credentials are using cryptographic hashing and/or signatures.

==Ensuring message freshness ==

Even a valid message may present a danger if it is utilized in a “replay attack” – i.e. it is sent multiple times to the server to make it repeat the requested operation. This may be achieved by capturing an entire message, even if it is sufficiently protected against tampering, since it is the message itself that is used for attack now (see the XML Injection section of the Interpreter Injection chapter).

Usual means to protect against replayed messages is either using unique identifiers (nonces) on messages and keeping track of processed ones, or using a relatively short validity time window. In the Web Services world, information about the message creation time is usually communicated by inserting timestamps, which may just tell the instant the message was created, or have additional information, like its expiration time, or certain conditions.

The latter solution, although easier to implement, requires clock synchronization and is sensitive to “server time skew,” whereas server or clients clocks drift too much, preventing timely message delivery, although this usually does not present significant problems with modern-day computers. A greater issue lies with message queuing at the servers, where messages may be expiring while waiting to be processed in the queue of an especially busy or non-responsive server.

==Protecting message integrity ==

When a message is received by a web service, it must always ask two questions: “whether I trust the caller,” “whether it created this message.” Assuming that the caller trust has been established one way or another, the server has to be assured that the message it is looking at was indeed issued by the caller, and not altered along the way (intentionally or not). This may affect technical qualities of a SOAP message, such as the message’s timestamp, or business content, such as the amount to be withdrawn from the bank account. Obviously, neither change should go undetected by the server.

In communication protocols, there are usually some mechanisms like checksum applied to ensure packet’s integrity. This would not be sufficient, however, in the realm of publicly exposed Web Services, since checksums (or digests, their cryptographic equivalents) are easily replaceable and cannot be reliably tracked back to the issuer. The required association may be established by utilizing HMAC, or by combining message digests with either cryptographic signatures or with secret key-encryption (assuming the keys are only known to the two communicating parties) to ensure that any change will immediately result in a cryptographic error.

==Protecting message confidentiality ==

Oftentimes, it is not sufficient to ensure the integrity – in many cases it is also desirable that nobody can see the data that is passed around and/or stored locally. It may apply to the entire message being processed, or only to certain parts of it – in either case, some type of encryption is required to conceal the content. Normally, symmetric encryption algorithms are used to encrypt bulk data, since it is significantly faster than the asymmetric ones. Asymmetric encryption is then applied to protect the symmetric session keys, which, in many implementations, are valid for one communication only and are subsequently discarded.

Applying encryption requires conducting an extensive setup work, since the communicating parties now have to be aware of which keys they can trust, deal with certificate and key validation, and know which keys should be used for communication.

In many cases, encryption is combined with signatures to provide both integrity and confidentiality. Normally, signing keys are different from the encrypting ones, primarily because of their different lifecycles – signing keys are permanently associated with their owners, while encryption keys may be invalidated after the message exchange. Another reason may be separation of business responsibilities - the signing authority (and the corresponding key) may belong to one department or person, while encryption keys are generated by the server controlled by members of IT department.

==Access control ==

After message has been received and successfully validated, the server must decide:

* Does it know who is requesting the operation (Identification)

* Does it trust the caller’s identity claim (Authentication)

* Does it allow the caller to perform this operation (Authorization)

There is not much WS-specific activity that takes place at this stage – just several new ways of passing the credentials for authentication. Most often, authorization (or entitlement) tasks occur completely outside of the Web Service implementation, at the Policy Server that protects the whole domain.

There is another significant problem here – the traditional HTTP firewalls do not help at stopping attacks at the Web Services. An organization would need a XML/SOAP firewall, which is capable of conducting application-level analysis of the web server’s traffic and make intelligent decision about passing SOAP messages to their destination. The reader would need to refer to other books and publications on this very important topic, as it is impossible to cover it within just one chapter.

==Audit ==

A common task, typically required from the audits, is reconstructing the chain of events that led to a certain problem. Normally, this would be achieved by saving server logs in a secure location, available only to the IT administrators and system auditors, in order to create what is commonly referred to as “audit trail”. Web Services are no exception to this practice, and follow the general approach of other types of Web Applications.

Another auditing goal is non-repudiation, meaning that a message can be verifiably traced back to the caller. Following the standard legal practice, electronic documents now require some form of an “electronic signature”, but its definition is extremely broad and can mean practically anything – in many cases, entering your name and birthday qualifies as an e-signature.

As far as the WS are concerned, such level of protection would be insufficient and easily forgeable. The standard practice is to require cryptographic digital signatures over any content that has to be legally binding – if a document with such a signature is saved in the audit log, it can be reliably traced to the owner of the signing key.

==Web Services Security Hierarchy ==

Technically speaking, Web Services themselves are very simple and versatile – XML-based communication, described by an XML-based grammar, called Web Services Description Language (WSDL, see http://www.w3.org/TR/2005/WD-wsdl20-20050510), which binds abstract service interfaces, consisting of messages, expressed as XML Schema, and operations, to the underlying wire format. Although it is by no means a requirement, the format of choice is currently SOAP over HTTP. This means that Web Service interfaces are described in terms of the incoming and outgoing SOAP messages, transmitted over HTTP protocol.

===Standards committees ===

Before reviewing the individual standards, it is worth taking a brief look at the organizations, which are developing and promoting them. There are quite a few industry-wide groups and consortiums, working in this area, most important of which are listed below.

W3C (see http://www.w3.org) is the most well known industry group, which owns many Web-related standards and develops them in Working Group format. Of particular interest to this chapter are XML Schema, SOAP, XML-dsig, XML-enc, and WSDL standards (called recommendations in the W3C’s jargon).

OASIS (see http://www.oasis-open.org) mostly deals with Web Service-specific standards, not necessarily security-related. It also operates on a committee basis, forming so-called Technical Committees (TC) for the standards that it is going to be developing. Of interest for this discussion, OASIS owns WS-Security and SAML standards.

Web Service Interoperability group (WS-I, see http://www.ws-i.org/) was formed to promote general framework for interoperable Web Services. Mostly its work consists of taking other broadly accepted standards, and develop so-called profiles, or set of requirements for conforming Web Service implementations. In particular, its Basic Security Profile (BSP) relies on the OASIS’ WS-Security standard and specifies sets of optional and required security features in Web Services that claim interoperability.

Liberty Alliance (LA, see http://projectliberty.org) consortium was formed to develop and promote an interoperable Identity Federation framework. Although this framework is not strictly Web Service-specific, but rather general, it is important for this topic because of its close relation with the SAML standard developed by OASIS.

Besides the previously listed organizations, there are other industry associations, both permanently established and short-lived, which push forward various Web Service security activities. They are usually made up of software industry’s leading companies, such as Microsoft, IBM, Verisign, BEA, Sun, and others, that join them to work on a particular issue or proposal. Results of these joint activities, once they reach certain maturity, are often submitted to standardizations committees as a basis for new industry standards.

==SOAP ==

Simple Object Access Protocol (SOAP, see http://www.w3.org/TR/2003/REC-soap12-part1-20030624/) provides an XML-based framework for exchanging structured and typed information between peer services. This information, formatted into Header and Body, can theoretically be transmitted over a number of transport protocols, but only HTTP binding has been formally defined and is in active use today. SOAP provides for Remote Procedure Call-style (RPC) interactions, similar to remote function calls, and Document-style communication, with message contents based exclusively on XML Schema definitions in the Web Service’s WSDL. Invocation results may be optionally returned in the response message, or a Fault may be raised, which is roughly equivalent to using exceptions in traditional programming languages.

SOAP protocol, while defining the communication framework, provides no help in terms of securing message exchanges – the communications must either happen over secure channels, or use protection mechanisms described later in this chapter.

===XML security specifications (XML-dsig & Encryption) ===

XML Signature (XML-dsig, see http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/), and XML Encryption (XML-enc, see http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/) add cryptographic protection to plain XML documents. These specifications add integrity, message and signer authentication, as well as support for encryption/decryption of whole XML documents or only of some elements inside them.

The real value of those standards comes from the highly flexible framework developed to reference the data being processed (both internal and external relative to the XML document), refer to the secret keys and key pairs, and to represent results of signing/encrypting operations as XML, which is added to/substituted in the original document.

However, by themselves, XML-dsig and XML-enc do not solve the problem of securing SOAP-based Web Service interactions, since the client and service first have to agree on the order of those operations, where do look for the signature, how to retrieve cryptographic tokens, which message elements should be signed and encrypted, how long a message is considered to be valid, and so on. These issues are addressed by the higher-level specifications, reviewed in the following sections.

===Security specifications ===

In addition to the above standards, there is a broad set of security-related specifications being currently developed for various aspects of Web Service operations.

One of them is SAML, which defines how identity, attribute, and authorization assertions should be exchanged among participating services in a secure and interoperable way.

A broad consortium, headed by Microsoft and IBM, with the input from Verisign, RSA Security, and other participants, developed a family of specifications, collectively known as “Web Services Roadmap”. Its foundation, WS-Security, has been submitted to OASIS and became an OASIS standard in 2004. Other important specifications from this family are still found in different development stages, and plans for their submission have not yet been announced, although they cover such important issues as security policies (WS-Policy et al), trust issues and security token exchange (WS-Trust), establishing context for secure conversation (WS-SecureConversation). One of the specifications in this family, WS-Federation, directly competes with the work being done by the LA consortium, and, although it is supposed to be incorporated into the Longhorn release of Windows, its future is not clear at the moment, since it has been significantly delayed and presently does not have industry momentum behind it.

==WS-Security Standard ==

WS-Security specification (WSS) was originally developed by Microsoft, IBM, and Verisign as part of a “Roadmap”, which was later renamed to Web Services Architecture, or WSA. WSS served as the foundation for all other specifications in this domain, creating a basic infrastructure for developing message-based security exchange. Because of its importance for establishing interoperable Web Services, it was submitted to OASIS and, after undergoing the required committee process, became an officially accepted standard. Current version is 1.0, and the work on the version 1.1 of the specification is under way and is expected to be finishing in the second half of 2005.

===Organization of the standard ===

The WSS standard itself deals with several core security areas, leaving many details to so-called profile documents. The core areas, broadly defined by the standard, are:

* Ways to add security headers (WSSE Header) to SOAP Envelopes

* Attachment of security tokens and credentials to the message

* Inserting a timestamp

* Signing the message

* Encrypting the message

* Extensibility

Flexibility of the WS-Security standard lies in its extensibility, so that it remains adaptable to new types of security tokens and protocols that are being developed. This flexibility is achieved by defining additional profiles for inserting new types of security tokens into the WSS framework. While the signing and encrypting parts of the standards are not expected to require significant changes (only when the underlying XML-dsig and XML-enc are updated), the types of tokens, passed in WSS messages, and ways of attaching them to the message may vary substantially. At the high level the WSS standard defines three types of security tokens, attachable to a WSS Header: Username/password, Binary, and XML tokens. Each of those types is further specified in one (or more) profile document, which defines additional token’s attributes and elements, needed to represent a particular type of security token.

[[Image:WSS_Specification_Hierarchy.gif|Figure 4: WSS specification hierarchy]]

===Purpose ===

The primary goal of the WSS standard is providing tools for message-level communication protection, whereas each message represents an isolated piece of information, carrying enough security data to verify all important message properties, such as: authenticity, integrity, freshness, and to initiate decryption of any encrypted message parts. This concept is a stark contrast to the traditional channel security, which methodically applies pre-negotiated security context to the whole stream, as opposed to the selective process of securing individual messages in WSS. In the Roadmap, that type of service is eventually expected to be provided by implementations of standards like WS-SecureConversation.

From the beginning, the WSS standard was conceived as a message-level toolkit for securely delivering data for higher level protocols. Those protocols, based on the standards like WS-Policy, WS-Trust, Liberty Alliance, rely on the transmitted tokens to implement access control policies, token exchange, and other types of protection and integration. However, taken alone, the WSS standard does not mandate any specific security properties, and an ad-hoc application of its constructs can lead to subtle security vulnerabilities and hard to detect problems, as is also discussed in later sections of this chapter.

==WS-Security Building Blocks ==

The WSS standard actually consists of a number of documents – one core document, which defines how security headers may be included into SOAP envelope and describes all high-level blocks, which must be present in a valid security header. Profile documents have the dual task of extending definitions for the token types they are dealing with, providing additional attributes, elements, as well as defining relationships left out of the core specification, such as using attachments.

Core WSS 1.1 specification, located at http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf, defines several types of security tokens (discussed later in this section – see 0), ways to reference them, timestamps, and ways to apply XML-dsig and XML-enc in the security headers – see the XML Dsig section for more details about their general structure.

Associated specifications are:

* Username token profile 1.1, located at http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf, which adds various password-related extensions to the basic UsernameToken from the core specification

* X.509 token profile 1.1, located at http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf which specifies, how X.509 certificates may be passed in the BinarySecurityToken, specified by the core document

* SAML Token profile 1.1, located at http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf that specifies how XML-based SAML tokens can be inserted into WSS headers.

* Kerberos Token Profile 1.1, located at http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf that defines how to encode Kerberos tickets and attach them to SOAP messages.

* Rights Expression Language (REL) Token Profile 1.1, located at http://www.oasis-open.org/committees/download.php/16687/oasis-wss-rel-token-profile-1.1.pdf that describes the use of ISO/IEC 21000-5 Rights Expressions with respect to the WS-Security specification.

* SOAP with Attachments (SWA) Profile 1.1, located at http://www.oasis-open.org/committees/download.php/16672/wss-v1.1-spec-os-SwAProfile.pdf that describes how to use WSS-Sec with SOAP Messages with Attachments.

===How data is passed ===

WSS security specification deals with two distinct types of data: security information, which includes security tokens, signatures, digests, etc; and message data, i.e. everything else that is passed in the SOAP message. Being an XML-based standard, WSS works with textual information grouped into XML elements. Any binary data, such as cryptographic signatures or Kerberos tokens, has to go through a special transform, called Base64 encoding/decoding, which provides straightforward conversion from binary to ASCII formats and back. Example below demonstrates how binary data looks like in the encoded format:

''cCBDQTAeFw0wNDA1MTIxNjIzMDRaFw0wNTA1MTIxNjIzMDRaMG8xCz''

After encoding a binary element, an attribute with the algorithm’s identifier is added to the XML element carrying the data, so that the receiver would know to apply the correct decoder to read it. These identifiers are defined in the WSS specification documents.

===Security header’s structure ===

A security header in a message is used as a sort of an envelope around a letter – it seals and protects the letter, but does not care about its content. This “indifference” works in the other direction as well, as the letter (SOAP message) should not know, nor should it care about its envelope (WSS Header), since the different units of information, carried on the envelope and in the letter, are presumably targeted at different people or applications.

A SOAP Header may actually contain multiple security headers, as long as they are addressed to different actors (for SOAP 1.1), or roles (for SOAP 1.2). Their contents may also be referring to each other, but such references present a very complicated logistical problem for determining the proper order of decryptions/signature verifications, and should generally be avoided. WSS security header itself has a loose structure, as the specification itself does not require any elements to be present – so, the minimalist header with an empty message will look like:

''<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">''

'' <soap:Header>''

'' <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="1">''

'' ''

'' </wsse:Security>''

'' </soap:Header>''

'' <soap:Body>''

'' </soap:Body>''

''</soap:Envelope>''

However, to be useful, it must carry some information, which is going to help securing the message. It means including one or more security tokens (see 0) with references, XML Signature, and XML Encryption elements, if the message is signed and/or encrypted. So, a typical header will look more like the following picture:

''<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">''

'' <soap:Header>''

'' <wsse:Security xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="1">''

'' <wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="aXhOJ5">MIICtzCCAi... ''

'' </wsse:BinarySecurityToken>''

'' <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">''

'' <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>''

'' <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">''

'' <wsse:SecurityTokenReference>''

'' <wsse:Reference URI="#aXhOJ5" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>''

'' </wsse:SecurityTokenReference> ''

'' </dsig:KeyInfo>''

'' <xenc:CipherData>''

'' <xenc:CipherValue>Nb0Mf...</xenc:CipherValue>''

'' </xenc:CipherData>''

'' <xenc:ReferenceList>''

'' <xenc:DataReference URI="#aDNa2iD"/>''

'' </xenc:ReferenceList>''

'' </xenc:EncryptedKey>''

'' <wsse:SecurityTokenReference wsu:Id="aZG0sG">''

'' <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-saml-token-profile-1.0#SAMLAssertionID" wsu:Id="a2tv1Uz"> 1106844369755</wsse:KeyIdentifier>''

'' </wsse:SecurityTokenReference>''

'' <saml:Assertion AssertionID="1106844369755" IssueInstant="2005-01-27T16:46:09.755Z" Issuer="www.my.com" MajorVersion="1" MinorVersion="1" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">''

'' ... ''

'' </saml:Assertion>''

'' <wsu:Timestamp wsu:Id="afc6fbe-a7d8-fbf3-9ac4-f884f435a9c1">''

'' <wsu:Created>2005-01-27T16:46:10Z</wsu:Created>''

'' <wsu:Expires>2005-01-27T18:46:10Z</wsu:Expires>''

'' </wsu:Timestamp>''

'' <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Id="sb738c7">''

'' <dsig:SignedInfo Id="obLkHzaCOrAW4kxC9az0bLA22">''

'' ...''

'' <dsig:Reference URI="#s91397860">''

'' ... ''

'' <dsig:DigestValue>5R3GSp+OOn17lSdE0knq4GXqgYM=</dsig:DigestValue>''

'' </dsig:Reference>''

'' </dsig:SignedInfo>''

'' <dsig:SignatureValue Id="a9utKU9UZk">LIkagbCr5bkXLs8l...</dsig:SignatureValue>''

'' <dsig:KeyInfo>''

'' <wsse:SecurityTokenReference>''

'' <wsse:Reference URI="#aXhOJ5" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>''

'' </wsse:SecurityTokenReference>''

'' </dsig:KeyInfo>''

'' </dsig:Signature>''

'' </wsse:Security>''

'' </soap:Header>''

'' <soap:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="s91397860">''

'' <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="aDNa2iD" Type="http://www.w3.org/2001/04/xmlenc#Content">''

'' <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>''

'' <xenc:CipherData>''

'' <xenc:CipherValue>XFM4J6C...</xenc:CipherValue>''

'' </xenc:CipherData>''

'' </xenc:EncryptedData>''

'' </soap:Body>''

''</soap:Envelope>''

===Types of tokens ===

A WSS Header may have the following types of security tokens in it:

* Username token

Defines mechanisms to pass username and, optionally, a password - the latter is described in the username profile document. Unless whole token is encrypted, a message which includes a clear-text password should always be transmitted via a secured channel. In situations where the target Web Service has access to clear-text passwords for verification (this might not be possible with LDAP or some other user directories, which do not return clear-text passwords), using a hashed version with nonce and a timestamp is generally preferable. The profile document defines an unambiguous algorithm for producing password hash:

''Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )''

* Binary token

They are used to convey binary data, such as X.509 certificates, in a text-encoded format, Base64 by default. The core specification defines BinarySecurityToken element, while profile documents specify additional attributes and sub-elements to handle attachment of various tokens. Presently, both the X.509 and the Kerberos profiles have been adopted.

'' <wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="aXhOJ5">''

'' MIICtzCCAi...''

'' </wsse:BinarySecurityToken>''

* XML token

These are meant for any kind of XML-based tokens, but primarily – for SAML assertions. The core specification merely mentions the possibility of inserting such tokens, leaving all details to the profile documents. At the moment, SAML 1.1 profile has been accepted by OASIS.

'' <saml:Assertion AssertionID="1106844369755" IssueInstant="2005-01-27T16:46:09.755Z" Issuer="www.my.com" MajorVersion="1" MinorVersion="1" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">''

'' ... ''

'' </saml:Assertion>''

Although technically it is not a security token, a Timestamp element may be inserted into a security header to ensure message’s freshness. See the further reading section for a design pattern on this.

===Referencing message parts ===

In order to retrieve security tokens, passed in the message, or to identify signed and encrypted message parts, the core specification adopts usage of a special attribute, wsu:Id. The only requirement on this attribute is that the values of such IDs should be unique within the scope of XML document where they are defined. Its application has a significant advantage for the intermediate processors, as it does not require understanding of the message’s XML Schema. Unfortunately, XML Signature and Encryption specifications do not allow for attribute extensibility (i.e. they have closed schema), so, when trying to locate signature or encryption elements, local IDs of the Signature and Encryption elements must be considered first.

WSS core specification also defines a general mechanism for referencing security tokens via SecurityTokenReference element. An example of such element, referring to a SAML assertion in the same header, is provided below:

'' <wsse:SecurityTokenReference wsu:Id="aZG0sGbRpXLySzgM1X6aSjg22">''

'' <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-saml-token-profile-1.0#SAMLAssertionID" wsu:Id="a2tv1Uz">''

'' 1106844369755''

'' </wsse:KeyIdentifier>''

'' </wsse:SecurityTokenReference>''

As this element was designed to refer to pretty much any possible token type (including encryption keys, certificates, SAML assertions, etc) both internal and external to the WSS Header, it is enormously complicated. The specification recommends using two of its possible four reference types – Direct References (by URI) and Key Identifiers (some kind of token identifier). Profile documents (SAML, X.509 for instance) provide additional extensions to these mechanisms to take advantage of specific qualities of different token types.

==Communication Protection Mechanisms ==

As was already explained earlier (see 0), channel security, while providing important services, is not a panacea, as it does not solve many of the issues, facing Web Service developers. WSS helps addressing some of them at the SOAP message level, using the mechanisms described in the sections below.

===Integrity ===

WSS specification makes use of the XML-dsig standard to ensure message integrity, restricting its functionality in certain cases; for instance, only explicitly referenced elements can be signed (i.e. no Embedding or Embedded signature modes are allowed). Prior to signing an XML document, a transformation is required to create its canonical representation, taking into account the fact that XML documents can be represented in a number of semantically equivalent ways. There are two main transformations defined by the XML Digital Signature WG at W3C, Inclusive and Exclusive Canonicalization Transforms (C14N and EXC-C14N), which differ in the way namespace declarations are processed. The WSS core specification specifically recommends using EXC-C14N, as it allows copying signed XML content into other documents without invalidating the signature.

In order to provide a uniform way of addressing signed tokens, WSS adds a Security Token Reference (STR) Dereference Transform option, which is comparable with dereferencing a pointer to an object of specific data type in programming languages. Similarly, in addition to the XML Signature-defined ways of addressing signing keys, WSS allows for references to signing security tokens through the STR mechanism (explained in 0), extended by token profiles to accommodate specific token types. A typical signature example is shown in an earlier sample in the section 0.

Typically, a XML signature is applied to secure elements such as SOAP Body and the timestamp, as well as any user credentials, passed in the request. There is an interesting twist when a particular element is both signed and encrypted, since these operations may follow (even repeatedly) in any order, and knowledge of their ordering is required for signature verification. To address this issue, the WSS core specification requires that each new element is pre-pended to the security header, thus defining the “natural” order of operations. A particularly nasty problem arises when there are several security headers in a single SOAP message, using overlapping signature and encryption blocks, as there is nothing in this case that would point to the right order of operations.

===Confidentiality ===

For its confidentiality protection, WSS relies on yet another standard, XML Encryption. Similarly to XML-dsig, this standard operates on selected elements of the SOAP message, but it then replaces the encrypted element’s data with a <xenc:EncryptedData> sub-element carrying the encrypted bytes. For encryption efficiency, the specification recommends using a unique key, which is then encrypted by the recipient’s public key and pre-pended to the security header in a <xenc:EncryptedKey> element. A SOAP message with encrypted body is shown in the section 0.

===Freshness ===

SOAP messages’ freshness is addressed via timestamp mechanism – each security header may contain just one such element, which states, in UTC time and using the UTC time format, creation and expiration moments of the security header. It is important to realize that the timestamp is applied to the WSS Header, not to the SOAP message itself, since the latter may contain multiple security headers, each with a different timestamp. There is an unresolved problem with this “single timestampt” approach, since, once the timestamp is created and signed, it is impossible to update it without breaking existing signatures, even in case of a legitimate change in the WSS Header.

'' <wsu:Timestamp wsu:Id="afc6fbe-a7d8-fbf3-9ac4-f884f435a9c1">''

'' <wsu:Created>2005-01-27T16:46:10Z</wsu:Created>''

'' <wsu:Expires>2005-01-27T18:46:10Z</wsu:Expires>''

'' </wsu:Timestamp>''

If a timestamp is included in a message, it is typically signed to prevent tampering and replay attacks. There is no mechanism foreseen to address clock synchronization issue (which, as was already point out earlier, is generally not an issue in modern day systems) – this has to be addressed out-of-band as far as the WSS mechanics is concerned. See the further reading section for a design pattern addressing this issue.

==Access Control Mechanisms ==

When it comes to access control decisions, Web Services do not offer specific protection mechanisms by themselves – they just have the means to carry the tokens and data payloads in a secure manner between source and destination SOAP endpoints.

For more complete description of access control tasks, please, refer to other sections of this Guide.

===Identification ===

Identification represents a claim to have certain identity, which is expressed by attaching certain information to the message. This can be a username, a SAML assertion, a Kerberos ticket, or any other piece of information, from which the service can infer who the caller claims to be.

WSS represents a very good way to convey this information, as it defines an extensible mechanism for attaching various token types to a message (see 0). It is the receiver’s job to extract the attached token and figure out which identity it carries, or to reject the message if it can find no acceptable token in it.

===Authentication ===

Authentication can come in two flavors – credentials verification or token validation. The subtle difference between the two is that tokens are issued after some kind of authentication has already happened prior to the current invocation, and they usually contain user’s identity along with the proof of its integrity.

WSS offers support for a number of standard authentication protocols by defining binding mechanism for transmitting protocol-specific tokens and reliably linking them to the sender. However, the mechanics of proof that the caller is who he claims to be is completely at the Web Service’s discretion. Whether it takes the supplied username and password’s hash and checks it against the backend user store, or extracts subject name from the X.509 certificate used for signing the message, verifies the certificate chain and looks up the user in its store – at the moment, there are no requirements or standards which would dictate that it should be done one way or another.

===Authorization ===

XACML may be used for expressing authorization rules, but its usage is not Web Service-specific – it has much broader scope. So, whatever policy or role-based authorization mechanism the host server already has in place will most likely be utilized to protect the deployed Web Services deployed as well.

Depending on the implementation, there may be several layers of authorization involved at the server. For instance, JSRs 224 (JAX-RPC 2.0) and 109 (Implementing Enterprise Web Services), which define Java binding for Web Services, specify implementing Web Services in J2EE containers. This means that when a Web Service is accessed, there will be a URL authorization check executed by the J2EE container, followed by a check at the Web Service layer for the Web Service-specific resource. Granularity of such checks is implementation-specific and is not dictated by any standards. In the Windows universe it happens in a similar fashion, since IIS is going to execute its access checks on the incoming HTTP calls before they reach the ASP.NET runtime, where SOAP message is going to be further decomposed and analyzed.

===Policy Agreement ===

Normally, Web Services’ communication is based on the endpoint’s public interface, defined in its WSDL file. This descriptor has sufficient details to express SOAP binding requirements, but it does not define any security parameters, leaving Web Service developers struggling to find out-of-band mechanisms to determine the endpoint’s security requirements.

To make up for these shortcomings, WS-Policy specification was conceived as a mechanism for expressing complex policy requirements and qualities, sort of WSDL on steroids. Through the published policy SOAP endpoints can advertise their security requirements, and their clients can apply appropriate measures of message protection to construct the requests. The general WS-Policy specification (actually comprised of three separate documents) also has extensions for specific policy types, one of them – for security, WS-SecurityPolicy.

If the requestor does not possess the required tokens, it can try obtaining them via trust mechanism, using WS-Trust-enabled services, which are called to securely exchange various token types for the requested identity.

[[Image: Using Trust Service.gif|Figure 5. Using Trust service]]

Unfortunately, both WS-Policy and WS-Trust specifications have not been submitted for standardization to public bodies, and their development is progressing via private collaboration of several companies, although it was opened up for other participants as well. As a positive factor, there have been several interoperability events conducted for these specifications, so the development process of these critical links in the Web Services’ security infrastructure is not a complete black box.

==Forming Web Service Chains ==

Many existing or planned implementations of SOA or B2B systems rely on dynamic chains of Web Services for accomplishing various business specific tasks, from taking the orders through manufacturing and up to the distribution process.

[[Image:Service Chain.gif|Figure 6: Service chain]]

This is in theory. In practice, there are a lot of obstacles hidden among the way, and one of the major ones among them – security concerns about publicly exposing processing functions to intra- or Internet-based clients.

Here is just a few of the issues that hamper Web Services interaction – incompatible authentication and authorization models for users, amount of trust between services themselves and ways of establishing such trust, maintaining secure connections, and synchronization of user directories or otherwise exchanging users’ attributes. These issues will be briefly tackled in the following paragraphs.

===Incompatible user access control models ===

As explained earlier, in section 0, Web Services themselves do not include separate extensions for access control, relying instead on the existing security framework. What they do provide, however, are mechanisms for discovering and describing security requirements of a SOAP service (via WS-Policy), and for obtaining appropriate security credentials via WS-Trust based services.

===Service trust ===

In order to establish mutual trust between client and service, they have to satisfy each other’s policy requirements. A simple and popular model is mutual certificate authentication via SSL, but it is not scalable for open service models, and supports only one authentication type. Services that require more flexibility have to use pretty much the same access control mechanisms as with users to establish each other’s identities prior to engaging in a conversation.

===Secure connections ===

Once trust is established it would be impractical to require its confirmation on each interaction. Instead, a secure client-server link is formed and maintained all time while client’s session is active. Again, the most popular mechanism today for maintaining such link is SSL, but it is not a Web Service-specific mechanism, and it has a number of shortcomings when applied to SOAP communication, as explained in 0.

===Synchronization of user directories ===

This is a very acute problem when dealing with cross-domain applications, as users’ population tends to change frequently among different domains. So, how does a service in domain B decide whether it is going to trust user’s claim that he has been already authenticated in domain A? There exist different aspects of this problem. First – a common SSO mechanism, which implies that a user is known in both domains (through synchronization, or by some other means), and authentication tokens from one domain are acceptable in another. In Web Services world, this would be accomplished by passing around a SAML or Kerberos token for a user.

===Domain federation ===

Another aspect of the problem is when users are not shared across domains, but merely the fact that a user with certain ID has successfully authenticated in another domain, as would be the case with several large corporations, which would like to form a partnership, but would be reluctant to share customers’ details. The decision to accept this request is then based on the inter-domain procedures, establishing special trust relationships and allowing for exchanging such opaque tokens, which would be an example of Federation relationships. Of those efforts, most notable example is Liberty Alliance project, which is now being used as a basis for SAML 2.0 specifications. The work in this area is still far from being completed, and most of the existing deployments are nothing more than POC or internal pilot projects than to real cross-companies deployments, although LA’s website does list some case studies of large-scale projects.

==Available Implementations ==

It is important to realize from the beginning that no security standard by itself is going to provide security to the message exchanges – it is the installed implementations, which will be assessing conformance of the incoming SOAP messages to the applicable standards, as well as appropriately securing the outgoing messages.

===.NET – Web Service Extensions ===

Since new standards are being developed at a rather quick pace, .NET platform is not trying to catch up immediately, but uses Web Service Extensions (WSE) instead. WSE, currently at the version 2.0, adds development and runtime support for the latest Web Service security standards to the platform and development tools, even while they are still “work in progress”. Once standards mature, their support is incorporated into new releases of the .NET platform, which is what is going to happen when .NET 2.0 finally sees the world. The next release of WSE, 3.0, is going to coincide with VS.2005 release and will take advantages of the latest innovations of .NET 2.0 platform in messaging and Web Application areas.

Considering that Microsoft is one of the most active players in the Web Service security area and recognizing its influence in the industry, its WSE implementation is probably one of the most complete and up to date, and it is strongly advisable to run at least a quick interoperability check with WSE-secured .NET Web Service clients. If you have a Java-based Web Service, and the interoperability is a requirement (which is usually the case), in addition to the questions of security testing one needs to keep in mind the basic interoperability between Java and .NET Web Service data structures.

This is especially important since current versions of .NET Web Service tools frequently do not cleanly handle WS-Security’s and related XML schemas as published by OASIS, so some creativity on the part of a Web Service designer is needed. That said – WSE package itself contains very rich and well-structured functionality, which can be utilized both with ASP.NET-based and standalone Web Service clients to check incoming SOAP messages and secure outgoing ones at the infrastructure level, relieving Web Service programmers from knowing these details. Among other things, WSE 2.0 supports the most recent set of WS-Policy and WS-Security profiles, providing for basic message security and WS-Trust with WS-SecureConversation. Those are needed for establishing secure exchanges and sessions - similar to what SSL does at the transport level, but applied to message-based communication.

===Java toolkits ===

Most of the publicly available Java toolkits work at the level of XML security, i.e. XML-dsig and XML-enc – such as IBM’s XML Security Suite and Apache’s XML Security project. Java’s JSR 105 and JSR 106 (still not finalized) define Java bindings for signatures and encryption, which will allow plugging the implementations as JCA providers once work on those JSRs is completed.

Moving one level up, to address Web Services themselves, the picture becomes muddier – at the moment, there are many implementations in various stages of incompleteness. For instance, Apache is currently working on the WSS4J project, which is moving rather slowly, and there is commercial software package from Phaos (now owned by Oracle), which suffers from a lot of implementation problems.

A popular choice among Web Service developers today is Sun’s JWSDP, which includes support for Web Service security. However, its support for Web Service security specifications in the version 1.5 is only limited to implementation of the core WSS standard with username and X.509 certificate profiles. Security features are implemented as part of the JAX-RPC framework and configuration-driven, which allows for clean separation from the Web Service’s implementation.

===Hardware, software systems ===

This category includes complete systems, rather than toolkits or frameworks. On one hand, they usually provide rich functionality right off the shelf, on the other hand – its usage model is rigidly constrained by the solution’s architecture and implementation. This is in contrast to the toolkits, which do not provide any services by themselves, but handing system developers necessary tools to include the desired Web Service security features in their products… or to shoot themselves in the foot by applying them inappropriately.

These systems can be used at the infrastructure layer to verify incoming messages against the effective policy, check signatures, tokens, etc, before passing them on to the target Web Service. When applied to the outgoing SOAP messages, they act as a proxy, now altering the messages to decorate with the required security elements, sign and/or encrypt them.

Software systems are characterized by significant configuration flexibility, but comparatively slow processing. On the bright side, they often provide high level of integration with the existing enterprise infrastructure, relying on the back-end user and policy stores to look at the credentials, extracted from the WSS header, from the broader perspective. An example of such service is TransactionMinder from the former Netegrity – a Policy Enforcement Point for Web Services behind it, layered on top of the Policy Server, which makes policy decisions by checking the extracted credentials against the configured stores and policies.

For hardware systems, performance is the key – they have already broken gigabyte processing threshold, and allow for real-time processing of huge documents, decorated according to the variety of the latest Web Service security standards, not only WSS. The usage simplicity is another attractive point of those systems - in the most trivial cases, the hardware box may be literally dropped in, plugged, and be used right away. These qualities come with a price, however – this performance and simplicity can be achieved as long as the user stays within the pre-configured confines of the hardware box. The moment he tries to integrate with the back-end stores via callbacks (for those solutions that have this capability, since not all of them do), most of the advantages are lost. As an example of such hardware device, DataPower provides a nice XS40 XML Security Gateway, which acts both as the inbound firewall and the outbound proxy to handle XML traffic in real time.

==Problems ==

As is probably clear from the previous sections, Web Services are still experiencing a lot of turbulence, and it will take a while before they can really catch on. Here is a brief look at what problems surround currently existing security standards and their implementations.

===Immaturity of the standards ===

Most of the standards are either very recent (couple years old at most), or still being developed. Although standards development is done in committees, which, presumably, reduces risks by going through an exhaustive reviewing and commenting process, some error scenarios still slip in periodically, as no theory can possibly match the testing resulting from pounding by thousands of developers working in the real field.

Additionally, it does not help that for political reasons some of this standards are withheld from public process, which is the case with many standards from the WSA arena (see 0), or that some of the efforts are duplicated, as was the case with LA and WS-Federation specifications.

===Performance ===

XML parsing is a slow task, which is an accepted reality, and SOAP processing slows it down even more. Now, with expensive cryptographic and textual conversion operations thrown into the mix, these tasks become a performance bottleneck, even with the latest crypto- and XML-processing hardware solutions offered today. All of the products currently on the market are facing this issue, and they are trying to resolve it with varying degrees of success.

Hardware solutions, while substantially (by orders of magnitude) improving the performance, can not always be used as an optimal solution, as they can not be easily integrated with the already existing back-end software infrastructure, at least – not without making performance sacrifices. Another consideration whether hardware-based systems are the right solution – they are usually highly specialized in what they are doing, while modern Application Servers and security frameworks can usually offer a much greater variety of protection mechanisms, protecting not only Web Services, but also other deployed applications in a uniform and consistent way.

===Complexity and interoperability ===

As could be deduced from the previous sections, Web Service security standards are fairly complex, and have very steep learning curve associated with them. Most of the current products, dealing with Web Service security, suffer from very mediocre usability due to the complexity of the underlying infrastructure. Configuring all different policies, identities, keys, and protocols takes a lot of time and good understanding of the involved technologies, as most of the times errors that end users are seeing have very cryptic and misleading descriptions.

In order to help administrators and reduce security risks from service misconfigurations, many companies develop policy templates, which group together best practices for protecting incoming and outgoing SOAP messages. Unfortunately, this work is not currently on the radar of any of the standard’s bodies, so it appears unlikely that such templates will be released for public use any time soon. Closest to this effort may be WS-I’s Basic Security Profile (BSP), which tries to define the rules for better interoperability among Web Services, using a subset of common security features from various security standards like WSS. However, this work is not aimed at supplying the administrators with ready for deployment security templates matching the most popular business use cases, but rather at establishing the least common denominator.

===Key management ===

Key management usually lies at the foundation of any other security activity, as most protection mechanisms rely on cryptographic keys one way or another. While Web Services have XKMS protocol for key distribution, local key management still presents a huge challenge in most cases, since PKI mechanism has a lot of well-documented deployment and usability issues. Those systems that opt to use homegrown mechanisms for key management run significant risks in many cases, since questions of storing, updating, and recovering secret and private keys more often than not are not adequately addressed in such solutions.

==Further Reading ==

* Piliptchouk, D., WS-Security in the Enterprise, O’Reilly ONJava

http://www.onjava.com/pub/a/onjava/2005/02/09/wssecurity.html

http://www.onjava.com/pub/a/onjava/2005/03/30/wssecurity2.html

* WS-Security OASIS site

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

* Microsoft, ''What’s new with WSE 3.0''

http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx?pull=/library/en-us/dnwse/html/newwse3.asp

* Eoin Keary, Preventing DOS attacks on web services

https://www.threatsandcountermeasures.com/wiki/default.aspx/ThreatsAndCountermeasuresCommunityKB.PreventingDOSAttacksOnWebServices

==Reference
[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Web Services]]

Web Services

2007-06-09T15:58:43Z

Mylene: /* WS-Security Building Blocks */ updated the associated specifications

[[Guide Table of Contents]]
__TOC__

This section of the Guide details the common issues facing Web services developers, and methods to address common issues. Due to the space limitations, it cannot look at all of the surrounding issues in great detail, since each of them deserves a separate book of its own. Instead, an attempt is made to steer the reader to the appropriate usage patterns, and warn about potential roadblocks on the way.

Web Services have received a lot of press, and with that comes a great deal of confusion over what they really are. Some are heralding Web Services as the biggest technology breakthrough since the web itself; others are more skeptical that they are nothing more than evolved web applications. In either case, the issues of web application security apply to web services just as they do to web applications.

At the simplest level, web services can be seen as a specialized web application that differs mainly at the presentation tier level. While web applications typically are HTML-based, web services are XML-based. Interactive users for B2C transactions normally access web applications, while web services are employed as building blocks by other web applications for forming B2B chains using the so-called SOA model. Web services typically present a public functional interface, callable in a programmatic fashion, while web applications tend to deal with a richer set of features and are content-driven in most cases.

==Securing Web Services ==

Web services, like other distributed applications, require protection at multiple levels:

* SOAP messages that are sent on the wire should be delivered confidentially and without tampering

* The server needs to be confident who it is talking to and what the clients are entitled to

* The clients need to know that they are talking to the right server, and not a phishing site (see the Phishing chapter for more information)

* System message logs should contain sufficient information to reliably reconstruct the chain of events and track those back to the authenticated callers

Correspondingly, the high-level approaches to solutions, discussed in the following sections, are valid for pretty much any distributed application, with some variations in the implementation details.

The good news for Web Services developers is that these are infrastructure-level tasks, so, theoretically, it is only the system administrators who should be worrying about these issues. However, for a number of reasons discussed later in this chapter, WS developers usually have to be at least aware of all these risks, and oftentimes they still have to resort to manually coding or tweaking the protection components.

==Communication security ==

There is a commonly cited statement, and even more often implemented approach – “we are using SSL to protect all communication, we are secure”. At the same time, there have been so many articles published on the topic of “channel security vs. token security” that it hardly makes sense to repeat those arguments here. Therefore, listed below is just a brief rundown of most common pitfalls when using channel security alone:

* It provides only “point-to-point” security

Any communication with multiple “hops” requires establishing separate channels (and trusts) between each communicating node along the way. There is also a subtle issue of trust transitivity, as trusts between node pairs {A,B} and {B,C} do not automatically imply {A,C} trust relationship.

* Storage issue

After messages are received on the server (even if it is not the intended recipient), they exist in the clear-text form, at least – temporarily. Storing the transmitted information at the intermediate aggravates the problem or destination servers in log files (where it can be browsed by anybody) and local caches.

* Lack of interoperability

While SSL provides a standard mechanism for transport protection, applications then have to utilize highly proprietary mechanisms for transmitting credentials, ensuring freshness, integrity, and confidentiality of data sent over the secure channel. Using a different server, which is semantically equivalent, but accepts a different format of the same credentials, would require altering the client and prevent forming automatic B2B service chains.

Standards-based token protection in many cases provides a superior alternative for message-oriented Web Service SOAP communication model.

That said – the reality is that the most Web Services today are still protected by some form of channel security mechanism, which alone might suffice for a simple internal application. However, one should clearly realize the limitations of such approach, and make conscious trade-offs at the design time, whether channel, token, or combined protection would work better for each specific case.

==Passing credentials ==

In order to enable credentials exchange and authentication for Web Services, their developers must address the following issues.

First, since SOAP messages are XML-based, all passed credentials have to be converted to text format. This is not a problem for username/password types of credentials, but binary ones (like X.509 certificates or Kerberos tokens) require converting them into text prior to sending and unambiguously restoring them upon receiving, which is usually done via a procedure called Base64 encoding and decoding.

Second, passing credentials carries an inherited risk of their disclosure – either by sniffing them during the wire transmission, or by analyzing the server logs. Therefore, things like passwords and private keys need to be either encrypted, or just never sent “in the clear”. Usual ways to avoid sending sensitive credentials are using cryptographic hashing and/or signatures.

==Ensuring message freshness ==

Even a valid message may present a danger if it is utilized in a “replay attack” – i.e. it is sent multiple times to the server to make it repeat the requested operation. This may be achieved by capturing an entire message, even if it is sufficiently protected against tampering, since it is the message itself that is used for attack now (see the XML Injection section of the Interpreter Injection chapter).

Usual means to protect against replayed messages is either using unique identifiers (nonces) on messages and keeping track of processed ones, or using a relatively short validity time window. In the Web Services world, information about the message creation time is usually communicated by inserting timestamps, which may just tell the instant the message was created, or have additional information, like its expiration time, or certain conditions.

The latter solution, although easier to implement, requires clock synchronization and is sensitive to “server time skew,” whereas server or clients clocks drift too much, preventing timely message delivery, although this usually does not present significant problems with modern-day computers. A greater issue lies with message queuing at the servers, where messages may be expiring while waiting to be processed in the queue of an especially busy or non-responsive server.

==Protecting message integrity ==

When a message is received by a web service, it must always ask two questions: “whether I trust the caller,” “whether it created this message.” Assuming that the caller trust has been established one way or another, the server has to be assured that the message it is looking at was indeed issued by the caller, and not altered along the way (intentionally or not). This may affect technical qualities of a SOAP message, such as the message’s timestamp, or business content, such as the amount to be withdrawn from the bank account. Obviously, neither change should go undetected by the server.

In communication protocols, there are usually some mechanisms like checksum applied to ensure packet’s integrity. This would not be sufficient, however, in the realm of publicly exposed Web Services, since checksums (or digests, their cryptographic equivalents) are easily replaceable and cannot be reliably tracked back to the issuer. The required association may be established by utilizing HMAC, or by combining message digests with either cryptographic signatures or with secret key-encryption (assuming the keys are only known to the two communicating parties) to ensure that any change will immediately result in a cryptographic error.

==Protecting message confidentiality ==

Oftentimes, it is not sufficient to ensure the integrity – in many cases it is also desirable that nobody can see the data that is passed around and/or stored locally. It may apply to the entire message being processed, or only to certain parts of it – in either case, some type of encryption is required to conceal the content. Normally, symmetric encryption algorithms are used to encrypt bulk data, since it is significantly faster than the asymmetric ones. Asymmetric encryption is then applied to protect the symmetric session keys, which, in many implementations, are valid for one communication only and are subsequently discarded.

Applying encryption requires conducting an extensive setup work, since the communicating parties now have to be aware of which keys they can trust, deal with certificate and key validation, and know which keys should be used for communication.

In many cases, encryption is combined with signatures to provide both integrity and confidentiality. Normally, signing keys are different from the encrypting ones, primarily because of their different lifecycles – signing keys are permanently associated with their owners, while encryption keys may be invalidated after the message exchange. Another reason may be separation of business responsibilities - the signing authority (and the corresponding key) may belong to one department or person, while encryption keys are generated by the server controlled by members of IT department.

==Access control ==

After message has been received and successfully validated, the server must decide:

* Does it know who is requesting the operation (Identification)

* Does it trust the caller’s identity claim (Authentication)

* Does it allow the caller to perform this operation (Authorization)

There is not much WS-specific activity that takes place at this stage – just several new ways of passing the credentials for authentication. Most often, authorization (or entitlement) tasks occur completely outside of the Web Service implementation, at the Policy Server that protects the whole domain.

There is another significant problem here – the traditional HTTP firewalls do not help at stopping attacks at the Web Services. An organization would need a XML/SOAP firewall, which is capable of conducting application-level analysis of the web server’s traffic and make intelligent decision about passing SOAP messages to their destination. The reader would need to refer to other books and publications on this very important topic, as it is impossible to cover it within just one chapter.

==Audit ==

A common task, typically required from the audits, is reconstructing the chain of events that led to a certain problem. Normally, this would be achieved by saving server logs in a secure location, available only to the IT administrators and system auditors, in order to create what is commonly referred to as “audit trail”. Web Services are no exception to this practice, and follow the general approach of other types of Web Applications.

Another auditing goal is non-repudiation, meaning that a message can be verifiably traced back to the caller. Following the standard legal practice, electronic documents now require some form of an “electronic signature”, but its definition is extremely broad and can mean practically anything – in many cases, entering your name and birthday qualifies as an e-signature.

As far as the WS are concerned, such level of protection would be insufficient and easily forgeable. The standard practice is to require cryptographic digital signatures over any content that has to be legally binding – if a document with such a signature is saved in the audit log, it can be reliably traced to the owner of the signing key.

==Web Services Security Hierarchy ==

Technically speaking, Web Services themselves are very simple and versatile – XML-based communication, described by an XML-based grammar, called Web Services Description Language (WSDL, see http://www.w3.org/TR/2005/WD-wsdl20-20050510), which binds abstract service interfaces, consisting of messages, expressed as XML Schema, and operations, to the underlying wire format. Although it is by no means a requirement, the format of choice is currently SOAP over HTTP. This means that Web Service interfaces are described in terms of the incoming and outgoing SOAP messages, transmitted over HTTP protocol.

===Standards committees ===

Before reviewing the individual standards, it is worth taking a brief look at the organizations, which are developing and promoting them. There are quite a few industry-wide groups and consortiums, working in this area, most important of which are listed below.

W3C (see http://www.w3.org) is the most well known industry group, which owns many Web-related standards and develops them in Working Group format. Of particular interest to this chapter are XML Schema, SOAP, XML-dsig, XML-enc, and WSDL standards (called recommendations in the W3C’s jargon).

OASIS (see http://www.oasis-open.org) mostly deals with Web Service-specific standards, not necessarily security-related. It also operates on a committee basis, forming so-called Technical Committees (TC) for the standards that it is going to be developing. Of interest for this discussion, OASIS owns WS-Security and SAML standards.

Web Service Interoperability group (WS-I, see http://www.ws-i.org/) was formed to promote general framework for interoperable Web Services. Mostly its work consists of taking other broadly accepted standards, and develop so-called profiles, or set of requirements for conforming Web Service implementations. In particular, its Basic Security Profile (BSP) relies on the OASIS’ WS-Security standard and specifies sets of optional and required security features in Web Services that claim interoperability.

Liberty Alliance (LA, see http://projectliberty.org) consortium was formed to develop and promote an interoperable Identity Federation framework. Although this framework is not strictly Web Service-specific, but rather general, it is important for this topic because of its close relation with the SAML standard developed by OASIS.

Besides the previously listed organizations, there are other industry associations, both permanently established and short-lived, which push forward various Web Service security activities. They are usually made up of software industry’s leading companies, such as Microsoft, IBM, Verisign, BEA, Sun, and others, that join them to work on a particular issue or proposal. Results of these joint activities, once they reach certain maturity, are often submitted to standardizations committees as a basis for new industry standards.

==SOAP ==

Simple Object Access Protocol (SOAP, see http://www.w3.org/TR/2003/REC-soap12-part1-20030624/) provides an XML-based framework for exchanging structured and typed information between peer services. This information, formatted into Header and Body, can theoretically be transmitted over a number of transport protocols, but only HTTP binding has been formally defined and is in active use today. SOAP provides for Remote Procedure Call-style (RPC) interactions, similar to remote function calls, and Document-style communication, with message contents based exclusively on XML Schema definitions in the Web Service’s WSDL. Invocation results may be optionally returned in the response message, or a Fault may be raised, which is roughly equivalent to using exceptions in traditional programming languages.

SOAP protocol, while defining the communication framework, provides no help in terms of securing message exchanges – the communications must either happen over secure channels, or use protection mechanisms described later in this chapter.

===XML security specifications (XML-dsig & Encryption) ===

XML Signature (XML-dsig, see http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/), and XML Encryption (XML-enc, see http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/) add cryptographic protection to plain XML documents. These specifications add integrity, message and signer authentication, as well as support for encryption/decryption of whole XML documents or only of some elements inside them.

The real value of those standards comes from the highly flexible framework developed to reference the data being processed (both internal and external relative to the XML document), refer to the secret keys and key pairs, and to represent results of signing/encrypting operations as XML, which is added to/substituted in the original document.

However, by themselves, XML-dsig and XML-enc do not solve the problem of securing SOAP-based Web Service interactions, since the client and service first have to agree on the order of those operations, where do look for the signature, how to retrieve cryptographic tokens, which message elements should be signed and encrypted, how long a message is considered to be valid, and so on. These issues are addressed by the higher-level specifications, reviewed in the following sections.

===Security specifications ===

In addition to the above standards, there is a broad set of security-related specifications being currently developed for various aspects of Web Service operations.

One of them is SAML, which defines how identity, attribute, and authorization assertions should be exchanged among participating services in a secure and interoperable way.

A broad consortium, headed by Microsoft and IBM, with the input from Verisign, RSA Security, and other participants, developed a family of specifications, collectively known as “Web Services Roadmap”. Its foundation, WS-Security, has been submitted to OASIS and became an OASIS standard in 2004. Other important specifications from this family are still found in different development stages, and plans for their submission have not yet been announced, although they cover such important issues as security policies (WS-Policy et al), trust issues and security token exchange (WS-Trust), establishing context for secure conversation (WS-SecureConversation). One of the specifications in this family, WS-Federation, directly competes with the work being done by the LA consortium, and, although it is supposed to be incorporated into the Longhorn release of Windows, its future is not clear at the moment, since it has been significantly delayed and presently does not have industry momentum behind it.

==WS-Security Standard ==

WS-Security specification (WSS) was originally developed by Microsoft, IBM, and Verisign as part of a “Roadmap”, which was later renamed to Web Services Architecture, or WSA. WSS served as the foundation for all other specifications in this domain, creating a basic infrastructure for developing message-based security exchange. Because of its importance for establishing interoperable Web Services, it was submitted to OASIS and, after undergoing the required committee process, became an officially accepted standard. Current version is 1.0, and the work on the version 1.1 of the specification is under way and is expected to be finishing in the second half of 2005.

===Organization of the standard ===

The WSS standard itself deals with several core security areas, leaving many details to so-called profile documents. The core areas, broadly defined by the standard, are:

* Ways to add security headers (WSSE Header) to SOAP Envelopes

* Attachment of security tokens and credentials to the message

* Inserting a timestamp

* Signing the message

* Encrypting the message

* Extensibility

Flexibility of the WS-Security standard lies in its extensibility, so that it remains adaptable to new types of security tokens and protocols that are being developed. This flexibility is achieved by defining additional profiles for inserting new types of security tokens into the WSS framework. While the signing and encrypting parts of the standards are not expected to require significant changes (only when the underlying XML-dsig and XML-enc are updated), the types of tokens, passed in WSS messages, and ways of attaching them to the message may vary substantially. At the high level the WSS standard defines three types of security tokens, attachable to a WSS Header: Username/password, Binary, and XML tokens. Each of those types is further specified in one (or more) profile document, which defines additional token’s attributes and elements, needed to represent a particular type of security token.

[[Image:WSS_Specification_Hierarchy.gif|Figure 4: WSS specification hierarchy]]

===Purpose ===

The primary goal of the WSS standard is providing tools for message-level communication protection, whereas each message represents an isolated piece of information, carrying enough security data to verify all important message properties, such as: authenticity, integrity, freshness, and to initiate decryption of any encrypted message parts. This concept is a stark contrast to the traditional channel security, which methodically applies pre-negotiated security context to the whole stream, as opposed to the selective process of securing individual messages in WSS. In the Roadmap, that type of service is eventually expected to be provided by implementations of standards like WS-SecureConversation.

From the beginning, the WSS standard was conceived as a message-level toolkit for securely delivering data for higher level protocols. Those protocols, based on the standards like WS-Policy, WS-Trust, Liberty Alliance, rely on the transmitted tokens to implement access control policies, token exchange, and other types of protection and integration. However, taken alone, the WSS standard does not mandate any specific security properties, and an ad-hoc application of its constructs can lead to subtle security vulnerabilities and hard to detect problems, as is also discussed in later sections of this chapter.

==WS-Security Building Blocks ==

The WSS standard actually consists of a number of documents – one core document, which defines how security headers may be included into SOAP envelope and describes all high-level blocks, which must be present in a valid security header. Profile documents have the dual task of extending definitions for the token types they are dealing with, providing additional attributes, elements, as well as defining relationships left out of the core specification, such as using attachments.

Core WSS 1.1 specification, located at http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf, defines several types of security tokens (discussed later in this section – see 0), ways to reference them, timestamps, and ways to apply XML-dsig and XML-enc in the security headers – see the XML Dsig section for more details about their general structure.

Associated specifications are:

* Username token profile 1.1, located at http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf, which adds various password-related extensions to the basic UsernameToken from the core specification

* X.509 token profile 1.1, located at http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf which specifies, how X.509 certificates may be passed in the BinarySecurityToken, specified by the core document

* SAML Token profile 1.1, located at http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf that specifies how XML-based SAML tokens can be inserted into WSS headers.

* Kerberos Token Profile 1.1, located at http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf that defines how to encode Kerberos tickets and attach them to SOAP messages.

* Rights Expression Language (REL) Token Profile 1.1, located at http://www.oasis-open.org/committees/download.php/16687/oasis-wss-rel-token-profile-1.1.pdf that describes the use of ISO/IEC 21000-5 Rights Expressions with respect to the WS-Security specification.

* SOAP with Attachments (SWA) Profile 1.1, located at http://www.oasis-open.org/committees/download.php/16672/wss-v1.1-spec-os-SwAProfile.pdf that describes how to use WSS-Sec with SOAP Messages with Attachments.

===How data is passed ===

WSS security specification deals with two distinct types of data: security information, which includes security tokens, signatures, digests, etc; and message data, i.e. everything else that is passed in the SOAP message. Being an XML-based standard, WSS works with textual information grouped into XML elements. Any binary data, such as cryptographic signatures or Kerberos tokens, has to go through a special transform, called Base64 encoding/decoding, which provides straightforward conversion from binary to ASCII formats and back. Example below demonstrates how binary data looks like in the encoded format:

''cCBDQTAeFw0wNDA1MTIxNjIzMDRaFw0wNTA1MTIxNjIzMDRaMG8xCz''

After encoding a binary element, an attribute with the algorithm’s identifier is added to the XML element carrying the data, so that the receiver would know to apply the correct decoder to read it. These identifiers are defined in the WSS specification documents.

===Security header’s structure ===

A security header in a message is used as a sort of an envelope around a letter – it seals and protects the letter, but does not care about its content. This “indifference” works in the other direction as well, as the letter (SOAP message) should not know, nor should it care about its envelope (WSS Header), since the different units of information, carried on the envelope and in the letter, are presumably targeted at different people or applications.

A SOAP Header may actually contain multiple security headers, as long as they are addressed to different actors (for SOAP 1.1), or roles (for SOAP 1.2). Their contents may also be referring to each other, but such references present a very complicated logistical problem for determining the proper order of decryptions/signature verifications, and should generally be avoided. WSS security header itself has a loose structure, as the specification itself does not require any elements to be present – so, the minimalist header with an empty message will look like:

''<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">''

'' <soap:Header>''

'' <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="1">''

'' ''

'' </wsse:Security>''

'' </soap:Header>''

'' <soap:Body>''

'' </soap:Body>''

''</soap:Envelope>''

However, to be useful, it must carry some information, which is going to help securing the message. It means including one or more security tokens (see 0) with references, XML Signature, and XML Encryption elements, if the message is signed and/or encrypted. So, a typical header will look more like the following picture:

''<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">''

'' <soap:Header>''

'' <wsse:Security xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="1">''

'' <wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="aXhOJ5">MIICtzCCAi... ''

'' </wsse:BinarySecurityToken>''

'' <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">''

'' <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>''

'' <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">''

'' <wsse:SecurityTokenReference>''

'' <wsse:Reference URI="#aXhOJ5" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>''

'' </wsse:SecurityTokenReference> ''

'' </dsig:KeyInfo>''

'' <xenc:CipherData>''

'' <xenc:CipherValue>Nb0Mf...</xenc:CipherValue>''

'' </xenc:CipherData>''

'' <xenc:ReferenceList>''

'' <xenc:DataReference URI="#aDNa2iD"/>''

'' </xenc:ReferenceList>''

'' </xenc:EncryptedKey>''

'' <wsse:SecurityTokenReference wsu:Id="aZG0sG">''

'' <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-saml-token-profile-1.0#SAMLAssertionID" wsu:Id="a2tv1Uz"> 1106844369755</wsse:KeyIdentifier>''

'' </wsse:SecurityTokenReference>''

'' <saml:Assertion AssertionID="1106844369755" IssueInstant="2005-01-27T16:46:09.755Z" Issuer="www.my.com" MajorVersion="1" MinorVersion="1" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">''

'' ... ''

'' </saml:Assertion>''

'' <wsu:Timestamp wsu:Id="afc6fbe-a7d8-fbf3-9ac4-f884f435a9c1">''

'' <wsu:Created>2005-01-27T16:46:10Z</wsu:Created>''

'' <wsu:Expires>2005-01-27T18:46:10Z</wsu:Expires>''

'' </wsu:Timestamp>''

'' <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Id="sb738c7">''

'' <dsig:SignedInfo Id="obLkHzaCOrAW4kxC9az0bLA22">''

'' ...''

'' <dsig:Reference URI="#s91397860">''

'' ... ''

'' <dsig:DigestValue>5R3GSp+OOn17lSdE0knq4GXqgYM=</dsig:DigestValue>''

'' </dsig:Reference>''

'' </dsig:SignedInfo>''

'' <dsig:SignatureValue Id="a9utKU9UZk">LIkagbCr5bkXLs8l...</dsig:SignatureValue>''

'' <dsig:KeyInfo>''

'' <wsse:SecurityTokenReference>''

'' <wsse:Reference URI="#aXhOJ5" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>''

'' </wsse:SecurityTokenReference>''

'' </dsig:KeyInfo>''

'' </dsig:Signature>''

'' </wsse:Security>''

'' </soap:Header>''

'' <soap:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="s91397860">''

'' <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="aDNa2iD" Type="http://www.w3.org/2001/04/xmlenc#Content">''

'' <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>''

'' <xenc:CipherData>''

'' <xenc:CipherValue>XFM4J6C...</xenc:CipherValue>''

'' </xenc:CipherData>''

'' </xenc:EncryptedData>''

'' </soap:Body>''

''</soap:Envelope>''

===Types of tokens ===

A WSS Header may have the following types of security tokens in it:

* Username token

Defines mechanisms to pass username and, optionally, a password - the latter is described in the username profile document. Unless whole token is encrypted, a message which includes a clear-text password should always be transmitted via a secured channel. In situations where the target Web Service has access to clear-text passwords for verification (this might not be possible with LDAP or some other user directories, which do not return clear-text passwords), using a hashed version with nonce and a timestamp is generally preferable. The profile document defines an unambiguous algorithm for producing password hash:

''Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )''

* Binary token

They are used to convey binary data, such as X.509 certificates, in a text-encoded format, Base64 by default. The core specification defines BinarySecurityToken element, while profile documents specify additional attributes and sub-elements to handle attachment of various tokens. Presently, the X.509 profile has been adopted, and work is in progress on the Kerberos profile.

'' <wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="aXhOJ5">''

'' MIICtzCCAi...''

'' </wsse:BinarySecurityToken>''

* XML token

These are meant for any kind of XML-based tokens, but primarily – for SAML assertions. The core specification merely mentions the possibility of inserting such tokens, leaving all details to the profile documents. At the moment, SAML 1.1 profile has been accepted by OASIS.

'' <saml:Assertion AssertionID="1106844369755" IssueInstant="2005-01-27T16:46:09.755Z" Issuer="www.my.com" MajorVersion="1" MinorVersion="1" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">''

'' ... ''

'' </saml:Assertion>''

Although technically it is not a security token, a Timestamp element may be inserted into a security header to ensure message’s freshness. See the further reading section for a design pattern on this.

===Referencing message parts ===

In order to retrieve security tokens, passed in the message, or to identify signed and encrypted message parts, the core specification adopts usage of a special attribute, wsu:Id. The only requirement on this attribute is that the values of such IDs should be unique within the scope of XML document where they are defined. Its application has a significant advantage for the intermediate processors, as it does not require understanding of the message’s XML Schema. Unfortunately, XML Signature and Encryption specifications do not allow for attribute extensibility (i.e. they have closed schema), so, when trying to locate signature or encryption elements, local IDs of the Signature and Encryption elements must be considered first.

WSS core specification also defines a general mechanism for referencing security tokens via SecurityTokenReference element. An example of such element, referring to a SAML assertion in the same header, is provided below:

'' <wsse:SecurityTokenReference wsu:Id="aZG0sGbRpXLySzgM1X6aSjg22">''

'' <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-saml-token-profile-1.0#SAMLAssertionID" wsu:Id="a2tv1Uz">''

'' 1106844369755''

'' </wsse:KeyIdentifier>''

'' </wsse:SecurityTokenReference>''

As this element was designed to refer to pretty much any possible token type (including encryption keys, certificates, SAML assertions, etc) both internal and external to the WSS Header, it is enormously complicated. The specification recommends using two of its possible four reference types – Direct References (by URI) and Key Identifiers (some kind of token identifier). Profile documents (SAML, X.509 for instance) provide additional extensions to these mechanisms to take advantage of specific qualities of different token types.

==Communication Protection Mechanisms ==

As was already explained earlier (see 0), channel security, while providing important services, is not a panacea, as it does not solve many of the issues, facing Web Service developers. WSS helps addressing some of them at the SOAP message level, using the mechanisms described in the sections below.

===Integrity ===

WSS specification makes use of the XML-dsig standard to ensure message integrity, restricting its functionality in certain cases; for instance, only explicitly referenced elements can be signed (i.e. no Embedding or Embedded signature modes are allowed). Prior to signing an XML document, a transformation is required to create its canonical representation, taking into account the fact that XML documents can be represented in a number of semantically equivalent ways. There are two main transformations defined by the XML Digital Signature WG at W3C, Inclusive and Exclusive Canonicalization Transforms (C14N and EXC-C14N), which differ in the way namespace declarations are processed. The WSS core specification specifically recommends using EXC-C14N, as it allows copying signed XML content into other documents without invalidating the signature.

In order to provide a uniform way of addressing signed tokens, WSS adds a Security Token Reference (STR) Dereference Transform option, which is comparable with dereferencing a pointer to an object of specific data type in programming languages. Similarly, in addition to the XML Signature-defined ways of addressing signing keys, WSS allows for references to signing security tokens through the STR mechanism (explained in 0), extended by token profiles to accommodate specific token types. A typical signature example is shown in an earlier sample in the section 0.

Typically, a XML signature is applied to secure elements such as SOAP Body and the timestamp, as well as any user credentials, passed in the request. There is an interesting twist when a particular element is both signed and encrypted, since these operations may follow (even repeatedly) in any order, and knowledge of their ordering is required for signature verification. To address this issue, the WSS core specification requires that each new element is pre-pended to the security header, thus defining the “natural” order of operations. A particularly nasty problem arises when there are several security headers in a single SOAP message, using overlapping signature and encryption blocks, as there is nothing in this case that would point to the right order of operations.

===Confidentiality ===

For its confidentiality protection, WSS relies on yet another standard, XML Encryption. Similarly to XML-dsig, this standard operates on selected elements of the SOAP message, but it then replaces the encrypted element’s data with a <xenc:EncryptedData> sub-element carrying the encrypted bytes. For encryption efficiency, the specification recommends using a unique key, which is then encrypted by the recipient’s public key and pre-pended to the security header in a <xenc:EncryptedKey> element. A SOAP message with encrypted body is shown in the section 0.

===Freshness ===

SOAP messages’ freshness is addressed via timestamp mechanism – each security header may contain just one such element, which states, in UTC time and using the UTC time format, creation and expiration moments of the security header. It is important to realize that the timestamp is applied to the WSS Header, not to the SOAP message itself, since the latter may contain multiple security headers, each with a different timestamp. There is an unresolved problem with this “single timestampt” approach, since, once the timestamp is created and signed, it is impossible to update it without breaking existing signatures, even in case of a legitimate change in the WSS Header.

'' <wsu:Timestamp wsu:Id="afc6fbe-a7d8-fbf3-9ac4-f884f435a9c1">''

'' <wsu:Created>2005-01-27T16:46:10Z</wsu:Created>''

'' <wsu:Expires>2005-01-27T18:46:10Z</wsu:Expires>''

'' </wsu:Timestamp>''

If a timestamp is included in a message, it is typically signed to prevent tampering and replay attacks. There is no mechanism foreseen to address clock synchronization issue (which, as was already point out earlier, is generally not an issue in modern day systems) – this has to be addressed out-of-band as far as the WSS mechanics is concerned. See the further reading section for a design pattern addressing this issue.

==Access Control Mechanisms ==

When it comes to access control decisions, Web Services do not offer specific protection mechanisms by themselves – they just have the means to carry the tokens and data payloads in a secure manner between source and destination SOAP endpoints.

For more complete description of access control tasks, please, refer to other sections of this Guide.

===Identification ===

Identification represents a claim to have certain identity, which is expressed by attaching certain information to the message. This can be a username, a SAML assertion, a Kerberos ticket, or any other piece of information, from which the service can infer who the caller claims to be.

WSS represents a very good way to convey this information, as it defines an extensible mechanism for attaching various token types to a message (see 0). It is the receiver’s job to extract the attached token and figure out which identity it carries, or to reject the message if it can find no acceptable token in it.

===Authentication ===

Authentication can come in two flavors – credentials verification or token validation. The subtle difference between the two is that tokens are issued after some kind of authentication has already happened prior to the current invocation, and they usually contain user’s identity along with the proof of its integrity.

WSS offers support for a number of standard authentication protocols by defining binding mechanism for transmitting protocol-specific tokens and reliably linking them to the sender. However, the mechanics of proof that the caller is who he claims to be is completely at the Web Service’s discretion. Whether it takes the supplied username and password’s hash and checks it against the backend user store, or extracts subject name from the X.509 certificate used for signing the message, verifies the certificate chain and looks up the user in its store – at the moment, there are no requirements or standards which would dictate that it should be done one way or another.

===Authorization ===

XACML may be used for expressing authorization rules, but its usage is not Web Service-specific – it has much broader scope. So, whatever policy or role-based authorization mechanism the host server already has in place will most likely be utilized to protect the deployed Web Services deployed as well.

Depending on the implementation, there may be several layers of authorization involved at the server. For instance, JSRs 224 (JAX-RPC 2.0) and 109 (Implementing Enterprise Web Services), which define Java binding for Web Services, specify implementing Web Services in J2EE containers. This means that when a Web Service is accessed, there will be a URL authorization check executed by the J2EE container, followed by a check at the Web Service layer for the Web Service-specific resource. Granularity of such checks is implementation-specific and is not dictated by any standards. In the Windows universe it happens in a similar fashion, since IIS is going to execute its access checks on the incoming HTTP calls before they reach the ASP.NET runtime, where SOAP message is going to be further decomposed and analyzed.

===Policy Agreement ===

Normally, Web Services’ communication is based on the endpoint’s public interface, defined in its WSDL file. This descriptor has sufficient details to express SOAP binding requirements, but it does not define any security parameters, leaving Web Service developers struggling to find out-of-band mechanisms to determine the endpoint’s security requirements.

To make up for these shortcomings, WS-Policy specification was conceived as a mechanism for expressing complex policy requirements and qualities, sort of WSDL on steroids. Through the published policy SOAP endpoints can advertise their security requirements, and their clients can apply appropriate measures of message protection to construct the requests. The general WS-Policy specification (actually comprised of three separate documents) also has extensions for specific policy types, one of them – for security, WS-SecurityPolicy.

If the requestor does not possess the required tokens, it can try obtaining them via trust mechanism, using WS-Trust-enabled services, which are called to securely exchange various token types for the requested identity.

[[Image: Using Trust Service.gif|Figure 5. Using Trust service]]

Unfortunately, both WS-Policy and WS-Trust specifications have not been submitted for standardization to public bodies, and their development is progressing via private collaboration of several companies, although it was opened up for other participants as well. As a positive factor, there have been several interoperability events conducted for these specifications, so the development process of these critical links in the Web Services’ security infrastructure is not a complete black box.

==Forming Web Service Chains ==

Many existing or planned implementations of SOA or B2B systems rely on dynamic chains of Web Services for accomplishing various business specific tasks, from taking the orders through manufacturing and up to the distribution process.

[[Image:Service Chain.gif|Figure 6: Service chain]]

This is in theory. In practice, there are a lot of obstacles hidden among the way, and one of the major ones among them – security concerns about publicly exposing processing functions to intra- or Internet-based clients.

Here is just a few of the issues that hamper Web Services interaction – incompatible authentication and authorization models for users, amount of trust between services themselves and ways of establishing such trust, maintaining secure connections, and synchronization of user directories or otherwise exchanging users’ attributes. These issues will be briefly tackled in the following paragraphs.

===Incompatible user access control models ===

As explained earlier, in section 0, Web Services themselves do not include separate extensions for access control, relying instead on the existing security framework. What they do provide, however, are mechanisms for discovering and describing security requirements of a SOAP service (via WS-Policy), and for obtaining appropriate security credentials via WS-Trust based services.

===Service trust ===

In order to establish mutual trust between client and service, they have to satisfy each other’s policy requirements. A simple and popular model is mutual certificate authentication via SSL, but it is not scalable for open service models, and supports only one authentication type. Services that require more flexibility have to use pretty much the same access control mechanisms as with users to establish each other’s identities prior to engaging in a conversation.

===Secure connections ===

Once trust is established it would be impractical to require its confirmation on each interaction. Instead, a secure client-server link is formed and maintained all time while client’s session is active. Again, the most popular mechanism today for maintaining such link is SSL, but it is not a Web Service-specific mechanism, and it has a number of shortcomings when applied to SOAP communication, as explained in 0.

===Synchronization of user directories ===

This is a very acute problem when dealing with cross-domain applications, as users’ population tends to change frequently among different domains. So, how does a service in domain B decide whether it is going to trust user’s claim that he has been already authenticated in domain A? There exist different aspects of this problem. First – a common SSO mechanism, which implies that a user is known in both domains (through synchronization, or by some other means), and authentication tokens from one domain are acceptable in another. In Web Services world, this would be accomplished by passing around a SAML or Kerberos token for a user.

===Domain federation ===

Another aspect of the problem is when users are not shared across domains, but merely the fact that a user with certain ID has successfully authenticated in another domain, as would be the case with several large corporations, which would like to form a partnership, but would be reluctant to share customers’ details. The decision to accept this request is then based on the inter-domain procedures, establishing special trust relationships and allowing for exchanging such opaque tokens, which would be an example of Federation relationships. Of those efforts, most notable example is Liberty Alliance project, which is now being used as a basis for SAML 2.0 specifications. The work in this area is still far from being completed, and most of the existing deployments are nothing more than POC or internal pilot projects than to real cross-companies deployments, although LA’s website does list some case studies of large-scale projects.

==Available Implementations ==

It is important to realize from the beginning that no security standard by itself is going to provide security to the message exchanges – it is the installed implementations, which will be assessing conformance of the incoming SOAP messages to the applicable standards, as well as appropriately securing the outgoing messages.

===.NET – Web Service Extensions ===

Since new standards are being developed at a rather quick pace, .NET platform is not trying to catch up immediately, but uses Web Service Extensions (WSE) instead. WSE, currently at the version 2.0, adds development and runtime support for the latest Web Service security standards to the platform and development tools, even while they are still “work in progress”. Once standards mature, their support is incorporated into new releases of the .NET platform, which is what is going to happen when .NET 2.0 finally sees the world. The next release of WSE, 3.0, is going to coincide with VS.2005 release and will take advantages of the latest innovations of .NET 2.0 platform in messaging and Web Application areas.

Considering that Microsoft is one of the most active players in the Web Service security area and recognizing its influence in the industry, its WSE implementation is probably one of the most complete and up to date, and it is strongly advisable to run at least a quick interoperability check with WSE-secured .NET Web Service clients. If you have a Java-based Web Service, and the interoperability is a requirement (which is usually the case), in addition to the questions of security testing one needs to keep in mind the basic interoperability between Java and .NET Web Service data structures.

This is especially important since current versions of .NET Web Service tools frequently do not cleanly handle WS-Security’s and related XML schemas as published by OASIS, so some creativity on the part of a Web Service designer is needed. That said – WSE package itself contains very rich and well-structured functionality, which can be utilized both with ASP.NET-based and standalone Web Service clients to check incoming SOAP messages and secure outgoing ones at the infrastructure level, relieving Web Service programmers from knowing these details. Among other things, WSE 2.0 supports the most recent set of WS-Policy and WS-Security profiles, providing for basic message security and WS-Trust with WS-SecureConversation. Those are needed for establishing secure exchanges and sessions - similar to what SSL does at the transport level, but applied to message-based communication.

===Java toolkits ===

Most of the publicly available Java toolkits work at the level of XML security, i.e. XML-dsig and XML-enc – such as IBM’s XML Security Suite and Apache’s XML Security project. Java’s JSR 105 and JSR 106 (still not finalized) define Java bindings for signatures and encryption, which will allow plugging the implementations as JCA providers once work on those JSRs is completed.

Moving one level up, to address Web Services themselves, the picture becomes muddier – at the moment, there are many implementations in various stages of incompleteness. For instance, Apache is currently working on the WSS4J project, which is moving rather slowly, and there is commercial software package from Phaos (now owned by Oracle), which suffers from a lot of implementation problems.

A popular choice among Web Service developers today is Sun’s JWSDP, which includes support for Web Service security. However, its support for Web Service security specifications in the version 1.5 is only limited to implementation of the core WSS standard with username and X.509 certificate profiles. Security features are implemented as part of the JAX-RPC framework and configuration-driven, which allows for clean separation from the Web Service’s implementation.

===Hardware, software systems ===

This category includes complete systems, rather than toolkits or frameworks. On one hand, they usually provide rich functionality right off the shelf, on the other hand – its usage model is rigidly constrained by the solution’s architecture and implementation. This is in contrast to the toolkits, which do not provide any services by themselves, but handing system developers necessary tools to include the desired Web Service security features in their products… or to shoot themselves in the foot by applying them inappropriately.

These systems can be used at the infrastructure layer to verify incoming messages against the effective policy, check signatures, tokens, etc, before passing them on to the target Web Service. When applied to the outgoing SOAP messages, they act as a proxy, now altering the messages to decorate with the required security elements, sign and/or encrypt them.

Software systems are characterized by significant configuration flexibility, but comparatively slow processing. On the bright side, they often provide high level of integration with the existing enterprise infrastructure, relying on the back-end user and policy stores to look at the credentials, extracted from the WSS header, from the broader perspective. An example of such service is TransactionMinder from the former Netegrity – a Policy Enforcement Point for Web Services behind it, layered on top of the Policy Server, which makes policy decisions by checking the extracted credentials against the configured stores and policies.

For hardware systems, performance is the key – they have already broken gigabyte processing threshold, and allow for real-time processing of huge documents, decorated according to the variety of the latest Web Service security standards, not only WSS. The usage simplicity is another attractive point of those systems - in the most trivial cases, the hardware box may be literally dropped in, plugged, and be used right away. These qualities come with a price, however – this performance and simplicity can be achieved as long as the user stays within the pre-configured confines of the hardware box. The moment he tries to integrate with the back-end stores via callbacks (for those solutions that have this capability, since not all of them do), most of the advantages are lost. As an example of such hardware device, DataPower provides a nice XS40 XML Security Gateway, which acts both as the inbound firewall and the outbound proxy to handle XML traffic in real time.

==Problems ==

As is probably clear from the previous sections, Web Services are still experiencing a lot of turbulence, and it will take a while before they can really catch on. Here is a brief look at what problems surround currently existing security standards and their implementations.

===Immaturity of the standards ===

Most of the standards are either very recent (couple years old at most), or still being developed. Although standards development is done in committees, which, presumably, reduces risks by going through an exhaustive reviewing and commenting process, some error scenarios still slip in periodically, as no theory can possibly match the testing resulting from pounding by thousands of developers working in the real field.

Additionally, it does not help that for political reasons some of this standards are withheld from public process, which is the case with many standards from the WSA arena (see 0), or that some of the efforts are duplicated, as was the case with LA and WS-Federation specifications.

===Performance ===

XML parsing is a slow task, which is an accepted reality, and SOAP processing slows it down even more. Now, with expensive cryptographic and textual conversion operations thrown into the mix, these tasks become a performance bottleneck, even with the latest crypto- and XML-processing hardware solutions offered today. All of the products currently on the market are facing this issue, and they are trying to resolve it with varying degrees of success.

Hardware solutions, while substantially (by orders of magnitude) improving the performance, can not always be used as an optimal solution, as they can not be easily integrated with the already existing back-end software infrastructure, at least – not without making performance sacrifices. Another consideration whether hardware-based systems are the right solution – they are usually highly specialized in what they are doing, while modern Application Servers and security frameworks can usually offer a much greater variety of protection mechanisms, protecting not only Web Services, but also other deployed applications in a uniform and consistent way.

===Complexity and interoperability ===

As could be deduced from the previous sections, Web Service security standards are fairly complex, and have very steep learning curve associated with them. Most of the current products, dealing with Web Service security, suffer from very mediocre usability due to the complexity of the underlying infrastructure. Configuring all different policies, identities, keys, and protocols takes a lot of time and good understanding of the involved technologies, as most of the times errors that end users are seeing have very cryptic and misleading descriptions.

In order to help administrators and reduce security risks from service misconfigurations, many companies develop policy templates, which group together best practices for protecting incoming and outgoing SOAP messages. Unfortunately, this work is not currently on the radar of any of the standard’s bodies, so it appears unlikely that such templates will be released for public use any time soon. Closest to this effort may be WS-I’s Basic Security Profile (BSP), which tries to define the rules for better interoperability among Web Services, using a subset of common security features from various security standards like WSS. However, this work is not aimed at supplying the administrators with ready for deployment security templates matching the most popular business use cases, but rather at establishing the least common denominator.

===Key management ===

Key management usually lies at the foundation of any other security activity, as most protection mechanisms rely on cryptographic keys one way or another. While Web Services have XKMS protocol for key distribution, local key management still presents a huge challenge in most cases, since PKI mechanism has a lot of well-documented deployment and usability issues. Those systems that opt to use homegrown mechanisms for key management run significant risks in many cases, since questions of storing, updating, and recovering secret and private keys more often than not are not adequately addressed in such solutions.

==Further Reading ==

* Piliptchouk, D., WS-Security in the Enterprise, O’Reilly ONJava

http://www.onjava.com/pub/a/onjava/2005/02/09/wssecurity.html

http://www.onjava.com/pub/a/onjava/2005/03/30/wssecurity2.html

* WS-Security OASIS site

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

* Microsoft, ''What’s new with WSE 3.0''

http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx?pull=/library/en-us/dnwse/html/newwse3.asp

* Eoin Keary, Preventing DOS attacks on web services

https://www.threatsandcountermeasures.com/wiki/default.aspx/ThreatsAndCountermeasuresCommunityKB.PreventingDOSAttacksOnWebServices

==Reference
[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Web Services]]

Talk:Web Services

2007-06-09T15:44:25Z

Mylene: Proposed change to chapter 11

I checked the OASIS website for the WSA specifications as stated in chapter 11. There seems to be no such thing as a WSA spec for Web Services Architecture. There is, however a WSA spec: Web Services Addressing.
I'd like to propose to change the text to:

WS-Security specification (WSS) was originally developed by Microsoft, IBM, and Verisign as part of a “Roadmap”. WSS served as the foundation for all other specifications in this domain, creating a basic infrastructure for developing message-based security exchange. Because of its importance for establishing interoperable Web Services, it was submitted to OASIS and, after undergoing the required committee process, became an officially accepted standard. Current version is 1.1.

Mylène

----

Buffer Overflows

2007-06-09T14:44:47Z

Mylene: /* Heap Overflow */ typo

[[Guide Table of Contents]]__TOC__'''

==Objective ==

To ensure that:

* Applications do not expose themselves to faulty components

* Applications create as few buffer overflows as possible

* Developers are encouraged to use languages and frameworks that are relatively immune to buffer overflows.

==Platforms Affected ==

Almost every platform, with the following notable exceptions:

* Java/J2EE – as long as native methods or system calls are not invoked

* .NET – as long as unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)

* PHP, Python, Perl – as long as external programs or vulnerable extensions are not used.

==Relevant COBIT Topics ==

DS11.9 – Data processing integrity.

==Description ==

Attackers generally use buffer overflows to corrupt the execution stack of a web application. By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code, possibly taking over the machine. Attackers have managed to identify buffer overflows in a staggering array of products and components.

Buffer overflow flaws can be present in both the web server and application server products that serve the static and dynamic portions of a site, or in the web application itself. Buffer overflows found in commonly used server products are likely to become widely known and can pose a significant risk to users of these products. When web applications use libraries, such as a graphics library to generate images or a communications library to send e-mail, they open themselves to potential buffer overflow attacks. Literature detailing buffer overflow attacks against commonly used products is readily available, and newly discovered vulnerabilities are reported almost daily.

Buffer overflows can also be found in custom web application code, and may even be more likely, given the lack of scrutiny that web applications typically go through. Buffer overflow attacks against customized web applications can sometimes lead to interesting results. In some cases, we have discovered that sending large inputs can cause the web application or the back-end database to malfunction. It is possible to cause a denial of service attack against the web site, depending on the severity and specific nature of the flaw. Overly large inputs could cause the application to display a detailed error message, potentially leading to a successful attack on the system.

Buffer overflow attacks generally rely upon two techniques (and usually the combination):

* Writing data to particular memory addresses

* Having the operating system mishandle data types

* This means that strongly-typed programming languages (and environments) that disallow direct memory access usually prevent buffer overflows from happening.

{| border=1
|-
! Language/Environment !! Compiled or Interpreted !! Strongly Typed !! Direct Memory Access !! Safe or Unsafe

|-

|| Java, Java Virtual Machine (JVM) || Both || Yes || No || Safe

|-

|| .NET || Both || Yes || No || Safe

|-

|| Perl || Both || Yes || No || Safe

|-

|| Python - interpreted || Intepreted || Yes || No || Safe

|-

|| Ruby || Interpreted || Yes || No || Safe

|-

|| C/C++ || Compiled || No || Yes || Unsafe

|-

|| Assembly || Compiled || No || Yes || Unsafe

|-

|| COBOL || Compiled || Yes || No || Safe

|-

|}
Table 8.1: Language descriptions

==General Prevention Techniques ==

A number of general techniques to prevent buffer overflows include:

* Code auditing (automated or manual)

* Developer training – bounds checking, use of unsafe functions, and group standards

* Non-executable stacks – many operating systems have at least some support for this

* Compiler tools – StackShield, StackGuard, and Libsafe, among others

* Safe functions – use strncat instead of strcat, strncpy instead of strcpy, etc

* Patches – Be sure to keep your web and application servers fully patched, and be aware of bug reports relating to applications upon which your code is dependent.

* Periodically scan your application with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications.

==Stack Overflow ==

Stack overflows are the best understood and the most common form of buffer overflows. The basics of a stack overflow is simple:

* There are two buffers, a source buffer containing arbitrary input (presumably from the attacker), and a destination buffer that is too small for the attack input. The second buffer resides on the stack and somewhat adjacent to the function return address on the stack.

* The faulty code does ''not'' check that the source buffer is too large to fit in the destination buffer. It copies the attack input to the destination buffer, overwriting additional information on the stack (such as the function return address).

* When the function returns, the CPU unwinds the stack frame and pops the (now modified) return address from the stack.

* Control does not return to the function as it should. Instead, arbitrary code (chosen by the attacker when crafting the initial input) is executed.

The following example, written in C, demonstrates a stack overflow exploit.

<pre>
#include <string.h>

void f(char* s) {
char buffer[10];
strcpy(buffer, s);
}

void main(void) {
f("01234567890123456789");
}

[root /tmp]# ./stacktest

Segmentation fault
</pre>

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values or non-executable stacks to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===
# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Heap Overflow ==

Heap overflows are problematic in that they are not necessarily protected by CPUs capable of using non-executable stacks. A heap is an area of memory allocated by the application at run-time to store data. The following example, written in C, shows a heap overflow exploit.

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

#define BSIZE 16
#define OVERSIZE 8 /* overflow buf2 by OVERSIZE bytes */

void main(void) {
u_long b_diff;
char *buf0 = (char*)malloc(BSIZE); // create two buffers
char *buf1 = (char*)malloc(BSIZE);

b_diff = (u_long)buf1 - (u_long)buf0; // difference between locations
printf("Initial values: ");
printf("buf0=%p, buf1=%p, b_diff=0x%x bytes\n", buf0, buf1, b_diff);

memset(buf1, 'A', BUFSIZE-1), buf1[BUFSIZE-1] = '\0';
printf("Before overflow: buf1=%s\n", buf1);

memset(buf0, 'B', (u_int)(diff + OVERSIZE));
printf("After overflow: buf1=%s\n", buf1);
}

[root /tmp]# ./heaptest

Initial values: buf0=0x9322008, buf1=0x9322020, diff=0xff0 bytes
Before overflow: buf1=AAAAAAAAAAAAAAA
After overflow: buf1=BBBBBBBBAAAAAAA
</pre>

The simple program above shows two buffers being allocated on the heap, with the first buffer being overflowed to overwrite the contents of the second buffer.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* copies data from one buffer on the stack to another without checking sizes first AND

* does not use techniques such as canary values to prevent buffer overflows THEN

it is likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Format String ==

Format string buffer overflows (usually called "format string vulnerabilities") are highly specialized buffer overflows that can have the same effects as other buffer overflow attacks. Basically, format string vulnerabilities take advantage of the mixture of data and control information in certain functions, such as C/C++'s printf. The easiest way to understand this class of vulnerability is with an example:

<pre>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

void main(void) {
char str[100] = scanf("%s");
printf("%s", str);
}
</pre>

This simple program takes input from the user and displays it back on the screen. The string <code>%s</code> means that the other parameter, str, should be displayed as a string. This example is ''not'' vulnerable to a format string attack, but if one changes the last line, it becomes exploitable:

printf(str);

To see how, consider the user entering the special input:

''%08x.%08x.%08x.%08x.%08x''

By constructing input as such, the program can be exploited to print the first five entries from the stack.

===How to determine if you are vulnerable ===

If your program:

* uses functions such as printf, snprintf directly, or indirectly through system services (such as syslog) or other AND

* the use of such functions allows input from the user to contain control information interpreted by the function itself

it is highly likely that the application is vulnerable to attack.

===How to protect yourself ===

# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc. Specifically check for control information (meta-characters like '%')
# Avoid the use of functions like printf that allow user input to contain control information
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Unicode Overflow ==

Unicode exploits are a bit more difficult to do than typical buffer overflows as demonstrated in Anley’s 2002 paper, but it is wrong to assume that by using Unicode, you are protected against buffer overflows. Examples of Unicode overflows include Code Red, a devastating Trojan with an estimated economic cost in the billions of dollars.

===How to determine if you are vulnerable ===

If your program:

* is written in a language (or depends upon a program that is written in a language) that allows buffer overflows to be created (see Table 8.1) AND

* takes Unicode input from a user AND

* fails to sanitize the input AND

* does not use techniques such as canary values to prevent buffer overflows THEN

===How to protect yourself ===

# Deploy on systems capable of using non-executable stacks, such as:
## AMD and Intel x86-64 chips with associated 64-bit operating systems
## Windows XP SP2 (both 32- and 64-bit)
## Windows 2003 SP1 (both 32- and 64-bit)
## Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64-bit mode
## OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
## Solaris 2.6 and later with the “noexec_user_stack” flag enabled
# Use higher-level programming languages that are strongly typed and that disallow direct memory access.
# Validate input to prevent unexpected data from being processed, such as being too long, of the wrong data type, containing "junk" characters, etc.
# If relying upon operating system functions or utilities written in a vulnerable language, ensure that they:
## use the principle of least privilege
## use compilers that protect against stack and heap overflows
## are current in terms of patches

==Integer Overflow ==

When an application takes two numbers of fixed word size and perform an operation with them, the result may not fit within the same word size. For example, if the two 8-bit numbers 192 and 208 are added together and stored into another 8-bit byte, the result will not fit into an 8-bit result:

'' 1100 0000''

'' + 1101 0000''

'' = 0001 1001 0000''

Although such an operation will usually cause some type of exception, your application must be coded to check for such an exception and take proper action. Otherwise, your application would report that 192 + 208 equals 144.

The following code demonstrates a buffer overflow, and was adapted from [http://www.phrack.org/phrack/60/p60-0x0a.txt Blexim's Phrack article]:

<pre>
#include <stdio.h>
#include <string.h>

void main(int argc, char *argv[]) {
int i = atoi(argv[1]); // input from user
unsigned short s = i; // truncate to a short
char buf[50]; // large buffer

if (s > 10) { // check we're not greater than 10
return;
}

memcpy(buf, argv[2], i); // copy i bytes to the buffer
buf[i] = '\0'; // add a null byte to the buffer
printf("%s\n", buf); // output the buffer contents

return;
}

[root /tmp]# ./inttest 65580 foobar
Segmentation fault
</pre>

The above code is exploitable because the validation does not occur on the input value (65580), but rather the value after it has been converted to an unsigned short (45).

Integer overflows can be a problem in any language and can be exploited when integers are used in array indices and implicit short math operations.

===How to determine if you are vulnerable ===

* Examine use of signed integers, bytes, and shorts.

* Are there cases where these values are used as array indices after performing an arithmetic operation (+, -, *, /, or % (modulo))?

* How would your program react to a negative or zero value for integer values, particular during array lookups?

===How to protect yourself ===

* If using .NET, use David LeBlanc’s SafeInt class or a similar construct. Otherwise, use a "BigInteger" or "BigDecimal" implementation in cases where it would be hard to validate input yourself.

* If your compiler supports the option, change the default for integers to be unsigned unless otherwise explicitly stated. Use unsigned integers whenever you don't need negative values.

* Use range checking if your language or framework supports it, or be sure to implement range checking yourself after all arithmetic operations.

* Be sure to check for exceptions if your language supports it.

==Further reading ==

* Team Teso, ''Exploiting Format String Vulnerabilities''

http://www.cs.ucsb.edu/~jzhou/security/formats-teso.html

* Newsham, Tim, ''Format String Attacks

''http://www.lava.net/~newsham/format-string-attacks.pdf

* w00 w00 and Matt Conover, ''Preliminary Heap Overflow Tutorial''

http://www.w00w00.org/files/articles/heaptut.txt

* Chris Anley, ''Creating Arbitrary Shellcode In Unicode Expanded Strings''

http://www.ngssoftware.com/papers/unicodebo.pdf

* David Leblanc, ''Integer Handling with the C++ SafeInt Class ''http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure01142004.asp

* Aleph One, ''Smashing the Stack for fun and profit''

http://www.phrack.org/phrack/49/P49-14

* Mark Donaldson, ''Inside the buffer Overflow Attack: Mechanism, method, & prevention''

http://rr.sans.org/code/inside_buffer.php

* ''NX Bit'', Wikipedia article

http://en.wikipedia.org/wiki/NX_bit

* Horizon'', How to bypass Solaris no execute stack protection

''http://www.secinf.net/unix_security/How_to_bypass_Solaris_nonexecutable_stack_protection_.html

* Alexander Anisimov'', Defeating Microsoft Windows XP SP2 Heap protection and DEP bypass'', Positive Technologies

http://www.maxpatrol.com/defeating-xpsp2-heap-protection.htm

* Matt Conover, w00w00 on Heap Overflows, w00w00 Security Team

http://www.w00w00.org/files/articles/heaptut.txt

* Blexim, ''Basic Integer Overflows

''http://www.phrack.org/phrack/60/p60-0x0a.txt

* StackShield

http://www.angelfire.com/sk/stackshield/index.html

* StackGuard

http://www.immunix.org

* Libsafe

http://www.research.avayalabs.com/project/libsafe

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]

Talk:Policy Frameworks

2007-06-09T11:51:43Z

Mylene: Question on version number of this guide

Shouldn't in the following line: "Many of the controls within OWASP Guide 2.0 are influenced by requirements of national standards or control frameworks such as COBIT; typically controls selected out of OWASP will satisfy relevant ISO 17799 and COBIT controls." OWASP Guide 2.0 be replaced with OWASP Guide 3.0?

Mylène

----