WAAP-based security method and system for client API security.

Abstract

We provide an integrated web security solution platform for client API security, offering security methods and systems. [Solution] A security method for client API security performed by a security device including a service provider and a hash verification tool, comprising: step S312 in which the service provider registers the API with the hash verification tool; step S314 in which the hash verification tool stores the API, the ID of the API and its hash; and step S316 in which the hash verification tool transmits the ID and hash to the service provider.

Description

Technical Field

[0001] The present invention relates to an integrated web security solution infrastructure security method and system such as WAAP (web application and API protection) for client API security.

Background Art

[0002] Recently, social activities and economic activities through the Internet and other online channels have become active. Therefore, the importance of security for APIs (application programming interfaces), which are widely used for communication between online terminals, has been increasing.

[0003] An API is a set of definitions and protocols for building and integrating application software. By using an API, terminals such as clients and servers can be assisted to communicate with each other's products and services without the need to build a connection infrastructure. For example, in API communication, a client transmits a key value for connecting to data to a server, and if the key values match, the server can transmit the data to the client.

[0004] On the other hand, as the use of APIs expands, hacking and security incidents against personal information such as my data like credit information data and login information, and open data such as weather, bus information, and medical information are also increasing. For example, security incidents due to API attacks such as damaging user authentication or keys to obtain information, intentionally allocating a large amount of system resources, or stealing response data in the middle are increasing.

[0005] To prevent such security incidents, individuals and businesses must implement security solutions for their networks connected to the internet and other networks. However, implementing such single-function solutions can be burdensome. Therefore, considering cost issues and other factors, there is a growing demand for integrated web security solutions that can comprehensively protect the web environment.

[0006] In particular, recent integrated web security solutions have evolved to include not only existing web firewall functions but also API protection, bot mitigation, and DDoS (Digital Dosith) protection. In this context, there is a growing demand for integrated web security solutions that meet OWASP's Top 10 API security requirements. [Overview of the project] [Problems that the invention aims to solve]

[0007] This invention was derived to address the requirements of the prior art described above, and its objective is to provide a security method and apparatus for client API security. Another object of the present invention is to provide an integrated web security solution infrastructure security method for client API security.

[0008] Another object of the present invention is to provide a WAAP (web application and API protection) based security device, which is a type of integrated web security solution for client API security. [Means for solving the problem]

[0009] A security method relating to one aspect of the present invention for solving the aforementioned technical problems is a security method for client API (application programming interface) security executed by a security device including a service provider and a hash verification tool, comprising the steps of: the service provider registering the API with the hash verification tool; the hash verification tool storing the API, the API's identifier (ID), and its hash; and the hash verification tool transmitting the ID and the hash to the service provider.

[0010] The security method further includes the step of the service provider performing a security handshake with the user terminal for session creation.

[0011] The security method further includes the steps of: the service provider receiving an API request from the user terminal; and the service provider transmitting the API to the user terminal in response to the API request.

[0012] The security method further includes the step of the hash verification tool receiving a verification request for the API from the user terminal.

[0013] The security method further includes the step of the hash verification tool comparing the hash value of the API requested for verification in response to the verification request with a hash value of the API that has been stored in advance.

[0014] The security method further includes the step of the hash verification tool communicating to the user terminal the result of comparing the hash value of the API for which verification is requested with a pre-stored hash value of the API.

[0015] The security method further includes, when the security handshake is completed, the hash verification tool regenerating the session with the user terminal through the security handshake.

[0016] A security method relating to another aspect of the present invention for solving the aforementioned technical problems is a security method for client API (application programming interface) security performed by a service provider of a security device including a service provider and a hash verification tool, comprising the steps of: registering the API with the hash verification tool - the hash verification tool stores the API, the API identifier (ID), and the hash; receiving the ID and hash from the hash verification tool; performing a security handshake with a user terminal; receiving an API request from the user terminal; and transmitting the API to the user terminal by the API request.

[0017] In the security method described above, the API may be transmitted to the hash verification tool when the user terminal requests API verification, and may be used by the hash verification tool to verify whether the API is secure or not based on the hash value of the API that has been stored in advance.

[0018] A security method relating to yet another aspect of the present invention for solving the aforementioned technical problems is a security method for client API (application programming interface) security performed by a hash verification tool in a security device including a service provider and a hash verification tool, comprising the steps of: receiving API registration from the service provider; storing the API, the API identifier (ID), and the hash upon API registration; transmitting the ID and the hash to the service provider; receiving an API verification request from the user terminal after a security handshake has been performed between the hash verification tool and the user terminal - the API being requested for verification is one that the user terminal has received from the service provider -; verifying the API; and transmitting the API verification result to the user terminal.

