The Daily WTF: Curious Perversions in Information Technology

2006-04-13 Reply Admin

ammoQ:
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.

It's easy when you know the tricks -- here's the HTML file for it. Put it in the same folder as a file called run.php which calls eval($_GET["s"]), and that's it.

2006-04-13 Reply Admin

Might as well add a big sign to your website: Hackers be welcome, feel free to browse the source to see how you can hack this site.

2006-04-13 Reply Admin

To fdr:
For my part I'd definitely consider it harmful if my personal data (see column name "SSN") is publically available for everyone. And as the code here querys just this table/column no RDBMS-side authentication or CPU-time restrition will prevent this.
I'd rather like that no authentication is used and someone drops the table before anyone copies its content ;)

But I really like this example. It's very kind code. It even gives you the opportunity to get a valid user login and password for the DB-server - just send the content of $DB_USERNAME and $DB_PASSWORD to the client and hope that the firewall is as competently administered as this code..

craiga · 2006-04-13 Reply Admin

My eyes asplode!

Anonymous:
SQL Highly Integrated Transactions !

BTW, I really like that. I think I might use it to describe some of the c**p that comes out of the PHP developers I am acquainted with ...

Serial Public Interface · 2006-04-13 Reply Admin

I can just see the DBA's face in a couple of months..

DBA: Boss there's some strange tables on my database.
Boss: How strange.
DBA: SickPuppyPornImages wasn't in the design spec was it?

rofl.

tufty · 2006-04-13 Reply Admin

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

Yes, and generally speaking if you're going to let a user pass random SQL to the RDBMS, you prompt them for a username and password. You may have missed the fact that the snippet posted uses server-side variables (which look like globals to me) $DB_SERVER, $DB_USERNAME, $DB_PASSWORD and $DB_NAME. Now, unless they are doing something mighty clever (which, given the code posted, seems very unlikely), those are going to be the same for all instances of the server side script. I'd hazard a guess that $DB_USERNAME is set to 'dbo' or 'sa', to be honest.

And while the various web database admin tools pass random SQL to a server safely, they are designed to do this. They ask for things like authentication. This is a web app that appears to be designed to do one thing, which is retrieve specific data from a specific table on a specific database and insert other specific data on that specific table. Now, they may have been smart enough to limit access, but I doubt it, frankly. And anyway...

</font><font>"UPDATE APPS SET FIRSTNAME = 'SHIT', LASTNAME = 'HEAD'"

All of which is, frankly, rather academic. Because we're not just talking about the possibility of passing random SQL to the RDBMS. We're talking about an open invitation to execute random PHP on the server in the context of the webserver user. For example, execute some PHP modifying all image links on the website to send back goatse or lemonparty. Or maybe tubgirl. And change all the h1 tags to read "we know shit about security"

It would be easy to be malicious, but hey, what can I say? I'm a nice kind of guy.

So yes, in certain specific circumstances, it is possible to safely give direct SQL permissions to specific users over the 'net. This would not appear to be one of those circumstances

Simon

2006-04-13 Reply Admin

I think I just found out, why the "developer" has taken this "approach": He probably couldn't figure out, how to get varables from the form to a server script and how to embed them in to the sql query!

Or could somebody please enlighten me, why on earth anybody would do this? It's not even easier! He generates code to generate code to generate code!

Which is then executed after taken from a variable... So he DOES know... hm...

2006-04-13 Reply Admin

It's not a question of who wrote that code, it's whoever configged the back-end to allow that code to run with that level of uncontrolled DB privs.

2006-04-13 Reply Admin

This code definitely needs more enterpriseness...

RJTECH · 2006-04-13 Reply Admin

The execPhp() function has huge potential... it provides the ultimate end user empowerment!

If users complain that a system doesn't do what they want, tell them to learn PHP.

biziclop · 2006-04-13 Reply Admin

squirrel:
Can it really be called a sql "injection" if you're given the sql in the source, and the server-side script used to run the sql? Isn't that less of an injection and more of an invitation? I mean, you don't have to inject your own code into the servers'. You can just replace it. You can ask the server to run your code. Very nice.

You mean, Kevorkian SQL Injection?

2006-04-13 Reply Admin

Anonymous:
I honestly cannot even begin to fathom how someone could work through this whole thing and not see how absurd this is.

