Java Developer Tools

Audit - Rules - Websphere

Description
This group contains audit rules that look for potential problems in Websphere services configuration.

Rules:

Details

Client Request Not Encrypted

Summary
Websphere web service client should only accept encrypted messages.

Description
This audit rule looks for declarations of Websphere web service client extensions and violates the declarations which do not declare message encryption.

Security Implications
Message-level encryption is especially important for messages that are passed via such easily readable protocols as HTTP or SMTP, as well as the others. Encrypted message maintains the required level of security not depending on the protocol.

Example
The following code specifies the encryption constraints that messages consumed by a service client must meet. If no encryption constraints, declared via <confidentiality> property, are defined, the whole <securityRequestSenderServiceConfig> declaration is marked as violation:

    <securityRequestSenderServiceConfig>
        <confidentiality>
            <confidentialParts part="bodycontent"/>
        </confidentiality>
        ...
    </securityRequestSenderServiceConfig>

Client Request Not Signed

Summary
Websphere web service client should only accept signed messages.

Description
This audit rule looks for declarations of Websphere web service client extensions and violates the declarations which do not declare signing the message.

Security Implications
Signing the message is important because this is the only way to provide the complete guarantee for the receiver of a message that the message was endeed sent by a specific sender. Otherwise a message could be intercepted and its contents could be changed.

Example
The following code verifies that that messages consumed by a service client are signed. If they are not verified to be signed, as declared via <integrity> property, the whole <securityRequestSenderServiceConfig> declaration is marked as violation:

    <securityRequestSenderServiceConfig>
        <integrity>
            <references part="body"/>
            <references part="timestamp"/>
        </integrity>
        ...
    </securityRequestSenderServiceConfig>

Client Request Timestamp Not Signed

Summary
Websphere web service timestamps should be signed.

Description
This audit rule looks for declarations of Websphere web service requester extensions and violates the declarations which do not declare signing of timestamps.

Security Implications
Unsigned timestamp can be intercepted and replaced by an attacker, thus easing a task of forging the message.

Example
The following code declares a <addCreatedTimeStamp> without mentioning it in a <integrity> list of signed components; it would thus be marked as violation:

    <securityRequestSenderServiceConfig>
        <integrity>
            <references part="body"/>
        </integrity>
        <addCreatedTimeStamp flag="true"/>
        ...
    </securityRequestSenderServiceConfig>

Client Response Not Encrypted

Summary
Websphere web service client should only produce encrypted messages.

Description
This audit rule looks for declarations of Websphere web service client extensions and violates the declarations which do not declare message encryption.

Security Implications
Message-level encryption is especially important for messages that are passed via such easily readable protocols as HTTP or SMTP, as well as the others. Encrypted message maintains the required level of security not depending on the protocol.

Example
The following code specifies the encryption constraints that messages produced by a service client must meet. If no encryption constraints, declared via <requiredConfidentiality> property, are defined, the whole <securityResponseReceiverServiceConfig> declaration is marked as violation:

    <securityResponseReceiverServiceConfig>
        <requiredConfidentiality>
            <confidentialParts part="bodycontent"/>
            <confidentialParts part="usernametoken"/>
        </requiredConfidentiality>
        ...
    </securityResponseReceiverServiceConfig>

Client Response Not Signed

Summary
Websphere web service client should only produce signed messages.

Description
This audit rule looks for declarations of Websphere web service client extensions and violates the declarations which do not declare signing the message.

Security Implications
Signing the message is important because this is the only way to provide the complete guarantee for the receiver of a message that the message was indeed sent by a specific sender. Otherwise a message could be intercepted and its contents could be changed.

Example
The following code verifies that that messages consumed by a service client are signed. If they are not verified to be signed, as declared via <requiredIntegrity> property, the whole <securityResponseReceiverServiceConfig> declaration is marked as violation:

    <securityResponseReceiverServiceConfig>
        <requiredIntegrity>
            <references part="body"/>
            <references part="timestamp"/>
        </requiredIntegrity>
        ...
    </securityResponseReceiverServiceConfig>