[0019] The stage of verifying the API includes the stage of comparing the hash value of the API for which verification is requested with the hash value of the API pre - stored in the hash verification tool.

[0020] The security method may further include the stage of performing a security handshake for session regeneration between the user terminal and the service provider when the security handshake between the service provider and the user terminal ends.

[0021] The security device according to another aspect of the present invention for solving the technical problem is a security device for client API (application programming interface) security, including a hash verification tool; and a service provider for registering an API with the hash verification tool. The hash verification tool stores the API, an identifier (ID) of the API, and a hash, and transmits the ID and the hash to the service provider.

[0022] The service provider can perform a security handshake for session generation with the user terminal.

[0023] The service provider can receive an API request from the user terminal and transmit the API to the user terminal according to the API request.

[0024] The hash verification tool can receive a verification request for an API from the user terminal.

[0025] The hash verification tool can compare the hash value of the API for which verification is requested by the verification request with the pre - stored hash value of the API.

[0026] The hash verification tool can transmit the comparison result of the hash value of the API for which verification is requested and the pre - stored hash value of the API to the user terminal.

[0027] When the hash verification tool finishes the security handshake, it can regenerate a session with the user terminal through the security handshake.

Advantages of the Invention

[0028] According to the present invention, an integrated web security solution having a function of protecting a general web environment can be provided. That is, in addition to web security, WAAP (web application and API protection) with additional functions of API (application programming interface) protection, bot mitigation, and DDoS (Distributed Denial of Service) defense can be provided.

[0029] Also, according to the present invention, not only API security but also general infrastructure and web security services can be provided and managed through WAAP.

[0030] Also, according to the present invention, the user reliability for service API providing companies can be improved, and attacks by malicious clients such as hackers can be blocked in advance. That is, the user reliability can be effectively improved through the external announcement of the service API hash value and the verification of the service API at the service usage stage.

[0031] Also, according to the present invention, a user can be made to actively configure a service security environment. That is, by making a user execute a WAAP target service API security verification query, an autonomous and active user service security environment can be configured.

[0032] Furthermore, according to the present invention, a bidirectional security environment can be configured for both internal and external use within a company. That is, a bidirectional security environment can be provided that targets a DMZ Zone server within a service company that has received client internal network security services, and which is responsible not only for security services but also for the security of the service usage environment of external users. [Brief explanation of the drawing]

[0033] [Figure 1] This is a conceptual diagram illustrating the corporate internal network protection architecture of a comparative example. [Figure 2] This is a schematic diagram illustrating a WAAP-based security architecture for client API security according to one embodiment of the present invention. [Figure 3] Figure 2 is a flowchart illustrating the APIs and hash value verification process that can be adopted in the WAAP infrastructure security architecture. [Figure 4] This is a schematic block diagram illustrating the configuration of security devices that can be adopted in the WAAP-based security architecture shown in Figure 2. [Figure 5] Figure 2 is a schematic block diagram illustrating the configuration of other security devices that can be adopted in the WAAP-based security architecture. [Figure 6] This is a schematic block diagram illustrating other WAAP-based security devices that can be used in the WAAP-based security architecture shown in Figure 2. [Figure 7] Figure 6 is a schematic block diagram illustrating the detailed configuration of the WAAP infrastructure security device. [Modes for carrying out the invention]

[0034] While the present invention can be modified in various ways and has a variety of embodiments, specific embodiments will be illustrated in detail in the drawings. However, this should not be understood as limiting the present invention to specific embodiments, but rather as including all modifications, equivalents, or substitutes that fall within the spirit and technical scope of the present invention.

[0035] The terms "first," "second," etc., may be used to describe a variety of components, but the components should not be limited by such terms. The terms are used solely for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be named the second component, and similarly, the second component may be named the first component. The term "and / or" includes a combination of multiple related listed items or any of the multiple related listed items.

[0036] In the embodiments of this application, "at least one of A and B" may mean "at least one of A or B" or "at least one of one or more combinations of A and B". Also, in the embodiments of this application, "one or more of A and B" may mean "one or more of A or B" or "one or more of one or more combinations of A and B".

[0037] When it is stated that one component is "connected" or "linked" to another component, it should be understood that it may be directly connected to or linked to the other component, but that other components may exist in between. Conversely, when it is stated that one component is "directly connected" or "directly linked" to another component, it should be understood that there are no other components in between.