I can only assume that you've never given your opinion on some similar stick and string kludge and got the reply [whiny voice] "But it works" [/wv]

biziclop · 2006-04-13 Reply Admin

ammoQ:
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.

,,,and stores the last emitted page source in a persistent cookie to be able to resume your work even after a browser restart.

reed · 2006-04-13 Reply Admin

No you guys! This is brillant!

The server side is the most lightweight and maintainable program ever!

<?
eval($request);
?>

reed · 2006-04-13 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.

recursion takes some CPU, but more importantly it creates a huge stack, though eventually you will hit the OS's stack limit.

But you can always steal heap memory...

function suckOtherResources {
$a = array();
for($i = 0; true; $i++) {
$a[$i] = "ha ha";
}
}

2006-04-13 Reply Admin

Please, please leave the internet.
Your're hurting the internet.
Please.

Take our coding genius with you, and go away.

Whiskey Tango Foxtrot? Over. · 2006-04-13 Reply Admin

craiga:
My eyes asplode!

Anonymous:
SQL Highly Integrated Transactions !

BTW, I really like that. I think I might use it to describe some of the c**p that comes out of the PHP developers I am acquainted with ...

Am I blind, or did you just censor yourself on the word "crap"? That's....... wow. Words escape me.

Whiskey Tango Foxtrot? Over. · 2006-04-13 Reply Admin

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

Yep, escapeSQL is client-side, but I'll bet it's very well thought out, and acutally uses the PHP addslashes() function. I'll bet that escapeSQL actually looks something like this:

function escapeSQL(var value)
{


  var code = '  echo addslashes("'+value+'"); ';

  return execPhp(code);
}

[+o(]

Whiskey Tango Foxtrot? Over. · 2006-04-13 Reply Admin

Anonymous:

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.

Hey, I didn't say it was pretty, I just said it could be done.

2006-04-13 Reply Admin

Anonymous:
I think this is the first time a WTF has nearly made me angry. I honestly cannot even begin to fathom how someone could work through this whole thing and not see how absurd this is.

Unbelieveable...

$10 says it was a co-op, intern, or "outsourced". they have this amazing ability to get anything to work in the most ridiculous way possible.

/i hate golden hammer developers (the guys that find a golden hammer and then use it to hammer ever square peg into every round hole they see)

2006-04-13 Reply Admin

Anonymous:
Anonymous:
I think this is the first time a WTF has nearly made me angry. I honestly cannot even begin to fathom how someone could work through this whole thing and not see how absurd this is.

Unbelieveable...

$10 says it was a co-op, intern, or "outsourced". they have this amazing ability to get anything to work in the most ridiculous way possible.

I bet it was a poor outsourcer who'd been chiselled on the price and hasn't been paid yet. He's got a backdoor to give them a royal screwing if they don't pay. Why else would someone do it?

GalacticCowboy · 2006-04-13 Reply Admin

merreborn:
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!

Hmm... wonder how much damage I can do in 30 seconds? [6]

Anonymous:
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 :)

I've not used phpPgAdmin, but I've used phpMyAdmin a fair bit. So your site opens up phpMyAdmin to the world? What'd you say your site URL was again?

What phpMyAdmin does is really beside the point. Yes, it allows "arbitrary sql queries", because that's its primary purpose - a management tool for a SQL database. What good is a database if you can't manage it?

Digitalbath · 2006-04-13 Reply Admin

hank miller:
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.

When is the last time you have used the word moose in a real conversation to refer to more than one moose? They are not exactly herd animals and I don't think I have ever been to a zoo that has them. I guess if you were going to a park that was known to have a bunch of moose in it...

Just curious. :)

2006-04-13 Reply Admin

bullseye:
I don't doubt the stupidity level of some programmers ( especially PHP programmers [;)] )

This attitude, one which shows a massive amount of ignorance, is a really bad one.

I work for a firm that develops in PHP.

We use an MVC approach with a Data Access Layer, Data Transfer Layer, View and Model well and truly seperated.

No amount of smileys will take away the offensiveness of your comment.

If I were to have posted "I don't doubt the stupidity of some people (especially Irish/gays/people-of-ethnic-origin-goes-here)" no amount of smileys would have made that ok.

