Top Ten PHP Security Issues, a preliminary list

[Chung Leong]

There's my draft list of the top ten PHP security issues. As you can see,
there's only nine right now. I've ranked them based on how readily the
vulnerability can be exploited. This is the reason why the client-side
scripting vulnerabilities are listed 2, 3, and 4, while SQL injection is
listed 7. Listed as number 1 is the arguably the lamest mistake in all
web-programming: pulling information from the database based on a
primary-key passed through the URL without any kind of access check. Because
even someone with no programming knowledge can take advantage of this hole,
it takes the top spot.

[drum roll]

1. Revealing private information without access check
2. Displaying user-provided text without escaping HTML special
characters
3. Allowing users to supply a URL for an image
4. Processing form data without checking the page referrer
5. Copying an uploaded file into a web-accessible directory
6. Using a GET/POST variable as parameter to include/require
7. Inserting GET/POST variables into SQL statements without validation
8. Using session_registe r() with sensitive variables
9. Performing restricted operations in the global scope of an include
file

The use of register_global s is not on the list, as the potential problems
are effectively covered by item 6, 7, 8, and 9 (or so I think).

I'll write up a more detailed description for each of these, along with
possible solutions, and post it somewhere on the net. Hopefully it'll be
interesting reading for beginners to the language. Thanks to all who
participated in the original thread. Additional comments are definitely
welcomed.

[Alex Farran]

Chung Leong writes:

Uzytkownik "Alex Farran" <al**@alexfarra n.com> napisal w wiadomosci
news:m3******** ****@alexfarran .com... DOM/Javascript security operates on a simple premise: content on a page at a
site is only accessible to scripts originating from the same site. When the
user click on a link and go from say www.paradiso.org to www.inferno.com,
scripts at www.inferno.com do not have access to any thing--including the
hidden number in question--at www.paradiso.org. This is true even if Interno
loads Paradiso in an inframe.
You're absolutely right. I'd forgotten that. Your scheme with the
unique numbers will work then.
Both your scheme and mine fall apart if the user opens new windows. The best
check is still the page referrer. Does anyone know if firewalls block all
referer headers or only absolute ones?
My scheme will only allow the user to interact with the site through
one window, that's true, but yours could be adapted to work with more
than one window. Instead of holding just one number in the session,
hold an array of all numbers sent. When a form is submitted search
for its number in the array, and if it's found accept the form and
delete the number from the array. That way every form can be
submitted exactly once, and only by person it was presented to.

Actually I think my scheme could be adapted similarly, but it would
still be restrictive compared to yours.
What we really need is a special kind of cookie (brownie?) that doesn't get
sent if the originating page isn't its creator.

I don't think we do now.

--

__o Alex Farran
_`\<,_ Analyst / Programmer
(_)/ (_) www.alexfarran.com

[Chung Leong]

Uzytkownik "Alex Farran" <al**@alexfarra n.com> napisal w wiadomosci
news:m3******** ****@alexfarran .com...

My scheme will only allow the user to interact with the site through
one window, that's true, but yours could be adapted to work with more
than one window. Instead of holding just one number in the session,
hold an array of all numbers sent. When a form is submitted search
for its number in the array, and if it's found accept the form and
delete the number from the array. That way every form can be
submitted exactly once, and only by person it was presented to.
That should work. If there's only a way to implement that without having to
modify every form... All I can think of is appending some JavaScript code at
the bottom of the page that inserts the hidden field dynamically. Not very
reliable.
--

__o Alex Farran
_`\<,_ Analyst / Programmer
(_)/ (_) www.alexfarran.com

[Ian.H]

On Thu, 12 Feb 2004 19:10:55 -0500, Chung Leong wrote:

Uzytkownik "Ian.H" <ia*@WINDOZEdig iserv.net> napisal w wiadomosci
news:pa******** *************** *****@hybris.di giserv.net...

Hmm.. and if someone's "firewall" (we're talking windoze here) blocks /
changes the referrer as part of it's "user privacy / security setting"?
Agnitum Outpost for example can block the referrer by replacing it with
'**BLOCKED BY OUTPOST**' or something.
Hmmm...Interest ing. I didn't know firewalls does that.

Seems to be some of the "security suites" for windoze have this feature
built in.

OTOH, although I haven't actually done it with PHP, I have set a page
referrer heading in a console Perl script using LWP. Could easily be made
into a "legitimate referrer".. ie: one that's expected by the site.

I know you're not suggesting _just_ using the referrer for validation,
but IMO, the referrer header is next to useless for any consideration.
Agreed, people are unlikely to want to try and hijack their own account,
but they may do this as a matter of course (blocking the referrer
header) and thus the system would fall over for IMO, a "false-positive".

Well, I don't know how else you can stop the cross-site scripting
vulnerability in question, because there is no other distinction between a
legitimate POST request and a malious one originating from a different
site from the HTTP referrer. We can perhaps work around the firewall/proxy
issue by rejecting only requests where there is a valid URL and it's not a
page on the local server.

[ snip ]
I share your thoughts on this.. but with my LWP description above.. the
firewall / proxy check wouldn't come into play either, as the referrer
would infact be the required one. Definitely an interesting scenario you
have outlined in this thread =)

Regards,

Ian

--
Ian.H
digiServ Network
London, UK
http://digiserv.net/