Client Response Timestamp Not Signed

Summary
Websphere web service timestamps should be signed.

Description
This audit rule looks for declarations of Websphere web service requester extensions and violates the declarations which do not declare signing of timestamps.

Security Implications
Unsigned timestamp can be intercepted and replaced by an attacker, thus easing a task of forging the message.

Example
The following code declares a <addReceivedTimeStamp> without mentioning it in a <requiredIntegrity> list of signed components; it would thus be marked as violation:

    <securityResponseReceiverServiceConfig>
        <requiredIntegrity>
            <references part="body"/>
        </requiredIntegrity>
        <addReceivedTimeStamp flag="true"/>
        ...
    </securityResponseReceiverServiceConfig>

Client Timestamp Does Not Expire

Summary
Websphere web service client timestamps should have an expiration date.

Description
This audit rule looks for declarations of Websphere web service client extensions and violates the declarations which do not declare expiration date for received timestamps.

Security Implications
Timestamp without an expiration date is valid indefinetely, thus allowing the attacker to delay and modify messages, perform replay attacks, etc.

Example
The following code declares a <addCreatedTimeStamp> without an expiration date set through a expires property; it would thus be marked as violation:

    <securityRequestSenderServiceConfig>
        <integrity>
            <references part="body"/>
            <references part="timestamp"/>
        </integrity>
        <addCreatedTimeStamp flag="true"/>
        ...
    </securityRequestSenderServiceConfig>

Client Uses Username Token

Summary
UsernameToken authentication is insecure and should not be used.

Description
This audit rule looks for declarations of Websphere web service client extensions and violates the declarations which use UsernameToken for authentication.

Security Implications
A UsernameToken authentication could use an unencrypted password that could be intercepted by an attacker.

Example
The following code declares a <securityToken> with a UsernameToken as an authentication token and would thus be marked as violation:

    <securityRequestGeneratorServiceConfig>
        <securityToken name="basicauth" uri="" localName="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken"/>
        ...
    </securityRequestGeneratorServiceConfig>

No Timestamp In Client Request

Summary
Websphere web service client should add timestamp to all produced messages.

Description
This audit rule looks for declarations of Websphere web service client extensions and violates the declarations which do not declare adding the timestamp to a request message.

Security Implications
A timestamp in the message allows the receiver to make a decision about trusting a message based on its freshness. If an attacker intercepts a message and modifies it, an outdated timestamp may be enough to indicate the problem.

Example
The following code does not declare a timestamp as a part of a produced message via <addCreatedTimeStamp> configuration option, thus the whole <securityRequestSenderServiceConfig> declaration is marked as violation:

    <securityRequestSenderServiceConfig>
        <integrity>
            <references part="body"/>
            <references part="timestamp"/>
        </integrity>
    </securityRequestSenderServiceConfig>

No Timestamp In Client Response

Summary
Websphere web service client should require a timestamp in all received messages.

Description
This audit rule looks for declarations of Websphere web service client extensions and violates the declarations which do not require a timestamp in a response message.

Security Implications
A timestamp in the message allows the receiver to make a decision about trusting a message based on its freshness. If an attacker intercepts a message and modifies it, an outdated timestamp may be enough to indicate the problem.

Example
The following code does not declare a timestamp as a part of a response message via <addReceivedTimeStamp> configuration option, thus the whole <securityResponseReceiverServiceConfig> declaration is marked as violation:

    <securityResponseReceiverServiceConfig>
        <requiredIntegrity>
            <references part="body"/>
            <references part="timestamp"/>
        </requiredIntegrity>
    </securityResponseReceiverServiceConfig>

No Timestamp In Server Request

Summary
Websphere web service Server should require a timestamp in all consumed messages.

Description
This audit rule looks for declarations of Websphere web service Server extensions and violates the declarations which do not require the timestamp in a request message.

Security Implications
A timestamp in the message allows the receiver to make a decision about trusting a message based on its freshness. If an attacker intercepts a message and modifies it, an outdated timestamp may be enough to indicate the problem.