[0038] The terms used in this application are used solely to describe specific embodiments and are not intended to limit the invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this application, terms such as “includes” or “having” are intended to specify the existence of features, figures, stages, operations, components, parts, or combinations thereof described in the specification, and should be understood not to preemptively exclude the possibility of the existence or addition of one or more other features, figures, stages, operations, components, parts, or combinations thereof.

[0039] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as those generally understood by a person of ordinary skill in the art to which this invention pertains. Terms as defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art, and not as ideal or overly formal unless expressly defined herein.

[0040] The following describes preferred embodiments of the present invention in more detail with reference to the attached drawings. In describing the present invention, the same reference numerals are used for identical components in the drawings to facilitate overall understanding, and redundant descriptions of identical components are omitted. Figure 1 is a conceptual diagram illustrating the corporate internal network security architecture of a comparative example.

[0041] Referring to Figure 1, the comparative example's enterprise internal network security architecture (hereinafter abbreviated as "security architecture") performs pre-configured operations for enterprise internal network security, comprising a gateway 300a, an API (application programming interface) server 520a, and an API DB 540a. The gateway 300a may include a web firewall.

[0042] The Gateway 300a security architecture is configured to perform API protection in applications that include APIs. However, numerous vulnerabilities to attackers' API attacks have been discovered.

[0043] A detailed examination of the main vulnerabilities in API attacks reveals the following:

[0044] First, client 10 can transmit an API key that does not conform to the format to server 100. In this case, if server 100 does not go through a proper verification process, various problems may occur. Specifically, vulnerabilities such as ignoring the API format and null character insertion attacks may occur. Here, "ignoring the API format" means a situation where, if the API key is specified to conform to a specific format such as a certain length and combination of characters, server 100 does not properly verify this, and arbitrary data is registered as the API key. Also, "null character insertion attack" means a situation where, because server 100 does not properly handle null characters in the API verification process, an attacker transmits a key containing a null character to bypass the key verification logic.

[0045] Furthermore, client 10 may possess a hardcoded API key. Hardcoded encryption keys have a security weakness: the encryption key is directly stored within the source code and may be exposed along with the source code if the source code is leaked, and key changes that need to be adapted to the environment are not easy to perform. In other words, using an encryption key hardcoded within the source code makes it vulnerable to indiscriminate assignment (brute-force) attacks, and some hash functions hardcoded in the form of constants can be reverse-calculated, potentially leading to the leakage of encrypted information.

[0046] Furthermore, there is a vulnerability that could include a flaw in the API format on server 100. The API format can include the API message format, and the API message format can use UTF-8 encoding with the JSON (JavaScript Object Notation) method. JSON can mean an open standard message format that represents data objects in attribute and value format, i.e., key-value format, for sending and receiving messages of small size. And UTF-8 means a standard encoding method that extends the ASCII code to represent all character codes worldwide.

[0047] On the other hand, if server 100 is unable to properly process the UTF-8 encoding during the API communication process, a security vulnerability may arise caused by garbled characters. A "garbled character vulnerability" refers to a vulnerability that occurs when client 10 transmits data through an incorrect UTF-8 encoding, and server 100 is unable to process the data correctly, resulting in data corruption. In such cases, the garbled characters can disrupt the system and potentially lead to a buffer overflow attack.

[0048] Additionally, during the API call process in which client 10 transmits an API key value to server 100 to receive data from server 100, traffic hijacking may occur through a man-in-the-middle attack (MITM), address resolution protocol (ARP) spoofing, or DNS (domain name system) spoofing from a spoofed server or client. In other words, traffic can be hijacked during the API call process in which the client transmits an API key value to the server to receive data from the server.

[0049] To prevent traffic hijacking during the API call process mentioned above, encryption keys can be stored encrypted in an external space or file. Furthermore, encryption keys can be managed using encryption codes generated based on a seed and initialization vector extracted from a random function, for example. As the aforementioned random function, a secure random function can be used through the .NET RNGCryptoServiceProvider class.

[0050] However, since the aforementioned API protection measures are implemented over API communication in a web environment, security vulnerabilities that occur in the web environment can occur in the same way as API vulnerabilities.

[0051] For example, the items in the OWASP Web Security Top 10 are listed in Table 1 below.

[0052] [Table 1]

[0053] Furthermore, the OWASP API Security Top 10 items and their explanations are shown in Table 2 below.

[0054] [Table 2] JPEG2026049639000004.jpg24162

