A black and white list-based URL permission control method and system

Abstract

The application relates to the technical field of network security, in particular to a URL permission control method and system based on black and white lists, which comprises black and white list creation and maintenance, request interception, priority comparison and decision-making, and log auditing; beneficial effects are that by allowing an administrator to set priorities for different black and white list items, the application realizes unprecedented flexibility of permission configuration. This feature enables the system to easily cope with various complex and changeable authorization requirements, including but not limited to scenarios of simultaneously allowing and refusing access to specific URLs, thereby greatly expanding the application range of the black and white list control strategy.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, in particular to a URL permission control method and system based on black and white lists. BACKGROUND

[0002] With the rapid development of Internet technology, the diversification and complexity of network applications make the management of URL access permissions an important problem to be solved. Traditional black and white list control schemes occupy a place in the field of network security, by explicitly listing the allowed or denied URL list to limit user access permissions. However, in the face of complex and changing authorization requirements in modern network environments, the traditional scheme is not up to the task.

[0003] Specifically, the traditional black and white list control scheme has significant shortcomings in handling complex permission configurations. It can usually only simply decide access permissions according to whether the URL exists in the black list or the white list, lacking flexibility to handle complex scenarios of allowing and denying access to specific URLs.

[0004] For example, user A is allowed to access all URLs (represented by white list / **), but at the same time, user A is not allowed to access all content under / users / (represented by black list / users / **). However, for special needs, user A is allowed to access specific URLs such as / users / {id}. In the traditional black and white list scheme, such requirements often cannot be implemented because the black list will unconditionally override the allow rules of the white list. SUMMARY

[0005] The purpose of the present application is to provide a URL permission control method and system based on black and white lists, which realizes flexible configuration and fine management of access control policies by introducing a priority mechanism, thereby meeting the urgent needs of complex authorization requirements in modern network environments to solve the problems raised in the background art.

[0006] To achieve the above purpose, the present application provides the following technical scheme: a URL permission control method based on black and white lists, including black and white list creation and maintenance steps, specifically:

[0007] The administrator creates black and white lists through an interface or API interface and dynamically updates and maintains them;

[0008] Blacklist and whitelist information is stored in a relational database table. The table fields include id, user_id, type, method, url_template, and priority. id is the primary key, user_id is the user ID, type is an enumeration type, with a value of black indicating a blacklist and a value of white indicating a whitelist. method is the request method, including POST / GET / DELETE / PUT / PATCH / ALL. ALL matches all types of request methods. url_template is a URL template that supports wildcards. ? matches a single character, * matches a string of any length except the path identifier " / ", and ** matches a string of any length. Priority is a numeric value. Smaller values ​​increase the priority, while larger values ​​decrease the priority.

[0009] Provides interfaces for creating, deleting, modifying, and querying blacklists and whitelists for specified users. The request method for creating a blacklist and whitelist is POST, with the request URI being / admin / url-permissions. The request body includes the type, userId, method, url_template, and priority fields. The request method for deleting a blacklist and whitelist is DELETE, with the request URI being / admin / url-permissions / {id}. The request method for modifying a blacklist and whitelist is PUT, with the request URI being / admin / url-permissions / {id}. The request body includes the type, method, url_template, and priority fields. The request method for querying a blacklist and whitelist for a specified user is GET, with the request URI being / admin / url-permissions?userId={userId}.

[0010] Preferably, the method further includes a request interception step:

[0011] The request interception module is located before all requests enter the backend service. It intercepts all requests by configuring the interception rules of the HTTP server or using the interceptor function of the framework.

[0012] Extract URL information from HTTP requests and perform necessary preprocessing, such as URL decoding and removing query parameters;

[0013] According to the system's authentication mechanism, the current user's identity information is extracted from the request, including parsing the user ID and user name information from the HTTP header, Cookie, Session or Token.

[0014] Preferably, the method further includes priority comparison and decision-making steps:

[0015] The priority comparison and decision module receives URL information and current user information from the request interception module;

[0016] Query all blacklists and whitelists of the current user from the database and sort them in ascending order from high to low priority;

[0017] Traverse the sorted blacklist and whitelist entries. If a whitelist entry is encountered first and its priority is higher than all possible conflicting blacklist entries, access is allowed. If a blacklist entry is encountered and its priority is higher than all possible whitelist entries that may cover it, access is denied. If multiple entries with the same priority are encountered at the same time, a decision is made based on the preset rules.

[0018] Based on the decision result, access to the current URL request is allowed or denied.

[0019] Preferably, the log audit step is also included:

