Web Services : Brokered Authentication

Context
A client needs to access a Web service. The Web service requires the application to present credentials for authentication so that additional controls such as authorization and auditing can be implemented.

Problem
How does the Web service verify the credentials that are presented by the client?

Forces
Any of the following conditions justifies using the solution described in this pattern:

· The client accesses additional services, which results in the need for a single sign on (SSO) solution. Without a single sign on solution, the client may be forced to authenticate prior to every Web service call or cache the user's credentials within the application. If the user's credentials include a password, caching the password is not recommended because it may pose a security risk.
· The client and the Web service do not trust each other directly. The client and the Web service may not trust one another to manage or exchange shared secrets securely. Establishing trust directly between a client and Web service often requires out of band interactions that can hinder clients and services from interacting dynamically.
· The Web service and the identity store do not trust each other directly. The Web service may be unable to communicate with the identity store directly, because of access control restrictions, network restrictions, or organizational policy.

The following condition is an additional reason to use the solution.

· The client and Web service share a standard access control infrastructure. You can simplify the development of new Web services by standardizing and centralizing the issuance and verification of credentials. You can also centralize the management of data associated with credentials; this reduces the costs associated with identity management.

Solution
Use brokered authentication where the Web service validates the credentials presented by the client, without the need for a direct relationship between the two parties. An authentication broker that both parties trust independently issues a security token to the client. The client can then present credentials, including the security token, to the Web service.

Participants

Brokered authentication involves the following participants:
· Client. The client accesses the Web service. The client provides the credentials for authentication during the request to the Web service.
· Service. The service is the Web service that requires authentication of a client prior to authorizing the client.
· Authentication broker. The authentication broker authenticates clients and maintains authoritative control over security tokens. It also vouches for the client by issuing it a security token.
· Identity store. The entity that stores a client's credentials for a particular identity domain.

Process
1. The client submits an authentication request to the authentication broker.
2. The authentication broker contacts the identity store to validate the client's credentials.
3. The authentication broker responds to the client, and if authentication is successful, it issues a security token. The client can use the security token to authenticate with the service. The security token can be used by the client for a period of time that is defined by the authentication broker. The client can then use the issued security token to authenticate requests to the service throughout the lifetime of the token.
4. A request message is sent to the service; it contains the security token that is issued by the authentication broker.
5. The service authenticates the request by validating the security token that was sent with the message.
6. The service returns the response to the client.

There are different types of authentication brokers. Each type uses different mechanisms to broker authentication between a client and a service. Common examples of an authentication broker include the following:
· X.509 PKI
· Kerberos protocol
· Web Service Security Token Service (STS)

Benefits
The benefits of using the Brokered Authentication pattern include the following:
· The authentication broker manages trust centrally. This eliminates the need for each client and service to independently manage their own trust relationships.
· Solutions built around brokered authentication with a centralized identity provider are often easier to maintain than direct authentication solutions. When new users who require access to any of the clients or Web services are added to the identity store, their credentials are maintained in one central point.
· Two parties participating in brokered authentication do not require prior knowledge of one another to communicate. If a client is modified to call a Web service it has never used before, the Web service requires no changes to its configuration or data to authenticate credentials presented by the client.
· Trust relationships can be established between different authentication brokers. This means that an authentication broker can issue security tokens that are used across organizational boundaries and autonomous security domains.

Liabilities
The liabilities associated with the Brokered Authentication pattern include the following:
· The centralized trust model that is used by Brokered authentication can sometimes create a single point of failure. Some types of authentication brokers, such as the Kerberos Key Distribution Center (KDC), must be online and available to issue a security token to a client. If the authentication broker somehow becomes unavailable, none of the parties that rely on the authentication broker to issue security tokens can communicate with each other. This problem of a single point of failure can be mitigated by implementing redundant or back-up authentication brokers, although this increases the complexity of the solution.
· Any compromise of an authentication broker results in the integrity of the trust that is provided by the broker also being compromised. If an attacker does successfully compromise the authentication broker, it can use the authentication broker to issue security tokens, and conduct malicious activity against parties that trust the authentication broker.