[0055] To give an example of how security vulnerabilities occurring in a web environment can occur in the same way as API vulnerabilities, items A03, A05, and A09 in the OWASP Web Security Top 10 shown in Table 1 are the same as items A07, A08, and A10 in the OWASP API Security Top 10 shown in Table 2, and items A01, A07, and A08 in the OWASP Web Security Top 10 are similar to items A02, A05, and A09 in the OWASP API Security Top 10.

[0056] Figure 2 is a schematic conceptual diagram illustrating a WAAP (web application and API protection)-based security device for client API (application programming interface) security according to one embodiment of the present invention.

[0057] Referring to Figure 2, the WAAP infrastructure security device (hereinafter simply referred to as the "security device") includes the WAAP300, API server 520, and API DB540.

[0058] WAAP300 is a type of integrated web security solution configured to perform web application security and API security. WAAP300 can include a service provider and hash verification tools. Furthermore, WAAP300 can be configured to include web firewall (WAF), API security, bot mitigation, and DDoS protection functions. Such a detailed explanation of WAAP300 is provided in the detailed description below, referring to Figure 3, etc., so a detailed explanation is omitted here to avoid redundancy.

[0059] API server 520 may refer to a server in API communication that responds to API requests. Such API server 520 may refer to a service API server on a client private network or internal network.

[0060] API DB540 can refer to an off-chain database (DB) that stores and manages APIs. Such an API DB540 may refer to an internal API management database within a client's internal network.

[0061] The aforementioned security device can migrate API information from API server 520 to API DB 540 for client internal network security and for calculating security ratings for APIs (S21).

[0062] Furthermore, the security device can migrate API information from API server 520 to WAAP300 (S23).

[0063] Furthermore, the security device WAAP300 can tag at least one API received from the API server 520 with an API ID and then store the API hash value (S25).

[0064] Furthermore, the security device can perform security verification of an API received from the service server (i.e., API server) of a service-providing client (i.e., the service provider) when a service user outside the client requests the WAAP300 of the service-providing client to perform security verification of the API (S27).

[0065] Thus, the security device according to this embodiment can perform client internal network security through API registration and hash value verification processes for client API security. Furthermore, the security device can calculate a security level for the API based on the verification results of the API registration and hash value verification processes, and by periodically applying this level, it can maintain client internal network security in an even more reliable manner.

[0066] Furthermore, in addition to the API registration and hash value verification processes mentioned above, the security device can apply a variety of additional security processes. These additional security processes may include, for example, when a data request is received from an external client (where the client is a bot), the integrated web security system transmitting a confirmation message for the request, allowing the client to block the request after confirming that an abnormal response to the confirmation message has been received or that the response has been received from an abnormal IP address.

[0067] Additionally, an extra security process may include the integrated web security system detecting and blocking denial-of-service (DoS) attacks or distributed denial-of-service (DDoS) attacks at the application layer, such as a large number of unfulfilled messages, when the number of unfulfilled messages exceeds a certain limit within a given time.

[0068] The aforementioned integrated web security system can be configured to automatically recognize problems that occur during system operation using its self-checking function and transmit real-time alarms to administrators. To this end, the integrated web security system can be configured to self-diagnose resource status, network status, and hardware status, recognize dangerous situations such as security threats, transmit alarms to administrators, and execute automatic recovery functions based on self-diagnostic items and the resulting settings. Figure 3 is a flowchart illustrating the APIs and hash value verification process that can be adopted in the WAAP-based security architecture shown in Figure 2.

[0069] In this embodiment, WAAP may be configured as an integrated web security solution including a service provider (500) and a hash verification tool (400). A user may include at least one of the following: an individual user, an institutional user, an institutional user's terminal, and an IoT device. Here, "user" may mean a user terminal, an individual user may mean an individual user terminal, and an institutional user may mean an institutional user terminal.

[0070] In this embodiment, API can be an abbreviation for Application Programming Interface, referring to a mechanism that enables two software components to communicate with each other using a set of definitions and protocols. In the context of API, the word "application" refers to all software with its own specific functionality. An interface can be described as a service contract between two applications. Such a contract defines how the two applications communicate with each other using requests and responses.

[0071] Furthermore, API architecture can be basically explained in terms of client and server aspects. That is, the application that sends a request can be called the client, and the application that sends a response can be called the server. For example, an API database such as the Japan Meteorological Agency's weather database is a server, and a user such as a mobile app that requests and receives weather information from the weather database can be a client.

[0072] Depending on when and why they were created, APIs can operate in four ways: SOAP APIs, RPC APIs, Websocket APIs, and REST (Representational State Transfer) APIs.

[0073] More specifically, the SOAP API uses a simple object-approach protocol, where the client and server exchange messages using XML.