[0020] The log audit module records relevant information at key points in the request processing process. The log information includes request time, user ID, request URL, request method, authentication result, blacklist and whitelist comparison results, and access control decisions.

[0021] Use the log framework to output log information to the specified storage medium, using a unified log format, including timestamp, log level, and log content fields;

[0022] Provides audit interfaces in the form of RESTful API or web interface, allowing administrators to query log records based on time range, user ID, and request URL conditions, supports paging and sorting functions, and desensitizes sensitive information.

[0023] A control system for a URL permission control method based on black and white lists, including a black and white list management module for realizing the creation, deletion, modification and query functions of the black and white lists;

[0024] In the blacklist and whitelist management module, the blacklist and whitelist information is stored in a data table of a relational database. The data table fields include id, user_id, type, method, url_template, and priority. id is the primary key, user_id is the user ID, type is an enumeration type, the value black indicates a blacklist, the value white indicates a whitelist, method is the request method, including POST / GET / DELETE / PUT / PATCH / ALL, and ALL can match all types of request methods. url_template is a URL template that supports wildcards. ? matches a single character, * matches a string of any length except the path identifier " / ", and ** matches a string of any length. Priority is a numeric type. A smaller value indicates a higher priority, and a larger value indicates a lower priority.

[0025] Provides interfaces for creating, deleting, modifying, and querying blacklists and whitelists for specified users. The request method for creating a blacklist and whitelist is POST, with the request URI being / admin / url-permissions. The request body includes the type, userId, method, url_template, and priority fields. The request method for deleting a blacklist and whitelist is DELETE, with the request URI being / admin / url-permissions / {id}. The request method for modifying a blacklist and whitelist is PUT, with the request URI being / admin / url-permissions / {id}. The request body includes the type, method, url_template, and priority fields. The request method for querying a blacklist and whitelist for a specified user is GET, with the request URI being / admin / url-permissions?userId={userId}.

[0026] Preferably, it also includes a request interception module, which is located before all requests enter the backend service;

[0027] The request interception module intercepts all requests by configuring the interception rules of the HTTP server or using the interceptor function of the framework;

[0028] Extract URL information from HTTP requests and perform necessary preprocessing, such as URL decoding and removing query parameters;

[0029] According to the system's authentication mechanism, the current user's identity information is extracted from the request, including parsing the user ID and user name information from the HTTP header, Cookie, Session or Token, and forwarding the extracted URL information and user information to the priority comparison and decision module.

[0030] Preferably, it also includes a priority comparison and decision module;

[0031] The priority comparison and decision module receives the URL information and current user information forwarded by the request interception module;

[0032] Query all blacklists and whitelists of the current user from the database and sort them in ascending order from high to low priority;

[0033] Traverse the sorted blacklist and whitelist entries. If a whitelist entry is encountered first and its priority is higher than all possible conflicting blacklist entries, access is allowed. If a blacklist entry is encountered and its priority is higher than all possible whitelist entries that may cover it, access is denied. If multiple entries with the same priority are encountered at the same time, a decision is made based on the preset rules.

[0034] Based on the decision result, access to the current URL request is allowed or denied.

[0035] Preferably, it also includes a log audit module;

[0036] The log audit module records relevant information at key nodes of the request processing process, including request time, user ID, request URL, request method, authentication result, blacklist and whitelist comparison result, and access control decision;

[0037] Use the log framework to output log information to the specified storage medium, using a unified log format, including timestamp, log level, and log content fields;

[0038] Provides audit interfaces in the form of RESTful API or web interface, allowing administrators to query log records based on time range, user ID, and request URL conditions, supports paging and sorting functions, and desensitizes sensitive information.

[0039] Compared with the prior art, the present invention has the following beneficial effects:

[0040] The proposed blacklist-based URL permission control method and system achieves unprecedented flexibility in permission configuration by allowing administrators to prioritize different blacklist and whitelist items. This feature enables the system to easily handle a variety of complex and changing authorization requirements, including but not limited to scenarios where access to specific URLs must be both permitted and denied simultaneously, thus significantly expanding the application scope of blacklist and whitelist control strategies.

[0041] The introduction of a priority mechanism ensures that the system makes decisions based on clear priority rules when handling permission conflicts, thus avoiding the misjudgment or omission of permissions that may occur in traditional solutions. This increased accuracy is crucial for ensuring network access security and compliance. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 Flow chart of the method of the present invention. DETAILED DESCRIPTION

