Web security development considerations

1. SQL injection: this is a common practice. Do not pin strings or filter keywords to prevent attacks. Note that parameters submitted by cookies can also cause injection vulnerabilities.
2. Side Note: ensure that your programs are okay, and ensure that other sites on the same server are okay. At least set system permissions, even if someone else's site has problems, it cannot affect your site.
3. Upload: Do not use the upload function if possible. You must also do the following: do not allow the user to define the path and file name, and restrict the types of files that can be uploaded. At the same time, you must restrict permissions. Basic rules: Execution and writeable permissions are mutually exclusive and should not exist at the same time.
4. Password strength: Password strength requirements should be added to functions such as password setting. When the server is deployed online, the default password should be changed immediately.
5. Anti-exhaustive mechanism: add the verification code as appropriate to prevent other users from using the program to raise the account password.
6. Third-party controls: the use of third-party controls should be strictly reviewed (many third-party controls intentionally leave defects), and unnecessary functions should be removed before use.
7. minimal permissions: read-only access is allowed. Try to be specific to each sub-directory.
8. The directory is very regular: it is difficult to obtain the Administrator account password, but cannot find the background logon address. The background path is not always http://www.bkjia.com/admin, manager, gl and so on, it is easy to guess.
10. XSS: cross-site scripting attacks. Users input HTML, JS, and other tags into the editing box. After receiving the data, the layout error and JS parsing and execution can be displayed again, all of which belong to the XSS category. If an attacker inserts an Iframe and connects to a Trojan webpage, the person who views the content will be miserable. Solution: filter the number greater than or less than the number.
11. Unverified csrf url Redirection Vulnerability: similar to XSS, the code is only written in the URL, as shown in
Http: // www.2cto.com/logout. aspx? Preurl1_aaaa.html
That is, it often appears on the login exit page. The preURL of the parameter determines the page to jump to when the action is completed.
Http://www.bkjia.com/logout. aspx? PreURL = javascript: alert ('test ')
In the dialog box, the JavaScript code has been executed.
 
In a word, in the development process, do not trust any data submitted by the user, plan the directory, minimize permissions, and close or delete unnecessary things, which will be much safer.
 
Cert security code suggestions:
1. Verification input: input from untrusted data sources must be verified. Appropriate input verification reduces the number of software vulnerabilities. You must be skeptical about most data sources, including command line parameters, network interfaces, environment variables, and user files.
2. Leave a message for the compiler warning: Use the highest warning level of the compiler when compiling the code, and reduce the warning by modifying the code.
3. architecture and design for security policies: security policies are used to build software architecture and design software. For example, if the system requires different permissions at different times, consider dividing the system into different subsystems that communicate with each other. Each system has the appropriate permissions.
4. Simplicity: The simpler the design, the better. Complicated design increases the possibility of errors during implementation.
5. default deny: the default access policy is based on the permission. That is to say, the default access is denied unless indicated as permitted.
6. Minimum permission principle: each process has the minimum permissions required to complete the work. The validity period of any permission must be as short as possible. This method can prevent attackers from using their permissions to execute arbitrary code.
7. clean data sent to other systems: clean all data sent to complex subsystems, such as command shell (shells), relational databases, and commercial components. Attackers may use SQL commands or injections to launch attacks. This is not a problem avoided by the subsystem through input verification. Because the subsystem does not know the call context, but the call process guidance context, it is the responsibility to clean the data when calling the subsystem.
8. defense in depth: this is a general security principle that avoids risks from multiple defense policies. If one layer fails, the other layer is still playing a role.
9. Use effective security and quality assurance technologies: Good Quality Assurance technologies can effectively detect and eliminate vulnerabilities. Penetration Testing, Fuzz testing, and source code auditing are all effective quality assurance measures. Independent security reviews allow for a safer system.
10. Adopt security coding standards: Specify security coding standards for development languages and platforms and adopt these standards.
 
 
From http://infosec.blog.51cto.com/226250/801492