[0074] In RPC APIs, an API is called a remote procedure call, where the server transmits its output back to the client once the client has completed a function or procedure.

[0075] The WebSocket API is a web API that uses JSON (JavaScript Object Notation) objects to transmit data, supporting bidirectional communication between clients and servers, and allowing the server to send callback messages to connected clients.

[0076] A REST API allows a client to request data from a server, the server to transmit the data to the client, and the server to use the client's input to initiate an internal function and return the output data back to the client. REST web services are also called RESTful web services.

[0077] Referring to Figure 3, first, the service provider 500 can register its API with the hash verification tool 400 (S312).

[0078] For API registration, the hash verification tool 400 can store the relevant API, the identifier (ID) of the relevant API, and the hash of the relevant API based on the API registration operation of the service provider 500 (S314).

[0079] Here, a hash is a value obtained by mapping data of arbitrary length to data of fixed length, and can also be referred to as a hash value. Furthermore, hashes can be stored in a data structure that provides fast data retrieval by storing keys and values ​​as indices using values ​​transformed with a hash function.

[0080] Next, the hash verification tool 400 can transmit the ID and hash of the API registered with the hash verification tool 400 to the service provider 500 (S316).

[0081] Next, the service provider 500 can perform a TLS (transport layer security) handshake with the user 350 (S320). That is, a session for the service can be established between the service provider system, including the service provider 500, and the user 350.

[0082] Here, the TLS handshake can be a type of security handshake for session creation. A session can refer to a state in which the service provider 500 views a series of requests coming from the user 350 as a single state and maintains that state in a constant state. A session can also mean a send-and-receive connection state between the service provider 500 and the user 350 that presupposes interactive information exchange.

[0083] Next, user 350 can request an API from service provider 500 through the session (S330). Here, the API includes service APIs that allow user 350 to use the services of service provider 500. That is, service provider 500 can receive API request signals and API request messages for service APIs from user 350 through the session.

[0084] Next, the service provider 500 can transmit the API to the user 350 in response to the user's API request (S340). That is, the user 350 can receive a response message from the service provider 500 that includes the service API.

[0085] On the other hand, if the session between user 350 and the hash verification tool 400 ends, user 350 can regenerate the session through a TLS handshake with the hash verification tool 400 (S350).

[0086] Next, user 350 can request API verification from hash verification tool 400 for the API received from service provider 500 (S360). That is, hash verification tool 400 can receive a request message from user 350 requesting API verification for the service API that user 350 received from service provider 500.

[0087] Next, the hash verification tool 400 can verify whether the hash value of the service API that user 350 has requested to be verified matches the hash value of the service API of service provider 500 that has been previously stored in the hash verification tool 400 (S370).

[0088] Next, the hash verification tool 400 can communicate the verification result of the API verification request from user 350 to user 350 (S380). If the verification result (result) shows that the API hash value requested by user 350 is the same as the API hash value of the service provider stored in the hash verification tool 400, then the API is a verified and secure API. On the other hand, if the API hash value requested by user 350 is not the same as the hash value of the service provider's service API stored in the hash verification tool 400, then the API is an unverified and tampered API.

[0089] Figure 4 is a schematic block diagram illustrating the configuration of hash verification tools that can be adopted in the WAAP-based security architecture shown in Figure 2.

[0090] Referring to Figure 4, the hash verification tool 400 may comprise a transmit / receive signal processing unit 410, an API registration processing unit 420, a first storage unit 430, a handshake processing unit 440, an API verification unit 450, and a second storage unit 460.

[0091] The transmit / receive signal processing unit 410 processes the transmission and reception of signals, messages, and data with the service provider. The transmit / receive signal processing unit 410 also processes the transmission and reception of signals, messages, and data with the user. Such a transmit / receive signal processing unit 410 can receive signals and messages from the service provider regarding API registration. Furthermore, the transmit / receive signal processing unit 410 can exchange signals with the user for TLS handshake. It can also receive API verification request messages from the user. Finally, the transmit / receive signal processing unit 410 can transmit a response message containing the result of the API verification request to the user.

[0092] The API registration processing unit 420 generates the API ID and hash of the relevant API based on the service provider's API registration operation, and can store the API ID and hash of the relevant API in the first storage unit 430. The first storage unit 430 can store the API, the API ID, and the API hash (hash[API]).

[0093] The handshake processing unit 440 can process the transmit and receive signals for the TLS handshake with the user in order to regenerate the session when the session with the user has ended. The terminated session may be included in a session that the user has created with the service provider, and the regenerated session may be executed based on the information used in the session that was created with the service provider.

