Attack Meta Structure

From WS-Attacks
Jump to: navigation, search

In this wiki each web service attack is structured the same way. It contains 8 different paragraphs that are described in the following. At the end of this page a "template" is provided. Just copy and paste this template when adding a new attack.

When creating a new attack you can also check other attacks to get an understanding of the attack metastructure.


Attack Meta Structure

Attack description

Each attack starts with an introductory attack description. The attack description gives a brief summary of the attack. It describes:

  • the violated security objective
  • why the attack works
  • the effectiveness of countermeasures.


Attack subtypes

Certain attacks are very similar to other attacks. In this case it does not make sense to give a new full attack description for each of these. Instead, attack subtypes are defined.


Prerequisites for attack

In order to execute an attack successfully certain prerequisites have to be fulfilled.In this paragraph all prerequisites for a successful attack should be listed.

Typical examples for prerequisites are:

  1. Attacker knows endpoint of web service. otherwise he is not able to reach the web service.
  2. Attacker knows that the web web service processes the security header and the "encryption" element and/or "signature" element. If the web service doens't "expect" an encrypted part, it just discards the encryption and the attack doesn't work.
  3. Attacker can reach endpoint from its location. Access to the attacked web service server is possible for the attacker. This prerequisite is important if the web service is only available to users within a certain network.


Graphic representation of attack

Each web service architecture is composed of the same elements, whatever scenario is used. Figure 2 shows the different components a SOAP request passes on its way from the client to the receiver and back.

AttackedComponent None.png

Each request originates at a sending client. It is then passed through an arbitrary number of intermediate web services. It is assumed that these intermediary web services do not alter the message in any way unless explicitly noted. The SOAP message is then passed to the receiving web service where it is usually processed in the following order:

  1. Schema validation
  2. Signature validation
  3. Decryption
  4. Other application-specific process
  5. Application logic

How and when the parsing is done depends on the used parser. That is why the parser is pictured as a parallel structure. The processing of a SOAP message by the receiving client is implementation-dependent. However, the order given above can be found in most web service frameworks today. Minor deviations in the processing order usually do not alter the attack concept.

Note: It is understood that the graphic representation of an attack explicitly shows the client-to-server communication. Other scenarios are also possible; e.g. a responding web service might take on the role of an attacker and send a malicious response to the client. However, since these cases are not as common, the client-to-server model is used. Furthermore, it is clear that the process we have shown of the inner workings of the web service framework is over-simplified. However, it is helpful to beginners in gaining a better understanding of the attacks.


Attack example

For each attack at least one example is given. Where suitable, a malicious payload is given. If attack subtypes are defined, an example of each attack subtype is given.


Attack mitigation / countermeasures

Any attack can be mitigated or even prevented if the developer understands the attack. In this section an attack mitigation strategy is described. If certain attack subtypes require special countermeasures, these are listed separately for each subtype.


Attack categorisation

The categorization of attacks in general is not yet standardized. Many researchers over the years have proposed many different categorizations of attacks on computer systems, each taken from a different point of view. Good examples of previous categorizations can be found in [23] and [9]. However, none of these classifications was web service specific, so an adapted attack classification was created that accounts for the complexity of web services. Various categorizations are relevant according to the viewpoint. For that reason, four types of categorizations have been chosen:

  1. Categorization by violated security objective
  2. Categorization by attack spreading
  3. Categorization by attacked component in web service architecture
  4. Categorization by number of parties involved


Categorisation by violated security objective

The four security objectives were already defined in chapter 2.2. Since some attacks do not really fit into one of those four categories, a fifth category “other” has been created. Therefore, five categories regarding “violated security objective” exist:

  1. integrity
  2. confidentiality
  3. availability
  4. access control
  5. other

In some cases an attack fits into more than one category. In this case, the attack has been put into the category which most strongly violates the security objective.

When new to MediaWiki, please refer to [1] for a tutorial on how to add a page to a category.


Categorisation by number of involved parties

In the simplest case one attacker at an arbitrary location executes an attack against a single web service. In more complex scenarios one attacker may control various parties, who then on behalf of the attacker unknowingly and successfully execute the attack. The classic example of this scenario is the distributed DOS (DDOS) attack, where a botnet controlled by an attacker attacks a web service. The following coding schema was therefore developed to describe the different scenarios that can arise.

The code always has the form X - Y - Z:

  • X = number of attackers
  • Y = number of involved intermediaries/other web services
  • Z = number of attacked web services

X, Y and Z can take the values:

  • 0 = no party involved
  • 1 = one party involved
  • 2+ = two or more parties involved

Example code: 1 - 0 - 1, which equals “one attacker, no involved intermediary, one targeted web service”.


Categorisation by attacked component in web service architecture

Each web service architecture consists of various components that are usually processed sequentially. We distinguish between the following components of a web service:

  1. Web Service Client
  2. Web Service Server
  3. BPEL Engine
  4. Web Service Intermediary
  5. XML Parser
  6. Schema validation
  7. Signature verification
  8. Decryption
  9. Other application-specific process
  10. Application Logic
  11. No specific component

Note: The element order is not fixed. Depending on the web service implementation, the order might change or some processes may run parallel. This list is not complete and a more fine-grained breakdown is possible. It is, however, adequate for the categorization.



Categorisation by attack spreading

We distinguish between attacks that are possible because of:

  1. application specific flaws - implementation weaknesses in the web service frameworks used
  2. conceptual flaws - flaws in the underlying standard.


References

Each attack should has its references listed.


ATTACK TEMPLATE


=Attack description=


=Attack subtypes=


=Prerequisites for attack=
In order for this attack to work the attacker has to have knowledge about the following thinks:
#'''Attacker knows endpoint of web service.''' otherwise he is not able to reach the web service. 
#'''Attacker knows that the web web service processes the security header and the "encryption" element and/or "signature" element.''' If the web service doens't "expect" an encrypted part, it just discards the encryption and the attack doesn't work.
#'''Attacker can reach endpoint from its location.''' Access to the attacked web service server is possible for the attacker. This prerequisite is important if the web service is only available to users within a certain network.




=Graphic representation of attack=

[[Image:AttackedComponent1.png]]

*Red = attacked web service component<br>
*Black = location of attacker<br>
*Blue = web service component not directly involved in attack.<br>




=Attack example=

<source lang="xml">

</source>


=Attack mitigation / countermeasures=


=Attack categorisation=
==Categorisation by violated security objective==
==Categorisation by number of involved parties==
==Categorisation by attacked component in web service architecture==
==Categorisation by attack spreading==


=References=