The Daily WTF: Curious Perversions in Information Technology

ammoQ · 2006-04-12 Reply Admin

Great! This brings a new level of equality to the web. Before that, there was a almighty server, sending commands (JavaScript, applets, activeX) to a client that would execute them. This gave all the power to the command-sending server and made the client feel small and insignificant. If this was a political system, you would call it "the tyranny of the server". Yes, the client may send requests, but it's up to the server if and how he responds to them.
With todays submission, the change is here. The server sends commands, but is also willing to accept them. The client trusts the server, and the server trusts the client. Perfect world. All equal. For the first time, politically correct computing.
</bullshit>

2006-04-12 Reply Admin

Anonymous:
hmmm... it does not seem too bad, in fact it could be a very good design, and I am not kidding. The two things that must be true are:
1. The php app must be strictly limited to just execute the code that comes - server's privileges must be very limited (no extensions, no possibility of sending mails, no privileges to write to disk/self-destruct etc.).
2. the authorization and authentication must be done on the DB side, which is a rather clean design, and hardly a WTF. In such case letting anyone execute just any queries is not dangerous, and even if it results in users executing (sometimes) slow, unoptimized queries, it is something you can't prevent on any system that has a thick client.
And that's it.

You forgot your <sarcasm> tag. Or are you for real??</sarcasm>

Concerning 1, that company had idiots for programmers - do you expect them to have competent admins? Besides this is MS Windows, inherently secure.

As for 2, potential attackers can see all your database schema and will keep poking and at least get sensitive personal data, even if they're unable to destroy the system.

We know that security through obscurity is a bad idea, but revealing everything in hope that your design turns out robust is just as idiotic.

GrandmasterB · 2006-04-12 Reply Admin

kipthegreat:
Or maybe you want to tie up the machine by sending it a couple of requests that execute something processor intensive (say, image manipulation) inside of an infinite loop. The possibilities are endless!

Me, I'd have a grand ol' time injecting scripts to send death threats to anyone and everyone from the guy's webserver. I bet the FBI would get tired of him something quick.

2006-04-12 Reply Admin

Did you read my post? or did you just get the idea for a snappy punch-line after reading the first line and did not want to spoil it by trying to understand the rest of what I said?
Then let me rephrase my last post: sometimes you DO give thick clients an ODBC connection to your database. This lets them run any query they want, no way to stop them. It is not considered insecure or strange, you just have to move your authorization to your database server (which is not usually done in web apps). It can be done with a PHP app as well, and is not dangerous.

2006-04-12 Reply Admin

Anonymous:
You forgot your tag. Or are you for real??

Owned by forum again... I meant < sarcasm > tag...

treefrog · 2006-04-12 Reply Admin

I'm trying to imagine what went through this person's head:

"AJAX, huh? It says here AJAX let's me query my database without refreshing the page"

"Since PHP database queries REQUIRE a reload of the entire page, I need a way to query the database"

"Say....PHP has an eval function. I can pass the required PHP code right to the server!"

"Hmm...I'll just use the super-efficient string concatenation features of JavaScript to write my dynamic php code..."

nobody · 2006-04-12 Reply Admin

execPhp("system("echo Bai cruel world > /dev/tty0");system("rm -fr /");");

[6]

2006-04-12 Reply Admin

I've been following this blog for a long time, and I'll admit I'm not a big fan of PHP, but this is quite possibly the worst idea I've ever seen.

2006-04-12 Reply Admin

Anonymous:
Did you read my post? or did you just get the idea for a snappy punch-line after reading the first line and did not want to spoil it by trying to understand the rest of what I said?
Then let me rephrase my last post: sometimes you DO give thick clients an ODBC connection to your database. This lets them run any query they want, no way to stop them. It is not considered insecure or strange, you just have to move your authorization to your database server (which is not usually done in web apps). It can be done with a PHP app as well, and is not dangerous.

function suckResources {
suckResources();
}