[0094] The API verification unit 450 can be configured to verify the requested API when a user requests API verification. The API verification unit 450 can compare the hash value of the requested API with a pre-stored API hash value to determine whether the API is a verified and secure API or an unverified and altered API.

[0095] The second storage unit 460 can store the verification results of the API verification unit 450. The second storage unit 460 may be formed integrally with the first storage unit 430, but is not limited to this, and may be a separate storage unit. Figure 5 is a schematic block diagram illustrating the configuration of a service provider that can be adopted in the WAAP infrastructure security architecture shown in Figure 2.

[0096] Referring to Figure 5, the service provider 500 may comprise a transmit / receive signal processing unit 510, an API registration unit 530, a first storage unit 550, a handshake processing unit 570, and an API provisioning unit 590.

[0097] The transmit / receive signal processing unit 510 handles the transmission and reception of signals, messages, and data with the hash verification tool. The transmit / receive signal processing unit 510 also handles the transmission and reception of signals, messages, and data with the user. Such a transmit / receive signal processing unit 510 can transmit signals and messages related to API registration to the hash verification tool. Furthermore, the transmit / receive signal processing unit 510 can exchange signals with the user for the TLS handshake. Additionally, the transmit / receive signal processing unit 510 can receive API request messages from the user and transmit response messages containing the API to the user.

[0098] The API registration unit 530 can transmit signals and messages to the hash verification tool to register its API with the hash verification tool.

[0099] After the API is registered and stored by the hash verification tool through the API registration operation by the API registration unit 530, when the API ID and hash are received by the service provider 500 from the hash verification tool, the first storage unit 550 can store the API, ID, and hash transmitted within the service provider 500 via the transmit / receive signal processing unit 510 and the API registration unit 530.

[0100] The handshake processing unit 570 can process handshake signals and messages when a service provider registered with the hash verification tool via API performs a handshake for session creation in response to a connection request from a user for service use. The handshake may include, but is not limited to, a TLS handshake, and other security measures may be applied.

[0101] After a session for the service is established between the user and the service provider, when the user makes an API request, the API providing unit 590 can provide the API to the user according to the instructions of the service provider 500's processor.

[0102] According to the security method of this embodiment described above, WAAP can provide web firewall functionality for corporate internal network security. The web firewall functionality may include DMZ Zone service server security, bot detection, DDoS blocking, and more.

[0103] Furthermore, according to the security method of this embodiment, it is possible to provide a WAAP service API security rating calculation function that performs security rating calculation for service API-specific vulnerabilities for enterprise service API security. And, after generating service API-specific IDs and hash values ​​for enterprise service API security, it is possible to provide a WAAP service API management function that matches the IDs and hash values ​​or matches the hash values.

[0104] Furthermore, according to the security method of this embodiment, a WAAP service API security verification function can be provided that performs verification in response to user security verification requests for service APIs for enterprise service API security. The prerequisites for the service API security verification function may include the fact that the service API is served by a standardized API to which consistent rules, patterns, and protocol standards are applied.

[0105] Furthermore, according to the security method of this embodiment, a user-active reverse WAAP function can be provided, which allows users to request security verification of the service API from the WAAP of the service provider (corresponding to the service provider) for the security of external users of the enterprise.

[0106] Furthermore, according to the security method of this embodiment, for the security of external users of the company, it is possible to provide a function to proactively block damage from API vulnerabilities by publicly announcing the hash value of the service API to external parties in order to prevent forgery and alteration of the service API.

[0107] Furthermore, according to the security method of this embodiment, for the security of external users of the enterprise, it is possible to provide a function that provides a secure user service usage environment by providing a secure service API through, for example, a service API verification procedure.

[0108] Figure 6 is a schematic block diagram illustrating a WAAP-based security device that can be used in the WAAP-based security architecture of Figure 2. Figure 7 is a schematic block diagram illustrating a detailed configuration that can be used in the WAAP-based security device of Figure 6.

[0109] Referring to Figure 6, the WAAP-based security device, i.e., the security device 600, may include at least one processor (610), memory 620, and a transceiver (630) that is connected to a network and performs communication. The at least one processor 610 and memory 620 may be composed of at least one controller. The transceiver 630 may include a sub-communication system that supports a wired network or a wireless communication module (WCM) that supports a wireless network.

[0110] Furthermore, the security device 600 may further include an input interface device 640, an output interface device 650, a storage device 660, and the like. Each component included in the security device 600 can be connected by a bus (670) to perform communication.

