Configuration File Tampering
If Configuration files are not protected then you should use the file system access control list (ACL) to protect them.
If registry entries are not protected then you should use the registry ACL to protect them.
Repudiation / Logging
Security exceptions should be logged for auditing purposes; therefore, you should define and implement logging and auditing strategies in the code. Push security exceptions–related information to the event log.
Assembly Tampering
To prevent assembly tampering, consider implementing Authenticode signatures for these assemblies.
Authentication and Authorization
You should consider various Internet, intranet, and extranet-based deployment for Web servers and database servers, and then implement appropriate authentication mechanisms.
You should implement transport-level security (secure socket layer [SSL]) to further strengthen the communication channel. You can also implement IPsec to secure communication channel between services and the database. To implement message-level security, use either WSE 3.0 or WCF to sign and encrypt messages. Choose appropriate certificates and encryption algorithms to enforce security without compromising business operations and performance.
You can prevent these attacks by providing a secure end-to-end communication channel between server and client (for example, SSL). You should also uniquely authenticate each request (for example, use a timestamp and digital signature), by implementing message-level security. Implement IP lockout policies if required.
You can prevent denial of service attacks by implementing strong authentication, authorization, and request validation mechanisms. Also, you should uniquely authenticate each request (for example, use a timestamp and digital signature) by implementing message-level security.
You can prevent repudiation attacks by implementing strong authentication, authorization, and request validation mechanisms. Also, you should implement the history and auditing feature for any database operations. You should not permanently delete the records from the database.
You should try to prevent dictionary attacks or password brute force attacks. Implement strong password policies to prevent password hijacking. Implement a maximum retries policy, and disable the account if the number of attempts exceeds the maximum number. Also, implement an IP lockout policy, if required. Implement auditing and logging for service contracts / Web server / service host access.
You can prevent spoofing attacks by implementing strong authentication, authorization, and request validation mechanisms.
Use an account that has restricted permissions in the database. Ideally, you should grant execute permissions only to selected stored procedures. Consider using database role and application role database security concepts to access a different set of database objects. For example, consider using different sets of database roles and application roles for read-only operations and read-write operations.
Configuration Files Clear Text Secrets
To protect your connection strings, secret app settings, consider using DPAPI to encrypt them and store clear text secrets in a restricted registry. Use file ACLs to control access to configuration files.
The database contains secrets in clear text. For a production application, you should consider encrypting sensitive data.
The Web.config file allows a malicious user to see the Web service documentation (wsdl file) by using documentation protocol. Using this information, the malicious user can get information about all data contracts and service contract details. The malicious user can then use the details to launch brute force attacks or false request attacks. You should configure the Web.config file to disable the documentation protocol.
The host program configuration file allows debugging. The Web.config file describes the debug = true attribute, which can allow the malicious user to debug the service implementation. This opens extra surface area, which allows a malicious user to explore injection threats. To prevent this type of attack, configure debug = false in the Web.config file.
The host program configuration file allows debugging. The Web.config file describes the CustomErrors Mode = off attribute, which can allow the malicious user to see the complete debug information in case of errors or exceptions. A malicious user can get the call stack information, which can launch injection or code malfunction attacks. To prevent this type of attack, configure CustomErrors Mode = on and make sure that the defaultUrl is appropriately configured in the Web.config file.
The database connection string in the Web.config file does not contain a definition for the PersistSecurityInfo attribute. This attribute should be set to false. When set to false, sensitive information, such as the password, is not returned as part of the connection if the connection is open or has ever been in an open state. Resetting the connection string resets all connection string values, including the password. Set the PersistSecurityInfo attribute to false in the connection string.
The database access assembly does not define the code access security attribute SqlClientPermission.
The CustomerRepository assembly should request minimum security permissions for SqlClientPermission.
When developing classes that will be deployed to a production environment, you should consider using sealed attributes for classes and methods.