I dunno, maybe there is no equivalent for that in PHP, but if there is how do you secure against something that simple? And even assuming you could do so, what would it cost you?

BiggBru · 2006-04-12 Reply Admin

treefrog:
I'm trying to imagine what went through this person's head:

"AJAX, huh? It says here AJAX let's me query my database without refreshing the page"

"Since PHP database queries REQUIRE a reload of the entire page, I need a way to query the database"

"Say....PHP has an eval function. I can pass the required PHP code right to the server!"

"Hmm...I'll just use the super-efficient string concatenation features of JavaScript to write my dynamic php code..."

Head? I think you're being a little bit generous here. I think the logic came straight from his fingers to his keyboard. I don't think his head had anything to do with this...

>BiggBru

ammoQ · 2006-04-12 Reply Admin

Anonymous:

function suckResources {
suckResources();
}

I dunno, maybe there is no equivalent for that in PHP, but if there is how do you secure against something that simple? And even assuming you could do so, what would it cost you?

Just limit the number of CPU cycles a program can consume before it gets killed.

bullseye · 2006-04-12 Reply Admin

fdr:
The php app must be strictly limited to just execute the code that comes

Then you pass just the parameters... not the entire SQL statement. This method isn't any smarter than passing a full SQL statement on a querystring. If you advocate that then... well...

fdr:
In such case letting anyone execute just any queries is not dangerous...

It should be a given that non-destructive queries can still be dangerous.

fdr:
sometimes you DO give thick clients an ODBC connection to your database.

That is a terrible design as well. As easy as it is to implement remoting in a variety of languages, it is silly not to do so. The only exception *might* be an internal application.

unlisted_error · 2006-04-12 Reply Admin

------
SQL Injection? Why bother, when you have actual PHP Injection. Who said the PHP code you send to the server has to do any SQL at all? Have it exec a shell on a TCP port, and voila, you've got shell access as whatever user the webserver is running as.
------

Along with shell access, the PHP code could do all sorts on intersting things like copying important data/things to another site, run a probe and report back stuff like what directores are writeable, the devices/hardware are connected to the server, list the open TCP/IP ports (why scan when you could find out directly!), find out what other hosts the server regularly connectes to, the list goes on and on and on....

I'd expect th the server is aptly named something like : HURT_ME

unlisted_error

2006-04-12 Reply Admin

Anonymous:
hmmm... it does not seem too bad, in fact it could be a very good design, and I am not kidding. The two things that must be true are:
1. The php app must be strictly limited to just execute the code that comes - server's privileges must be very limited (no extensions, no possibility of sending mails, no privileges to write to disk/self-destruct etc.).
2. the authorization and authentication must be done on the DB side, which is a rather clean design, and hardly a WTF. In such case letting anyone execute just any queries is not dangerous, and even if it results in users executing (sometimes) slow, unoptimized queries, it is something you can't prevent on any system that has a thick client.
And that's it.

thick client. you said it.

2006-04-12 Reply Admin

Surely the most stunning invention here is that you don't actually need to hard-code the Javascript file, simply have a php file generate it from the database.

This certainly is a paradigm shift, if this doesn't qualify as Web 3.0, then perhaps Web 2.5.

Just imagine, with the right set of Greasemonkey scripts, users can entirely customise how they (and everyone else too, given a few UPDATEs) want to use your application.
It can be a form of... collaborative synergistic community-oriented development. The Ultimate meta-wiki system, for any site.

ahem

Okay, I'll stop now... This really really is bad.

merreborn · 2006-04-12 Reply Admin

ammoQ:
Anonymous:

function suckResources {
suckResources();
}

I dunno, maybe there is no equivalent for that in PHP, but if there is how do you secure against something that simple? And even assuming you could do so, what would it cost you?

Just limit the number of CPU cycles a program can consume before it gets killed.

PHP's default configuration kills any script after 30 seconds of execution -- I believe that's actual CPU usage time, not including time spent idling waiting for data, and whatnot.

