UI Security Check #1

I was trying to collate a few checks for Web UI Security. Here are somethings for check ONE....
I invite people to put in their suggestions and comments for the same.

#1. Does the UI disclose information that might compromise the security of the system?

• Don’t provide information in error messages that might compromise the security of the system.
• Don’t reveal data store locations and URL’s when they are not necessary
• Mask sensitive information such as SQL Server name, User ID, Password
• Don’t return errors with cross-site scripts
• Don’t allow links to open executables
• Don’t provide error information with clickable links. Convert links to plain text to encourage these to be scrutinized prior to being launched
• Ensure that logs are correctly stripped of sensitive information

Relevance: Developer

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.

Alternative to IE and Firefox

An interesting alternative is SecureIE (www.secureie.com) which costs 30$ and seems
to outperform Firefox and IE in the security field (http://tinyurl.com/bjayn).