[OpenSIPS-Users] Potential feature request: OpenSIPS security and concept of tainted variables

[Bogdan-Andrei Iancu]

Hi all,

While the idea is great, let's me come back with the feedback:

1) not all the values you are handling at script level may be "risky" or 
tainted ... Some may be loaded from DBs or other external services, so 
"trustful". Only what comes from signaling may be risky.

2) the escaping may not be required in all DB op cases - the injection 
is typical for raw queries, but for mysql OpenSIPS does statements. Or 
there are DB backends which are only statement (API) driven, no raw 
queries, like the dbtext for example. So, depending on the DB backend, 
the injection may or not be a problem.

3) while the $unsafe_fU was mentioned as alternative, I do not see the 
difference to using the escape transformation, if really the case.

So whatever improvement we do consider, we need to take the above into 
consideration - there is no need to over complicate things ;)

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 29.05.2025 15:28, Sandro Gauci via Users wrote:
> Thanks for this feedback!
>
> So Gary proposed two potential solutions - tainting and automatic 
> escaping. Thought I'd write a few paragraphs on this approach.
>
> The concept of tainting is appealing, as it resembles how static code 
> analyzers track data flow. Under this approach, user-controlled 
> pseudo-variables would initially be 'tainted.' They would then need to 
> be 'untainted' - effectively marked as safe - but only after 
> undergoing proper validation or another protective mechanism.
>
> Automatically escaping can be problematic and may not fully resolve 
> vulnerabilities, as its effectiveness is highly dependent on the 
> 'sink.' The 'sink' refers to the specific format or language of the 
> dangerous function or data consumer, such as SQL, shell commands, 
> NoSQL, or JSON. While attractive, such 'magical' security solutions 
> are bound to fail in specific cases. This inherent unreliability poses 
> a risk, as OpenSIPS operators would over-rely on them.
>
> Conversely, the optimal approach for building security-sensitive 
> content from user input - content that is subsequently passed to 
> security-sensitive functions - is to employ programmatic techniques 
> (e.g., parameterized queries for SQL) instead of string concatenation. 
> This method offers a more robust programming pattern than relying on 
> tainting or 'magical' solutions.
>
> Cheers!
>
> --
>     Sandro Gauci, CEO at Enable Security GmbH
>
>     Register of Companies:       AG Charlottenburg HRB 173016 B
>     Company HQ: Neuburger Straße 101 b, 94036 Passau, Germany
>     RTCSec Newsletter: https://www.enablesecurity.com/subscribe/
>     Our blog: https://www.enablesecurity.com/blog/
>     Other points of contact: https://www.enablesecurity.com/contact/
>
>
> On Tue, 27 May 2025, at 12:15 PM, Gregory Massel via Users wrote:
>>
>> Hi all
>>
>> After listening to Sandro's presentation at OpenSIPS Summit, and 
>> further to posts I sent on 30 Nov 2023 and 5 Dec 2023 ("Help dropping 
>> SQL injection attacks"), it struck me that the OpenSIPS script allows 
>> for unsafe variable references by default.
>>
>> While extremely powerful, this makes configuration implementations 
>> susceptible to oversights that result in potential injection 
>> vulnerabilities.
>>
>> The Exim project addressed this with the concept of "tainted" 
>> variables. In essence, by default, it prevents you to passing 
>> potentially unsafe variables to dangerous functions without first 
>> filtering or escapting. This may be worth consideration as a security 
>> feature in future versions of OpenSIPS.
>>
>> It may also be worth considering escaping certain variables by 
>> default and aliasing the originals. E.g. Instead of having to 
>> explicitly check variables as follows:
>>
>> if ( $fU != $(fU{s.escape.common}) || $tU != $(tU{s.escape.common}) ) {
>> 	xlog ("Rejecting SQL injection attempt received from $socket_in(proto):$si:$sp (Method: $rm; From: $fu; To: $tu; Contact: $ct).");
>> 	send_reply (403,"Forbidden");
>> 	exit;
>> }
>> if ( $fU != $(fU{s.escape.user}) || $tU != $(tU{s.escape.user}) ) {
>> 	xlog ("Rejecting request with unusual characters received from $socket_in(proto):$si:$sp (Method: $rm; From: $fu; To: $tu; Contact: $ct).");
>> 	send_reply (403,"Forbidden");
>> 	exit;
>> }
>>
>> if ( $(ct.fields(uri){uri.user}) != $(ct.fields(uri){uri.user}{s.escape.common}) ) {
>> 	send_reply (403,"Forbidden");
>> 	exit;
>> }
>> There may be something to be said for having variables like $fU, $tU 
>> escaped by default and adding variables like $unsafe_fU, $unsafe_tU 
>> contain the original variables. Backwards compatibility could be 
>> achieved with a core configuration variable to disable this.
>>
>> Alternatively, as with Exim, if one tries to reference the variables 
>> within a database function or exec function, regard these variables 
>> as "tainted" and throw an error if the {s.escape.common} (or similar) 
>> isn't applied.
>>
>> Regards
>>
>> Greg
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250603/be60de5b/attachment.html>