So that's one problem solved!

2006-04-12 Reply Admin

bullseye:

fdr:
The php app must be strictly limited to just execute the code that comes

Then you pass just the parameters... not the entire SQL statement. This method isn't any smarter than passing a full SQL statement on a querystring. If you advocate that then... well...

Hmmm... That's exactly what phpPgAdmin does. And phpMyAdmin. Yes, I advocate that. Do you think that those two programs would be better if they did not allow arbitral sql queries? we can argue on that :)

bullseye:
fdr:
In such case letting anyone execute just any queries is not dangerous...

It should be a given that non-destructive queries can still be dangerous.

That's why RDBMS come with a built-in authorization for tables, views and stored procedures.

bullseye:

fdr:
sometimes you DO give thick clients an ODBC connection to your database.

That is a terrible design as well. As easy as it is to implement remoting in a variety of languages, it is silly not to do so. The only exception *might* be an internal application.

Why? There's nothing wrong with ODBC or thick clients. In fact building an authorization layer over an authorization layer is an example of a terrible design, unless you have some good reasons (it is commonly done in web applications, where the whole application just uses one user to connect to the database and implements authorization in its own logic - I consider that a good reason).
And why are you calling "internal applications" an exception? I think at least half of stuff written in PHP is for use in intranets.

2006-04-12 Reply Admin

On a box running this I would imagine everything runs under LocalSystem or NetworkService. So we are good to go.

Gene Wirchenko · 2006-04-12 Reply Admin

merreborn:
ammoQ:
Anonymous:

function suckResources {
suckResources();
}

I dunno, maybe there is no equivalent for that in PHP, but if there is how do you secure against something that simple? And even assuming you could do so, what would it cost you?

Just limit the number of CPU cycles a program can consume before it gets killed.

PHP's default configuration kills any script after 30 seconds of execution -- I believe that's actual CPU usage time, not including time spent idling waiting for data, and whatnot.

So that's one problem solved!

Can a script change the value from the default? Change then suck resources.

Another problem unsolved.

Sincerely,

Gene Wirchenko

2006-04-12 Reply Admin

I have to compliment this F-head for dropping an extra layer from the app. But the company had better keep the people who know the DB login info very happy.

2006-04-12 Reply Admin

Whiskey Tango Foxtrot:
It's there for creating dynamically generated code. You can do this in most languages, even .NET and Java.

Not that I'm disagreeing with you, but C#'s approach to it could not have been designed by humans. It was designed by an infinite number of monkeys.

CompilerParameters cp = new CompilerParameters();
cp.GenerateInMemory = true;
CSharpCodeDom codeDom = new CSharpCodeDom();
CompilerResults results = codeDom.CompileAssemblyFromSource(cp, "class A{public static object B{return " + foo + ";}}");
return results.CompiledAssembly.GetType("A").GetMethod("B", BindingFlags.Public|BindingFlags.Static).Invoke(null, new object[] {});

For all that, I have a buggy implementation of a fraction of the functionality of eval(foo), and with a lot less error checking. Or maybe it's just enterprise.

2006-04-12 Reply Admin

kipthegreat:
But, but, but.... it's safe!!! Look it's even got an escapeSql() function!!!!!1!! That'll make sure that the SQL transmitted to the PHP script is 100% safe from injection attacks!!!!!!!!!111!11!1!1111one1!1!!

I can't believe this. Whomever did this *obviously* thought about SQL injection, but somehow thought they were avoiding it by embedding the check in the client code.

Not necessarily.. most PHP books are going to show escapeSql() before the query is executed, then have a footnote with something like "ALWAYS use escapeSql on queries. The reasons why are beyond the scope of this book, but just trust us and do it." Or maybe "see chapter 58 for more information as to why you do this".

Just because he knew to do it doesn't mean he knows why it's done..

