×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

305 comments

what rush (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#8983870)

don't see no rush

JIM CROW 2004 (-1, Troll)

Anonymous Coward | more than 9 years ago | (#8984139)

Hah, the moderators think [slashdot.org] that The State Assembly of Virginia [metafilter.com] is a bunch of hateful trolls!

HOUSE BILL NO. 751 AMENDMENT IN THE NATURE OF A SUBSTITUTE (Proposed by the Senate Committee for Courts of Justice on March 8, 2004) (Patron Prior to Substitute--Delegate R. G. Marshall) A BILL to amend the Code of Virginia by adding a section numbered 20-45.3, relating to the Affirmation of Marriage Act for the Commonwealth of Virginia.

Be it enacted by the General Assembly of Virginia:

1. 20-45.3 [state.va.us] . Civil unions between persons of same sex.

A civil union, partnership contract or other arrangement between persons of the same sex purporting to bestow the privileges or obligations of marriage is prohibited. Any such civil union, partnership contract or other arrangement entered into by persons of the same sex in another state or jurisdiction shall be void in all respects in Virginia and any contractual rights created thereby shall be void and unenforceable.>

Don't they teach these stupid fucking state senators "bill writing 101" before they turn them lose on the legislature? This is worded so it voids ANY CONTRACT between any two people of the same sex, not just homosexuals looking for a marriage license. I guess it you're so ignorant that you're trying to enshrine hatespeach in the state's laws, little things like logic are beyond you.

LoL (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#8983871)

interweb security

bam (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#8983874)

bam

fp (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#8983876)

fp!

Where'd the fake XBOX 2 article go? (-1, Offtopic)

strictnein (318940) | more than 9 years ago | (#8983880)

Come on CMDRTACO, let everyone see the article you almost posted.

The XBOX-2 with three 3.5GHz PowerPC processors?

Yeah... that's real.

Re:Where'd the fake XBOX 2 article go? (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#8983917)

You mean this [slashdot.org] ?

A bad workman blames his tools (5, Insightful)

dorward (129628) | more than 9 years ago | (#8983898)

Looks more like "Scripts people write using PHP and SQL without understanding security issues are being proven more weak every day." to me.

Re:A bad workman blames his tools (3, Insightful)

sv25 (773540) | more than 9 years ago | (#8983955)

"Scripts people write using PHP and SQL without understanding security issues are being proven more weak every day."

That is stating the obvious, but none the less - it must be said. Nealry every language/backend is a potential threat when developers who don't have an understanding or awareness of security start coding.

Re:A bad workman blames his tools (5, Insightful)

quigonn (80360) | more than 9 years ago | (#8983985)

Well, sometimes you can simply blame the tools. Or would you blame the workman who cuts off his arm with the buzz saw's totally unprotected blade?

The same is valid for programming languages, with some it's just easier to shoot yourself in the foot when you make a mistake. One example are buffer overflows and C: it's so easy to mistakenly write code that produces one, while in other languages like Ada or Perl it's virtually impossible.

The same goes for PHP and SQL, which is shown everyday on the usual mailing lists like Bugtraq or full-disclosure.

Re:A bad workman blames his tools (4, Informative)

ArsenneLupin (766289) | more than 9 years ago | (#8984047)

Well, sometimes you can simply blame the tools. Or would you blame the workman who cuts off his arm with the buzz saw's totally unprotected blade?

Yes, of course. A good workman would never willingly use such a dangerous tool!

That being said, as far as SQL security goes, PHP fares far better than its competitor, ASP.

Indeed, by default, PHP comes with gpc_magic_quotes enabled, which prevents the more obvious SQL injection attacks. Of course, nothing is 100% foolproof, but we're nowhere near the sieve that ASP+Sequel Sewer is.

Re:A bad workman blames his tools (1)

grub (11606) | more than 9 years ago | (#8984078)


Or would you blame the workman who cuts off his arm with the buzz saw's totally unprotected blade?

I'd blame natural selection. What if his arm had titanium bones and kevlar skin which broke the blade? He'd pass on those mighty arm genes to his children and so forth. In a few generations we would have an army of super-carpenters, unafraid of smashing thumbnails or severing of limbs.

What a wonderful world it would be.

Re:A bad workman blames his tools (2, Insightful)

dorward (129628) | more than 9 years ago | (#8984088)

Would you blame the workman who cuts off his arm with the buzz saw's totally unprotected blade?

I would if he ignored the instructions telling him to protect himself before using it after hearing the horror stories from the large collection of one armed men (watch out Dr Richard Kimble) in the building!

Re: cutting off an arm (5, Interesting)

sczimme (603413) | more than 9 years ago | (#8984208)


Or would you blame the workman who cuts off his arm with the buzz saw's totally unprotected blade?

Yes, I would: he was obviously doing something with the saw that was inappropriate; what saw-oriented task [when done correctly] involves waving it at one's own arm?* The fact that the blade was unprotected is irrelevant since he should have known it was unprotected and therefore dangerous. All tools can be used stupidly, and oddly enough the results really can be the fault of the operator. It is also possible for fault to lie in more than one area.

Yes, I know the traditional definition of 'hacking' includes making $ITEM do something it was not intended to do, but there are limits.

* I'm guessing that 'buzz-saw' == 'circular saw'.

Re:A bad workman blames his tools (1)

Neil Watson (60859) | more than 9 years ago | (#8984318)

If PHP installs by default with register_globals = off and developers turn them on can we really blame PHP?

Re:A bad workman blames his tools (1)

chegosaurus (98703) | more than 9 years ago | (#8984052)

Absolutely. It's not PHP's fault it has a lot of clueless and/or lazy users.

And it isn't PERL's fault that people use it to write utterly incomprehensible code. Or is it...?

Crappy Programmers = = Crappy Code... (1)

Saeed al-Sahaf (665390) | more than 9 years ago | (#8984503)

Absolutely. It's not PHP's fault it has a lot of clueless and/or lazy users.So true. The same argument can be used in relation to crappy Visual Basic apps: Crappy / ignorant / lazy programmers build bad VB code. This formula can be applied to any language (C... let me at those pointers...).

Blame should be shared between coder and language (1, Informative)

Sanity (1431) | more than 9 years ago | (#8984075)

Languages which encourage the mixing of code and data make it extremely easy to write insecure code, and no programmer is immune to bugs. Yes, the coder is to blame, but so is the language.

SQL is probably the most widespread example of this, closely followed by regular expressions in Perl. I am often amazed that more people aren't working towards programatic ways to express SQL queries and/or regular expressions (attempts exist for both, but rarely make much progress).

Re:Blame should be shared between coder and langua (2, Insightful)

NineNine (235196) | more than 9 years ago | (#8984124)

I am often amazed that more people aren't working towards programatic ways to express SQL queries and/or regular expressions

They're called stored procedures. They've existed for at least 20 years.

Re:Blame should be shared between coder and langua (1)

Sanity (1431) | more than 9 years ago | (#8984251)

They're called stored procedures. They've existed for at least 20 years.
No they aren't. Stored procedures still require SQL code to be embedded in the client code - and therefore still requires the mixing of code and data.

Re:Blame should be shared between coder and langua (1)

NineNine (235196) | more than 9 years ago | (#8984439)

Stored procedures still require SQL code to be embedded in the client code - and therefore still requires the mixing of code and data.


Have you ever used a stored procedure? You call the name of it, and that's it. You give the web server permission to call the stored procs.

ha (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#8983899)

ha!

Here come the jokes... (0, Funny)

caluml (551744) | more than 9 years ago | (#8983905)

When the site falls over, cue the jokes about PHP and MySQL, from the battle-hardened Perl and Postgres veterans.

Re:Here come the jokes... (2, Funny)

tcopeland (32225) | more than 9 years ago | (#8983941)

When/if it does, here's the first challenge:
PHP GAUNTLET CHALLENGE 1
Challenge : Create Article Submition, Display, and Approval System
Submitted by : April 10th, 2004 (Date may be changed, number of submitions pending)
Requirements: See Below

Welcome to the first of many PHP GAUNTLET CHALLEGES. The concept behind these challenges is to have a user create an article submition, display, and approval system. This system has to utilize an SQL database, have email functions, and be portable. When I say "portable" I mean that it should be easily transferable from different template desigins. A good example of an article submition system is the one at Slashdot.org.

Specific Requirements:

1. The PHP scripts must be universally executable, meaning, they should be able to be moved to any directory (structure intact) and work properly.
2. The PHP scripts must have a include file called "connect.php", in this file, you should be able to specify the database server, passoword, and userid. An Example of this can be seen below :

$dbuser = '';
$dbpass = '';
$dbhost = '';
$dbdatabase = '';
$db = mysql_connect("$dbhost");
mysql_select_db("$dbdat abase",$db);

3. The PHP script must be able to be included into an area of a page, allowing for ease of portability.
4. Register Globals will be on.
5. You will be given 1 database, and unlimited tables.
6. The PHP script must have an article display, submition, and approval system.
7. The submition system must work in conjunction with the approval system. Once something is submitted, it should be able to be emailed to the site webmaster, and then approved by a URL in the email.

I know that most of this seems complicated, and very specific. However, I am attempting to make everything as such to give everyone a fair chance. If you wish to add any features, please do so. I will hopefully be submitting an example script for everyone to look off of soon.

first? (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#8983908)

am I first?

No. (5, Insightful)

mfh (56) | more than 9 years ago | (#8983916)

PHP and MySQL are not weak; faux programmers are weak. Purification of incoming data is essential, and often ignored by novice script-writers, and that's the problem. SQL injections are common among novice coders, and they can slip past even competent coders, but a strict design engine for passing SQL vars using $_REQUEST, and turning off register_globals, will result in better results.

Essentially, the problem is with those making insecure scripts, not the whole PHP and SQL system.

Re:No. (1)

Shaklee39 (694496) | more than 9 years ago | (#8983978)

Why would you use $_REQUEST? That means you don't know if your variables are coming from POST or GET, so you decide to use a catchall to make it easier on yourself.

Re:No. (0)

Anonymous Coward | more than 9 years ago | (#8984104)

It's not that you don't know, it's that you don't CARE. Either way, you're dealing with user input that should not be trusted, and should be processed appropriately.

Re:No. Mod Parent Up (1, Insightful)

Anonymous Coward | more than 9 years ago | (#8984178)

This is exactly right. GET, POST, or COOKIE data? It's all equally dangerous. Anybody have firefox and the web developer extension? Try displaying form details and change some post inputs. Or just use javascript in the url to alter the form at will.

General purpose ... (1)

zonix (592337) | more than 9 years ago | (#8984222)

Why would you use $_REQUEST?

If you need general purpose functions etc., I'd imagine it could be beneficial to have them just use $_REQUEST.

You can then let your particular frontend deal with where the values came from (get/post), and sanitize the data there. Afterwards the values will be available via $_REQUEST.

Of course you could also pass the sanitized data to the functions as parameters, with no need for $_REQUEST. As always, YMMV.

z

Re:No. (2, Insightful)

Richthofen80 (412488) | more than 9 years ago | (#8984031)

Seriously, I agree. Object oriented programming should prevent this, too. Develop object models then take the request variables and insert them into the objects before inserting them into SQL. Constructors should parse special characters that could lead to injection. Also, it is easier to implement business rules using OOP. Seriously, even interpreted languages do OO now, its time we all used them.

Re:No. (5, Insightful)

leandrod (17766) | more than 9 years ago | (#8984054)

>
Object oriented programming should prevent this

Security comes from simplicity, not complexity. And security should start at the DBMS level, not be left to applications.

Bind variables (4, Insightful)

ArsenneLupin (766289) | more than 9 years ago | (#8984128)

Actually, bind variables help much more than object oriented programming.

Writing al=execute_query("SELECT access_level FROM user WHERE user=? AND password=?", user, password) is naturally so much more secure than al=execute_query("SELECT access_level FROM user WHERE user='"+user+"' AND password='"+password+"'");

Nowadays, most database products worth their salt (Oracle, Postgresql, and even my Mysql!) support bind variables. And even if you have an old version of Mysql (which doesn't support them), Perl DBI and Php PEAR can emulate bind variables for you.

Of course, if you're stuck with ASP and Sequel Sewer, you're somewhat out of luck, and need to do the proper quote escaping yourself.

I disagree (1)

beldraen (94534) | more than 9 years ago | (#8984529)

Security does not belong in the database because it removes context of action. The correct level of security is to place it in between the database and the interface through a well-defined, simple interface that keeps the context of the action secured from the interface. By treating each element in the table as an object, the object is loaded with the security of the entity at the time of instantiation; thus, even if the interface is highjacked and the object is commanded to alter information, the user does not have permission to alter it even if under other scenarios the user might have the right to do so. In other words, a database can never know why something is being altered, and an interface can never been trusted to fully comply with security.

What about Windows? (0, Troll)

goldspider (445116) | more than 9 years ago | (#8984070)

If you're going to make that argument (which, BTW, I think is accurate), then you'd better be prepared to say that Windows isn't inherantly insecure as well. You can't blame the platform for the sloppy coding of others who write apps for it, under ANY circumstance.

Re:What about Windows? (-1, Troll)

Anonymous Coward | more than 9 years ago | (#8984147)

uh wtf you talking about?

"If you're going to make that argument (which, BTW, I think is accurate), then you'd better be prepared to say that Windows isn't inherantly insecure as well."

windows comes insecure out of the box, where as php and mysql does not. Even a 13 year old kiddie should know that.

Walked Right Into That (2, Insightful)

mfh (56) | more than 9 years ago | (#8984431)

> If you're going to make that argument (which, BTW, I think is accurate), then you'd better be prepared to say that Windows isn't inherantly insecure as well.

No, not really. If you're arguing that Windows isn't insecure (which is slightly off-topic) I would have to disagree. The security flaws in Windows are due to over-complication of a proprietary system, leading to gaping holes that keep springing up on a systemic level; these holes are compounded by closed source, financial rationale (lacking in motivation for corrections) and corporate belligerence on a systemic level. Fewer eyes have seen Windows source code than PHP source code, and those that have are swimming from confusing and conflicting design models.

Windows is insecure because the people involved are xenophobic. Plus PHP isn't an operating system, so we're really talking about penguins, apples and windows.

Re:No. (1)

Sanity (1431) | more than 9 years ago | (#8984196)

PHP and MySQL are not weak; faux programmers are weak.
"Nuclear weapons are not dangerous, people with nuckear weapons are dangerous".

Regardless of where the ultimate blame lies, the simple reality is that languages which encouraging the mixing of data and code encourage security-threatening bugs. SQL is a nasty example of this, Perl regular expressions are another.

Yes (0)

Anonymous Coward | more than 9 years ago | (#8984248)

Purification of incoming data is essential

Then why doesn't the language do it by default?

If you need the unfiltered data, you should be forced to jump though at least one hoop to get it.

Take RXML [caudium.net] for example. By default, all user-supplied data is encoded, unless you explicitly say that you want the raw format. That way, novice script writers don't get bitten by it.

Re:Yes (0)

Anonymous Coward | more than 9 years ago | (#8984381)

Well that's basically what register_globals does, and PHP is constantly insulted for that feature. I agree with the insults too; register_globals was a cop-out and should never have been the default setting. The ends do not justify the means.

As for purifying the content... can't be done, of course. Any content could be dangerous, depending on how you write your program.

Re:Yes (0)

Anonymous Coward | more than 9 years ago | (#8984424)

Erm, I meant magic_quotes_gpc, not register_globals. Doh!

Hoppity Hop (3, Informative)

Tablizer (95088) | more than 9 years ago | (#8984350)

and turning off register_globals, will result in better results.

One of the problems is that PHP has kept changing the way it handles session variables such that if you move your site you may encounter problems (it takes some sites a while to upgrade their PHP interpreter). One solution is to make your own set of session var functions (scalar only) to wrap the changes or per-site differences, or simply live with register_globals on.

Maybe in a few years it will settle down, but the recent changes have gummed things up for the near future. Every language has had some stupid progressions, and session handling is high on PHP's Stupid List.

Agreed (1)

Xformer (595973) | more than 9 years ago | (#8984359)

Liberal use of addslashes() +
Surrounding data from clients with quotes in SQL =
SQL injections? Where?

Re:No. (4, Informative)

Anonymous Coward | more than 9 years ago | (#8984484)

I regard myself as a fairly competent PHP programmer, and while I wouldn't be surprised if there are security holes in some of the stuff I've written, I've made every effort to stop them from happening.

I've got a couple of rules I try to abide by - can anyone confirm if they're good programming practice? If they are, then they might prove useful to other people. :-)
  • Always check user input as much as is possible. Probably at least two-thirds of my programming is input data verification.
  • Always escape text which is going into an SQL query, or do an (integer )$number if it's supposed to be an integer. Do this in a very obvious place (eg when setting the $query string itself) so you don't forget. SQL injections are horrid. Test any functions which generate SQL until you're absolutely sure they aren't doing the wrong thing.
  • Use htmlspecialchars() on any text that's being output, to stop users putting rogue HTML, Javascript or anything into the output - even if it'll only end up in an error message or similar.
  • Put database usernames, passwords, pathnames and other similarly important but site-specific data in a define(), where once set it cannot be redefined.
  • Never include() or require() something that isn't a hard-coded string. Use readfile() or fpassthru() or similar if you need to output an HTML template or whatever.
  • Be hugely careful with any file operations. Don't use any user-supplied filenames, etc, unless they're thoroughly checked.
  • Initialise variables, and forcibly set the type of incoming data with an (integer ), (string ) or whatever.
  • Always use $_GET, $_POST etc to get submitted variables and not register_globals, and put anything that's not dealing with getting such data into a function - page_blah( (integer )$_GET['id'], text_unescape( $_GET['moo'] ) ); and so on, in a place neatly out of the scope of any register_globals crap.
  • Never rely on automatic escaping of input variables - I've got a bunch of functions for automatically unescaping arrays and strings which have been mangled by the magic_quotes_gpc rubbish. I'd switch the feature off, but hosts often have it switched on - and my functions check if it is and respond accordingly.
  • Be paranoid. Always assume the user is out to get you. If there's a function which does something restricted but is called by an apparently safe function, double-check the user's credentials.

Re:No. (4, Informative)

Lumpy (12016) | more than 9 years ago | (#8984505)

not only purification but treat all incoming data as hostile.

every thing that comes from the user needs to be scrubbed, bleached, hammered and then finally used when you know it is 100% safe. and it must be used in a safe manner.

what blows my mind is those that use the DB column name in a webform to be passed.. Oh nice. select from that drop down item_number and simply change it to start playing corrupt the database games.

Nothing that is ever given to the user, or recieved from the user should be trusted... EVER. that is the first rule and needs to be pounded into everyone in every book about any programming language for the first 5 chapters.

start there and you will heve very little security issues.

Ease of introduction (5, Insightful)

holzp (87423) | more than 9 years ago | (#8983920)

I think a lot of the blame for this can be traced to the ease of getting started with PHP/MySQL. Result: more people learning how to program with php will of course result in less thought about security. Add the ability to have input arguments via the http request be automagically available to the running code shares a lot of the blame too. Put them togeather and thats a disaster.

Re:Ease of introduction (2, Insightful)

TekZen (611640) | more than 9 years ago | (#8984053)

Good point.
PHP/MySQL will be considered secure once XAML and Avalon [ximian.com] are released to the world. That will be the new "insecure platform" on slashdot. Not be cause PHP is inherently insecure now and XAML and Avalon will be more insecure, but rather because PHP is the easiest entry into programming and XAML will lower the bar.
-Jackson [jaxn.org]

Re:Ease of introduction (1)

johnkoer (163434) | more than 9 years ago | (#8984164)

I have to agree with you on this. I have run into a few systems that were running ASP and a SQL based database in the background that had absolutely no user input validation. I put one on my machine and was able to drop tables and hack my way in in about 10-15 minutes. This system was running at version 2.1 and noone had caught this up until that point. I reported it to the developers, but they didn't seem to keen on actually fixing the problem. Then again if you call the company you realize the VP is the one who was walking you through their phone system.

Should I submit this one? (5, Funny)

blcamp (211756) | more than 9 years ago | (#8983951)

This one is pretty secure...

<?php

// Try to break into this script!
echo "Hello World!";

?>

Re:Should I submit this one? (0, Redundant)

Enrico Pulatzo (536675) | more than 9 years ago | (#8984094)

I bet you spent an extra amount of time rechecking syntax before posting, just to keep yourself free of typo-nazis, didn't you?

Maybe that's just what I would do...

Re:Should I submit this one? (1)

megarich (773968) | more than 9 years ago | (#8984311)

Haha. With all the security flaws going on I've been joking around with my friends saying that the "Hello World" program can cause a denial of service attack..

Re:Should I submit this one? (4, Funny)

horza (87255) | more than 9 years ago | (#8984409)

You sound like a security expert. I'm told one of my scripts might be insecure, do you think you could tighten up the following:

<a href="$PHP_SELF?command=date">Click here to see the date</a>
<?php // Try to break into this script!
if ($command) echo system($command);
?>

Thanks,

Phillip.

Re:Should I submit this one? (1)

Phidoux (705500) | more than 9 years ago | (#8984530)

Please supply a flow diagram so we can understand what your script does!

magic_quotes (5, Funny)

ftzdomino (555670) | more than 9 years ago | (#8983970)

You could also enable magic_quotes in your php.ini. However, if you\'re too dumb to know the basics of sql, chances are your program won\'t work quite right.

Re:magic_quotes (1)

TravisWatkins (746905) | more than 9 years ago | (#8984163)

You could, but then you piss off all the real programmers on the server who use addslashes() when they need to. ; SELECT * FROM users WHERE id = 1

Re:magic_quotes (1)

solidox (650158) | more than 9 years ago | (#8984210)

providing you addslashes before entering and stripslashes after reading from db then it'll be fine whether it's on or off.

Re:magic_quotes (1)

TravisWatkins (746905) | more than 9 years ago | (#8984276)

Hmm, seems it does now. That was a big problem last time I had to deal with it. I guess enough people complained.

Re:magic_quotes (3, Informative)

ArsenneLupin (766289) | more than 9 years ago | (#8984319)

You could, but then you piss off all the real programmers on the server who use addslashes() when they need to

That's why you can enable/disable this setting on a per virtual host or per directory base.

Leave it enabled from the numbnuts who come straight from the Windows world and can't be bothered about security, and disable it for the more experienced programmers.

<Directory "/home/site/numbnut">
php_flag magic_quotes_gpc on
</Directory>

<Directory "/home/site/leet_penguin_master">
php_flag magic_quotes_gpc off
</Directory>

Re:magic_quotes (2, Informative)

ArsenneLupin (766289) | more than 9 years ago | (#8984214)

gpc_magic_quotes is intended to protect the novice, non-security aware user. Of course, it will garble the data, but at least it protects the site from being hacked.

Once our novice gets more knowledgeable, he can convince his admin to remove gpc_magic_quotes setting from his VirtualHost, and use addslashes [php.net] , instead, which allows finer grained operation.

That way, Peter O'Neill can register with his true name in his Php app.

My site is solid..... (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#8983984)

I use PHP and mySQL and I am unhackable.
My site [slashdot.org] has been attacked but never successfully hacked. PHP is a very easy language and I refuse to switch to something like java. Its not neccessary. I worked really hard on my site and noone will tell me different.

I can't take a security sight seriously that... (5, Funny)

bbzzdd (769894) | more than 9 years ago | (#8984003)

uses MS Comic font for their articles. Sorry.

Re:I can't take a security sight seriously that... (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#8984115)

that Mrs Meinel... never heard of her?

Re:I can't take a security sight seriously that... (3, Interesting)

enrico_suave (179651) | more than 9 years ago | (#8984140)

or even a security site =) but I agree, totally.

and to boot are they running php as a CGI instead of a module?

*shrug*

e.

Re:I can't take a security sight seriously that... (1)

bbzzdd (769894) | more than 9 years ago | (#8984198)

Yeah I caught the spelling mistake after I hit post, oops :)

Re:I can't take a security sight seriously that... (5, Funny)

daeley (126313) | more than 9 years ago | (#8984185)

Never mind that, they're using a <font> tag to achieve it! The horror! ;)

Re:I can't take a security sight seriously that... (0)

Anonymous Coward | more than 9 years ago | (#8984380)

I quite agree. This site is laughable at best. It has dead links and spelling errors, and not much real content.

I was hoping for a walkthrough of dos and don'ts in PHP/MySQL, but there's only a small introductory PHP text -- as far as I could find, before the awful design made me leave the site.

Then there's the empty forum and the not-so-well-thought-out monthly challenge. And the site navigation made me dizzy.

Why bother?

PHP is as secure as you make it (4, Insightful)

kyndig (579355) | more than 9 years ago | (#8984050)

Your scripts are only as secured as you make them. What this "UBERHACK" website is simply doing is sending a flock of young script junkies out to locate sites which have not implemented a good code structure.

PHP documentation clearly states the pitfalls of using variables in a global scope. It is for this reason that PHP changed its GLOBAL array structure to read $_POST and $_GET methods, as well as default setting register_globals to off.

I find it a poor use of a developers time to attempt to see whose site they can deface. It is imoral and shows a lack of respect for those whom put countless hours into their site development.

I would challenge "UBERHACKER" to spend more time developing their website which is showing to be in poor syntatical use of HTML, slow loading and poor in URL design. Why run a php scritp in a /cgi-bin/ do you feel more secure by doing so? The ScriptAlias which you most probably have set for this directory will in no way prevent malicious intent from remote connections if your php is not properly configured for base_directories, register_globals, and safe_mode.

http://uberhacker.com/cgi-bin/index.php?page=fla b
Pick up any book on programming and learn proper developmental tactics ( Throw / Catch ) before promoting the attack of others because your 'Uber' site thinks it can't be Hax0r3d.

End Rant.

Re:PHP is as secure as you make it (-1, Troll)

Anonymous Coward | more than 9 years ago | (#8984141)

It is imoral and shows a lack of respect for those whom put countless hours into their site development.

Those who put countless hours into site development and yet leave it easily hacked are not deserving of our respect!

Re:PHP is as secure as you make it (2, Insightful)

CaptainTux (658655) | more than 9 years ago | (#8984328)

Those who put countless hours into site development and yet leave it easily hacked are not deserving of our respect!

Last time I checked, PERSONAL morals and ethics weren't defined by the actions of others or whether you "respected" someone or not. You're either moral or not. Nobody can "earn" your morality.

Re:PHP is as secure as you make it (0)

Anonymous Coward | more than 9 years ago | (#8984257)

Oh, and the next time an exploit of MSIE comes about, I'm sure you'll be heard saying that reproducing the exploit in neat code for all young script-kiddies to abuse, is _necessary_ to keep Redmond on its toes.

It's this simple; you believe in security through obscurity; I believe in security through defensive coding, testing, and breaking if necessary. php allows you to code naively and therefore, should come packaged _closed_ instead of open, as it is now. Or if it comes packaged open, it should fill your httpd error log with annoying messages indicative of the state of sloppy mess that some people call programming until you make it safe.

Re:PHP is as secure as you make it (2, Insightful)

kyndig (579355) | more than 9 years ago | (#8984329)

There is a responsible aproach, and an irresponsable aproach. The responsible thing to do is if you are reviewing code, or a website and locate a falacy which could be considered a security concern; you notify the individual or group.

What this site is promoting is the Defacement of a website. They further go to provide script security tips which have no relevance in any way to good program practices. Quite frankly, I am suprised this topic made it to /. It apears to be nothing more than an advertisement for a poorly designed and thought out website.

C'mon, Drop the FUD (4, Insightful)

da3dAlus (20553) | more than 9 years ago | (#8984066)

There is no trully unsecure language, only programmers that practice building unsecure sites. Bugs and security holes can always be patched, but if the site is crap to begin with, then that's just asking for trouble. You should always check user input, esp if you plan to use said input as part of a SQL query or entry. Duh.

Re:C'mon, Drop the FUD (0)

Anonymous Coward | more than 9 years ago | (#8984374)

"There is no trully unsecure language"

There are extremely poor spelling and incorrect word choices, however.

MySQL is not SQL (3, Insightful)

leandrod (17766) | more than 9 years ago | (#8984149)

When will /. stop posting misinformation?

SQL is a language, defined by ISO. MySQL is not SQL-compliant. Not even Oracle is. IBM DB2, PostgreSQL are SQL compliant, and a lot better than MySQL too. PostgreSQL is even faster and simpler.

MOD PARENT TROLL FOR POINTING OUT /.'S IDIOCY! (0)

Anonymous Coward | more than 9 years ago | (#8984277)

You have indicated that Slashdot is not 100% accurate. You will be Slashimilated.

Guides to Secure Programming? (5, Informative)

JumboMessiah (316083) | more than 9 years ago | (#8984188)

Other than the scripting challenge, what's on this site? I've read the guides to hacking [uberhacker.com] , but it's all a bunch of kindergarden material. Seems if you follow the guides you'll certainly have insecure PHP scripts with all kinds of SQL injection. How about posting some real articles on secure PHP scripting...

Re:Guides to Secure Programming? (4, Informative)

shiflett (151538) | more than 9 years ago | (#8984391)

I have a few articles on my Web site that might be informative: http://shiflett.org/articles [shiflett.org]

I'm also writing a monthly PHP security column in php|architect [phparch.com] , and these articles will be available for free six months after publication.

Lastly, I am writing PHP Security for O'Reilly, which is due out in the fall.

The worst I ever saw (1)

DamienMcKenna (181101) | more than 9 years ago | (#8984223)

<mode type="rant">

The worst practice I ever saw was making the global variables local scope using the extract() function, in... every... single... file... especially the security login files - its almost like register_globals and v4.1 never happened.

Then again this is the same person who insisted in using the $array[key] [php.net] array syntax which was never the correct way of doing to start with.

And this was the supergenius hired to replace me. Fun city. Glad I don't work there anymore.

</mode>

Damien

Part 2: Taking and Using Data (1)

tokul (682258) | more than 9 years ago | (#8984233)

Notice: Undefined index: name in example.php on line 2

Notice: Undefined variable: submit in example.php on line 3

SQL injection 101 ... (4, Funny)

zonix (592337) | more than 9 years ago | (#8984272)

People! Remember the quotes! Do:

delete from table where id = '$var'

Not:

delete from table where id = $var

Try for $var = "10 and id = 11 and id = 12 ...".

z

Re:SQL injection 101 ... (0)

Anonymous Coward | more than 9 years ago | (#8984402)

What about $var = "10' and id = '11' and id = '12" ?

Adding quotes is not enough, you should escape all quotes within $var.

Re:SQL injection 101 ... (2, Informative)

p3d0 (42270) | more than 9 years ago | (#8984472)

That's exactly the kind of crappy code that makes web sites insecure. If $var includes the right apostrophes, then an attacker can execute pretty much arbitrary SQL code.

SQL Injection in PHP (5, Informative)

uss_valiant (760602) | more than 9 years ago | (#8984291)

AFAIK SQL injection can be prevented by binding the parameters to the SQL statement and not putting them within SQL.
An example:
It's easy to inject some malicious SQL when using the following PHP code:
mysql_query("INSERT INTO FOO('Bar') VALUES('$some_post_param');");
But if you prepare the SQL statement with parameters and bind the variable $some_post_param to the statement, it will be secure.
see mysql manual for mysqli_stmt_bind_param() aka bind_param [php.net]
$stmt = $mysqli->prepare("INSERT INTO CountryLanguage VALUES (?, ?, ?, ?)"); $stmt->bind_param('sssd', $code, $language, $official, $percent);

I know this concept from Perl DBI, but in PHP I haven't seen anyone (phpBB, ...) using bind_param. Why is this? Performance? Keeping the code short and simple?

As for general webserver security: use PHP and perl as cgi, use suEXEC, run the webserver as nobody/www, put the users into chroot jails, but by all means, don't use PHP safe_mode On.

Re:SQL Injection in PHP (2, Informative)

shiflett (151538) | more than 9 years ago | (#8984493)

I know this concept from Perl DBI, but in PHP I haven't seen anyone (phpBB, ...) using bind_param. Why is this? Performance? Keeping the code short and simple?

The reason is that the function you reference is only available in ext/mysqli [php.net] , and this requires MySQL 4.1 or greater. There was previously no way to bind parameters like this using PHP and MySQL.

Also, phpBB is not a good example to use with regard to secure programming practices. It is one of the applications that give people this silly notion that the language is to blame for poor programming.

This business will ALWAYS have amateurs (2, Interesting)

Anonymous Coward | more than 9 years ago | (#8984314)

It is an economic fact of life. People will always be learning in the job. We will never have a guaranteed level of expertise, let alone competence. Tools will have to start enforcing security. Humble coders have been dealing in overflows, SQL injection, and cross-site scripting forever. Tools that manage buffer/stack overflows are not just for junior programmers. Tools/frameworks that add taint checking and build-in automagic security (like ASP.Net's validaterequest). If we have to rely on all the programmers becoming competent experts we will never have security.

Crap site (2, Interesting)

pommaq (527441) | more than 9 years ago | (#8984323)

Yes, that guide to secure scripting was very useful - a "hello world" program. Whoopee. To be frank, that site looked... well, less than professional, and with a name like "uberhacker" I expected their tips to be a little more advanced than "look, you can change the values in a query string but don't tell anyone!!!!11"

That being said, I used to write a lot of PHP (I rarely do it anymore at work, but I still try to keep up with the language) and when I first started out I would have loved a comprehensive and easy-to-understand guide to common security holes. The world needs a simple "how to write security-conscious code" for beginners! The sooner you get to see stuff like SQL injection or XSS in action, the better.

oh god, this is hosted on HappyHacker (1)

joeldg (518249) | more than 9 years ago | (#8984360)

Jeez... this is hosted on HappyHacker ..
Won't that lady *ever go away*...

How long has it been.. she calls the FBI constantly trying to say people who put up negative stuff about her are "hacking" her.

Dis had to sue to get his face off the cover of her book. I was in the middle of a move and didn't get the email about getting my face off of there.. And I am still pissed about it.

bah..
don't give this retch any more publicity.. she is a bottom feeder.

Secure Programming HOWTO (4, Informative)

dwheeler (321049) | more than 9 years ago | (#8984361)

For guidelines on how to develop secure programs, see my Secure Programming for Linux and Unix HOWTO [dwheeler.com] . This Free book provides a set of design and implementation guidelines for writing secure programs for Linux and Unix systems. That includes application programs used as viewers of remote data, web applications (including CGI scripts), network servers, and setuid/setgid programs. The book includes specific guidance for a number of languages, including C, C++, Java, Perl, Python, PHP, and Ada95.

PRETTY HOMO PROGRAMMING (-1, Troll)

Anonymous Coward | more than 9 years ago | (#8984379)

PRETTY HOMO PROGRAMMING

what a good way (0)

Anonymous Coward | more than 9 years ago | (#8984410)

for the admins at uberhacker to plug their own site, put up a shitty page, tell /. /. is so shit nowadays it accepts..

Input verification (3, Interesting)

ZeroExistenZ (721849) | more than 9 years ago | (#8984447)

Think it was just a "look at my cool site, try to slashdot that one!" kindof 'article'.


So far the most "unsafe" aspect with PHP / SQL setups is poor input validation;

If you allow direct writing to your SQL and don't do sufficient checks on the input, well.. you'll get in probs with that.

Proof of concept;
Hello.. enter your email for free porn: sucker@hotmail.com '; DROP TABLE 'emails';

Or you have those pages who mess up or display info which can be abused (and / or shouldn't be on that particular page) after there's a "<blockquote>" injected and redisplayed without checking..
Same with <input type=text>

Then.. there's JS, and htmlentities, and, and..
All caffeine intense, and headache inducing subjects you should keep in mind if you plan on bringing something on wire.

"Nah.. you don't have to do that.. Who's going to know how to do that?"
"Trust me.. You want me to put in that extra code.."
"If you really say so.."

You also have stupid defaults, and uninspired [google.com] coding which gets abused, ofcourse...

I actually like the PHP / SQL combination and believe it to be safe enough for what I do with it.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...