Follow secure coding practices in Enterprise 11
- 최종 업데이트2022/08/10
Follow secure coding practices in Enterprise 11
Bot developers should ensure their code follows standard secure coding practices, including Bot Logic and C# code written for DLLs.
The following list of security checks are generally applicable and relevant for bot creation.
These checks correspond to specific software vulnerabilities identified by the Open Web Application Security Project (OWASP), a not-for-profit organization focused on improving the security of software. Each of the following OWASP issues correspond to specific items included in the Common Weakness Enumeration (CWE), a list of software security vulnerabilities which can occur in software development as provided by MITRE, a nonprofit research and development group.
Developers must consider additional secure coding practices in accordance with the internal security policies of their environments.
| OWASP issue | Description | Corresponding CWEs |
|---|---|---|
| A1: Injection | Almost any source of data can be an injection vector, environment variables, parameters, external and internal web services, and all types of users. Injection flaws occur when an attacker can send hostile data to an interpreter. |
|
| A2: Broken Authentication | Attackers have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. Session management attacks are well understood, particularly in relation to unexpired session tokens. |
|
| A3: Sensitive Data Exposure | Rather than directly attacking crypto, attackers steal keys, execute man-in-the-middle attacks, or steal clear text data off the server, when in transit, or from the user's client, such as a browser. A manual attack is generally required. Previously retrieved password databases could be brute forced by Graphics Processing Units (GPUs). |
|
| A5: Broken Access Control | Exploitation of access control is a core skill of attackers. SAST and DAST tools can detect the absence of access control but cannot verify if it is functional when it is present. Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks. |
|
| A6: Security Misconfiguration | Attackers often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories, and so on, to gain unauthorized access or knowledge of the system. |
|
| A9: Using Components with Known Vulnerabilities | Although it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require a concentrated effort to develop a custom exploit. |
|