Home » Php » Top Ten PHP Security Hole – PHP

Top Ten PHP Security Hole – PHP

Posted by: admin February 22, 2020 Leave a comment

Q(Question):

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

This mistake allows someone to upload a .php file onto your website and gain
complete control.

A(Answer):

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:Hu********************@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.

A(Answer):

ch***********@hotmail.com says…

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

This mistake allows someone to upload a .php file onto your website and gain
complete control.

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

A(Answer):

JimC wrote:

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:Hu********************@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.

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.

– Dan
http://blog.dantripp.com/

A(Answer):

On Thu, 05 Feb 2004 02:59:05 +0000, Dan Tripp wrote:

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’;">

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.

Shouldn’t this be done at the server level?
[.htaccess] RedirectMatch .* http://foobar.com
or if just denying:
[.htaccess] Order deny,allow
Deny from all
Allow from none

Regards,

Ian


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

A(Answer):

Hello,

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

A(Answer):

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."

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.

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

A(Answer):

On Wed, 4 Feb 2004 19:50:44 -0500, "Chung Leong"
<ch***********@hotmail.com> 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."

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.

* 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 )

A(Answer):

David Mackenzie wrote:

On Wed, 4 Feb 2004 19:50:44 -0500, "Chung Leong"
<ch***********@hotmail.com> 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."

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.

* 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.

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

A(Answer):

David Mackenzie:

* 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

A(Answer):

Chung Leong wrote:

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"

A(Answer):

Chung Leong <ch***********@hotmail.com> 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."

I’m missing crosssite (java)scripting bugs: always (html)encode output
(don’t forget ENT_QUOTES), to avoid session hyjacking…

Daniel Tryba

A(Answer):

Yup, that’s a big one, while oft overlooked. I would list that as number
one, since it’s look easy to exploit.

Uzytkownik "Daniel Tryba" <ne****************@canopus.nl> napisal w
wiadomosci news:bv**********@news.tue.nl…

Chung Leong <ch***********@hotmail.com> 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."

I’m missing crosssite (java)scripting bugs: always (html)encode output
(don’t forget ENT_QUOTES), to avoid session hyjacking…

Daniel Tryba

A(Answer):

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.

Uzytkownik "André Næss" <an*********************@ifi.uio.no> napisal w
wiadomosci news:bv*********@maud.ifi.uio.no…

David Mackenzie:

* 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

A(Answer):

Register_globals doesn’t create holes. Programmers do. It pointless to say a
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" <no**********@see.my.signature.con> napisal w
wiadomosci news:40***********************@mercury.nildram.net …

Chung Leong wrote:

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"

A(Answer):

I’m more in favor of giving people who go poking around my site the Apache
access denied error.

Uzytkownik "JimC" <ji**@cross-comp.com> napisal w wiadomosci
news:tJ*****************@newssvr29.news.prodigy.co m…

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.

A(Answer):

On Thu, 05 Feb 2004 15:45:13 +0000, André Næss
<an*********************@ifi.uio.no> wrote:

David Mackenzie:

* 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.

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.


David ( @priz.co.uk )

A(Answer):

In article <pa****************************@hybris.digiserv.ne t>,
"Ian.H" <ia*@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!

A(Answer):

"David Mackenzie" <[email protected]> wrote in message
news:1t********************************@4ax.com…

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.

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

A(Answer):

Interesting scenario. I must admit that’s not one I’ve considered before. It
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" <jb****@donotspam.remove.me.heraldic.us> napisal w
wiadomosci news:Of******************@nwrddc01.gnilink.net…

"David Mackenzie" <[email protected]> wrote in message
news:1t********************************@4ax.com…

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.
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

A(Answer):

Joshua Beall <jb****@donotspam.remove.me.heraldic.us> wrote:
[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

A(Answer):

"Chung Leong" <ch***********@hotmail.com> wrote in
news:p-********************@comcast.com:

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.

A(Answer):

"Daniel Tryba" <ne****************@canopus.nl> wrote in message
news:c0**********@news.tue.nl…

Joshua Beall <jb****@donotspam.remove.me.heraldic.us> wrote:
[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%

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.

A(Answer):

The PHP session id is stored in the cookie.

Uzytkownik "Eric Bohlman" <eb******@earthlink.net> napisal w wiadomosci
news:Xn******************************@130.133.1.17 …

"Chung Leong" <ch***********@hotmail.com> wrote in
news:p-********************@comcast.com:

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.

A(Answer):

Eric Bohlman <eb******@earthlink.net> wrote:

<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

A(Answer):

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.

Uzytkownik "Joshua Beall" <jb****@donotspam.remove.me.heraldic.us> napisal w
wiadomosci news:qo******************@nwrddc02.gnilink.net…

"Daniel Tryba" <ne****************@canopus.nl> wrote in message
news:c0**********@news.tue.nl…

Joshua Beall <jb****@donotspam.remove.me.heraldic.us> wrote:
[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%

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.

A(Answer):

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:uK********************@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 😉

A(Answer):

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.

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" <jb****@donotspam.remove.me.heraldic.us> napisal w
wiadomosci news:Cv******************@nwrddc01.gnilink.net…

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:uK********************@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 😉

A(Answer):

"Chung Leong" <ch***********@hotmail.com> wrote in message news:<id********************@comcast.com>…

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

A(Answer):

On Sat, 7 Feb 2004 13:34:22 -0500, "Chung Leong"
<ch***********@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 )

A(Answer):

Chung Leong <ch***********@hotmail.com> wrote:

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

A(Answer):

Uzytkownik "David Mackenzie" <[email protected]> napisal w wiadomosci
news:04********************************@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.

A(Answer):

The assumption is, of course, you don’t JUST use the referrer for security
🙂

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" <ne****************@canopus.nl> napisal w
wiadomosci news:c0**********@news.tue.nl…

Chung Leong <ch***********@hotmail.com> wrote:

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