Example
The following code does not require a timestamp as a part of a consumed message via <addReceivedTimestamp> configuration option, thus the whole <securityRequestReceiverServiceConfig> declaration is marked as violation:

    <securityRequestReceiverServiceConfig>
        <requiredIntegrity>
            <references part="body"/>
            <references part="timestamp"/>
        </requiredIntegrity>
    </securityRequestReceiverServiceConfig>

No Timestamp In Server Response

Summary
Websphere web service Server should require a timestamp in all produced messages.

Description
This audit rule looks for declarations of Websphere web service Server extensions and violates the declarations which do not add a timestamp to a response message.

Security Implications
A timestamp in the message allows the receiver to make a decision about trusting a message based on its freshness. If an attacker intercepts a message and modifies it, an outdated timestamp may be enough to indicate the problem.

Example
The following code does not declare a timestamp as a part of a response message via <addCreatedTimestamp> configuration option, thus the whole <securityResponseSenderServiceConfig> declaration is marked as violation:

    <securityResponseSenderServiceConfig>
        <integrity>
            <references part="body"/>
            <references part="timestamp"/>
        </integrity>
    </securityResponseSenderServiceConfig>

Nonce Not Used

Summary
<wsse:Nonce> and <wsu:Created> should be used in UsernameToken configuration.

Description
This audit rule violates Websphere UsernameToken configurations that do not declare the usage of both <wsse:Nonce> and <wsu:Created> elements.

Security Implications
Two optional elements are introduced in the <wsse:UsernameToken> element to provide a countermeasure for replay attacks: <wsse:Nonce> and <wsu:Created>. A nonce is a random value that the sender creates to include in each UsernameToken that it sends. Although using a nonce is an effective countermeasure against replay attacks, it requires a server to maintain a cache of used nonces, consuming server resources. Combining a nonce with a creation timestamp has the advantage of allowing a server to limit the cache of nonces to a "freshness" time period, establishing an upper bound on resource requirements.

Example
The following sample configuration in ws-security.xml Websphere configuration file has com.ibm.ws.wssecurity.config.token.BasicAuth.Nonce property disabled and would thus be marked as violation:

    <?xml version="1.0" encoding="UTF-8"?>
    <com.ibm.etools.webservice.wssecurity:WSSecurity xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wssecurity="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wssecurity.xmi" xmi:id="WSSecurity_1084441805509">
        <properties xmi:id="Property_1057972161460" name="com.ibm.ws.wssecurity.config.token.BasicAuth.Nonce" value="false"/>
        <properties xmi:id="Property_1057972161461" name="com.ibm.ws.wssecurity.config.token.BasicAuth.NonceRequired" value="false"/>
    </com.ibm.etools.webservice.wssecurity:WSSecurity>

Server Request Not Encrypted

Summary
Websphere web service should only accept encrypted messages.

Description
This audit rule looks for declarations of Websphere web service provider extensions and violates the declarations which do not declare message encryption.

Security Implications
Message-level encryption is especially important for messages that are passed via such easily readable protocols as HTTP or SMTP, as well as the others. Encrypted message maintains the required level of security not depending on the protocol.

Example
The following code specifies the encryption constraints that messages consumed by a service provider must meet. If no encryption constraints, declared via <requiredConfidentiality> property, are defined, the whole <securityRequestReceiverServiceConfig> declaration is marked as violation:

    <securityRequestReceiverServiceConfig>
        <requiredConfidentiality>
            <confidentialParts part="bodycontent"/>
            <confidentialParts part="usernametoken"/>
        </requiredConfidentiality>
        ...
    </securityRequestReceiverServiceConfig>

Server Request Not Signed

Summary
Websphere web service should only accept signed messages.

Description
This audit rule looks for declarations of Websphere web service provider extensions and violates the declarations which do not declare signing the message.

Security Implications
Signing the message is important because this is the only way to provide the complete guarantee for the receiver of a message that the message was endeed sent by a specific sender. Otherwise a message could be intercepted and its contents could be changed.

