Access control vulnerabilities are common in Java applications, especially in web development, and are mainly caused by poor permission verification. There are four solutions: First, the permission verification pre-installation, intercepting at the Controller or Filter layer, and unifying the entry control permissions; second, use Spring Security to simplify permission control, and centrally manage interface permissions through annotation or configuration classes; third, prevent IDOR vulnerabilities, do attribution checks when accessing resources, and restrict overprivileges in combination with database query; fourth, avoid hard-coded permission logic, and use the RBAC model to dynamically configure permission rules to improve flexibility and maintainability.

Access control vulnerabilities are very common in Java applications, especially in web development. If permission verification is not strict, it is easily bypassed. This type of problem is usually not because of Java itself, but because developers neglect details when implementing permission logic. The key to solving this type of problem is: strictly verify user identity, refine permission control, and avoid hard-coded permission logic .

User permission verification should be pre-set, not post-set

Many Java applications like to make judgments in business logic when processing permissions, such as:

 if (user.role == "admin") {
    // Perform an action}

This method is easily bypassed, especially when the URL directly exposes the resources. The correct way is to do permission verification before entering the business logic, such as intercepting in the Controller layer or Filter layer.

For example:

 @Override
protected void doFilterInternal(HttpServletRequest request, 
                                  HttpServletResponse response, 
                                  FilterChain filterChain)
    throws ServletException, IOException {

    String token = extractToken(request);
    User user = getUserFromToken(token);

    if (!isAccessAllowed(request, user)) {
        response.sendError(HttpServletResponse.SC_FORBIDDEN);
        return;
    }

    filterChain.doFilter(request, response);
}

The advantage of this is to unify entry control permissions and avoid writing verification logic through each interface.

Simplify permission control with Spring Security

If you are using Spring Boot, Spring Security is a very practical tool. It can not only perform login authentication, but also finely control interface permissions.

For example, you can use annotations to restrict access to methods:

 @PreAuthorize("hasRole('ADMIN')")
public void deleteUser(Long userId) {
    // Only the ADMIN role can be called}

Or configure URL permissions uniformly in the configuration class:

 @Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .requestMatchers("/admin/**").hasRole("ADMIN")
                .requestMatchers("/user/**").hasAnyRole("USER", "ADMIN")
                .anyRequest().authenticated()
            .and()
            .httpBasic();
        return http.build();
    }
}

The advantage of this is that permission logic is centralized management, which facilitates maintenance and auditing.

Avoid IDOR (Insecure Direct Object References)

IDOR is a common Broken Access Control problem, which refers to users who can access resources that do not belong to their own by modifying the request parameters. for example:

 GET /api/users/123

If user A can access user B's information by changing 123 to 456, it is a typical IDOR vulnerability.

The solution is: every time you access the resource, you must do an attribution check .

for example:

 User requestedUser = userService.findById(userId);
if (!requestedUser.getOwnerId().equals(currentUser.getId())) {
    throw new AccessDeniedException("No permission to access");
}

Or combine database queries more granularly:

 SELECT * FROM users WHERE id = ? AND owner_id = ?

In this way, even if the attacker guesses the ID, he will not be able to access it beyond his authority.

Do not hard-code permission data, consider dynamic configuration

Many projects like to use if-else to judge roles when controlling permissions, such as:

 if (user.getRole().equals("admin")) {
    // ...
}

The problem with this approach is that once the permission logic changes, the code needs to be changed and redeployed. A more reasonable approach is to use a database or configuration center to manage permission rules.

Consider:

• Using the RBAC (role-based access control) model
• Store permission rules in the database
• Dynamic query permissions every time you access

The advantage of this is that permission adjustments are flexible and there is no need to change the code.

In general, the core of access control issues in Java applications is that permission verification must be unified, pre-oriented, and fine-grained . Tools such as Spring Security have provided good basic capabilities, and the key is that developers must use them correctly. Many loopholes are not because of technical difficulties, but because the details are not done properly.

The above is the detailed content of Java Security for Broken Access Control. For more information, please follow other related articles on the PHP Chinese website!