[0043] In order to clearly and completely describe the objectives and technical solutions of the present invention and make the advantages more clearly understood, the embodiments of the present invention are further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are part of the embodiments of the present invention, not all of them, and are only used to explain the embodiments of the present invention, not to limit the embodiments of the present invention. All other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0044] In the first embodiment, the present invention provides a technical solution: a URL permission control method based on a blacklist and whitelist, including the steps of creating and maintaining a blacklist and whitelist, specifically:

[0045] Administrators create blacklists and whitelists through the interface or API interface, and dynamically update and maintain them;

[0046] Blacklist and whitelist information is stored in a relational database table. The table fields include id, user_id, type, method, url_template, and priority. id is the primary key, user_id is the user ID, type is an enumeration type, with a value of black indicating a blacklist and a value of white indicating a whitelist. method is the request method, including POST / GET / DELETE / PUT / PATCH / ALL. ALL matches all types of request methods. url_template is a URL template that supports wildcards. ? matches a single character, * matches a string of any length except the path identifier " / ", and ** matches a string of any length. Priority is a numeric value. Smaller values ​​increase the priority, while larger values ​​decrease the priority.

[0047] Provides interfaces for creating, deleting, modifying, and querying blacklists and whitelists for specified users. The request method for creating a blacklist and whitelist is POST, with the request URI being / admin / url-permissions. The request body includes the type, userId, method, url_template, and priority fields. The request method for deleting a blacklist and whitelist is DELETE, with the request URI being / admin / url-permissions / {id}. The request method for modifying a blacklist and whitelist is PUT, with the request URI being / admin / url-permissions / {id}. The request body includes the type, method, url_template, and priority fields. The request method for querying a blacklist and whitelist for a specified user is GET, with the request URI being / admin / url-permissions?userId={userId}.

[0048] It also includes the request interception step:

[0049] The request interception module is located before all requests enter the backend service. It intercepts all requests by configuring the interception rules of the HTTP server or using the interceptor function of the framework.

[0050] Extract URL information from HTTP requests and perform necessary preprocessing, such as URL decoding and removing query parameters;

[0051] According to the system's authentication mechanism, the current user's identity information is extracted from the request, including parsing the user ID and user name information from the HTTP header, Cookie, Session or Token.

[0052] It also includes priority comparison and decision-making steps:

[0053] The priority comparison and decision module receives URL information and current user information from the request interception module;

[0054] Query all blacklists and whitelists of the current user from the database and sort them in ascending order from high to low priority;

[0055] Traverse the sorted blacklist and whitelist entries. If a whitelist entry is encountered first and its priority is higher than all possible conflicting blacklist entries, access is allowed. If a blacklist entry is encountered and its priority is higher than all possible whitelist entries that may cover it, access is denied. If multiple entries with the same priority are encountered at the same time, a decision is made based on the preset rules.

[0056] Based on the decision result, access to the current URL request is allowed or denied.

[0057] Also includes log audit steps:

[0058] The log audit module records relevant information at key points in the request processing process. The log information includes request time, user ID, request URL, request method, authentication result, blacklist and whitelist comparison results, and access control decisions.

[0059] Use the log framework to output log information to the specified storage medium, using a unified log format, including timestamp, log level, and log content fields;

[0060] Provides audit interfaces in the form of RESTful API or web interface, allowing administrators to query log records based on time range, user ID, and request URL conditions, supports paging and sorting functions, and desensitizes sensitive information.

[0061] Example 2, based on Example 1, proposes a control system for a URL permission control method based on a blacklist and whitelist, including:

[0062] Blacklist and whitelist management module: Administrators create blacklist and whitelist through the interface or API interface, and dynamically update and maintain them.

[0063] Blacklist and whitelist storage: Blacklist and whitelist information is stored in a relational database table. The table structure is as follows:

[0064]

[0065] Main interfaces

[0066] Create a blacklist and whitelist

[0067] Request method POST

[0068] Request URI: / admin / url-permissions Request Body:

[0069]

[0070]

[0071] Delete blacklist and whitelist

[0072] Request method DELETE

[0073] Request URI / admin / url-permissions / {id}

[0074] Modify the blacklist and whitelist

[0075] Request method PUT

[0076] Request URI / admin / url-permissions / {id}

[0077] Request Body:

[0078]

[0079] Query the blacklist and whitelist of a specified user

[0080] Request method GET

[0081] Request URI: / admin / url-permissions?userId={userId} Return result:

[0082]

[0083]

[0084] Request interception module: The request interception module is located before all requests enter the backend service. It is responsible for intercepting all requests, extracting the requested URL information and current user information, and forwarding the request to the subsequent priority comparison and decision module for further processing based on this information.