Example
The following code verifies that that messages consumed by a service provider are signed. If they are not verified to be signed, as declared via <requiredIntegrity> property, the whole <securityRequestReceiverServiceConfig> declaration is marked as violation:

    <securityRequestReceiverServiceConfig>
        <requiredIntegrity>
            <references part="body"/>
            <references part="timestamp"/>
        </requiredIntegrity>
        ...
    </securityRequestReceiverServiceConfig>

Server Request Timestamp Not Signed

Summary
Websphere web service timestamps should be signed.

Description
This audit rule looks for declarations of Websphere web service provider extensions and violates the declarations which do not declare signing of timestamps.

Security Implications
Unsigned timestamp can be intercepted and replaced by an attacker, thus easing a task of forging the message.

Example
The following code declares a <addReceivedTimestamp> without mentioning it in a <requiredIntegrity> list of signed components; it would thus be marked as violation:

    <securityRequestReceiverServiceConfig>
        <requiredIntegrity>
            <references part="body"/>
        </requiredIntegrity>
        <addReceivedTimestamp flag="true"/>
        ...
    </securityRequestReceiverServiceConfig>

Server Response Not Encrypted

Summary
Websphere web service should only produce encrypted messages.

Description
This audit rule looks for declarations of Websphere web service provider extensions and violates the declarations which do not declare message encryption.

Security Implications
Message-level encryption is especially important for messages that are passed via such easily readable protocols as HTTP or SMTP, as well as the others. Encrypted message maintains the required level of security not depending on the protocol.

Example
The following code specifies the encryption constraints that messages produced by a service provider must meet. If no encryption constraints, declared via <confidentiality> property, are defined, the whole <securityResponseSenderServiceConfig> declaration is marked as violation:

    <securityResponseSenderServiceConfig>
        <confidentiality>
            <confidentialParts part="bodycontent"/>
        </confidentiality>
        ...
    </securityResponseSenderServiceConfig>

Server Response Not Signed

Summary
Websphere web service should only produce signed messages.

Description
This audit rule looks for declarations of Websphere web service provider extensions and violates the declarations which do not declare signing the message.

Security Implications
Signing the message is important because this is the only way to provide the complete guarantee for the receiver of a message that the message was endeed sent by a specific sender. Otherwise a message could be intercepted and its contents could be changed.

Example
The following code verifies that that messages consumed by a service provider are signed. If they are not verified to be signed, as declared via <integrity> property, the whole <securityResponseSenderServiceConfig> declaration is marked as violation:

    <securityResponseSenderServiceConfig>
        <integrity>
            <references part="body"/>
            <references part="timestamp"/>
        </integrity>
        ...
    </securityResponseSenderServiceConfig>

Server Response Timestamp Not Signed

Summary
Websphere web service timestamps should be signed.

Description
This audit rule looks for declarations of Websphere web service provider extensions and violates the declarations which do not declare signing of timestamps.

Security Implications
Unsigned timestamp can be intercepted and replaced by an attacker, thus easing a task of forging the message.

Example
The following code declares a <addCreatedTimestamp> without mentioning it in a <integrity> list of signed components; it would thus be marked as violation:

    <securityResponseSenderServiceConfig>
        <integrity>
            <references part="body"/>
        </integrity>
        <addCreatedTimestamp flag="true"/>
        ...
    </securityResponseSenderServiceConfig>

Server Timestamp Does Not Expire

Summary
Websphere web service timestamps should have an expiration date.

Description
This audit rule looks for declarations of Websphere web service provider extensions and violates the declarations which do not declare expiration date for created timestamps.

Security Implications
Timestamp without an expiration date is valid indefinetely, thus allowing the attacker to delay and modify messages, perform replay attacks, etc.

Example
The following code declares a <addCreatedTimestamp> without an expiration date set through a expires property; it would thus be marked as violation:

    <securityResponseSenderServiceConfig>
        <integrity>
            <references part="body"/>
            <references part="timestamp"/>
        </integrity>
        <addCreatedTimestamp flag="true"/>
        ...
    </securityResponseSenderServiceConfig>

Server Uses Username Token

Summary
UsernameToken authentication is insecure and should not be used.

