On Sun, 28 Sep 2003 12:58:16 -0700, Dave Anderson wrote:
Hi Dave
Tim, that link is dead. Also, it seems that the main thrust of the
first article is in regards to stored procedures:
Yeah, but it's important to have such articles to educate programmers as to some of
the traps.
--
Cheers
Ron
On Sun, 28 Sep 2003 12:54:46 +0100, Tim Bunce wrote:
Hi Tim
And here: http://www.nextgenss.com/research/papers.html
Ummm, no. Requested URL was not found on this server.
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 29/09/2003
http://savage.net.au/index.html
On Sun, Sep 28, 2003 at 12:58:16PM -0700, Dave Anderson wrote:
Tim, that link is dead.
Ah phoey. And the internet archive (archive.org) doesn't have a copy either.
Also, it seems that the main thrust of the first
article is in regards to stored procedures:
(excerpted from first link
On Mon, Sep 29, 2003 at 12:42:11AM +0100, Tim Bunce wrote:
On Sun, Sep 28, 2003 at 12:58:16PM -0700, Dave Anderson wrote:
Tim, that link is dead.
Ah phoey. And the internet archive (archive.org) doesn't have a copy either.
Seems like the site was renamed. Here's an updated set of links
Ron Savage wrote:
On Sun, 28 Sep 2003 12:54:46 +0100, Tim Bunce wrote:
And here: http://www.nextgenss.com/research/papers.html
Ummm, no. Requested URL was not found on this server.
True, but dropping the '/research' finds it - though I dropped the
papers.html first, found
I can see where in some cases that might be useful, but as I mentioned
below the values are coming from the database in the first place. So
from that standpoint alone you are talking about a very low risk
exploit. I suppose that someone could build a form and enter bogus
values, but this
On 2003-09-27 01:53:46 -0700, Dave Anderson wrote:
I can see where in some cases that might be useful, but as I mentioned
below the values are coming from the database in the first place. So
from that standpoint alone you are talking about a very low risk
exploit. I suppose that someone
On Sat, 27 Sep 2003 01:53:46 -0700, Dave Anderson wrote:
Hi Dave
In case no-one mentioned it yet, you can read about SQL injection attacks here:
http://www.securityfocus.com/infocus/1644
This is a superb article.
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 28/09/2003
I finally solved this by doing sort of an end run around the issue.
There seems to be no way to bind an arbitrary number of variables to an
IN clause, especially when there are multiple IN clauses with
different numbers of variables to bind for each. For example, in the SQL
below,
On 2003-09-25 02:16:46 -0700, Dave Anderson wrote:
sub buildValueStrings {
my ($a) = shift;
my ($h) = shift;
for (@test = @$a) {
(($_ eq 0) ? (@$a = keys %$h) : );
}
grep($_ = '$_', @$a);
This still allows somebody to inject sql code by embedding
10 matches
Mail list logo
