Session match_ip uses raw $_SERVER['REMOTE_ADDR'] instead of CI_Input::ip_address() — breaks behind proxy / Cloudflare

[rctann]

Summary
All session drivers bind the session to the client IP (when sess_match_ip = TRUE) using the raw $_SERVER['REMOTE_ADDR'], while the rest of the framework resolves the client IP through CI_Input::ip_address(), which honours the configured proxy_ips and (in setups that add it) HTTP_CF_CONNECTING_IP. This makes the session's IP handling inconsistent with $this->input->ip_address() and effectively breaks match_ip behind a reverse proxy / load balancer / Cloudflare.

Affected code
The raw $_SERVER['REMOTE_ADDR'] is used directly in:

system/libraries/Session/drivers/Session_database_driver.php — read(), write() (insert + update), destroy(), updateTimestamp(), validateId(), and the MySQL/PostgreSQL _get_lock() (also written into the ip_address column on every insert).
system/libraries/Session/drivers/Session_redis_driver.php — __construct() (key prefix).
system/libraries/Session/drivers/Session_memcached_driver.php — __construct() (key prefix).
system/libraries/Session/drivers/Session_files_driver.php — open() (file path component).
Impact
When the app sits behind a proxy and proxy_ips is configured:

match_ip becomes ineffective. REMOTE_ADDR is the proxy's IP, which is identical for all clients. So binding the session to it provides no real per-client binding — every user shares the same "IP".
Inconsistency. $this->input->ip_address() returns the real client IP everywhere else in the app, but the session layer stores/compares the proxy IP. The ci_sessions.ip_address column is misleading for auditing.
The database driver persists the wrong value in the ip_address column even when match_ip is off (it's always part of the insert).
Reproduction
Put the app behind a reverse proxy / Cloudflare and set proxy_ips in config.php accordingly.
Set sess_match_ip = TRUE and use the database (or files/redis/memcached) driver.
Observe that ci_sessions.ip_address holds the proxy IP, not the value returned by $this->input->ip_address().
Proposed change
Resolve the IP via CI_Input::ip_address() (with a fallback to $_SERVER['REMOTE_ADDR'] if the input class isn't available yet), instead of reading the superglobal directly. Example for the database driver constructor:

$CI =& get_instance();
isset($CI->db) OR $CI->load->database();
$this->_db = $CI->db;

// Honour proxy_ips / Cloudflare instead of the raw REMOTE_ADDR (the proxy's IP).
$this->_ip_address = isset($CI->input)
? $CI->input->ip_address()
: $_SERVER['REMOTE_ADDR'];
…then use $this->_ip_address in every place that currently reads $_SERVER['REMOTE_ADDR']. The same isset($CI->input) ? $CI->input->ip_address() : $_SERVER['REMOTE_ADDR'] pattern applies to the redis/memcached key prefix and the files driver path. This keeps PHP 5.2.4 compatibility (no new syntax).

Question for maintainers
Is the use of raw REMOTE_ADDR here intentional (i.e. preferring the unspoofable TCP peer address over the proxy-trusting ip_address() for a security feature), or is it an oversight? If it's intentional, would you accept making it opt-in / consistent with ip_address(), given that match_ip is essentially a no-op behind a shared proxy? Happy to send a PR against develop (with changelog entry) if there's `interest.```

[narfbg]

It is intentional. The lack of configuration is also intentional - that just leads to insecure configurations, as unfortunately very few people understand the implications and most will blindly trust user-controlled headers.

Bottom line is, anyone competent enough to know when and how it's safe to utilize a proxy-propagated client IP value, should also know how to overwrite REMOTE_ADDR even before it reaches the PHP process.