Security Considerations
Security considerations associated with the Brokered Authentication pattern include the following:
· Claims held in security tokens often contain sensitive data, and must be protected in transit, either by using message layer security, or transport level security.
· Security tokens must be signed by the issuing authentication broker. If they are not, their integrity cannot be verified. This could result in attackers trying to issue false tokens.
· A Time of Change/Time of Use vulnerability may exist if the client's account status, identity attributes, or authorization attributes are modified by an account administrator. If these changes are not reflected in the security token, it creates a vulnerability that may lead to invalid clients interacting with the service with elevated privileges.

Avoiding Clear Text Passwords

Perform the following steps to avoid sending cleartext passwords over the network:

• If possible, remove the need for a password at all by specifying ClientCredentialType=”Windows”, ClientCredentialType=”Certificate”, or a custom token that does not require a password.

• If the user must enter a password, protect the password by specifying either to secure the channel or to secure the messages. Do not specify in the configuration as this will provide no communication security.

Impersonation without Windows Authentication

How to Impersonate the Original Caller without Windows Authentication

When using non-windows authentication like Certificate Authentication or username authentication, if you need to impersonate the original caller (if it has windows account) or a service account you have following 2 options

1. Using the S4U Kerberos extensions - For this you must grant your process account the "Act as part of the operating system" user right.
2. Using the LogonUser windows API - this needs to have access to the user credentials (username and password) - which increases the security risk of maintaining the user credentials in WCF Service.

Note: S4U Kerberos extensions places your process within the trusted computing base (TCB) of the Web server, which makes your Web server process very highly privileged. Where possible, you should avoid this approach because an attacker who manages to inject code and compromise your Web application will have unrestricted capabilities on the local computer.

Disabling Discovery

Microsoft WCF 3.5: How to Stop Clients from Referencing Your Service

If you want block clients from accessing the WSDL of your service you should remove all metadata exchange endpoints and set the httpGetEnabled and httpsGetEnabled attributes to false.

If the metadata is exposed, unwanted clients will be able to generate proxy files (e.g. using SvcUtil.exe) and inspect potentially sensitive methods and parameters offered by the service.

To stop your clients from referencing your service, stop your service from publishing its metadata. To do this, remove all the Mex endpoints from your service configuration and configure HttpGetEnabled and HttpsGetEnabled to false in the ServiceBehavior section as shown below:

serviceMetadata httpGetEnabled="False" httpsGetEnabled="False"

App Security Testing Cheat Sheet

Hi,

I thought to prepare a brief cheat sheet for Application Security Testing.

Please have a look and drop in your views. In case you wish to use it for your testing, please drop me a mail at dharmeshmm at gmail dot com to notify me about it.

Authentication Checks

1. Login and Change Password pages on SSL?
2. All sensitive pages (accepting SSN, Credit Card) over SSL?
3. Strong Password Policy? (Joe Accounts/Blank Passwords/Max Password Age/Min Password Age, etc)
4. Is Forgot Password page secure?
5. Password Change forced on 1st login?
6. Re-authenticate before moving to sensitive pages (Edit Account Info?)
7. Prompts old password before changing password?
8. Has "Remember Me" feature? If so, how's password stored?
9. Warns before allowing "Remember Me"?
10. Has CAPTCHA to prevent password guessing?
11. Does show error msgs like "Invalid User/Invalid Password"?
12. Can auth. be by-passed for priviledged URL's?
13. Is AutoComplete set to OFF?
14. Is password re-submitted on 'Back/Refresh' of browser?
15. SQL Injection in login?

Session Management

1. Is session id random enough?
2. Session Timeout present?
3. Stored in what form? (persistent cookie/in-memory cookie)?
4. Session Id expires on request tampering?
5. Sensitive data in cookie?
6. Can you see X user's data with Y's session id?
7. Session expires at server-side on logout?
8. Can logged out user's session be re-used?
9. Is new session id generated on login?
10. Is cookie over-written on logout?

