Technology0How Do Load Balancers and Real IP Relationship Risk Your Security?

One of the benefits of being a security specialist is working with numerous teams. After an audit, security specialists will have the opportunity to work with database administrators and analysts. For an application to work properly and securely, these teams try to deal with security vulnerabilities that have a common basis. Dialogues between these teams raise some issues with real IP.

Proxy and Real IP Concepts

Today’s web applications run on multiple app servers and database systems. Imagine two application servers sharing the same source code. Requests from the user are ready to be met by either of these servers depending on the load situation. The load balancing mechanism, which handles HTTP requests in front of the application servers, decides which request to forward to which application server. This poses a big question for middleware system administrators and software developers: what is the user’s real IP address?

Proxies are in charge of transmitting data between two systems. The load balancer is the mechanism in charge of the proxy. In other words, just one system communicates with both the user and the application server. In terms of network traffic, web A or web B servers always communicate with the load balancer’s IP address. The same may be said for users. For security professionals, load balancers cause serious problems in time-based SQL injection attacks. But the main focus here is IP spoofing.

X-Forwarded-For and IP Relationship

Consider the relationship between X-Forwarded-For, developer, and middleware. For example, let’s say that the task of the developer of an application is to record all activities, such as incorrect password attempts by users, with their IP addresses. At first, the developer will determine the IP address of the user when the HTTP request is met with the opportunity provided by the programming language he uses and will try to continue using this data in the application.

Since its IP address will be fixed throughout the development process, it will always see the same address during tests because generally, user computers in corporate networks work with static IP over MAC address. The unit will perform some acceptance tests; however, there will be problems with these. The test unit will forward this problem to the software developer.

At this stage, the developer may write a controller in the development environment and see the HTTP request transmitted to the application in raw form, since everyone has the same IP address. This will result in working with X-Forwarded-For.

Header information called X-Forwarded-For will be sent to the application server. At this stage, the software developer will see their IP address, which they control with ipconfig, not the load balancer they see in the logs. Many programmers think that they can solve this problem with a code block like this:

 function getIPaddress() {
    $ipKeys = array(
'HTTP_CLIENT_IP', 
'HTTP_X_FORWARDED_FOR', 
'HTTP_X_FORWARDED', 
'HTTP_X_CLUSTER_CLIENT_IP', 
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED', 
'REMOTE_ADDR'
);
    foreach ($ipKeys as $key) {
        if (array_key_exists($key, $_SERVER) === true) {
            foreach (explode("https://news.google.com/__i/rss/rd/articles/,", $_SERVER[$key]) as $ip) {
                $ip = trim($ip);
                if (validate_ip($ip)) {
                    return $ip;
                }
            }
        }
    }
    return isset($_SERVER['REMOTE_ADDR']) ? $_SERVER['REMOTE_ADDR'] : false;
}
 

This will not be enough—the developer needs to check whether the incoming value is a valid IP address.

Everything above belonged to the part handled by the developer. But for an application to work properly and securely, teams—working together in theory, but in reality, at extreme points from each other—try to deal with security vulnerabilities that have a common basis. Now try to look at the issue from the perspective of the person responsible for the configuration of the load balancer.

System administrators might think that developers record information such as X-Forwarded-For because data in the HTTP request cannot be trusted. Those administrators often transmit X-Forwarded-For; however, they also transmit the TCP source address of the system that sent the request as a second header value. The True-Client-IP structure is a good example of this.

When you put all these things together, two different units follow different paths for the same problem, known as client IP spoofing. The result is a critical issue where no IP logging and IP-based authorization will work.

How Is Client IP Spoofing Detected in Penetration Tests?

Most penetration testers use Firefox for their security checks. They configure Firefox with a simple add-on, X-Forwarded-For: 127.0.0.1 for all HTTP requests. And so, the possibility of detecting such vulnerabilities in all penetration tests increases. Performing an audit according to the OWASP Checklist ensures you check for such vulnerabilities. However, to detect the X-Forwarded-For vulnerability, you need a module in the application that shows your IP address or the actions taken.

How to Solve the X-Forwarded-For Vulnerability

Organizations need a mandatory secure application development document for all software teams and outsourcing companies. For example, if you need a user IP address, the company should plan ahead and make it a rule about the header information it will use here. Otherwise, different teams will produce different solutions. If such a situation cannot be dealt with, outsourcing applications will come into play, making it difficult to measure source codes. In general, companies do not want to follow such a path.

But to solve this problem, you can use the following F5 rule:

 when HTTP_REQUEST {
  HTTP::header remove X-Forwarded-For 
  HTTP::header insert X-Forwarded-For [IP::remote_addr]
}
 

This removes the X-Forwarded-For field in the HTTP request from the outside world. Then it transmits the request by adding the IP address of the system that sent the request to it. That way, a reliable list is created for software that acts according to X-Forwarded-For.

To summarize, the biggest goal here is to perform some checks on HTTP requests and to create a reliable environment. The code block above is a good example you can use for this.

Cybersecurity Frameworks and Documentation for Enterprises

The units that seem to be independent of each other are actually parts of a whole. That’s why everything has to work systematically. The rules determined beforehand must be applied between each unit. If such a working system is not adopted, many problems such as the X-Forwarded-For vulnerability may occur. For this, everything should be considered beforehand and documentation as comprehensive as possible should be used.

And every unit in this large system needs to adopt and implement cybersecurity frameworks. Your starting point should be to research and learn the working logic of these frameworks.