[0085] Request interception: By configuring the interception rules of the HTTP server (such as Nginx, Apache or Tomcat, etc.), or using the interceptor function of the framework (such as Spring MVC, ASP.NET MVC, etc.), all HTTP requests entering the system can be intercepted.

[0086] URL extraction: Extract URL information from HTTP requests and perform necessary preprocessing (such as URL decoding, removing query parameters, etc.).

[0087] User extraction: Extract the current user's identity information from the request based on the system's authentication mechanism. This may include parsing the user ID, username, and other information from HTTP headers (such as Authorization, X-User-ID, etc.), cookies, sessions, or tokens.

[0088] Priority comparison and decision-making module:

[0089] The priority comparison and decision module is responsible for comparing the URL information extracted from the request with the entries in the blacklist and whitelist database, and making access control decisions based on the priority rules.

[0090] Information extraction: Receive URL information (including request method and URL path) and current user information from the request interception module.

[0091] Get all blacklist and whitelist information for the current user: Query all blacklist and whitelist information for the current user from the database and sort them from high to low by priority. Since the lower the priority value, the higher the priority, the matching entries need to be sorted in ascending order.

[0092] Decision logic: Traverse the sorted blacklist and whitelist entries:

[0093] If a whitelist entry is encountered first and takes precedence over all potentially conflicting blacklist entries, access is allowed.

[0094] If a blacklist entry is encountered and its precedence is higher than any whitelist entry that might override it, access is denied.

[0095] If multiple entries with the same priority are encountered at the same time (although this should be avoided as much as possible by design), a decision is made based on preset rules (such as "blacklist first").

[0096] Result output:

[0097] If the decision result is allow, the current URL request is allowed to access.

[0098] If the decision result is denied, access to the current URL request is denied.

[0099] Log audit module:

[0100] The log audit module is responsible for recording user access behavior, authentication results, blacklist and whitelist comparison results and other information, and provides an audit interface for administrators to trace and review.

[0101] Logging: Record relevant information at key points in the request processing process (such as request interception, priority comparison and decision-making, access control execution, etc.). Log information includes but is not limited to: request time, user ID, request URL, request method, authentication results, blacklist and whitelist comparison results, access control decisions, etc.

[0102] Use a logging framework (such as Log4j, Serilog, etc.) to output log information to a specified storage medium (such as a file, database, remote log server, etc.).

[0103] Log format: Use a unified log format to facilitate subsequent parsing and querying.

[0104] It can include fields such as timestamp, log level (such as INFO, WARN, ERROR, etc.), log content, etc.

[0105] Audit interface: Provides an audit interface in the form of a RESTful API or web interface, allowing administrators to query log records based on conditions such as time range, user ID, and request URL.

[0106] Supports paging and sorting functions to allow administrators to browse and review log information efficiently.

[0107] Sensitive information is desensitized to protect user privacy and data security.

[0108] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A URL permission control method based on blacklist and whitelist, characterized by: Includes steps for creating and maintaining blacklists and whitelists, specifically: Administrators create blacklists and whitelists through the interface or API interface, and dynamically update and maintain them; Blacklist and whitelist information is stored in a relational database table. The table fields include id, user_id, type, method, url_template, and priority. id is the primary key, user_id is the user ID, type is an enumeration type, with a value of black indicating a blacklist and a value of white indicating a whitelist. method is the request method, including POST / GET / DELETE / PUT / PATCH / ALL. ALL matches all request methods. url_template is a URL template that supports wildcards. ? matches a single character, * matches a string of any length except the path identifier " / ", and ** matches a string of any length. Priority is a numeric value. A smaller value indicates a higher priority, while a larger value indicates a lower priority. Provides interfaces for creating, deleting, modifying, and querying blacklists and whitelists for specified users. The request method for creating a blacklist and whitelist is POST, the request URI is / admin / url-permissions, and the request body contains the type, userId, method, url_template, and priority fields. The request method for deleting a blacklist and whitelist is DELETE, the request URI is / admin / url-permissions / {id}. The request method for modifying a blacklist and whitelist is PUT, the request URI is / admin / url-permissions / {id}, and the request body contains the type, method, url_template, and priority fields. The request method for querying a blacklist and whitelist for a specified user is GET, the request URI is / admin / url-permissions?userId={userId}. It also includes priority comparison and decision-making steps: The priority comparison and decision module receives URL information and current user information from the request interception module; Query all blacklists and whitelists of the current user from the database and sort them in ascending order from high to low priority; Traverse the sorted blacklist and whitelist entries. If a whitelist entry is encountered first and its priority is higher than all possible conflicting blacklist entries, access is allowed. If a blacklist entry is encountered and its priority is higher than all possible whitelist entries that may cover it, access is denied. If multiple entries with the same priority are encountered at the same time, a decision is made based on the preset rules. Based on the decision result, access to the current URL request is allowed or denied.

