Thank you Bogdan!
It's worth noting that, if using {s.escape.user}, it won't detect a SQL
injection, however, it may detect other potentially problematic
characters, so one then has to apply both checks individually, e.g.
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;
}
So above doesn't block UTF-8; it just enforces that it must be received
from the client in fully escaped form.
I'm gathering that UTF-8 is actually acceptable for the user part (and
most other parts) of the URI, provided that it's encoded with '%'? I
work with purely ASCII user parts however, out of interest, was
wondering if it is allowable and/or commonplace to use Unicode extended
character sets for any portions of the URI in parts of the world where
other character sets are more frequently used? From what I could find,
it seems that UTF16 is not allowed in the User Part and that the domain
would be internationalised using Punycode, so the full URI should always
be encoded in ASCII but with UTF-8 (but not UTF-16) permitted in
%-encoded form for the user part?
With respect to the Contact header, I'm struggling a bit. Is the syntax
below correct?
if ( $(ct.fields(uri){uri.user}) !=
$(ct.fields(uri){uri.user}{s.escape.common}) ) {
send_reply (403,"Forbidden");
exit;
}
--
Thanks
*Gregory Massel*
On 2023-12-05 11:33, Bogdan-Andrei Iancu wrote:
Hi Gregory,
As it is said, there is no single way to skin the cat :). Your
approach is a valid one, by using the escaping transformation. Maybe
you should check the s.escape.user [1].
Such checks make sense when using avp_db_query(), so raw queries. The
internal queries (like auth, etc) are done via prepared statements, so
safe to injections.
[1] https://www.opensips.org/Documentation/Script-Tran-3-2#s.escape.user
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 30.11.2023 02:34, Gregory Massel via Users wrote:
Hi all
I'm wondering what the best practice is in terms of detection and
dropping attempted SQL injection attacks?
Is something like the following adequate or can this be enhanced:
if ( $fU != $(fU{s.escape.common}) || $tU != $(tU{s.escape.common}) ) {
drop();
}
Obviously this does not remove the need to escape anything passed to
avp_db_query(), however, what I want to do is identify these sorts of
attacks at the top of the script and avoid processing.
To date all the attacks I've seen focus on the contact and from user,
e.g.:
INVITEsip:00111390237920793@x.x.x.x:5060;transport=UDP SIP/2.0
Contact:<sip:a'or'3=3--@x.x.x.x:5060;transport=UDP>
To:<sip:00111390237920793@x.x.x.x;transport=UDP>
From:<sip:a'or'3=3--@x.x.x.x;transport=UDP>;tag=v2pjtxqb
I'm not quite sure how to match the Contact user. Would the following
work?
if ( $(ct.fields(uri){uri.user}) !=
$(ct.fields(uri){uri.user}{s.escape.common}) ) {
drop();
}
--
Regards
*Gregory Massel*
_______________________________________________
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
