First, the MVC framework Security
from the data inflow, the user submits the data successively through the view layer, Controller, model layer, the data outflow is in turn. when designing a security solution, hold on to the key factor of data.
In spring security, for example, access control via URL pattern requires the framework to handle all user requests, and it is possible to implement a post-security check after the spring security acquires the URL handler. In the spring security configuration, the first step is to add a filter to the Web. xml file to take over the user data.
<Filter> <Filter-name>Springsecurityfilterchain</Filter-name> <Filter-class>Org.springframework.web.filter.DelegatingFilterProxy</Filter-class></Filter><filter-mapping> <Filter-name>Springsecurityfilterchain</Filter-name> <Url-pattern>/*</Url-pattern></filter-mapping>
Some of the major web security threats, such as XSS, CSRF, SQL injection, access control, authentication, URL jumps, and other security issues that do not involve business logic, can be centrally addressed in the MVC framework.
Second, template engine and XSS defense
In the view layer, you can resolve the XSS issue. XSS attacks are performed on the user's browser, and the process is caused by the injection of malicious HTML code when the server-side page renders. From the MVC architecture, it happens in the view layer, so the defense method using "output encoding" is more reasonable, which means that there is a need to use different encoding methods for XSS attack scenarios of different contexts.
Third, web framework and CSRF Defense
security tokens can be used in web frameworks to solve the csrf attack problem.
The target of the CSRF attack generally produces the URL of the "Write data" operation, because the attacker is unable to obtain the data returned by the server during the CSRF attack, and the attacker simply triggers the server's action by using the user's hand. So reading data has no direct meaning for CSRF (but if there is an XSS vulnerability or other cross-domain vulnerability, it can cause other problems, here, just to discuss the csrf confrontation itself).
in Web application development, it is necessary to distinguish between "read operations" and "write operations", such as requiring all "write operations" to use HTTP POST.
In fact, the post itself is not enough to fight CSRF, because post can also be automatically submitted. However, the use of post, for the protection of tokens has a positive meaning, the privacy of the two security token (non-predictable principle), is the basis of defense csrf attack.
for web frameworks, tokens can be automatically added to all code that involves post, including all form forms, all Ajax post requests, and so on.
A complete CSRF defense solution, there are several places to change for the web framework.
- Binds tokens in the session. If it cannot be saved to the server-side session, it can be saved in a cookie instead.
- The token field is automatically populated in the form form, such as <input Type=hidden name= "Anti_csrf_token" value= "$token"/>.
- Tokens are automatically added to AJAX requests, which may require support for an existing Ajax wrapper implementation.
- Verify the CSRF attack by comparing the token of the post submission parameter with the token binding in the session on the server side.
Iv. HTTP Headers Management
In the web framework, HTTP headers can be processed globally, so some HTTP header-based security schemes can be implemented well.
For example, CRLF injection for HTTP return headers.
Similarly, for 30X to return a good HTTP Response, the browser will jump to the URL specified by the location, attackers often use such features to implement phishing or scams.
http/1.1 302 Moved temporarily (...) Location:http://www.phishing.tld
for the framework, it is necessary to manage the jump address . Generally speaking, this thing can be done in two places:
- If the web framework provides a unified jump function, you can implement a white list within the Jump function, specifying that the jump address can only be in the whitelist;
- Another solution is to control the Location field of the HTTP, which can only be used to limit the values of the locations, as well as the same effect.
V. Data persistence layer and SQL injection
Using the ORM (Object/relation Mapping) framework is positive for SQL injection. The best way to combat SQL injection is to use precompiled binding variables.
[note] "White hat Talk Web Security"-Web framework Security