What is Digg?24 Comments
- Poltras, on 10/12/2007, -1/+11Aw come on...
Don't want to be a troll, but these 10 vulnerabilities are just a copy-paste of the top 10 from OWASP (open source web application security project, http://www.owasp.org) which are listed since 2002 or something, and then the author tells that some can or not be applied to PHP code. Nothing original here.
Nothing new, and it applies to web application in general, so title misleading. If you want to be useful, link to the real owasp website with the real content. They a bloat of PHP examples already. - GeneralFailure, on 10/12/2007, -0/+9Every single one of these "tips" boils down to one of two things: validate your input and carefully output. It gets boring after seeing the same thing on a weekly basis.
- boycy, on 10/12/2007, -1/+6@dzone - seeing as the site you mention is obviously yours, I would post it yourself instead of spamming it here...
- rollergoof, on 10/12/2007, -0/+5yeh its true. check out this video of a real live sql injection..
http://youtube.com/watch?v=MJNJjh4jORY&search=SQL%20Injection - deut, on 10/12/2007, -0/+5@Poltras
Indeed that may be so. Looking at http://www.owasp.org/index.php/OWASP_Top_Ten_Project does in fact reveal the exact top ten list. But this is not a copy-n-paste.
What I like about Bitruder's submission...
1) Concise and to the point.
2) Contains specific php examples.
3) Handy reference.
Furthermore, if you look more closely at the site you would notice that the author pays due respect to OWASP, - "The Open Web Application Security Project released a helpful document that lists what they think are the top ten security vulnerabilities in web applications." - with links back to the OWASP.
So, all in all, I think the site that Bitruder submitted is actually more practically useful than the one you advocate. - artnez, on 10/12/2007, -4/+8What? Another one of these? Come on folks, stop repeating the same things over ... and over .. and over again. Do a simple google search for "PHP Security" and you'll find wave after wave of the exact same advice. I'm surprised these guys haven't plagorized one another at this point -- seeing as there are too few words in the english language to repeat the same thing time and again without ending up writing things word for word.
Furthermore, I think articles like this are totally counterproductive and only used by the writers to fill some space on their stats and/or generate some traffic. The reasons are simple:
1) They outline very fundamental concepts that can get very complicated with very large applications. If someone reads those 10 points on security and actually learns something new, they have no business writing web software that is publicly available in the first place.
Things like XSS security, user validation, session security, etc are all learned when you actually learn the language/markup/etc that they pertain to!
For instance, if you really knew how PHP sessions work in the first place, you would automatically realize that storing session data on remote hosts is a big no-no if you're serious about security.
2) Telling people to blindly use a PEAR library is easy, but bad for the people. If you don't know *how* somethings works, how can you be sure that the code you're using is safe? You can't be, unless you understand how it works and take the time to briefly glance at the code you will be using.
At the end of the day, PHP is such a simple language and writing web software is so straightforward (few holes to patch up) that anyone who needs articles like this needs to go back to binary 101.
Sorry for the rant folks, it's just that I deal with too many amateur devs on a day to day basis that read articles like this and instantly certify themselves on the topic of security. They dont know how.. they know when... but atleast they know what! - turkdigle, on 10/12/2007, -0/+4Although the tips should be memorized by us PHP coders by now, it is always nice when articles like these pop up. Everyone learns PHP from different resources whether it is web tutorials or a book, they may not be fully aware of all these issues, so it is nice to give a quick look and make sure you are on the up and up with PHP security. I also agree with others that this is not the best written PHP security article, but the more attention to PHP security the better (IMO)!
- pornel, on 10/12/2007, -0/+3My #1:
$page = $_GET['page'];
include "pages/$page.html";
/index.php?page=../../any-file.iwant%00 - bobslaede, on 10/12/2007, -0/+2@pornel
dude, thats the same #1 as in the article.... - inactive, on 10/12/2007, -0/+2My first question (and maybe it's a stupid one) is: How could a user tamper with the value in a hidden form field?
- dblyth, on 10/12/2007, -0/+2If you copy/paste the generated html (from the view source window) and change some of the hrefs inside (like form actions) to point to the original on the server, you could change the hidden field and have it be submitted like normally.
Or so I've heard. - inactive, on 10/12/2007, -0/+1Interesting video rollergoof...
One question: I understand why he did the first apostrophe and the "or 1=1", but why did he type -- at the end of the injection? - shiflett, on 10/12/2007, -0/+1The -- denotes the start of a comment, so it effectively terminates the query at that point.
My favorite username is something like:
chris' --
I say that only in jest, but a surprising number of web applications would let me basically hijack the chris account with this username. Of course, this technique also lets you target specific accounts. - Ensnared, on 10/12/2007, -0/+1Hidden fields are submitted just like visible ones - the server never knows the difference, so anything can be done with them clientside. A JavaScript can be inserted to change the value for instance, or the user can use some tool to edit the HTML on the fly, or one can simply download and save the html-file locally, edit it, and open it in the browser.
The rule of thumb is, never ever trust user input. Even if you use JavaScript to validate the fields client-side before the form is submitted, a user can easily bypass that, so everything should be validated on the serverside. - Ensnared, on 10/12/2007, -0/+1I prefer:
$page = $_GET['page'];
if (is_file('pages/'.$page.'.php')) {
include('pages/'.$page.'.php');
} else {
exit();
}
Or, alternatively, with an array $validpages containing the valid pages (duh!):
$page = $_GET['page'];
if (in_array($page, $validpages)) {
include('pages/'.$page.'.php');
} else {
exit();
} - chris9902, on 10/12/2007, -1/+2there are some good tips there but some seem overkill. If you run your own server or host from a good company things like "register_globals" can and should be turned off so you don't need to worry about them.
These are good tips for anyone who wants to make there source code public. Many open source projects have failed at even the most basic security in the past.
good artible +digg - ascheinberg, on 10/12/2007, -2/+2Unlike most article about PHP security, all of these are real concerns, not stupid entry level crap.
This gets a digg. - Kamino, on 10/12/2007, -2/+1After reading your illuminating reply I modded both of them down.
- thefrenzy, on 10/12/2007, -1/+0Unless of course you have open_basedir restrictions in place (like any good webhost should).
Still, it's a silly thing to write, if you really really need to do something like this have the pages in an array, or better yet a database and pass a "pageid" value. - inactive, on 10/12/2007, -4/+0The list:
1. Using PHP.
2. See #1. - inactive, on 10/12/2007, -7/+2Seems useful.
Let's wait for the derisive remarks to roll in before making any judgments, however. - inactive, on 10/12/2007, -10/+0Someone dugg that down?
LOSER. - dzone, on 10/12/2007, -21/+1This type of vulnerability list can be a useful resource. You should post this at http://www.dzone.com
Check out the new & improved 
© Digg Inc. 2009
— Content created and posted by Digg users is