<!DOCTYPE html><html><head><title></title></head><body><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/">https://www.enablesecurity.com/subscribe/</a></div><div class="signature"> Our blog: <a href="https://www.enablesecurity.com/blog/">https://www.enablesecurity.com/blog/</a></div><div class="signature"> Other points of contact: <a href="https://www.enablesecurity.com/contact/">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">Users@lists.opensips.org</a></div><div><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a></div><div><br></div></blockquote><div><br></div></body></html>