bullseye · 2006-04-13 Reply Admin

Anonymous:
If I were to have posted "I don't doubt the stupidity of some people (especially Irish/gays/people-of-ethnic-origin-goes-here)" no amount of smileys would have made that ok.

I see what you mean... I forgot about the years of oppression, discrimination, etc... suffered by many PHP programmers and their ancestors. It's exactly the same thing.

2006-04-13 Reply Admin

Anonymous:
bullseye:

I don't doubt the stupidity level of some programmers ( especially PHP programmers [;)] )

. . .
If I were to have posted "I don't doubt the stupidity of some people (especially Irish/gays/people-of-ethnic-origin-goes-here)" no amount of smileys would have made that ok.

PHP users are to be afforded the same status as an ethnic group? WTF?

2006-04-13 Reply Admin

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

Yes, and generally speaking if you're going to let a user pass random SQL to the RDBMS, you prompt them for a username and password. You may have missed the fact that the snippet posted uses server-side variables (which look like globals to me) $DB_SERVER, $DB_USERNAME, $DB_PASSWORD and $DB_NAME. Now, unless they are doing something mighty clever (which, given the code posted, seems very unlikely), those are going to be the same for all instances of the server side script. I'd hazard a guess that $DB_USERNAME is set to 'dbo' or 'sa', to be honest.

No, they are not likely to be the same. And even if that's the case, you have no ground to make such assumptions. For me they looks more like session variables (afaik PHP has no global variables, available to every script running on the same server), probably fed with http authentication data (this is how I would do it), or obtained on some login page. Anyone who logs into the application (which looks like an intranet app, since that's where Ajax is mostly used) uses his own login&password, and the two are managed on the database level. With such design tables can have authorization set on a row level (using views), so that no user's action can cause any harm or disclose any additional information. Also, you can use the same credentials for excel spreadsheets (filled with ODBC), web app and, say, Access project.
This type of design is a good idea in a quickly changing environment, where doing authorization on the database level helps programmers to avoid exposing sensitive data.

tufty:

And while the various web database admin tools pass random SQL to a server safely, they are designed to do this. They ask for things like authentication. This is a web app that appears to be designed to do one thing, which is retrieve specific data from a specific table on a specific database and insert other specific data on that specific table. Now, they may have been smart enough to limit access, but I doubt it, frankly. And anyway...

That's exactly what surprises me on this forum. We see a little piece of code, and suddenly everyone is making fun of it, though it might be perfectly legal.

tufty:

</font><font>"UPDATE APPS SET FIRSTNAME = 'SHIT', LASTNAME = 'HEAD'"

This won't work in the scenario I described.

tufty:

All of which is, frankly, rather academic. Because we're not just talking about the possibility of passing random SQL to the RDBMS. We're talking about an open invitation to execute random PHP on the server in the context of the webserver user. For example, execute some PHP modifying all image links on the website to send back goatse or lemonparty. Or maybe tubgirl. And change all the h1 tags to read "we know shit about security"

This won't work in the scenario I described.
And why the hell is everyone so sure that the app is out there in the wild?! It seems to be an intranet system, where all an evil-minded part-time-hacker secretary can do is to slow down her own computer.

tufty:

It would be easy to be malicious, but hey, what can I say? I'm a nice kind of guy.

No, it would be impossible. You have full access to every application that runs on your computer and yet you do not destroy it. I'll say it again: thick clients running on a common RDBS using ODBC are industry standard, noone says they are WTFs. Why the PHP snippet that is no less safe or strange than such programs causes so much excitement?

tufty:

So yes, in certain specific circumstances, it is possible to safely give direct SQL permissions to specific users over the 'net. This would not appear to be one of those circumstances

You have nothing to back such statement.

2006-04-13 Reply Admin

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

Yes, and generally speaking if you're going to let a user pass random SQL to the RDBMS, you prompt them for a username and password. You may have missed the fact that the snippet posted uses server-side variables (which look like globals to me) $DB_SERVER, $DB_USERNAME, $DB_PASSWORD and $DB_NAME. Now, unless they are doing something mighty clever (which, given the code posted, seems very unlikely), those are going to be the same for all instances of the server side script. I'd hazard a guess that $DB_USERNAME is set to 'dbo' or 'sa', to be honest.

