What is Digg?Sponsored by Travelzoo
Take Advantage of Ridiculously Low Holiday Airfares view!
travelzoo.com - Flights $52 and up for Thanksgiving, Christmas & New Year. But move on it now.
50 Comments
- Vedlen, on 07/06/2009, -2/+32This deals with security without even mentioning SQL injections.. I know this is about PHP and SQL injection is about databases but isn't it prevented with some good PHP practices..?.. Sounds like the basics to me..
- peterjmag, on 07/06/2009, -0/+19Sanitize, sanitize, sanitize!!
- alethes1973, on 07/06/2009, -0/+14He wants to read about it so he doesn't have to read about it. Duh.
- mysql101, on 07/06/2009, -0/+14The article reads:
Step 1 for securing your PHP website:
Do not use the new GOTO operator that comes in PHP 5.3.
http://us.php.net/goto - boorock666, on 07/05/2009, -3/+17Absolutely useful
- mymate, on 07/06/2009, -0/+13your comment makes no logical sense?
- mysql101, on 07/06/2009, -2/+11The article was on PHP security. SQL injections are a DB issue.
With that said, is there any reason for people to not use parameterized mysqli these days? - maz2331, on 07/06/2009, -1/+8#1 should be "Turn off 'allow_url_fopen'". I've never found where it's needed, and it is a huge security hole. Kill it with fire, then nuke it from orbit.
- bradleyland, on 07/06/2009, -1/+8SQL injection is an attack against your database, but bad PHP code is what makes you vulnerable to SQL injection attack, so it's still a PHP security issue. There is no patch for your DB that will protect you against stupid coding.
Having said that, I'm kind of glad this article didn't rehash SQL injection. When I see a "PHP Security" article show up on Digg, I immediately think, "Oh boy, yet another article about preventing against SQL injection attacks." This article covers two increasingly popular attacks, XSS and remote file inclusion. XSS especially, is responsible for a large number of attacks against many of my customers' websites. SQL injection is pretty easy to prevent these days if you're using a decent class library for your DB interface. - mysql101, on 07/06/2009, -0/+7How do you tell if a value is a regular internal global or one that was user input?
Just make a validation class and never take user input unless it goes through it. I don't see the point in ever using register_globals. It was horrible coding practice back then, and it's no better now. - headzoo, on 07/06/2009, -0/+7"due to the fact that it’s such a forgiving language that will often “work” even when there are a few loose ends in the coding."
That's completely true of any language. To my knowledge there is no language in existence that won't compile because of programmed logic errors that create security holes.
There's really only one reason PHP might appear less secure than other languages: PHP users aren't trained very well. As a result there is more poorly written PHP source code floating around than other languages. - mysql101, on 07/06/2009, -0/+6There's a lot of hysteria over XSS, even on intranet sites. The only way I could get one project out of security review was to assure them that there would be no possibility of XSS attacks. The way we did that was to scrub all input, and this included input taken from the DB. Otherwise if you only watch what you echo out, it's easy to forget one, and end up having a hole in the system. Scrubbing all data regardless of source means no chance of messing up.
Needless to say, the application got slower. But that's how I know it's Enterprise Ready. :) - BenRT, on 07/06/2009, -4/+10"it’s such a forgiving language that will often “work” even when there are a few loose ends in the coding."
I don't know about you, but whenever I typo my code, I get a lovely, massive PHP syntax error. It does not "just work". - alarion, on 07/06/2009, -1/+5And you can write just as ugly code in any other language. Yes, PHP is easy to learn. Just because SOME people are idiots doesn't automatically remove a tool from the toolbox.
That being said, I would rather code in PHP all day long over the nightmare that is JSP. - tdmeth, on 07/06/2009, -0/+4For the most part, I agree with you. PEBKAC errors are millions of times worse when it's on the developer end rather than the user. And no language can compensate for morons on the development end. However, languages can be more forgiving than others. Take Java vs C++ for example. C++ is more "forgiving" than Java because it allows you to really shoot yourself in the foot with pointers, whereas java does not. Similar thing here. PHP makes it much easier to shoot yourself in the foot, compared to languages such as ASP, JSP, and ColdFusion. I mean, the default settings allow you to alter variables from the URL, for crying out loud!
- mysql101, on 07/06/2009, -2/+6Apparently your experience is as useful as your advice.
- purpled1, on 07/06/2009, -0/+3most php devs still don' t know that if you use the e modifier to preg_replace, the regular expression replacement gets evaluated as php code so they send unfiltered stuff to the preg_replace and you get trivial php execution on the machine. I have made alot of $$ in web security through this.
- tdmeth, on 07/06/2009, -0/+3No kidding! Who thought that was a good idea? Yeah, GOTO has its place, but that is extremely rare.
- tdmeth, on 07/06/2009, -0/+3No kidding. Prepared statements are wonderful. Not only do they go a long way in preventing injection attacks, they also increase the speed of your queries. Some languages even use them as the default method of DB access because of how much they enhance your application.
- tdmeth, on 07/06/2009, -0/+3Exactly. I do think that PHP is a very good scripting language, but that is it. If you're looking for a good application language, look to Python, JSP, ASP, and CF. Each of those have their own set of strengths and weaknesses. Use the right tool for the job.
- wesw02, on 07/06/2009, -1/+3Most articles like this aren't very good. But this one is definitley worth a look even if you only tinker with PHP, good stuff to know.
- jaxter2010, on 07/06/2009, -1/+3mysqli & prepared statements. problem solved.
- Vedlen, on 07/06/2009, -0/+2What do you suggest ? Django ? ASP maybe ?
- MtheoryX, on 07/06/2009, -0/+2True, but if you program logic errors, it WILL still work; it just won't work how you want it to work.
- bradleyland, on 07/06/2009, -0/+2You do both. With Register_Globals turned on, a user could potentially overwrite the value of a local variable, and you'd have no way to expect it. You always sanitize user supplied data, but with Registered_Globals, even your sanitization efforts can be at risk.
- ucffool, on 07/06/2009, -0/+2I'm so glad you didn't suggest addslashes() as the solution. If someone else wonders why that is:
http://www.phpreferencebook.com/clarifications/mys ... - IamNomad, on 07/06/2009, -0/+2because dinosaurs will eat your guts.
- tdmeth, on 07/06/2009, -0/+2Well, it's not an end in and of itself, but it is a major hole that you need to patch.
- ceolwulf, on 07/06/2009, -1/+3buried for being the reason other web devs cut their wrists at night.
- kopiwrite, on 07/06/2009, -2/+3Again, there is nothing WRONG with PHP, but the easiest language tends to attract the laziest coders
You make a valid point, but I think instead of telling people not to use PHP because they could be lazy you should instead write some articles on how to keep PHP secure. Digg articles like this and encourage education, not sticking your head in the sand. Every language has it's vulnerabilities, you just need to be aware of them and protect against them. - bsmang, on 07/06/2009, -3/+4I take great pride in the level of laziness I've attained as a coder.
- sagegoku666, on 07/06/2009, -0/+1true true, but the easiest way out for a nub (i.e. the article's target audience) is mysql_real_escape_string()
just make sure you're connected to a db first or it won't work. - MasterQ, on 07/06/2009, -0/+1mysql_real_escape() was so 5 years ago. all the cool kids are using prepared statements now...
- bieber, on 07/06/2009, -2/+3Right. Because using goto to break out of nested loops is going to make my code automatically less secure. Avoiding Goto is about readability and style, not security.
- sagegoku666, on 07/06/2009, -1/+2mysql_real_escape_string($problem_solved)
- Rekutyn, on 07/06/2009, -1/+2It's likely a sure sign you should be using recursion, instead.
- Carbunkulous, on 09/08/2009, -0/+1You failed Digg.
- headzoo, on 07/07/2009, -0/+1"I mean, the default settings allow you to alter variables from the URL, for crying out loud!"
Hahah.. Yeah, I was going to mention features like register_globals that are just dying to be exploited, but I figured that fell under the umbrella of poorly trained users, because an experienced PHP user would never rely on those features. - sensor, on 07/06/2009, -0/+1PDO is the way to do it these days.
- foltaggio, on 07/07/2009, -0/+1http://xkcd.com/292/
- thomasproject, on 07/06/2009, -0/+0Very interesting. From the standpoint of an individual that has been hacked in the past, I love to read articles in security. I'm going to do a bit of study on seeing how this can transfer to things like wordpress blogs. Cheers! www.usingwp.com
- MadTom, on 07/05/2009, -5/+3I just bought a book on php about two weeks ago, hopefully this will cover some of the stuff I didn't want to read
- siteforbiz, on 07/06/2009, -3/+0well, there are certain protocols you must follow when building a site:
1- if you wrote your code, try to get rid of redundant data.
2-if it is a script you bought somewhere, make sure it is a reputable site and keep up with their updates.
3- try to include the latest exception handlers available online and include it in the code.
4-always monitor the traffic on your site along with ip activities, most visited links and the patterns of users.
5-check with your hosting company if they monitor cron jobs and logwatche for the server. We usually monitor those and block ip's trying brute force attacks or automatic submission Technics.
6- protect your folders by inserting redirection codes when needed.
7- place dummy folders only accessible by bots, and log the access to it. resolve the ip's and if they dont belong to a search engine you can take the best choice to block them.
8- use online antivirus. Which siteforbiz.com provides.
9- use SSL to protect your customers transactions and interactions if you have shopping cart or you handle sensitive information.
all the above will only make breaking the system harder but never impossible.
if you have further questions, please contact us on info@siteforbiz.com
thanks.
Richard
http://www.siteforbiz.com - EverybodyPanic, on 07/06/2009, -7/+4The article failed to mention not leaving children unattended in the pool. I know this is about PHP, but a security article ought to mention watching children playing in the pool. It's also good practice to buckle up while driving, I wish a PHP security article would mention that.
- jaxter2010, on 07/06/2009, -8/+4Python, JSP/JSF (my fav as of late), and ASP to name a few...
Again, there is nothing WRONG with PHP, but the easiest language tends to attract the laziest coders. - ceolwulf, on 07/06/2009, -5/+1puh-puh-puh-puh-perl?
- Vedlen, on 07/06/2009, -6/+1Don't read just the first sentence... I know it's about PHP..
However I don't think people bother using parameterized mysqli - inactive, on 07/06/2009, -8/+2Buried for it's.
-
Show 51 - 52 of 52 discussions
© Digg Inc. 2009
— Content created and posted by Digg users is