I am stress-testing ZOracleDA, and found it almost perfect for large web applications: it supports multi-threaded access and a kind of connection pooling, and quite reliable. However, there are two points, which makes me a bit anxious: (1) Doug Hellman mentioned that ZOracleDA does not stop long running requests when the user cancels the HTTP request. Is it possible for a malicious cracker to conduct a denial-of-service attack exploiting this behaviour? I think this is not a ZOracleDA specific problem, but a general issue with Oracle. Do other technologies (PHP, mod_perl, etc) have a solution for this problem? Is this a real threat? (2) The ZSQL technology does not use bind variables, instead, literal values are included into the SQL statemets. This may be a big problem for Oracle. Oracle has a very primitive mechanism to determine if an SQL statement be parsed or there is one in its cache: it simply compares the SQL statement strings. If you use bind variables (eg. insert into t(c1,c2) values(:bv1,:bv2)) the SQL statement string is always the same, if you use literals (eg insert into t(c1,c2) values('xxx',512.67)) Oracle is forced to parse all SQL statements. We benchmarked this behaviour and found the 20 - 30 % more Oracle resources are used for this extra parsing. Is there a way to force ZOracleDA to use binding instead of literal substitution? NM
On 1/14/00 5:14 PM, Nemeth Miklos at nemeth@iqsoft.hu wrote:
I am stress-testing ZOracleDA, and found it almost perfect for large web applications: it supports multi-threaded access and a kind of connection pooling, and quite reliable.
Almost perfect is good :-)
However, there are two points, which makes me a bit anxious:
(1) Doug Hellman mentioned that ZOracleDA does not stop long running requests when the user cancels the HTTP request. Is it possible for a malicious cracker to conduct a denial-of-service attack exploiting this behaviour? I think this is not a ZOracleDA specific problem, but a general issue with Oracle. Do other technologies (PHP, mod_perl, etc) have a solution for this problem? Is this a real threat?
I do not believe anyone has a solution for this problem, and yes it could be used as an attack, pretty much regardless of their type. This is a form of resource starvation, and it is unavoidable without active defenses, something we don't have right now (nor does Apache, which can be starved the same way). Having said that, there is really no way that I know of to know that the user has stopped their HTTP request, it's not part of the protocol, you'd have to detect the socket being closed pre-maturely, which would NEVER be available thru PCGI or FastCGI, though it is theoretically feasible in ZServer to propagate this information.
(2) [ Nemeth talks about bind variables] We benchmarked this behaviour and found the 20 - 30 % more Oracle resources are used for this extra parsing.
Wow I wasn't aware of this problem being performance related, but in retrospect it makes perfect sense. 20-30% is a pretty substantial amount.
Is there a way to force ZOracleDA to use binding instead of literal substitution?
There is not currently, though obviously its feasible. I'll try and do some research about this in the near term and factor it into product plans! Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
PHP has a solution for this - see http://www.php.net/manual/features.connection-handling.php3 It sets a flag your script can check so you can decide to abort or complete an initiated server-side process after the connection is broken. Guy N. Hurst Christopher Petrilli wrote:
On 1/14/00 5:14 PM, Nemeth Miklos at nemeth@iqsoft.hu wrote: ...
However, there are two points, which makes me a bit anxious:
(1) Doug Hellman mentioned that ZOracleDA does not stop long running requests when the user cancels the HTTP request. Is it possible for a malicious cracker to conduct a denial-of-service attack exploiting this behaviour? I think this is not a ZOracleDA specific problem, but a general issue with Oracle. Do other technologies (PHP, mod_perl, etc) have a solution for this problem? Is this a real threat?
I do not believe anyone has a solution for this problem, and yes it could be used as an attack, pretty much regardless of their type. This is a form of resource starvation, and it is unavoidable without active defenses, something we don't have right now (nor does Apache, which can be starved the same way). Having said that, there is really no way that I know of to know that the user has stopped their HTTP request, it's not part of the protocol, you'd have to detect the socket being closed pre-maturely, which would NEVER be available thru PCGI or FastCGI, though it is theoretically feasible in ZServer to propagate this information.
On 1/17/00 9:49 AM, Guy N. Hurst at gnhurst@hurstlinks.com wrote:
PHP has a solution for this - see http://www.php.net/manual/features.connection-handling.php3
It sets a flag your script can check so you can decide to abort or complete an initiated server-side process after the connection is broken.
Interesting, they must be getting some information directly from Apache because they are a module. I know this information isn't available from PCGI, but perhaps from FastCGI? It really doesn't matter towards the 'resource starvation' attack though, because that's not how an attacker would behave, unless of course he had a sudden change of heart! :-) Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
On Mon, 17 Jan 2000, Christopher Petrilli wrote:
On 1/17/00 9:49 AM, Guy N. Hurst at gnhurst@hurstlinks.com wrote:
PHP has a solution for this - see http://www.php.net/manual/features.connection-handling.php3
It sets a flag your script can check so you can decide to abort or complete an initiated server-side process after the connection is broken.
Interesting, they must be getting some information directly from Apache because they are a module. I know this information isn't available from PCGI, but perhaps from FastCGI?
If it'd be possible to get such information from Apache, I'd be glad to develop a patch for my mod_pcgi2... Oleg. ---- Oleg Broytmann Foundation for Effective Policies phd@phd.russ.ru Programmers don't die, they just GOSUB without RETURN.
participants (4)
-
Christopher Petrilli -
Guy N. Hurst -
Nemeth Miklos -
Oleg Broytmann