<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="monospace">Hi all,<br>
<br>
While the idea is great, let's me come back with the feedback:<br>
<br>
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.<br>
<br>
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.<br>
<br>
3) while the $unsafe_fU was mentioned as alternative, I do not see
the difference to using the escape transformation, if really the
case.<br>
<br>
So whatever improvement we do consider, we need to take the above
into consideration - there is no need to over complicate things ;)<br>
<br>
Regards, <br>
</font>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="https://www.opensips-solutions.com">https://www.opensips-solutions.com</a>
<a class="moz-txt-link-freetext" href="https://www.siphub.com">https://www.siphub.com</a></pre>
<div class="moz-cite-prefix">On 29.05.2025 15:28, Sandro Gauci via
Users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a7984a4d-f103-43c0-be49-def3d96941b5@app.fastmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title></title>
<div>Thanks for this feedback! </div>
<div><br>
</div>
<div>So Gary proposed two potential solutions - tainting and
automatic escaping. Thought I'd write a few paragraphs on this
approach. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers!</div>
<div><br>
</div>
<div id="sig45665722">
<div class="signature">--</div>
<div class="signature"> </div>
<div class="signature"> Sandro Gauci, CEO at Enable Security
GmbH</div>
<div class="signature"><br>
</div>
<div class="signature"> Register of Companies: AG
Charlottenburg HRB 173016 B</div>
<div class="signature"> Company HQ:
Neuburger Straße 101 b, 94036 Passau, Germany</div>
<div class="signature"> RTCSec Newsletter: <a
href="https://www.enablesecurity.com/subscribe/"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.enablesecurity.com/subscribe/</a></div>
<div class="signature"> Our
blog: <a
href="https://www.enablesecurity.com/blog/"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.enablesecurity.com/blog/</a></div>
<div class="signature"> Other points of contact: <a
href="https://www.enablesecurity.com/contact/"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.enablesecurity.com/contact/</a></div>
<div class="signature"><br>
</div>
</div>
<div><br>
</div>
<div>On Tue, 27 May 2025, at 12:15 PM, Gregory Massel via Users
wrote:</div>
<blockquote type="cite" id="qt" style="">
<p>Hi all</p>
<p>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.</p>
<p>While extremely powerful, this makes configuration
implementations susceptible to oversights that result in
potential injection vulnerabilities.</p>
<p>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.</p>
<p>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:</p>
<pre>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;
}
</pre>
<div>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.</div>
<p>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.</p>
<p>Regards</p>
<p>Greg</p>
<div>_______________________________________________</div>
<div>Users mailing list</div>
<div><a href="mailto:Users@lists.opensips.org"
moz-do-not-send="true" class="moz-txt-link-freetext">Users@lists.opensips.org</a></div>
<div><a
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users"
moz-do-not-send="true" class="moz-txt-link-freetext">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a></div>
<div><br>
</div>
</blockquote>
<div><br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</body>
</html>