Description
This audit rule looks for declarations of Websphere web service server extensions and violates the declarations which use UsernameToken for authentication.

Security Implications
A UsernameToken authentication could use an unencrypted password that could be intercepted by an attacker.

Example
The following code declares a <requiredSecurityToken> with a UsernameToken as an authentication token and would thus be marked as violation:

    <securityRequestConsumerServiceConfig>
        <requiredSecurityToken name="Token_123" uri="" localName="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken" usage="Required"/>
        ...
    </securityRequestConsumerServiceConfig>

Service Provider Request Security Not Configured

Summary
Websphere service provider should use WS-Security extension in order to provide encryption needed to protect sensitive data from sniffing or other ways of man-in-the-middle attacks.

Description
This audit rule violates Websphere server deployment descriptor extension file (ibm-webservices-ext.xmi) that does not use <securityRequestConsumerServiceConfig> to declare the usage of WS-Security.

Security Implications
WS-Security extension should be used to protected messages that are passed through third-party services from man-in-the-middle attacks via proper encryption and authentication of data.

Example
The following ibm-webservices-ext.xmi configuration does not use <securityRequestConsumerServiceConfig> and would thus be violated:

    <?xml version="1.0" encoding="UTF-8"?>
    <com.ibm.etools.webservice.wsext:WsExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wsext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wsext.xmi" xmi:id="WsExtension_1118244521562">
        <wsDescExt xmi:id="WsDescExt_1119553210812" wsDescNameLink="RRDService">
            <pcBinding xmi:id="PcBinding_1119553210812" pcNameLink="RRDService"/>
            <pcBinding xmi:id="PcBinding_1118244521562" pcNameLink="RRDServiceCustom">
                <serverServiceConfig xmi:id="ServerServiceConfig_1123269103509"/>
            </pcBinding>
        </wsDescExt>
    </com.ibm.etools.webservice.wsext:WsExtension>

Service Provider Response Security Not Configured

Summary
Websphere service provider should use WS-Security extension in order to provide encryption needed to protect sensitive data from sniffing or other ways of man-in-the-middle attacks.

Description
This audit rule violates Websphere server deployment descriptor extension file (ibm-webservices-ext.xmi) that does not use <securityResponseGeneratorServiceConfig> to declare the usage of WS-Security.

Security Implications
WS-Security extension should be used to protected messages that are passed through third-party services from man-in-the-middle attacks via proper encryption and authentication of data.

Example
The following ibm-webservices-ext.xmi configuration does not use <securityResponseGeneratorServiceConfig> and would thus be violated:

    <?xml version="1.0" encoding="UTF-8"?>
    <com.ibm.etools.webservice.wsext:WsExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wsext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wsext.xmi" xmi:id="WsExtension_1118244521562">
        <wsDescExt xmi:id="WsDescExt_1119553210812" wsDescNameLink="RRDService">
            <pcBinding xmi:id="PcBinding_1119553210812" pcNameLink="RRDService"/>
            <pcBinding xmi:id="PcBinding_1118244521562" pcNameLink="RRDServiceCustom">
                <serverServiceConfig xmi:id="ServerServiceConfig_1123269103509"/>
            </pcBinding>
        </wsDescExt>
    </com.ibm.etools.webservice.wsext:WsExtension>

Service Requester Request Security Not Configured

Summary
Websphere service requester should use WS-Security extension in order to provide encryption needed to protect sensitive data from sniffing or other ways of man-in-the-middle attacks.

Description
This audit rule violates Websphere server deployment descriptor extension file (ibm-webservicesclient-ext.xmi) that does not use <securityRequestGeneratorServiceConfig> to declare the usage of WS-Security.

Security Implications
WS-Security extension should be used to protected messages that are passed through third-party services from man-in-the-middle attacks via proper encryption and authentication of data.

Example
The following ibm-webservicesclient-ext.xmi configuration does not use <securityRequestGeneratorServiceConfig> and would thus be violated:

    <clientServiceConfig>
        <securityResponseConsumerServiceConfig />
    </clientServiceConfig>

Service Requester Response Security Not Configured

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.