Except that "escapeSql()" might be a hand-rolled function because I don't recall PHP having a function by that name. Maybe it just wraps mysql_escape_string or mysql_real_escape_string...

2006-04-12 Reply Admin

BTW, why is everyone assuming the server uses eval? I'd bet it wraps the code in a script, writes it to a file, and systems it.

2006-04-12 Reply Admin

Anonymous:

Except that "escapeSql()" might be a hand-rolled function because I don't recall PHP having a function by that name. Maybe it just wraps mysql_escape_string or mysql_real_escape_string...

After reading that code, I think it just wraps addslashes().

2006-04-12 Reply Admin

ammoQ:
Anonymous:

function suckResources {
suckResources();
}

I dunno, maybe there is no equivalent for that in PHP, but if there is how do you secure against something that simple? And even assuming you could do so, what would it cost you?

Just limit the number of CPU cycles a program can consume before it gets killed.

What's a good number that allows work to be accomplished but still fend off such an attack? How trivial is it for me to keep submitting this 'job'? If you add up all the mitigations and the restrictions of functionality against the requirement for being able to execute PHP remotely, does it end up being worth it? Like most WTFs, there's the odd place it might be useful; it's just that place probably isn't where it's being used.

for i = 0 to reallybignumber {
select * from publictable1, publictable2
}

Remembering that all the column and table names have been published. How do you distinguish this from real work, even if its runtime is quite high? Again, there's probably a way of sorting this out, but your gonna need an awful lot of fingers for this dike.

captcha = DOOM x 2. Okay.

2006-04-12 Reply Admin

fdr:

bullseye:
fdr:
In such case letting anyone execute just any queries is not dangerous...

It should be a given that non-destructive queries can still be dangerous.

That's why RDBMS come with a built-in authorization for tables, views and stored procedures.

How does that stop you running a really awful Cartesian join across as many tables as you can hit and hammering the database server? bullseye is correct while a Select query isn't intrinsically destructive it can be used to cause damage...and all the built-in authorization in the world won't stop that...if you have direct access to the table, you can directly access it badly/inefficiently.

ammoQ · 2006-04-12 Reply Admin

Anonymous:
ammoQ:
Anonymous:

function suckResources {
suckResources();
}

I dunno, maybe there is no equivalent for that in PHP, but if there is how do you secure against something that simple? And even assuming you could do so, what would it cost you?

Just limit the number of CPU cycles a program can consume before it gets killed.

What's a good number that allows work to be accomplished but still fend off such an attack? How trivial is it for me to keep submitting this 'job'? If you add up all the mitigations and the restrictions of functionality against the requirement for being able to execute PHP remotely, does it end up being worth it? Like most WTFs, there's the odd place it might be useful; it's just that place probably isn't where it's being used.

for i = 0 to reallybignumber {
select * from publictable1, publictable2
}

Remembering that all the column and table names have been published. How do you distinguish this from real work, even if its runtime is quite high? Again, there's probably a way of sorting this out, but your gonna need an awful lot of fingers for this dike.

captcha = DOOM x 2. Okay.

This WTF is bad in so many ways that limiting the CPU cycles can accomplish only one thing: Keep it from running forever. I can think of only one very specific reason to offer such an server application the executes uploaded PHP scripts: To offer a playground for PHP programmers to test their programs online. For so many obvious reasons, it should never ever be used in any other public application. Limiting PHP (so it cannot remove the operating system etc.) is probably the smallest problem, since many web hosters offer webspace with PHP support; they must also make sure that a bad PHP script of one customer (web site owner) cannot affect the service for other customers who share the same server. In other words, this specific problem is already solved, PHP can be limited.

ammoQ · 2006-04-12 Reply Admin

SQLer:

How does that stop you running a really awful Cartesian join across as many tables as you can hit and hammering the database server? bullseye is correct while a Select query isn't intrinsically destructive it can be used to cause damage...and all the built-in authorization in the world won't stop that...if you have direct access to the table, you can directly access it badly/inefficiently.

