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

[Sandro Gauci]

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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250529/d45d8ff9/attachment.html>