API Security for Data Privacy in the MyData Era

It will be two years next January (implemented on January 5, 2022) since the Financial MyData Service was fully implemented (prohibiting scraping methods and providing Financial MyData services via API methods). 

Although the Financial MyData Service has only been in service for two years, it has quickly established itself thanks to the efforts of the government and service providers. This year (January 10, 2023), plans for establishing detailed criteria for the billing system of the Financial MyData Service and payment plans were even announced. 

Furthermore, encouraged by the successful service implementation in the financial sector, the foundation was laid for implementing MyData services across all industries with the revised Personal Information Protection Act implemented on September 15, 2023 (new establishment of Article 35-2, Request for Transmission of Personal Information; enforcement date for this item undefined). 

In other words, while requests for the transmission of personal credit information were previously made based on the Credit Information Act (Article 33-2), it is now possible to request the transmission of personal information based on the Personal Information Protection Act. 

This does not merely mean that the legal basis has become clearer or that the information that can be requested has expanded. It means that the data that can be legally utilized with the consent of the data subject has increased, providing the driving force for the data market utilizing such data to grow. 

In fact, the government announced its goal to additionally grow the data market size by more than 20% by 2027 under the vision of a 'Digital Great Transformation Era Led by MyData'. Assuming the domestic data industry market, which was worth 25 trillion won in 2022, grows at an annual average of 11.9% as in the past three years, an additional 20% growth means a market exceeding 50 trillion won by 2027. 

To achieve these goals, the public and private sectors are joining forces and showing active moves (launch of the Public-Private Consultative Body for the Expansion of MyData Adoption across all sectors on November 14, 2023). 

However, uninvited guests always follow such huge markets, contrary to expectations. From a slightly different perspective, a massive market of 50 trillion won can sound like a market worth 50 trillion won to hackers with malicious intent. 

In particular, personal information is data traditionally favored by hackers enough to be actively traded on the dark web because it can be utilized for Credential Stuffing and various phishing attacks. 

In this situation, if services utilizing personal information increase due to the expansion of MyData services and the value of personal information rises, hackers are highly likely to become even more desperate to target personal information. 

Of course, MyData services have been strengthened in terms of technical security compared to existing personal information processing methods. Representatively, MyData services are provided through API methods (services via API are mandatory for Financial MyData services, and while not mandatory for public and medical services, providing services via API is recommended). 

Before API methods, web scraping was mainly used. However, since web scraping can collect all paged data, it has vulnerabilities such as the risk of information leakage and excessive collection of personal information. 

On the other hand, APIs provide information only through responses to requested information, resolving vulnerabilities problematic in web scraping. When used with mutual authentication communication called mTLS (mutual TLS) used in MyData services, it provides higher security compared to web scraping methods because it communicates only with targets whose reliability has been verified. 

However, APIs are only relatively safer than web scraping; they are not free of vulnerabilities. Representatively, searching for API in the CVE (Common Vulnerabilities and Exposures) list, a global list of publicly disclosed vulnerabilities, yields over 3,000 vulnerabilities.  

Also, OWASP (Open Web Application Security Project), a global non-profit organization that improves security by analyzing vulnerabilities in web applications, has been publishing the OWASP API Security Top 10 list since 2019. 

As such, even relatively safe APIs that support encrypted communication are exposed to many vulnerabilities. Therefore, institutions and companies supporting MyData services using APIs require significant attention and effort regarding security. 

Personal Information Leakage Using API Vulnerabilities

Now, let's get to the main point and find out what new challenges personal information protection faces with the implementation of MyData services using APIs. First, we must understand conceptually that the protection area of personal information protection has expanded and the protection methods have changed. 

  Protection Area

Since personal information before MyData services was stored as data, the protection area was also focused on databases and server storage storing data. In other words, at the network level, it was sufficient to control access to databases and server storage storing data well, and measures against forgery, alteration, and leakage of data could be taken within the system where the data was stored. 

However, APIs generally allow access to personal information via the HTTP protocol not only from the internal network but also from external networks. Therefore, the area to be protected has expanded to include API interfaces across all network areas. 

  Protection Method

As the area to protect has expanded, the method of protection also requires a different approach from before. In security to protect data in existing databases and server storage, access to the network was first controlled through UTM. Antivirus software was installed to prevent forgery and alteration of data through malware and backdoors, and personal information was protected by encrypting data and preventing leakage through DRM/DLP. 

However, in services using APIs, API interface security for API communication payloads must be additionally considered, such as whether the response payload contains identification information that can infer another person's identification information, whether it is a valid request, and whether excessive information is included causing sensitive information to leak. 

Then, let's verify through several scenarios how personal information can be forged, altered, or leaked based on the vulnerabilities mentioned in the actual OWASP API Security Top 10. 

1. First Scenario - Accessing another person's personal information by inferring their identification information because the URL contains identification information

This is a situation that can occur because RESTful APIs, used like a standard in APIs, basically identify resources through URL formats. 

① Normal login attempt.

② Confirm that user identification information is '<Figure 1>' in the response payload for the login request. Identifying Identification Information through User Login

③ Guess that other users' identification information is also an integer based on the fact that one's own user identification information is '1'.

④ Access another person's information using the guessed user identification information. <Figure 3> Accessing Another Person's Personal Information Using Inferred Identification Information

In such a scenario, depending on the server, it is possible not only to acquire another person's personal information using the guessed identification information but also to forge or alter the information. 

