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