[B] Tag notification is not sending #2485
[B] PHP 8.4 deprecations for OSSN 8.8 #2484
[B] User can view blocked user album photo #2483
[B] RealTimeComments shows comments if user are blocked #2482
[E] Show user groups on seperate page avoid searching in init function for menus #2480
[B] SQL Injection discoverd by KGAN #2479

We prioritized the security and longevity of the Open-Source Social Network platform. With the OSSN 8.8 release, we implemented a fundamental change to how database queries were constructed. This change was mandatory for future compatibility and decisively addressed the single biggest risk in web applications: SQL Injection.

The Critical Danger of String Interpolation

We acknowledged that many developers had previously relied on system sanitization functions (like a hypothetical input() or built-in validation) for user variables like $user_guid. However, using a variable directly inside SQL quotes had remained a critical security flaw:

// Old, dangerous method: Mixing Code and Data
$sql = "SELECT * FROM users WHERE guid='{$user_guid}'"; 

Why sanitization wasn't enough: The core purpose of a sophisticated attack was to structurally break the SQL command, not just bypass a simple validation filter. Even if the input function had protected against common exploits, it couldn't prevent a crafted payload from breaking the surrounding quotes and injecting unauthorized SQL code. The fundamental issue was mixing executable code (the SELECT command) with user data ($user_guid) in a single string, creating a vulnerability point that could not be fully secured by external validation alone.

To truly eliminate this risk, we had to stop mixing data and code.

Important Security Note

This change was primarily a major architectural security hardening effort. However, we confirmed that a single, specific SQL Injection vulnerability had been identified during internal audits and was being patched with the release of the new query system in OSSN 8.8. To maintain the integrity and security of all existing installations, we did not disclose the details of this specific vulnerability. Updating to 8.8 was the most effective way to address this and prevent future exploits.

The Solution: Parameterized Queries (Prepared Statements)

In OSSN 8.8, we enforced the use of Parameterized Queries (also known as Prepared Statements). This method sent the SQL structure and the variable values to the database separately.

1. The database received the secure structure first: SELECT * FROM users WHERE guid = ?
2. It then securely bound the data ($user_guid) to the placeholder (?).

The database never interpreted the data as executable code, making injection impossible. This required converting all direct SQL strings into the structured array format:

// New, secure structure: Separating Code and Data
$wheres = array(
    array('name' => 'guid', 'comparator' => '=', 'value' => $user_guid),
);

Simplified Queries with the New Helpers

We knew that manually building arrays for complex OR logic could be cumbersome. To make this transition seamless and boost development speed, we had introduced two helper methods:

OssnDatabase::wheres(...): For creating single, secure conditions (e.g., column = ?). The optional separator could be used to link conditions with OR.
OssnDatabase::wheresGroup(...): For creating secure, nested groups (parentheses) to handle complex logic like (A AND B) OR (C AND D).

Call to Action: Update Your Queries Now if you were using them in your components

Migrating to these secure WHERE conditions was the most important action developers could take to future-proof their modules and protect users.

We provided the following comprehensive documentation to guide the conversion process:

• Understanding the Array Structure (Complex AND/OR Logic):
  https://github.com/opensource-socialnetwork/opensource-socialnetwork/wiki/OSSN-8.8-Database-complex-wheres-using-array

• How to Use the New Helper Functions (Recommended):
  https://github.com/opensource-socialnetwork/opensource-socialnetwork/wiki/OSSN-8.8-simplified-wheres-builder-using-helper-methods

We looked forward to a more secure OSSN 8.8 release thanks to developers’ commitment to these new standards!