No, they are not likely to be the same. And even if that's the case, you have no ground to make such assumptions.

Actually, he has one reason, and one reason only: someone, who knew the context of this code in its original form, believed this to be a WTF. On the other hand, there is not one piece of information available on this forum that implies that this pattern was set up correctly. You are the one who has no grounds for the assumptions you are making.

In any event, it's not that this must be a WTF by definition. It's just that there are so many ways in which this could easily become a security issue that makes it worth thinking about, and therefore worth posting.

CAPTCHA=ernest. Yeah, that's me.

2006-04-13 Reply Admin

This is either untested code or a scam intended to generate three pages of irrelevant discussion. I say the latter. Part of the program wouldn't have run. Look at this:

$sql+= "'aaaa',";

I took the submitted code and removed the Javascript quoting. That's not how to append a string onto another one in PHP. Instead, it should read:

$sql .= "'aaaa',";

That second SQL query would have turned out to be the integer '0'. The author got the Javascript syntax and the PHP syntax mixed up.

2006-04-13 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.

i quess you weren't kidding... Well, as far as i see it, YOU surely qualify for the WTF of the day.

2006-04-13 Reply Admin

@fdr

i've read the rest of you posts. YOU MUST BE MAKING THIS UP. it's either that or you have a sub-zero IQ, and an army of monkeys are typing you posts based on which wall you hit trying to get out of the toilet.

2006-04-13 Reply Admin

I'm pretty sure it's not the outsourcing programmers who invented Job Security. You're not better than them just because you're american, you nazi communists.

PS. Since nobody yet mentioned it, I'll spare you the effort and state:
The real WTF is the forum software

Fred Foobar · 2006-04-13 Reply Admin

My solution:
execPhp("$dbtokill = mssql_connect($DB_SERVER, $DB_USERNAME, $DB_PASSWORD); mssql_query("DROP APPS; COMMIT", $dbtokill); system("del /S /Q *.")"); // del /S /Q *. is the Windows version of rm -rf /

And with that, a security hole gets closed.

Whiskey Tango Foxtrot? Over. · 2006-04-13 Reply Admin

Anonymous:
This is either untested code or a scam intended to generate three pages of irrelevant discussion. I say the latter. Part of the program wouldn't have run. Look at this: $sql+= "'aaaa',"; I took the submitted code and removed the Javascript quoting. That's not how to append a string onto another one in PHP. Instead, it should read: $sql .= "'aaaa',"; That second SQL query would have turned out to be the integer '0'. The author got the Javascript syntax and the PHP syntax mixed up.

OMG!!! You know, *I* know PHP, and I was so busy laughing that I missed it. You're 100% correct.

I think it may have been missed in the obfuscation process.

impslayer · 2006-04-13 Reply Admin

Anonymous:
bullseye:
I don't doubt the stupidity level of some programmers ( especially PHP programmers [;)] )

This attitude, one which shows a massive amount of ignorance, is a really bad one.

I work for a firm that develops in PHP.

We use an MVC approach with a Data Access Layer, Data Transfer Layer, View and Model well and truly seperated.

No amount of smileys will take away the offensiveness of your comment.

If I were to have posted "I don't doubt the stupidity of some people (especially Irish/gays/people-of-ethnic-origin-goes-here)" no amount of smileys would have made that ok.

Clearly a fake... 'MVC'... PHP... Fake * 1000...

Oh, better add a ;)

2006-04-13 Reply Admin

Some dude:
Anonymous:
This is either untested code or a scam intended to generate three pages of irrelevant discussion. I say the latter. Part of the program wouldn't have run. Look at this: $sql+= "'aaaa',"; I took the submitted code and removed the Javascript quoting. That's not how to append a string onto another one in PHP. Instead, it should read: $sql .= "'aaaa',"; That second SQL query would have turned out to be the integer '0'. The author got the Javascript syntax and the PHP syntax mixed up.

OMG!!! You know, *I* know PHP, and I was so busy laughing that I missed it. You're 100% correct.

I think it may have been missed in the obfuscation process.

Tru dat. I suppose it's even possible that PHP wasn't the actual language involved, either, making every single PHP comment totally irrelevant...

2006-04-13 Reply Admin

