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
> [email protected]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
