reading the last discussion ...
aside the magic words from Don to just change $id to :id that would
solve the issue
and the nice and very conceptual answer from jeff
i tried to play a bit in attempt to understand and and practice the
sqlinjection stuff
I tried to run the following tcl script
set id 1456
set sql_query "select * from acs_objects where object_id = :id"
set db [ns_db gethandle]
set selection [ns_db select $db $sql_query]
ns_db getrow $db $selection
but i got an error at [ns_db gethandle]
i ran the scripts from tcl page within directory www
how do i fix it?
iuri
[04/Dec/2009:08:24:14][2307.2998479792][-default:3-] Error: dbinit: db
handle limit exceeded: thread already owns 1 handle from pool 'pool1'
[04/Dec/2009:08:24:14][2307.2998479792][-default:3-] Warning:
/sqlinjection has no doc(title) set.
[04/Dec/2009:08:24:14][2307.2998479792][-default:3-] Error: GET
http://192.168.1.15/sqlinjection?
referred by ""
could not allocate 1 handle(s) from pool "pool1"
while executing
"ns_db gethandle"
("uplevel" body line 5)
invoked from within
"uplevel {
set id 1456
set sql_query "select * from acs_objects where object_id = :id"
set db [ns_db gethandle]
set selection [ns_db select $db $sql_q..."
(procedure
"code::tcl::/usr/local/aolserver/servers/openacs/www/sqlinjec..." line 2)
invoked from within
"code::tcl::$__adp_stub"
("uplevel" body line 12)
invoked from within
"uplevel {
if { [file exists $__adp_stub.tcl] } {
# ensure that data source preparation procedure exists and is
up-to-date
adp_init t..."
(procedure "adp_prepare" line 2)
invoked from within
"adp_prepare"
invoked from within
"template::adp_parse [file root [ad_conn file]] {}"
(procedure "adp_parse_ad_conn_file" line 6)
invoked from within
"$handler"
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
$handler
} ad_script_abort val {
# do nothing
}"
invoked from within
"rp_serve_concrete_file [ad_conn file]"
(procedure "rp_serve_abstract_file" line 60)
invoked from within
"rp_serve_abstract_file "$root/[ad_conn extra_url]""
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
rp_serve_abstract_file "$root/[ad_conn extra_url]"
set tcl_url2file([ad_conn url]) [ad_conn file]
set tcl..."
[04/Dec/2009:08:24:20][2307.2997423024][-sched:17-] Notice: Running
notification::sweep::sweep_notifications
Jeff Rogers wrote:
The short answer is yes, it might be vulnerable; it depends on what
scrubbing you do of your input data.
The good news it that it's also fairly easy to fix. If you're using
openacs then there's already a set of tools
(check_for_form_variable_naughtiness) for checking what is being
passed into your forms.
Otherwise, you could add in a site-wide filter that checks various
well-known form vars (such as "id") for stuff that shouldn't be there
(like non-integers).
Unfortunately the postgres driver doesn't protect against against dml
injection. I'm fairly certain it wasn't possible to do so before
postgres 8 because of the APIs available, and the driver probably
hasn't been updated to use the new APIs (PQexecParams instead of
PQexec) and besides, doing so would probably break existing code.
There's another subtler problem too, in that the db drivers support 3
different query methods - select, dml, and generic exec. However, if
the generic exec method is supported at all, then the (possibly) more
specific select or dml calls are not used.
-J
I've been alerted that a site I maintain, running on AOLserver 4.5.0
using the nspostgres driver, may be vulnerable to sql injection.
A typical adp page performs a query like this:
set sql_query "select * from sometable where entrynumber = $id"
set db [ns_db gethandle]
set selection [ns_db select $db $sql_query]
ns_db getrow $db $selection
...
I would guess that "ns_db select" would make any damaging injected dml
statements impossible. Is that correct?
In a previous discussion thread here ("ns_db and bind variable
support") I see "ns_db prepare..." mentioned. Is that a safer way to
perform db queries in adp pages?
/Björn
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