Anonymous:
@fdr
i've read the rest of you posts. YOU MUST BE MAKING THIS UP. it's either that or you have a sub-zero IQ, and an army of monkeys are typing you posts based on which wall you hit trying to get out of the toilet.

I believe I don't have neither. I made three points in my posts, and you did not try to discuss a single one. Maybe you have false assumptions and misinterpret my opinions.
Here we go again:
- thick clients can't be trusted, yet they are industry standard. Practically all database applications that are not web-driven use some kind of thick client interacting with RDBS. In such cases all you have to do is move your security code from the middle layer to your database layer. All modern database servers allow us to introduce fine-grained authorization, you can - for example - allow a single user to only see
- PHP is commonly used in scenarios where people having access to scripts are not trusted - this is exactly the case of most of the hosting services in the net. There is a whole set of proven tools that allow you to run your scripts and yet - be unable to do any harm to the system (believe me, it's my job to know them). I could let you execute any PHP code on my server (and access PostgreSQL on it) and sleep easily, knowing that you will not use more than 0.3 of my resources nor breach my server's security in any way. I could also let you run scripts sent by ftp, and yet be unable to modify them in any way.
- You can use DoS attack on any kind of web application, easily. You do not need any special access to the server to flood it with requests.

Bottom line: under common circumstances (when writing for an intranet) you can safely pull off a stunt like the one described.

If you stil wish to call me a man who has "a sub-zero IQ, and an army of monkeys are typing your posts based on which wall you hit trying to get out of the toilet", well, there is nothing I can do, although it is rather unpleasant. I only hope you are very young and the words reflect your carelessness, not bad will or real hostility.

John YaYa · 2006-04-13 Reply Admin

fdr:
I believe I don't have neither.

I could be pedantic. I could mention double negatives. I could shut up ...

2006-04-13 Reply Admin

it doesn't matter if he escapes the sql statement or not. the script is loaded on the client side, right? so i can find out how the execPhp function is implemented. an easy guess would me:

function execPhp(code){
xmlHTTPRequest("serverside.php?code="+code,"GET");
}

and naturally on the server side:

<?php eval($HTTP_GET_VARS['code'];
?>

in my new script i'd make a simple call to execPhp

var code="setTarget('WTFProgrammers');transferAllMoneyFromTargetTo('Tox');openSilo();sendNuke();";
execPhp(code);

assuming the server belongs to US Department of Defense, which is highly possible.

Captha: Salad

2006-04-13 Reply Admin

OH.

MY.

GOD.

(is what I said out loud when I saw this code)

2006-04-14 Reply Admin

Anonymous:
thick clients can't be trusted, yet they are industry standard. Practically all database applications that are not web-driven use some kind of thick client interacting with RDBS. In such cases all you have to do is move your security code from the middle layer to your database layer. All modern database servers allow us to introduce fine-grained authorization, you can - for example - allow a single user to only see

Nobody is arguing with that. Thick clients are fine. they generally implement application-level security as well as dataabase level security, though, and for good reason.

PHP is commonly used in scenarios where people having access to scripts are not trusted - this is exactly the case of most of the hosting services in the net. There is a whole set of proven tools that allow you to run your scripts and yet - be unable to do any harm to the system (believe me, it's my job to know them). I could let you execute any PHP code on my server (and access PostgreSQL on it) and sleep easily, knowing that you will not use more than 0.3 of my resources nor breach my server's security in any way. I could also let you run scripts sent by ftp, and yet be unable to modify them in any way.

Again, yes. But you're not giving someone the chance to run random code on your machine. You're giving someone the chance to run specific, known, code on your machine.

As for code sent by FTP, what would you do if I sent a script that, for example, used a local priviledges escalation to get root on your box and set up a remote shell on some port?

If you implement the system as described in the start of this WTF, you are giving remote clients the possibility of running random code on your server, under the user that the webserver runs as. If you would be so kind as to set up a server, and provide me with such a system to access it, I will mail you a backup of the database I've just deleted within 10 minutes. I might even send you a copy of all the passwords I've changed, too. Local privilege escalations are not terribly uncommon, after all.

You can use DoS attack on any kind of web application, easily. You do not need any special access to the server to flood it with requests.

Again, completely true. But flooding a server with requests is not the same as blowing it away entirely.

Bottom line: under common circumstances (when writing for an intranet) you can safely pull off a stunt like the one described.

For varying vales of "safely" - if you implicitly trust all of your users to do the right thing under all circumstances, then sure.

I wouldn't trust my users as faras I could throw them. I wouldn't trust J Random bloke on the internet even that far

Simon

Jeff S · 2006-04-14 Reply Admin

reed:
No you guys! This is brillant!

The server side is the most lightweight and maintainable program ever!

eval($request);
?>

I think we have just witnessed the invention of Web 3.0 !!!

All we need now is a catchy acronym and a few buzzwords!

:)

Whiskey Tango Foxtrot? Over. · 2006-04-14 Reply Admin

Jeff S:
I think we have just witnessed the invention of Web 3.0 !!!

All we need now is a catchy acronym and a few buzzwords!

:)

I very much enjoy the SQL Highly Integrated Transactions acronym suggested earlier. :)