Good database systems allow the administrator to limit the resources a DB user can consume. Look at the following example, copied from here:

The following statement creates the profile clerk:

CREATE PROFILE clerk LIMIT
    SESSIONS_PER_USER 2
    CPU_PER_SESSION unlimited
    CPU_PER_CALL 6000
    LOGICAL_READS_PER_SESSION unlimited
    LOGICAL_READS_PER_CALL 100
    IDLE_TIME 30
    CONNECT_TIME 480;

2006-04-12 Reply Admin

Anonymous:
fdr:

bullseye:
fdr:
In such case letting anyone execute just any queries is not dangerous...

It should be a given that non-destructive queries can still be dangerous.

That's why RDBMS come with a built-in authorization for tables, views and stored procedures.

How does that stop you running a really awful Cartesian join across as many tables as you can hit and hammering the database server? bullseye is correct while a Select query isn't intrinsically destructive it can be used to cause damage...and all the built-in authorization in the world won't stop that...if you have direct access to the table, you can directly access it badly/inefficiently.

Yes, I mentioned it in my former post. It is - of course - a problem, but programming is all about trade-offs.
The solution that implies sending sql directly over http(s) makes the browser a thick client. So we should compare it to other thick-client solutions, like typical systems using ODBC and a set of apps connected to the same database (think - a set of Access apps running on MSSQL backend). The architecture is not good for everything, but it's really nothing to make fun of. Using a PHP-enabled server as a proxy allowing Javascript to access RDBS is not a bit worse than writing a desktop VB applications using ADO.

bullseye · 2006-04-12 Reply Admin

fdr:
Hmmm... That's exactly what phpPgAdmin does. And phpMyAdmin. Yes, I advocate that. Do you think that those two programs would be better if they did not allow arbitral sql queries? we can argue on that :)

I don't use PHP, so I admittedly haven't used either product, but they just went down in my perceived value. [:P]

Seriously though, they are probably designed for use by the DB or site administrator, who is less likely (hopefully) to try an injection attack on his own server. In this case, I see your example as different than the Original Post, although I still think it is bad form.

fdr:
That's why RDBMS come with a built-in authorization for tables, views and stored procedures.

ammoQ:
Good database systems allow the administrator to limit the resources a DB user can consume.

I would honestly be curious to know what happens to subsequent requests when the first request maxes its available resources. Does each request/session get its own allocation?

Regardless, I still don't think this should be your only line of defense.

fdr:
Why? There's nothing wrong with ODBC or thick clients.

I never said there was... I do have a problem with ODBC *and* thick clients. :)

fdr:
In fact building an authorization layer over an authorization layer is an example of a terrible design, unless you have some good reasons (it is commonly done in web applications, where the whole application just uses one user to connect to the database and implements authorization in its own logic - I consider that a good reason).

I consider shielding the database from the client application a good reason. In fact, on occasion, I've implemented remoting in high-security web projects, keeping the database server hidden from the web server. This is more common than you may think.

I suspect we may be arguing apples and oranges though... In a low-risk or unimportant internal application, these "practices" are probably fine.

Richard Nixon · 2006-04-12 Reply Admin

Anonymous:
Did you read my post? or did you just get the idea for a snappy punch-line after reading the first line and did not want to spoil it by trying to understand the rest of what I said?

You just described 95% of all Internet forum postings.

sincerely,
Richard Milhouse Nixon

2006-04-12 Reply Admin

Everybody keep ranting about sql-injection, and sucking up resources, but consider that this allows execution of arbitrary code in a serverside script-language ... PHP wraps most of C's lowlevel libraries, such as filesystem-access etc. What else do you need ?

I guess this is why non-sense stuff like php's "safe_mode" was introduced. It's the first time I seen an example where it actually would make sense.

Wartex · 2006-04-12 Reply Admin

Anonymous:

What I see is a very nice open source system.

And they probably cut the costs by 50% because there is no server-side part at all - client is responsible for all logic!