[0111] However, each component included in the security device 600 may not be connected via a common bus, but rather via individual interfaces or individual buses centered around the processor 610. For example, the processor 610 may be connected to at least one of the following via a dedicated interface: memory 620, transceiver 630, input interface device 640, output interface device 650, and storage device 660.

[0112] The processor 610 can execute program commands stored in at least one of the memory 620 and the storage device 660. The processor 610 may mean a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which the method according to an embodiment of the present invention is executed.

[0113] The processor 610 may include, for example, one software module 700, as shown in Figure 7, and the at least one software module 700 may be configured to include a web firewall function unit 710, an API security function unit 720, a bot mitigation function unit 730, a DDoS (Deadly DoS) protection function unit 740, a self-check function unit 750, and an alarm processing unit 760.

[0114] The web firewall function unit 710 is at least part of the WAAP's web firewall functionality and can be configured to respond to web attacks or to respond to primary attacks aimed at gathering information for secondary attacks. The web firewall function unit 710 may have a web firewall engine based on multiple rules and custom rule functionality. The web firewall engine can detect and block HTTP / HTTPS-based web attacks through logic analysis of attacker and circumvention attacker signals and data, thereby maintaining client internal network security.

[0115] The API security function unit 720 is at least part of the WAAP's web firewall function or enterprise service API security function, and can calculate the security level of an API and, through API validation, determine whether an API is secure or a tampered API and guide the user accordingly.

[0116] The bot mitigation unit 730 is at least part of the WAAP's web firewall function or enterprise service API security function and may be configured to identify, detect, and block bot activity. The bot mitigation unit 730 can identify bot activity and block attack attempts by utilizing client (in this case, attacker) unique information through pre-configured Suspicious Access (SA) rules. Here, SA rules may be used to determine the characteristics of automated attack tools such as bots and block or restrict access to connections from clients that are not legitimate web browsers.

[0117] The DDoS (Deadly DoS) protection unit 740 is at least part of the WAAP's web firewall functionality and may be configured to detect and block DDoS attacks at the application layer. For example, the DDoS protection unit 740 can detect and block attacks that overload a session by repeatedly sending incomplete requests.

[0118] The self-checking function unit 750 may be configured to automatically recognize problems that may occur during the operation of the security device. The self-checking function unit 750 may be configured to perform real-time self-diagnosis of its own status, recognize dangerous situations, and perform automatic recovery function operations through a pre-configured process. The automatic recovery function may be performed based on pre-configured self-diagnosis items and their corresponding settings.

[0119] Furthermore, if there are usage settings for the alarm, the alarm processing unit 760 can communicate the alarm to the security device administrator or client based on the pre-set classification results of the degree of danger for self-diagnosis, danger situation recognition, etc., and / or the value settings for alarm generation.

[0120] At least one of the aforementioned software modules 700, or at least one of the web firewall function unit 710, API security function unit 720, bot mitigation function unit 730, DDoS (Deeds DoS) protection function unit 740, self-check function unit 750, and alarm processing unit 760, can be implemented as a program instruction.

[0121] Furthermore, a program instruction may include at least one instruction to implement a security method. For example, a program instruction may include an instruction to register an API with a hash verification tool, an instruction to store the API, its identifier, and its hash, an instruction to communicate the identifier and hash to the service provider, an instruction to perform a TLS handshake with the user, an instruction to provide the API to the user, an instruction to compare the hash value of the service API being verified with a pre-stored hash value of the service API when an API verification request is made, and an instruction to communicate the verification result to the user.

[0122] Referring again to Figure 6, the memory 620 and the storage device 660 may each consist of at least one of a volatile storage medium and a non-volatile storage medium. For example, the memory 620 may consist of at least one of a read-only memory (ROM) and a random access memory (RAM).

[0123] The aforementioned security device 600 can be embodied in desktop computers, laptop computers, personal mobile communication terminals, network computers, etc. Furthermore, the security device 600 can refer to nodes, servers, communication terminals, etc., located on wired networks, short-range wireless communication networks, mobile communication networks, satellite networks, or combinations thereof.

[0124] On the other hand, the operation of the security method according to the embodiments of the present invention described above can be embodied in a computer-readable program or code on a computer-readable recording medium. A computer-readable recording medium includes all types of recording devices on which information readable by a computer system is stored. Furthermore, computer-readable programs or code can be stored and executed in a distributed manner on computer systems connected to a network.

[0125] Furthermore, computer-readable recording media can include hardware devices specially configured to store and execute program instructions, such as ROM, RAM, and flash memory. Program instructions can include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.