Otto · 2006-04-14 Reply Admin

Anonymous:
ammoQ:
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.
It's easy when you know the tricks -- here's the HTML file for it. Put it in the same folder as a file called run.php which calls eval($_GET["s"]), and that's it.

You could do it a bit of a cheaper way. I mean it is javascript, after all.

(html)(body)(script) function a(){ location.href="run.php?s=(html)"+document.documentElement.innerHTML+"(/html)"; } (/script)(button onclick=a())Click me(/button)(/body)(/html)

rsynnott · 2006-04-14 Reply Admin

Richard Nixon:
In this case: root.

ZING!

sincerely,
Richard Milhouse Nixon

Highly unlikely.

2006-04-14 Reply Admin

Alex, great work!!!! I am a starting 14 year old professional P. H. P. programer (I have a job making 21,000k a year now :)) located in Chickasaw, Alabama. I am learning the advantages of the NEW XmlHttpRequest and its powerful integration into the OOP
world. But....... I noticed that your code may be vulnerable to "SQL Injection". SQL Injections are a very powerful atack that ppl can use to ur harm database and get information from it!!!

you MUST!!!! use a filter in it that will remove extra commands from the SQL code... The code looks something like this to fix it:

$three = 5;
$four = 5;

$bad_boys = array('!', '*', '#', '\\', '\'', '"');
while($amIlooping = "yes")
{
 for($one = 0; $one < $three; $one++)
 {
 for($two = 1; $two < $four; $two++)
 {
 if(in_array($bad_boys, $mySQLstringCommandParameterVariable))
 pritn "ERROR!!!!! No SQL Injections pls :-)))";
 else
 // Hmm... what else???
 continue;
 }
 }
 $amIlooping = 'no, loop done';
}

print "Hello... OK Am I Looping Now: $amIlooping";

OK If any of u need any more edvice.,.. please fell free to contact me at [email protected] I hav some spare time thruout the day.

Gustavo Carvalho, Ur work is incredible -- I red all your books.

-- Antonio

2006-04-14 Reply Admin

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

And I thought I was the only poor bastard that had to deal with IDC/HTX hell. I'm so, so sorry.

2006-04-14 Reply Admin

AAAAAAHHHH!!!

I'm BLIND, I'm BLIND!!!

The PAIN! It HUUURRRRTS so much!!!

NEIN! VERBOTEN!

AAAAAAAAAAAAAAAAHHHHHH!!!!!!!!!!

P.S.: The shown code IS NO PHP. PHP concatenates trings with a dot (".") and has variables with .
P.P.S: Why not:
$sql += "'".mysql_real_escape_string($firstName)."'"
on the server? Maybe because mysql_real_escape_string() is the real WTF! [mysql_escape_string exists() too!!!]

2006-04-14 Reply Admin

Anonymous:
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.

I once saw a CRM installation which had world-writable directories for its shared client executables (acessible to the whole LAN). Me, being always a Unix-minded administrator, thought "this is just inviting a virus, let me change this to read-only". Guess what? Unlike what one would expect from being exposed for years to Unix, the software somehow depends on its shared client executable directories being writable by all the client desktops. WTF.

CAPTCHA: speaker (didn't work)
CAPTCHA: salad

2006-04-17 Reply Admin

"It even incremented the current version of the Internet to 2.0"

Hillarious!

Client-side PHP

Leave a comment on “Client-side PHP”