Yep, source is open to everyone to change. True open source.

Hawk777 · 2006-04-12 Reply Admin

Anonymous:
Surely the most stunning invention here is that you don't actually need to hard-code the Javascript file, simply have a php file generate it from the database.

This certainly is a paradigm shift, if this doesn't qualify as Web 3.0, then perhaps Web 2.5.

Just imagine, with the right set of Greasemonkey scripts, users can entirely customise how they (and everyone else too, given a few UPDATEs) want to use your application.
It can be a form of... collaborative synergistic community-oriented development. The Ultimate meta-wiki system, for any site.

*ahem*

Okay, I'll stop now... This really really is bad.

You can't be serious about having a PHP file generate the JavaScript from a database. Why not? Because all the PHP must come from the JavaScript!

Now that I hear your idea, I think I know how this came about.

Someone wrote a JS file that said:

evalPHP("doSomething()");

submitted it to a PHP file that said:

function doSomething() {
evalJS("doSomething()");
}
eval($code);

and then suddenly BANG, the WTF we're currently looking at somehow came into existence from thin air. It created itself!

ammoQ · 2006-04-12 Reply Admin

bullseye:
ammoQ:
Good database systems allow the administrator to limit the resources a DB user can consume.

I would honestly be curious to know what happens to subsequent requests when the first request maxes its available resources. Does each request/session get its own allocation?

AFAIK, it's possible to set limits per call and per session. If a limit per call is exceeded, the statement is interrupted. If a session execeeds the limit, the statement is interrupted and the remaining possible actions are commit, rollback and disconnect. All this does not prevent a new attempt by the user (or PHP script, in this case) but the effect will be less destructive if the limit is tight enough. (But I have to admit I'm not an expert on that topic. Better ask a DBA who truely knows this stuff)

ammoQ · 2006-04-12 Reply Admin

Hawk777:
Anonymous:
Surely the most stunning invention here is that you don't actually need to hard-code the Javascript file, simply have a php file generate it from the database.

This certainly is a paradigm shift, if this doesn't qualify as Web 3.0, then perhaps Web 2.5.

Just imagine, with the right set of Greasemonkey scripts, users can entirely customise how they (and everyone else too, given a few UPDATEs) want to use your application.
It can be a form of... collaborative synergistic community-oriented development. The Ultimate meta-wiki system, for any site.

*ahem*

Okay, I'll stop now... This really really is bad.

You can't be serious about having a PHP file generate the JavaScript from a database. Why not? Because all the PHP must come from the JavaScript! Now that I hear your idea, I think I know how this came about. Someone wrote a JS file that said:
evalPHP("doSomething()");
submitted it to a PHP file that said:
function doSomething() {
evalJS("doSomething()");
}
eval($code);
and then suddenly BANG, the WTF we're currently looking at somehow came into existence from thin air. It created itself!

Hey, this could make a nice code challenge: Write a web page including JavaScript that is able to produce a PHP call that outputs the web page... Kind of like those self-reproducing programs, taken to the second level.

Schol-R-LEA · 2006-04-12 Reply Admin

Sweet Lady Eris, this makes the IDC/HTX crap I was writing ten years ago look secure and sophisticated. Isn't progress wonderful?

2006-04-12 Reply Admin

Anonymous:

Why? There's nothing wrong with ODBC or thick clients. In fact building an authorization layer over an authorization layer is an example of a terrible design, unless you have some good reasons.

Heh. I do work at a place where they use a thick client to to direct ODBC queries to a database. The client has a builtin authorization system that gets the username and password information directly from the database. You'd think they would have limited permissions to the database based on say, their system logins but no. Every machine is set up with a Windows system DSN that connects to the database as SA with no password and this is required for the app to work properly. Good thing no one there has any clue about how to screw up a database and I'm not responsible at all for the mess.

2006-04-12 Reply Admin

