Nine Most common security errors made by Web application developers

Nine Most common security errors made by Web application developers

Web application development is a broad topic. This article only discusses security errors that Web application developers should avoid. These errors involve basic security principles that should not be ignored by any developer.

What basic security principles should developers pay attention? What security errors should be avoided? To answer these questions, the following suggestions can be answered.

Self-righteous: Develop your own security methods

Some developers mistakenly think that their algorithms or authentication methods are safer: after all, hackers have never seen this method, so they are more difficult to crack. Is that true?

The answer is no. It is an error for developers to develop their own authentication or login methods because they will make one or more mistakes that hackers can discover. Developers should rely on existing fully tested security methods because they have been repeatedly tested by the security community. Therefore, these methods are unlikely to include major security vulnerabilities ignored by developers. Some security experts pointed out that anyone can invent an encryption algorithm that they cannot crack, but it is much more difficult to develop a method that others cannot crack. Therefore, developers should honestly use the authenticated or security testing methods.

Careless: access the database directly using the information provided by the user

When developing applications, especially Web applications, many developers fail to fully validate the input data received from users. This approach has security issues because it allows illegal data to enter the customer's database and has a greater security risk. User input cannot be verified (whether from the Web or from the API), resulting in SQL injection, cross-site scripting attacks, command hijacking, and buffer overflow, and other Web application vulnerabilities exploited by attackers.

This error is most common in Web application development. If these programs are not protected, users may use input fields to inject malicious scripts into the application or access the private data of the database. Of course, most users do not have any malicious attempts, but developers must use defensive mentality and methods to process user input.

 

Developers should not trust user input easily, but perform dual verification on the client and server. Otherwise, serious vulnerabilities may occur, such as cross-site scripting attacks and SQL injection.

 

Ignore global: Focus on components rather than the entire system

Large development projects are often different parts of applications developed by multiple developers, so developers are easy to focus on individual components. Of course, every small part of an application developed in this way may be safe, but have developers considered the overall security?

Many security problems arise not from components, but only when data and processes flow from one part of the business process to another. Developers generally assume a part of a business process, and generally do not understand other parts of the business process. This lack of awareness can lead to insecure data transmission, which can expose data to various attacks and threats, such as man-in-the-middle attacks, data integrity problems, and information leakage.

It is essential for developers to have a systematic view of Enterprise Business Services. Only in this way can they understand how all components work together and how to ensure the security of the merged applications.

Post-fix: add security features later in development

Some websites or Web applications do not have built-in security during construction. Remember: security is not something that will be added in the future. It should be part of the overall functionality of the entire application architecture. Architecture is the most important aspect of application development because it affects all other aspects of the application, including security.

The performance of such errors (such as vulnerabilities and misconfiguration) can be traced back to the development stage: developers finally use security as an additional feature or feature. If some development teams know this: yes, all the functions are running normally. Now, let's start to solve the security problem. This idea brings security vulnerabilities in the application architecture to increase risks. After the application is fully deployed, it is difficult for anyone to solve cross-site Request Forgery (CSRF) and a large number of SQL injection vulnerabilities. Therefore, developers should build security throughout the entire lifecycle of developing and building Web applications.

Allow Users: allow users to generate weak passwords

When attackers crack websites or Web applications and expose user passwords, a clear fact emerges: users' security habits are too bad. For example, the most common passwords for users are "abcde" or "12345678. Web application developers should not allow users to create weak passwords. Developers should require the user's password to be sufficiently long to ensure it is easy to remember but difficult to guess (for example, a strong password should contain at least letters, numbers and special characters, it can contain more than 10 characters ). The best password is not necessarily the most complex. Forcing users to use overly complex passwords often leads to insecure user practices, such as writing down the passwords and then sticking them to a place on the computer.

 

Ignore encryption: store user passwords and data in plain text

The most common mistake for Web application developers is that they do not ensure the security of user authentication creden. Users assume that websites or Web applications are safe, but unfortunately too many websites or Web applications are not doing well. In general, Web applications or websites often have vulnerabilities in password processing and saving methods.

Q: How can I properly Save the password? Here we will focus on one of the most common but insecure practices: Saving passwords in plain text. Many large companies may make such mistakes. Any damages to enterprise databases should not expose user data to risks, especially passwords used by users. Therefore, enterprise applications should encrypt users' passwords and other details before saving them in a database.

Enterprise Application developers must think about how hackers can easily steal data when they gain access to enterprise databases? If the developer encrypts the data, a large amount of personal and enterprise information will be leaked.

Only because the database engine requires a user name and password does not mean that hackers cannot steal data files and . Data security depends on the security of the database engine. If hackers exploit the vulnerabilities of the database engine, they can easily access the database. This is why many large games and e-commerce websites have been cracked and all personal information, including credit card data, has been stolen.

"Repair path": Passing variables through URL pathnames

There is also a dangerous but common practice: many developers put variables in URLs, which opens the door for hackers to exploit other applications or data. The risk of such errors is huge.

Developers absolutely cannot allow variables for user interaction to become part of the file path. If the URL contains the path of the downloaded file, attackers can modify the URL to reference another file, which may download the file containing the user password. Therefore, attackers can exploit the vulnerability by using a link (for example, this link allows users to download the free version of the application.

The so-called developer "mingxiu" has made a "Treasure road", but has been "Hacked" by attackers ".

Ignore this: only perform authorization on the client

 

Nowadays, more and more developers are paying more and more attention to clients. This trend will make the application faster and more powerful, but if the developer cannot solve the authorization problem of the program correctly, it will bring security risks.

 

Many Web application developers rely on the client browser to complete previous tasks on the server. From the security point of view, this approach lacks a lot of control, because developers do not understand the types of clients. The client may not even be a browser. Developers should not trust the operations on the client easily, and should not rely solely on JavaScript or client code to implement key functions. Pay attention to functions involving payment information and other sensitive information.

Blind optimism: Think you cannot have problems

When developing Web applications, developers may easily make the mistake of believing that their applications will not be attacked or that they will not make mistakes. These ideas will lead to security issues. Developers should always imagine that their programs will be attacked and they will also make security mistakes. This idea helps developers avoid or reduce security risks and avoid losses to the company.

Everyone will make mistakes. If the developer finds the problem before the hacker finds the vulnerability, the problem is not big. When developers and Software testers test and audit Web applications, or before the enterprise is put into use, developers or testers may use the well-known open-source tool owasp zap to scan enterprise applications, find Common Vulnerabilities and errors.

Conclusion

This article describes some of the most basic but important security errors. On this basis, developers are expected to further discover and summarize other problems in the Web application development process, and build a more solid security guarantee.