2. A URL permission control method based on blacklist and whitelist according to claim 1, characterized in that: It also includes the request interception step: The request interception module is located before all requests enter the backend service. It intercepts all requests by configuring the interception rules of the HTTP server or using the interceptor function of the framework. Extract URL information from HTTP requests and perform necessary preprocessing, such as URL decoding and removing query parameters; According to the system's authentication mechanism, the current user's identity information is extracted from the request, including parsing the user ID and user name information from the HTTP header, Cookie, Session or Token.

3. The method for controlling URL permissions based on blacklists and whitelists according to claim 2, wherein: Also includes log audit steps: The log audit module records relevant information at key points in the request processing process. The log information includes request time, user ID, request URL, request method, authentication result, blacklist and whitelist comparison results, and access control decisions. Use the log framework to output log information to the specified storage medium, using a unified log format, including timestamp, log level, and log content fields; Provides audit interfaces in the form of RESTful API or web interface, allowing administrators to query log records based on time range, user ID, and request URL conditions, supports paging and sorting functions, and desensitizes sensitive information.

4. A control system for the URL permission control method based on blacklists and whitelists according to claim 3, characterized in that: Includes a blacklist and whitelist management module for creating, deleting, modifying, and querying blacklists and whitelists; In the blacklist and whitelist management module, the blacklist and whitelist information is stored in a relational database data table. The data table fields include id, user_id, type, method, url_template, and priority. id is the primary key, user_id is the user ID, type is an enumeration type, the value black indicates a blacklist, the value white indicates a whitelist, method is the request method, including POST / GET / DELETE / PUT / PATCH / ALL, and ALL can match all types of request methods. url_template is a URL template that supports wildcards. ? matches a single character, * matches a string of any length except the path identifier " / ", and ** matches a string of any length. Priority is a numeric type. A smaller value indicates a higher priority, and a larger value indicates a lower priority. Provides interfaces for creating, deleting, modifying, and querying blacklists and whitelists for specified users. The request method for creating a blacklist and whitelist is POST, the request URI is / admin / url-permissions, and the request body contains the type, userId, method, url_template, and priority fields. The request method for deleting a blacklist and whitelist is DELETE, the request URI is / admin / url-permissions / {id}. The request method for modifying a blacklist and whitelist is PUT, the request URI is / admin / url-permissions / {id}, and the request body contains the type, method, url_template, and priority fields. The request method for querying a blacklist and whitelist for a specified user is GET, the request URI is / admin / url-permissions?userId={userId}. It also includes priority comparison and decision-making modules; The priority comparison and decision module receives the URL information and current user information forwarded by the request interception module; Query all blacklists and whitelists of the current user from the database and sort them in ascending order from high to low priority; Traverse the sorted blacklist and whitelist entries. If a whitelist entry is encountered first and its priority is higher than all possible conflicting blacklist entries, access is allowed. If a blacklist entry is encountered and its priority is higher than all possible whitelist entries that may cover it, access is denied. If multiple entries with the same priority are encountered at the same time, a decision is made based on the preset rules. Based on the decision result, access to the current URL request is allowed or denied.

5. A URL permission control system based on blacklist and whitelist according to claim 4, characterized in that: It also includes a request interception module, which is located before all requests enter the backend service; The request interception module intercepts all requests by configuring the interception rules of the HTTP server or using the interceptor function of the framework; Extract URL information from HTTP requests and perform necessary preprocessing, such as URL decoding and removing query parameters; According to the system's authentication mechanism, the current user's identity information is extracted from the request, including parsing the user ID and user name information from the HTTP header, Cookie, Session or Token, and forwarding the extracted URL information and user information to the priority comparison and decision module.

6. A URL permission control system based on blacklist and whitelist according to claim 5, characterized in that: Also includes a log audit module; The log audit module records relevant information at key nodes of the request processing process, including request time, user ID, request URL, request method, authentication result, blacklist and whitelist comparison result, and access control decision; Use the log framework to output log information to the specified storage medium, using a unified log format, including timestamp, log level, and log content fields; Provides audit interfaces in the form of RESTful API or web interface, allowing administrators to query log records based on time range, user ID, and request URL conditions, supports paging and sorting functions, and desensitizes sensitive information.

Images