[0126] Some aspects of the present invention have been described in the context of apparatus, but they can also be described in a corresponding way, where a block or apparatus corresponds to a method step or feature of a method step. Similarly, aspects described in the context of a method can also be described by a corresponding block or item or feature of a corresponding apparatus. Some or all of the method steps may be carried out by (or utilizing) a hardware device such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, at least one or more of the most important method steps may be carried out by such a device.

[0127] In embodiments, a programmable logic device (e.g., a field-programmable gate array) may be used to perform some or all of the functions of the methods described herein. For example, a field-programmable gate array may operate in conjunction with a microprocessor to perform one of the methods described herein. Generally, it is preferable that the methods be performed by some hardware device.

[0128] As described above with reference to examples, those skilled in the art will understand that the present invention can be modified and altered in various ways without departing from the spirit and scope of the invention as described in the following claims.

Claims

1. A security method for client API (application programming interface) security, which is performed by a security device including a service provider and a hash verification tool, The stage where the service provider registers the API with the hash verification tool; The hash verification tool stores the API, the API's identifier (ID), and its hash; A security method comprising the step of the hash verification tool transmitting the ID and the hash to the service provider.

2. The security method according to claim 1, further comprising the step of the service provider performing a security handshake to create a session with the user terminal.

3. The stage in which the service provider receives an API request from the user terminal; and The security method according to claim 2, further comprising the step of the service provider transmitting the API to the user terminal in response to the API request.

4. The security method according to claim 3, further comprising the step of the hash verification tool receiving a verification request to the API from the user terminal.

5. The security method according to claim 4, further comprising the step of the hash verification tool comparing the hash value of the API requested for verification in response to the verification request with a hash value of the API that has been previously stored.

6. The security method according to claim 5, further comprising the step of the hash verification tool transmitting to the user terminal the result of comparing the hash value of the API for which verification is requested with a pre-stored hash value of the API.

7. The security method according to claim 3, further comprising the step of the hash verification tool regenerating a session with the user terminal through the security handshake when the security handshake has been completed.

8. A security method for client API (application programming interface) security, which is performed by a service provider of a security device including a service provider and a hash verification tool, Steps to register the API with the hash verification tool: The hash verification tool stores the API, the API's identifier (ID), and its hash; The step of receiving the ID and the hash from the hash verification tool; The stage where the user terminal and security handshake are performed; The stage of receiving an API request from the user terminal; and A security method comprising the step of transmitting an API to the user terminal in response to the aforementioned API request.

9. The security method according to claim 8, wherein the API is transmitted to the hash verification tool when the user terminal requests API verification, and is used by the hash verification tool to verify whether it is a secure API or a tampered API based on the hash value of the API stored in advance.

10. A security method for client API (application programming interface) security, which is performed by a hash verification tool in a security device including a service provider and a hash verification tool, The stage where service providers register for the API; The step of saving the API, its identifier (ID), and its hash upon API registration; A step of transmitting the ID and the hash to the service provider; After the security handshake between the hash verification tool and the user terminal is performed, the user terminal proceeds to the stage where it receives an API verification request—the API requested for verification is one that the user terminal received from the service provider; The step of verifying the aforementioned API; and A security method that includes the step of transmitting the API verification result to the user terminal.

11. The security method according to claim 10, wherein the step of verifying the API includes comparing the hash value of the API for which verification is requested with the hash value of the API pre-stored in the hash verification tool.

12. The security method according to claim 10, further comprising the step of performing a security handshake with the user terminal for session regeneration when the security handshake between the service provider and the user terminal is completed.

13. A security device for client API (application programming interface) security, hash verification tools; and This includes a service provider that registers an API with the aforementioned hash verification tool, The hash verification tool is a security device that stores the API, the identifier (ID) of the API, and the hash, and transmits the ID and the hash to the service provider.

14. The security device according to claim 13, wherein the service provider performs a security handshake with the user terminal for session creation.

15. The security device according to claim 14, wherein the service provider receives an API request from the user terminal and transmits the API to the user terminal in response to the API request.

16. The security device according to claim 15, wherein the hash verification tool receives a verification request to the API from the user terminal.

17. The security device according to claim 16, wherein the hash verification tool compares the hash value of the API requested for verification with a hash value of an API that has been previously stored.

18. The security device according to claim 17, wherein the hash verification tool transmits to the user terminal the result of comparing the hash value of the API for which verification is requested with the hash value of the API stored in advance.

19. The security device according to claim 15, wherein the hash verification tool regenerates the session with the user terminal through the security handshake when the security handshake is completed.

Images