Top Ten PHP Security Hole
Chung Leong
language--is hard. The end result is many PHP sites with security issues. I
thought therefore it would be a good idea to put together a top ten list of
mistakes to avoid, so that beginners have something concrete to check their
work against, instead of fuzzy recommendations like "using session variables
is more secured."
Here's my nomination:
* Copying an uploaded file into a web-accessible folder without checking its
extension
This mistake allows someone to upload a .php file onto your website and gain
complete control.
JimC
"Chung Leong" <cherny...@hotmail.com> wrote in message
news:HuKdnfh8I_c...@comcast.com...
> Building web sites with PHP is easy. Building secured web sites--in any
> language--is hard. The end result is many PHP sites with security issues. I
> thought therefore it would be a good idea to put together a top ten list of
> mistakes to avoid, so that beginners have something concrete to check their
> work against, instead of fuzzy recommendations like "using session variables
> is more secured."
>
> Here's my nomination:
>
> * Copying an uploaded file into a web-accessible folder without checking its
> extension
Do you mean setting its permissions, or is there a security issue raised by
giving PHP files (e.g., ones that are included in a "regular" PHP file)
extensions other than ".PHP"?
> This mistake allows someone to upload a .php file onto your website and gain
> complete control.
It's a good idea to include a blank index.htm file in auxiliary directories.
It might force a load of the Web site's home page with something
like
<body onload="javascript:window.top.location='my-website.com';">
Jim
www.cross-comp.com
www.cross-comp.com/pages/software
for software goodies.
gmuldoon
Suggest it should just read:
* Copying an uploaded file into a web-accessible folder
I now always put uploaded files outside the web server doc root, and use
a function to safely "deliver" (read, not execute/parse) them back to a
browser if required.
Geoff M
Dan Tripp
Maybe it'd be better to have an index.php file that has a redirect
header in it. Kinda like:
<?php
header("Location: http://www.my-website.com/");
?>
That way it'd redirect if the client's browser has javascript disabled.
Manuel Lemos
On 02/04/2004 10:50 PM, Chung Leong wrote:
> Building web sites with PHP is easy. Building secured web sites--in any
> language--is hard. The end result is many PHP sites with security issues. I
> thought therefore it would be a good idea to put together a top ten list of
> mistakes to avoid, so that beginners have something concrete to check their
> work against, instead of fuzzy recommendations like "using session variables
> is more secured."
My favourite is leaving the database server accessible for everybody to
connect from outside the server of a site. Even better is to use MySQL
with root account password empty.
If you know a site that uses MySQL, try telneting to port 3306, or just
use a MySQL client specifying as host the address of the site and using
the root user with no password. If you can connect successfully, you can
party in the site database! ;-)
--
Regards,
Manuel Lemos
Free ready to use OOP components written in PHP
http://www.phpclasses.org/
Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html
Cameron
Once took a look at the code for a rather widly used web log script,
noticed that it seemed the developers had written it with the E_ALL
~E_NOTICE error setting, with me having it turned on locally I got a
screen full of notices, should someone be using it with register globals
on who knows what nasty things could happen.
~Cameron
David Mackenzie
* Never never never never never never never never never trust
client-imputted data (including GET vars - even if they don't come
from a form).
* Be aware of SQL injection attacks. Always use addslashes() when
inserting textual client-entered data into your database. Check that
numeric values really are numeric.
* Don't have links that "do" something (such as deleting a record).
Use a form with a POST action.
The first one is a bit fuzzy.
--
David ( @priz.co.uk )
Shawn Wilson
LOL! I did this last one once and forgot to pw-protect the directory. Every
damn record got deleted. I thought it was odd that someone had guessed at the
directory name and got in. After checking the server logs I realized that an IE
toolbar I had to monitor site popularity reported the address to it's parent
site's bot. The bot then crawled the entire site. Luckily, I was able to get
the records from the backup tapes.
Anyway, lesson learned. I always pw-protect directories right away, even before
they contain real data. I never use links for any actions. And I always check
to make sure a valid user is logged in before executing admin scripts (just
because a directory is password protected today doesn't mean it won't be
accidentally removed in 6 months).
Regards,
Shawn
--
Shawn Wilson
sh...@glassgiant.com
http://www.glassgiant.com
André Næss
> * Don't have links that "do" something (such as deleting a record).
> Use a form with a POST action.
Uh... A POST action is not any different from a GET request in this respect.
What you shouldn't do is have administration systems that aren't password
protected. If you always make sure users authenticate themselves before
they perform operations like 'delete' then there is no problem.
André Næss
Robert Downes
>
> Here's my nomination:
>
> * Copying an uploaded file into a web-accessible folder without checking its
> extension
>
> This mistake allows someone to upload a .php file onto your website and gain
> complete control.
How about using register-globals, despite being warned of the possible
holes it allows.
--
Bob
London, UK
echo Mail fefsensmrrjyaheeoceoq\! | tr "jefroq\!" "@obe.uk"
Daniel Tryba
> Building web sites with PHP is easy. Building secured web sites--in any
> language--is hard. The end result is many PHP sites with security issues. I
> thought therefore it would be a good idea to put together a top ten list of
> mistakes to avoid, so that beginners have something concrete to check their
> work against, instead of fuzzy recommendations like "using session variables
> is more secured."
I'm missing crosssite (java)scripting bugs: always (html)encode output
(don't forget ENT_QUOTES), to avoid session hyjacking...
--
Daniel Tryba
Chung Leong
one, since it's look easy to exploit.
Uzytkownik "Daniel Tryba" <news_comp...@canopus.nl> napisal w
wiadomosci news:bvucqc$1n9$2...@news.tue.nl...
Chung Leong
mention. Once I was called into the office of this guy who claimed he'd
discovered a huge vulnerability: He could log in by adding
?username=jdoe&password=qwerty to the URL! He was still fiddling with HTTP
authenticating when he lost his job.
Uzytkownik "André Nćss" <andrena.spa...@ifi.uio.no> napisal w
wiadomosci news:bvtkm5$pi$1...@maud.ifi.uio.no...
> André Nćss
Chung Leong
feature is somehow not safe when it's its misusage that causes issue. Using
$_GET certainly won't save you if you write something like:
include_once($_GET['do']);
That's an actual sighting and is a security hole that deserves a place on
the top ten.
* Using a client-provided variable in include/require
This hole allows someone to insert arbitrary PHP code into a script by
linking in a remote script. Prepending the variable with a path doesn't
help, since an attacker can backtrack to a FTP pub folder or to the Apache
log file using ../../../../filename.
Uzytkownik "Robert Downes" <nospam...@see.my.signature.con> napisal w
wiadomosci news:402269fa$0$29113$65c6...@mercury.nildram.net...
Chung Leong
access denied error.
Uzytkownik "JimC" <ji...@cross-comp.com> napisal w wiadomosci
news:tJgUb.9618$y24....@newssvr29.news.prodigy.com...
David Mackenzie
I was thinking of Shawn's story when I wrote that.
Reading my post back, I can see that the thread is about *security*,
and POST isn't more *secure* than GET.
However, from an application point ov view, POST is more robust than
GET.
Senator Jay Billington Bulworth
"Ian.H" <i...@WINDOZEdigiserv.net> wrote:
> Shouldn't this be done at the server level?
Absolutely!
>
> [.htaccess]
> RedirectMatch .* http://foobar.com
>
>
> or if just denying:
>
>
> [.htaccess]
> Order deny,allow
> Deny from all
> Allow from none
..or my favorite,
DirectoryIndex index.php index.html index.htm index.cgi /403.php
Assuming you have a custom HTTP 403 forbidden script at /403.php, the
above directive in the .htaccess of the document root will send all
fooling to the 403 page. My /403.php's usually are set up to send me an
email with the remote IP, to see who's messing around.
Drop this into httpd.conf if you run the entire server, and you never
have to worry about open directory listings anywhere.
hth
--
Bulworth : fu...@fung.arg | My email address is ROT13 encoded, decode to mail
--------------------------|--------------------------------------------------
<http://www.phplabs.com/> | PHP scripts and thousands of webmaster resources!
Joshua Beall
news:1to620522afrc3a1e...@4ax.com...
> I was thinking of Shawn's story when I wrote that
> and POST isn't more *secure* than GET.
Maybe so, maybe no. Let's consider a hypothetical scenario:
I write web forum has a script "/admin/delete.php" that can be used to
delete a specific post, passed in the GET string. Now, being being a good
programmer, I make sure that this script will not execute unless the user
calling it has been authenticated. Maybe I am really paranoid, and I check
the IP address against a list of known good IP addresses, to make it more
difficult to spoof.
Now John A Cracker comes along sees a post he wants to delete, and sets his
avatar, and sets his avatar to <img src="/admin/delete.php?ID=10">.
Now I come along, and pull up something he has posted. His avatar tries to
load, and since it is *my* *user*, and even my *IP* that is requesting
/admin/delete.php, it executes as expected.
Could be even worse if I allowed delete.php to execute arbitary SQL code
passed in the GET string.
As you can see, this scenario would never happen if I had used POST to pass
the ID.
So, I'll leave it up to the reader to decide if GET is really just as secure
as POST. But I think the answer should be obvious. It would me much harder
to get someone else's browser to POST data than it is to get them to GET a
URI, and send info that way.
-Josh
Chung Leong
definitely belongs on the top ten.
Using GET is only marginally more secured though, since an attack can use
<img src="javascript: [JS code that steals your cookie ]">
to gain access.
Uzytkownik "Joshua Beall" <jbe...@donotspam.remove.me.heraldic.us> napisal w
wiadomosci news:OfRUb.16983$EH5....@nwrddc01.gnilink.net...
Daniel Tryba
[snip scenario]
> Could be even worse if I allowed delete.php to execute arbitary SQL code
> passed in the GET string.
>
> As you can see, this scenario would never happen if I had used POST to pass
> the ID.
If html can be inserted, inserting javascript is only a little more
complicated, so instead of an image a selfsubmitting form
(method='post') can be inserted. Added security: 0%
--
Daniel Tryba
Eric Bohlman
> Using GET is only marginally more secured though, since an attack can
> use
>
> <img src="javascript: [JS code that steals your cookie ]">
> to gain access.
If you're storing sensitive/confidential/useful-for-exploit information in
a cookie, you've got at least two *big* problems: you're trusting input
from the client, and you're relying on security by obscurity. If you have
information that you don't want the client software's user to know about,
the only secure thing to do is not to send it to the client in the first
place, and putting it into a cookie is by definition sending it to the
client and reading it back from the client is by definition trusting input
from the client.
Joshua Beall
news:c01ahn$p5q$1...@news.tue.nl...
My scenario does not require HTML to be inserted. It requires the path to a
file to be inserted.
Plenty of forums say "put the link to your avatar here." Probably a lot of
them strip the tags out of that to prevent you from doing exactly what you
suggested.
Chung Leong
Uzytkownik "Eric Bohlman" <eboh...@earthlink.net> napisal w wiadomosci
news:Xns9487BBCF9C0Ee...@130.133.1.17...
Daniel Tryba
>> <img src="javascript: [JS code that steals your cookie ]">
>> to gain access.
>
> If you're storing sensitive/confidential/useful-for-exploit information in
> a cookie, you've got at least two *big* problems: you're trusting input
> from the client, and you're relying on security by obscurity.
Neither (have to) applie(s) for session cookies. The default session
scheme is extremely vulnerable to hijacking. Alternatives always might
exclude some users (esp. users behind loadbalanced proxies) IMHO.
--
Daniel Tryba
Chung Leong
attacker can easily link to a page that does an auto-submit to your php
script.
Uzytkownik "Joshua Beall" <jbe...@donotspam.remove.me.heraldic.us> napisal w
wiadomosci news:qoWUb.15683$9a7....@nwrddc02.gnilink.net...
Joshua Beall
news:uKOdnWbl19-...@comcast.com...
> A lot of sites let you put hyperlinks in your messages too. A potential
> attacker can easily link to a page that does an auto-submit to your php
> script.
True, but the devious thing about the way of doing it with the avatar is
that it will get loaded without the viewer even doing anything - if it was a
link, then you would have to dupe them into clicking on it.
But with the number of people that open executables they get in their mail,
I suppose that this might not be that hard ;-)
Chung Leong
see if the link actually points to an image.
I thought a bit more about the GET-vs-POST question and it seems using POST
for operations that alters data is perhaps preferrable, if only as a mean of
keeping them separate from data retrieval requests. You can then stop the
cross-scripting vulne by forbiddening POST operation from a referrer
different from the current site.
Uzytkownik "Joshua Beall" <jbe...@donotspam.remove.me.heraldic.us> napisal w
wiadomosci news:CvYUb.20927$EH5....@nwrddc01.gnilink.net...
R. Rajesh Jeba Anbiah
> Thinking that POST is somehow more secured than GET deserves an honorable
> mention. Once I was called into the office of this guy who claimed he'd
> discovered a huge vulnerability: He could log in by adding
> ?username=jdoe&password=qwerty to the URL! He was still fiddling with HTTP
> authenticating when he lost his job.
+----+---------+-------+
| user_settings |
+----+---------+-------+
|pKey|for.Key | data |
+----+---------+-------+
| id | user_id | xyz |
+----+---------+-------+
| 1 | 1 | abc |
| 2 | 1 | abcd |
| 3 | 1 | abcde |
| 4 | 2 | qwe |
| 5 | 2 | qwer |
+----+---------+-------+
Usually, in a situation like above, we'll usually list the record
for that particular user with the query like:
"SELECT * FROM user_settings WHERE user_id=".$_SESSION['user_id']
And, while displaying we will give link to delete each record like
deleteSettings.php?id=1... where "id" is the primary key of the table.
In most of the scripts I have seen, programmers just delete the
record without checking if that record actually belongs to that user
or not.
e.g. "DELETE FROM user_settings WHERE id=".$_GET['id']
For example, in the above case, only 2 records (4&5) are belong to
user2. And if the user2, manipulate the url like
deleteSettings.php?id=1, he can even delete the records that belong to
user1.
I avoid this issue with the query like (so that he can delete his
own record alone---even if he manipulates the url):
"DELETE FROM user_settings WHERE id=".$_GET['id']." AND
user_id=".$_SESSION['user_id']
I don't know, if anyone already documented such trick; but yet I
haven't seen such a code/trick.
--
"Success = 10% sweat + 90% tears"
If you live in USA, please support John Edwards.
Email: rrjanbiah-at-Y!com
David Mackenzie
<cherny...@hotmail.com> wrote:
>I guess the only way to prevent that is to do a getimagesize() on the URL to
>see if the link actually points to an image.
But as soon as you request the URL, it will be executed. I was going
to suggest checking the Content Type, but that has the same problem.
You could have the user upload their image to your server via <input
type='file'>. The type can then be determined without fear of it being
"executed".
>I thought a bit more about the GET-vs-POST question and it seems using POST
>for operations that alters data is perhaps preferrable, if only as a mean of
>keeping them separate from data retrieval requests. You can then stop the
>cross-scripting vulne by forbiddening POST operation from a referrer
>different from the current site.
--
David ( @priz.co.uk )
Daniel Tryba
> I thought a bit more about the GET-vs-POST question and it seems using POST
> for operations that alters data is perhaps preferrable, if only as a mean of
> keeping them separate from data retrieval requests. You can then stop the
> cross-scripting vulne by forbiddening POST operation from a referrer
> different from the current site.
Using the referrer to secure things.... this one should be in the top 10
also.
--
Daniel Tryba
Chung Leong
Uzytkownik "David Mackenzie" <m...@privacy.net> napisal w wiadomosci
news:04le20tganalb7c4q...@4ax.com...
> But as soon as you request the URL, it will be executed. I was going
> to suggest checking the Content Type, but that has the same problem.
But the requested action (deleting a message, say) would fail, since the
user is not logged in. You only have the problem when the browser make the
request on behalf of the user. In this case the server would be talking to
itself, so nothing should happen.
Chung Leong
:-)
In this case, as it's quite reasonable to expect that the intended victim
wouldn't spoof the HTTP referrer in order to hijack his own account, I don't
think it's an issue.
Uzytkownik "Daniel Tryba" <news_comp...@canopus.nl> napisal w
wiadomosci news:c081d4$9g2$1...@news.tue.nl...