SQL Injection Checks

1. SQL Injection : '
2. SQL Injection : ' OR 1=1 --
3. SQL Injection : '; waitfor delay'00:00:05'--

XSS Checks

1. XSS Javascript
2. XSS Encoded
3. XSS Cookie
4. Is CSRF possible?

Input Validation Checks

1. Use proxy to by-pass client side validation?
2. Generate errors for information disclosure?
3. Web Page source reveals sensitive application information
4. HTTP Headers manipulation
5. Viewstate manipulation
6. GET and POST parameter manipulation

Secure Storage Checks

1. Are passwords stored in clear text?
2. Is sensitive information like Credit Card encrypted?
3. What encryption algo used? Standard or Proprietary?
4. Is connection string in clear text?
5. Any passwords hard-coded in application?

Browser Checks
1. Check browser history? Are sensitive pages cached?
2. Is data cached by search engines or desktop search engine?
3. Any hard-coded secrets in javascripts?
4. Web Page code reveals sensitive comments?

File Checks

1. Is file upload /download allowed?
2. Can files be downloaded directly from URL?
3. Can malicious files be uploaded?


Environment Checks

1. Are default apps installed?
2. Are default accounts enabled? Do they have strong passwords?
3. Is firewall deployed?
4. Is code obfuscated?
5. Can detect server details using banner grabbing?
6. Are forms bot resistant?

In case you have your views, please feel free to write here or mail me at dharmeshmm at gmail dot com

Cheers,
Dharmesh.

Web Services Design Security Considerations

Web Services Design Security Considerations

I. Information Gathering

1. WSDL Retrieval: Identify web method call mechanics
2. SOAP Error Messages
3. Web Method Enumeration: Identify methods not published in the WSDL.

II. Parameter Manipulation

1. Identify mishandling of numerical fields, character strings, Base64 data handling, etc.
2. Identify SQL Injection/XPATH Injection Vulnerabilities
3. XML input data is validated based on an agreed schema.
4. If parameter manipulation is a concern (particularly where messages are routed through multiple intermediary nodes across multiple network links). Messages are digitally signed to ensure that they cannot be tampered with.
5. Determine whether the logging mechanism is vulnerable to arbitrary entry creation via carriage return and line feed injection.
6. Assess the possibility of inserting HTML tags into a HTML based log.
7. Assess the possibility of inserting XML elements and/or attributes into an XML based log.
8. Determine the logging mechanism’s susceptibility to white space injection.
9. Assess the ability of the web service to log messages that contain special separator characters.
10. Assess the handling of log data after reaching the upper log size limit.
11. Assess the web service’s susceptibility to LDAP injection.

III. Authentication and Authorization

1. Web services that support restricted operations or provide sensitive data require and support authentication.
2. Where appropriate, access to publicly accessible Web methods is restricted using declarative principle permission demands.

IV. Sensitive Data

1. Sensitive data in Web service SOAP messages is encrypted using XML encryption OR messages are only passed over encrypted communication channels (for example, using SSL.)
2. Identify the encryption cipher used in the application.
3. Determine the items within web service communications that are encrypted.
4. Determine the items within web service communications that are protected by message integrity checks.

V. Exception Handling

1. SOAP Exceptions are thrown and returned to the client using the standard SOAP element.
2. If application-level exception handling is required a custom SOAP extension is used.

VI. Auditing & Logging

1. The Web service logs transactions and key operations.

VII. Proxy Considerations

1. The URL Behavior property of the Web reference is set to dynamic for added flexibility.
2. The endpoint address in Web Services Description Language (WSDL) is checked for validity.

VIII. Configuration

1. Unnecessary Web service protocols, including HTTP GET and HTTP POST, are disabled.
2. The Web service runs using a least-privileged process account.
3. Debugging and Tracing are disabled.
4. Identify directory traversal vulnerabilities.
5. Assess the level of information disclosure from temporary files.