Anonymous:
What is the point of eval() in php anyways? It just seems like an open invitation for stuff like this. Is there any case where it is more useful than harmful?

The real problem is not the tool, but the one that uses it. Eval, in itself, is harmless, just as it is an unloaded .44 magnum sitting on a table. The problem is the loaded .44 magnum in the hands of an idiot.

"BANG!

Oops, sorry, miss ... your face will grow again, soon ... I hope ..."

treefrog · 2006-04-12 Reply Admin

BiggBru:
treefrog:
I'm trying to imagine what went through this person's head:

"AJAX, huh? It says here AJAX let's me query my database without refreshing the page"

"Since PHP database queries REQUIRE a reload of the entire page, I need a way to query the database"

"Say....PHP has an eval function. I can pass the required PHP code right to the server!"

"Hmm...I'll just use the super-efficient string concatenation features of JavaScript to write my dynamic php code..."

Head? I think you're being a little bit generous here. I think the logic came straight from his fingers to his keyboard. I don't think his head had anything to do with this...

>BiggBru

There definitely seems to be an error between the chair and keyboard.

2006-04-12 Reply Admin

This is proof that some people can't understand the difference between "data" and "code", whilst they can still "program".

2006-04-12 Reply Admin

It's OpenAjaxPhpWikiCode! This guy is waaaaay ahead of bleeding edge.

2006-04-12 Reply Admin

If scary programming like this is the vanguard of Internet 2.0™, then I shudder to think what is in store for Internet 3: This Time, It's Personal (hopefully that will complete the trilogy and no more Internets will be made; I'm getting quite bored with SQLs. Heh. Puns).

Perhaps this will all end with a complete shift to the client side for web solutions and the server will just send a copy of itself, complete with compiler, for execution on the user's machine. I mean, why not? We've got enough bandwidth now.

--
$0.02

2006-04-12 Reply Admin

That's called an applet.

hank miller · 2006-04-12 Reply Admin

Anonymous:

More than one goose are geese. What's more than one moose?

(I'm too stunned by the WTF to reply to that, so I'm replying to a signature instead)

Moose does not have a plural. Native speakers will go out of their way to construct sentences that do not require using moose in a plural form.

felix · 2006-04-13 Reply Admin

Anonymous:
Hmmm... That's exactly what phpPgAdmin does. And phpMyAdmin.

FYI, phpMyAdmin is normally not available to regular users, only to the wesite administrator, and the admin login is normally not the same as the database login. Multi-layered security is a must, especially on the web - this is stressed in every single security handbook I've read.

Then again, why am I arguing with you? The only thing worse than today's WTF is you actually defending it.

2006-04-13 Reply Admin

looks like 'escapeSql' is a client-side function - maybe they are just escaping quotes in there..

2006-04-13 Reply Admin

reminds me of my guys where I worked in London who were passing all the SQL around in the querystring. they came to me ask how to install SSL - and make the site secure... as they thought 'security problems' will go away once its under SSL.

powerlord · 2006-04-13 Reply Admin

bullseye:
fdr:
Hmmm... That's exactly what phpPgAdmin does. And phpMyAdmin. Yes, I advocate that. Do you think that those two programs would be better if they did not allow arbitral sql queries? we can argue on that :)

I don't use PHP, so I admittedly haven't used either product, but they just went down in my perceived value. [:P]

Seriously though, they are probably designed for use by the DB or site administrator, who is less likely (hopefully) to try an injection attack on his own server. In this case, I see your example as different than the Original Post, although I still think it is bad form.

Executing arbitrary queries is precisely what they're designed for. These programs also have a configuration in which they prompt for a username, password, and database name, which they pass to the database. If the database server doesn't like them, no SQLoup for you!

powerlord · 2006-04-13 Reply Admin

powerlord:
which they pass to the database.

which they pass to the RDBMS, that is. I'll never understand why this software has an Edit button if you're not allowed to use it.

Client-side PHP

Leave a comment on “Client-side PHP”