In modern web development, using the MVC framework is a popular approach. MVC stands for model–view–controller. It divides web applications into three interconnected layers. The view layer can be any output representation of information and is responsible for the user’s view, the page display, etc.; the controller accepts inputs and converts them into commands for the model or view layers; the model layer is responsible for the implementation of the model to complete the processing of data.
Let us look at how the data flow in. User-submitted data has flown through the view, controller, and model layers. The outflow of data is in the opposite direction. We should focus on data in the design of security solutions. In the MVC framework, by slicing, filters, etc., we can often process data within the whole picture of data flow, which is very convenient for the design of security solutions.
For example, in Spring Security, access control by the URL pattern needs the framework to handle all the requests of users. After Spring Security obtains the URL handler, it is possible to implement a subsequent security check. In the configuration for Spring Security, the first step is to add a filter in the web.xml file to take over the user data.
However, data processing is complex; for example, the content of data may have changed after being processed by different applications. The data will change from uppercase to lowercase by the “toLowercase” process, while some decoding can change GDB into Unicode. This processing will change the contents of the data; therefore, in the design of safety programs, we should consider possible changes in the data to carefully time the security checks.
An excellent security program should be: “do the right thing in the right place.” For example, in Injection Attacks we did not use magic_quotes_gpc in PHP as a defense program against SQL injection; this is because magic_quotes_gpc is defective and does not solve the problem in the right place. magic_quotes_gpc actually calls addslashes () to change some special symbols (such as the single quotation mark) into \’. In the MVC architecture, this is done in the view layer, and SQL injection is the problem that the model layer needs to resolve. As a result, hackers have found a variety of ways to bypass magic_quotes_gpc, such as using GBK encoding, with injection of no single quotation mark.
PHP finally started to face this issue after a few years, so in official documents,* they no longer recommended using it. So it would be counterproductive to solve the problem of the model layer in the view layer.
In general, we need to think clearly what problem is to be solved and then conduct security checks for data in the right place after an in-depth understanding of these issues. Some of the major web security threats, such as XSS, CSRF, SQL injection, access control, authentication, URL jumps, etc., do not involve business logic and can be solved in the MVC framework. The implementation of safety programs in the framework has more advantages than fixing bugs one by one by the programmer.
First, some security problems can be solved in the framework at the same time to greatly reduce the workload of programmers and labor cost. When the code size is too big, specifically spending time to fix vulnerabilities one by one is almost impossible under strict deadlines. Second, some of the common vulnerabilities, which are repaired one by one by the programmer, may still have problems, but a unified solution in the framework can solve the missed problems. This requires the development of relevant standards and code tools. Finally, fixing security holes in each business cannot make patch standard consistent, and the implementation of a centralized security solution in the framework can benefit all framework-based businesses, which makes it easier to manage the effectiveness of the security program.