2. Second Scenario - Accessing personal information because the integrity of JWT (JSON Web Token), mainly used in the JSON format of APIs (used as standard API in Financial MyData services), is compromised

The second scenario shows a total of two situations occurring when the API server does not consider integrity checks for JWT:

- A scenario accepted as a normal request even though an expired JWT was used.
- A scenario accepted as a normal request even though access was attempted from a different IP using authentication information under the assumption that JWT was hijacked and authentication information was leaked. 

     Scenario: Lack of JWT Expiration Verification

① Acquire authentication information for an already expired JWT ("exp": "0" means the token has expired). <Figure 4> Acquiring Authentication Information for Expired JWT

② Request information by inserting the acquired authentication information into the header.

③ The API server processes it as a normal request because it does not check whether the JWT has expired. <Figure 5> Successful Request Using Expired JWT Authentication Information

  Scenario: Lack of JWT Hijacking Verification

① Intercept packets in the middle to acquire JWT authentication information.

② Attempt access from a person with a different IP using the authentication information.

③ Process as a normal request because hijacking status (IP check, etc.) is not verified. <Figure 6> Attempting Access from a Different IP Using Stolen JWT Authentication Information

Like the first scenario, this scenario is also a situation where an unauthorized person can acquire, forge, or alter another person's personal information. 

3. Third Scenario - A scenario where personal information is leaked because excessive information is included in the request API, exposing more data than needed.

In the case of a server containing more personal information than the original purpose of the service, personal information is leaked by providing excessive personal information. 

① Request personal information from an API service providing names and contact information.

② However, the personal information held by that service includes more personal information beyond names and contact information.

③ The API server fails to recognize this and provides all included personal information as a response to the request. <Figur 7> Server Providing Excessive Information

This scenario is a situation where personal information can be leaked because excessive personal information is transmitted beyond what the data subject requested and consented to. Conversely, the receiving system may receive personal information it should not receive, potentially leading to management problems by holding excessive personal information. 

4. Fourth Scenario - A scenario where a response is generated even for inappropriate requests because unnecessary functions or HTTP methods are activated due to incorrect security configuration.

This is a situation where personal information is leaked because the GET method is allowed in a service that should process only POST and PUT methods as normal requests. 

① Request personal information from a system that inputs or modifies personal information.

② Provide personal information by processing it as a normal request because requests for the GET method are allowed. <Figure 8> Server Responding by Processing GET Method as Normal Request

Technical Measures via WAAP

As examined in the previous scenarios, API vulnerabilities are mostly configuration errors in the system. They may occur simply because they were missed during the development process or due to operator inexperience, or there may be cases where such vulnerabilities must be inevitably left alone due to the structure or operational mechanism of the system. 

However, since we cannot just leave these vulnerabilities alone, we must take other technical measures. One of those methods is API security through WAAP. 

WAAP stands for Web Application and API Protection, a security solution that adds API security functions to the existing WAF (Web Application Firewall). (For more details on WAAP, refer to '[Security White Paper] API Security and WAAP'). Then, let's see how WAAP can address the vulnerability scenarios introduced earlier. 

1. Measure for First Scenario - Scenario of accessing another person's personal information by inferring their identification information because the URL contains identification information.

Measures can be taken by randomizing or hiding the identification information included in the URL through encryption. In other words, if WAAP, which can act as a proxy server in a general network structure, provides a function to randomize or hide desired fields among response fields, measures are possible. Identification Information in Response Payload Randomized and Impossible to Infer 

2. Measure for Second Scenario - Scenario of accessing personal information because JWT integrity is compromised.

Measures are possible by WAAP performing integrity checks on JWT (checking token expiration status via Timestamp, verifying legitimacy by matching token IP, etc.) as a proxy server. <Figure 10> Access Failed Due to JWT Token Expiration Check <Figure 11> Access Failed Due to JWT IP Validity Check 

3. Measure for Third Scenario - Scenario where personal information is leaked because excessive information is included in the request API, exposing more data than needed.

Measures can be taken by masking or deleting response fields that the server should not provide. This is also possible by WAAP acting as a proxy in front of the server and cloaking desired fields among response fields according to the service.

4. Measure for Fourth Scenario - Scenario where a response is generated even for inappropriate requests because unnecessary functions or HTTP methods are activated due to incorrect security configuration.

This scenario can also be addressed by WAAP allowing only methods suitable for the purpose of the service at the proxy location.

The above measures are all screens demonstrated using PIOLINK's WAAP, WEBFRONT-K, in vulnerability scenario environments. Like this, WAAP is representative equipment that can provide technical measures for API vulnerabilities, and WAAP is already expanding its market as an API security solution in the global market. 

MyData Services and API Security

So far, based on the OWASP API Security Top 10 vulnerabilities, we have looked at several possible scenarios of security incidents related to personal information and technical measures for them. The vulnerability scenarios covered in this white paper are truly a tiny fraction; there must be unknown API vulnerabilities as well as vulnerability scenarios of unimaginable methods. And there must be more hackers lurking to exploit them than imagined. 

That is why PIOLINK is researching and developing API security even more diligently and is creating empirical references with customers to provide safe and convenient MyData services. We hope that many institutions and companies contemplating providing safe MyData services will resolve their concerns through WAAP, and for concerns difficult to solve alone, contact PIOLINK to solve them with API security experts.