php-general Digest 23 Aug 2007 10:44:37 -0000 Issue 4977
Topics (messages 261140 through 261156):
Re: Announcement: Releasing CORE GRASP for PHP. An open source, dynamic web
application protection system.
261140 by: mike
261143 by: Chris
261145 by: mike
261146 by: Chris
261147 by: mike
Recompiling PHP with mssql
261141 by: Liz Kim
261144 by: Chris
Re: using disable_functions silently
261142 by: Chris
261150 by: Samuel Vogel
261152 by: Craige Leeder
261154 by: Chris
261155 by: Craige Leeder
Upload and resize file
261148 by: Beauford
261151 by: Craige Leeder
Re: Releasing CORE GRASP for PHP. An open source, dynamic web application
protection system.
261149 by: Daevid Vincent
Re: Outputting a PDF.
261153 by: Craige Leeder
read only?
261156 by: coolcoder
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
On 8/22/07, M. Sokolewicz <[EMAIL PROTECTED]> wrote:
> because such options slow down the execution of every PHP script, even
> though "disabled".
compile time options wouldn't be much of a slowdown.
and in my mind, with CPU power being quite cheap, i could see it being
more valuable to have more bounds checking, security checks, etc, etc.
add that extra couple ms per request...
there's probably a lot more bloat that could be cut down on in place
of a more robust layer of security. PHP has some reputation for being
insecure, mainly due to the people writing crappy apps - but if the
engine itself cut down on allowing those crappy apps it would cut down
on them being exploitable (can't fix the code for them, but perhaps
fix them from being exploited to begin with)
--- End Message ---
--- Begin Message ---
Daevid Vincent wrote:
-----Original Message-----
From: mike [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 22, 2007 1:32 PM
I thing a good FAQ entry would be how this patch fits in
with Suhosin
and what are the comparable/conflicting concepts, are they
compatible
with each other etc.
http://www.hardened-php.net/suhosin/a_feature_list.html
Both systems are liable to appeal to the same sort of
people so it makes
sense to cover this.
What I do not understand is why don't these patches get put instantly
back into the core PHP distribution? So patches against 5.2.3 perhaps
would be in 5.2.4, etc?
IMHO there shouldn't be a hardened PHP project. Their patches should
be put in whenever possible, perhaps during an RCx before a gold build
or something. Any loss of functionality due to them should be a
configuration option to turn on/off but otherwise everyone would
benefit from security, memory leak, and other patches...
- mike
Amen to that... I too don't see why the 'fork' or add on... It should
just be a normal compile time switch, like --with-suhosin or
--with-grasp or something like you do everything else. In fact, I'd
almost be swayed into a --with-out-suhosin and --with-out-grasp options
instead, and make this stuff default so that even newb' installations
would be less susceptible to attack -- they're probably the ones that
need the most security!
That's a completely wrong assumption. PhpBB has had a lot of
vulnerabilities in the past, as has php-nuke and other popular packages.
They've been around for years and not written by newbie's as far as I
know - but I don't have any link to either package I just mentioned.
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
On 8/22/07, Chris <[EMAIL PROTECTED]> wrote:
> That's a completely wrong assumption. PhpBB has had a lot of
> vulnerabilities in the past, as has php-nuke and other popular packages.
>
> They've been around for years and not written by newbie's as far as I
> know - but I don't have any link to either package I just mentioned.
both of those packages are spaghetti code. they started from something
small and grew. combine adding features on top + development teams of
different skills, backgrounds and language barriers and you typically
get a very diverse codebase. when code isn't as tight, it opens itself
up for having inconsistent methods of doing things - perhaps someone
wrote an XSS-safe feature, but someone else didn't reuse that portion
or reused it incorrectly.
i think that's pretty common sense. i coded my own forum from scratch,
and while not as feature-rich as phpbb, nothing in it can be exploited
like that. each feature i add on top of it is also that tight. but i
am a single developer, i know everything i have done. adding other
people i would expect that it would not be as tight. it is the problem
with all projects.
--- End Message ---
--- Begin Message ---
mike wrote:
On 8/22/07, Chris <[EMAIL PROTECTED]> wrote:
That's a completely wrong assumption. PhpBB has had a lot of
vulnerabilities in the past, as has php-nuke and other popular packages.
They've been around for years and not written by newbie's as far as I
know - but I don't have any link to either package I just mentioned.
both of those packages are spaghetti code. they started from something
small and grew. combine adding features on top + development teams of
different skills, backgrounds and language barriers and you typically
get a very diverse codebase. when code isn't as tight, it opens itself
up for having inconsistent methods of doing things - perhaps someone
wrote an XSS-safe feature, but someone else didn't reuse that portion
or reused it incorrectly.
i think that's pretty common sense. i coded my own forum from scratch,
and while not as feature-rich as phpbb, nothing in it can be exploited
like that. each feature i add on top of it is also that tight. but i
am a single developer, i know everything i have done. adding other
people i would expect that it would not be as tight. it is the problem
with all projects.
I agree with all you've said - but saying that a hardened-php type
project should only be installed for a 'newbie' installation is just wrong.
You can't possibly audit every single line of code that is going to be
run on your server.
The two packages I mentioned are very popular and are run all over the
place - if I'm running the server that one of these packages are
installed on, then I'm of course going to do all I can to make sure it's
secure as possible.
I'm agreeing with the ideas behind Grasp & Suhosin - I'm just
disagreeing with Daevid's comment about them only being for 'newbie'
installations.
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
On 8/22/07, Chris <[EMAIL PROTECTED]> wrote:
> I'm agreeing with the ideas behind Grasp & Suhosin - I'm just
> disagreeing with Daevid's comment about them only being for 'newbie'
> installations.
oh, most definately. i consider myself a very tight coder - but i'd
prefer to have them in my PHP install as well. i mean, why not? sorry
i misunderstood! i want these in the core PHP source for everyone,
newbies or not!
--- End Message ---
--- Begin Message ---
Hi,
I am trying to install Microsoft SQL server functions to PHP 4.3.9 on
redhat.
When PHP was first installed, it was not configured to include the MSSQL
functions.
I would like to only add these functions and not touch what is already
there...
How do I proceed? Any help would be greatly appreciated.
Thank you,
LK
--- End Message ---
--- Begin Message ---
Liz Kim wrote:
Hi,
I am trying to install Microsoft SQL server functions to PHP 4.3.9 on
redhat.
When PHP was first installed, it was not configured to include the MSSQL
functions.
I would like to only add these functions and not touch what is already
there...
There could be a php-mssql package you can install if you're using rpm's
to do all the work.
If you're not then the php site has good info about what you need to do:
http://php.net/mssql
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
Samuel Vogel wrote:
I would like to know, if there is any way, to use disable_functions
silently.
We are running an shared hosting environment and therefore forbid the
use of exec() etc.
Many of our users, just seem to be to dumb to comment out exec() in
phpBB etc.
Since removing the exec()-calls works fine, is there any way to just
omit them silently from the server side?
Don't think so. The code just needs to handle it better. I do it like this:
$disabled_functions = explode(',', str_replace(' ', '',
ini_get('disable_functions')));
if (!in_array('set_time_limit', $disabled_functions)) {
set_time_limit(0);
}
Works every time :)
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
Unfortunately we would need a solution without changing the PHP code of
our users.
No way to do that?
Regards,
Samy
Chris schrieb:
Samuel Vogel wrote:
I would like to know, if there is any way, to use disable_functions
silently.
We are running an shared hosting environment and therefore forbid the
use of exec() etc.
Many of our users, just seem to be to dumb to comment out exec() in
phpBB etc.
Since removing the exec()-calls works fine, is there any way to just
omit them silently from the server side?
Don't think so. The code just needs to handle it better. I do it like
this:
$disabled_functions = explode(',', str_replace(' ', '',
ini_get('disable_functions')));
if (!in_array('set_time_limit', $disabled_functions)) {
set_time_limit(0);
}
Works every time :)
--- End Message ---
--- Begin Message ---
Are you *running* a shared hosting environment? If so, what is to stop
you from adding the exec() function to the list in php.ini?
- Craige
> > Don't think so. The code just needs to handle it better. I do it like
> > this:
> >
> > $disabled_functions = explode(',', str_replace(' ', '',
> > ini_get('disable_functions')));
> >
> > if (!in_array('set_time_limit', $disabled_functions)) {
> > set_time_limit(0);
> > }
> >
> > Works every time :)
> >
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Craige Leeder wrote:
Are you *running* a shared hosting environment? If so, what is to stop
you from adding the exec() function to the list in php.ini?
He wants php to automatically ignore functions listed in the
'disabled_functions' list - which there is no way to do.
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
Oh, okay. He simply wants to ignore them without raising any flags to
say it has been done. I get what he wants. However, as you stated,
there is no way to do this (to the best of my knowledge).
- Craige
On 8/23/07, Chris <[EMAIL PROTECTED]> wrote:
> Craige Leeder wrote:
> > Are you *running* a shared hosting environment? If so, what is to stop
> > you from adding the exec() function to the list in php.ini?
>
> He wants php to automatically ignore functions listed in the
> 'disabled_functions' list - which there is no way to do.
>
> --
> Postgresql & php tutorials
> http://www.designmagick.com/
>
--- End Message ---
--- Begin Message ---
I downloaded this 'upload and resize image' script, and since I have no idea
what I am looking at as this is something I have never done, could someone
have a look and see what the problem might be. I've been searching around
but haven't come across anything that makes any sense yet.
When a picture needs to be resized I am getting the following error. If it
is the same size or under I don't get this error.
Warning: unlink() [function.unlink]: No such file or directory in
/usr/local/apache/htdocs/website/upload.php on line 92
The full code is below.
Thanks
------------------------------------------------------------------
<html>
<head>
<title>web.blazonry : PHP : Upload and Resize an Image</title>
<?php
if ($_SERVER['REQUEST_METHOD'] == "POST")
{
/* SUBMITTED INFORMATION - use what you need
* temporary filename (pointer): $imgfile
* original filename : $imgfile_name
* size of uploaded file : $imgfile_size
* mime-type of uploaded file : $imgfile_type
*/
/*== upload directory where the file will be stored
relative to where script is run ==*/
$uploaddir = "images";
/*== get file extension (fn at bottom of script) ==*/
/*== checks to see if image file, if not do not allow upload ==*/
$pext = getFileExtension($imgfile_name);
$pext = strtolower($pext);
if (($pext != "jpg") && ($pext != "jpeg"))
{
print "<h1>ERROR</h1>Image Extension Unknown.<br>";
print "<p>Please upload only a JPEG image with the extension .jpg or
.jpeg ONLY<br><br>";
print "The file you uploaded had the following extension:
$pext</p>\n";
/*== delete uploaded file ==*/
unlink($imgfile);
exit();
}
//-- RE-SIZING UPLOADED IMAGE
/*== only resize if the image is larger than 250 x 200 ==*/
$imgsize = GetImageSize($imgfile);
/*== check size 0=width, 1=height ==*/
if (($imgsize[0] > 250) || ($imgsize[1] > 200))
{
/*== temp image file -- use "tempnam()" to generate the temp
file name. This is done so if multiple people access the
script at once they won't ruin each other's temp file ==*/
$tmpimg = tempnam("/tmp", "MKUP");
/*== RESIZE PROCESS
1. decompress jpeg image to pnm file (a raw image type)
2. scale pnm image
3. compress pnm file to jpeg image
==*/
/*== Step 1: djpeg decompresses jpeg to pnm ==*/
system("djpeg $imgfile >$tmpimg");
/*== Steps 2&3: scale image using pnmscale and then
pipe into cjpeg to output jpeg file ==*/
system("pnmscale -xy 250 200 $tmpimg | cjpeg -smoo 10 -qual 50
>$imgfile");
/*== remove temp image ==*/
unlink($tmpimg);
}
/*== setup final file location and name ==*/
/*== change spaces to underscores in filename ==*/
$final_filename = str_replace(" ", "_", $imgfile_name);
$newfile = $uploaddir . "/$final_filename";
/*== do extra security check to prevent malicious abuse==*/
if (is_uploaded_file($imgfile))
{
/*== move file to proper directory ==*/
if (!copy($imgfile,"$newfile"))
{
/*== if an error occurs the file could not
be written, read or possibly does not exist ==*/
print "Error Uploading File.";
exit();
}
}
/*== delete the temporary uploaded file ==*/
unlink($imgfile);
print("<img src=\"images\\$final_filename\">");
/*== DO WHATEVER ELSE YOU WANT
SUCH AS INSERT DATA INTO A DATABASE ==*/
}
?>
</head>
<body bgcolor="#FFFFFF">
<h2>Upload and Resize an Image</h2>
<form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="POST"
enctype="multipart/form-data">
<input type="hidden" name="MAX_FILE_SIZE" value="50000">
<p>Upload Image: <input type="file" name="imgfile"><br>
<font size="1">Click browse to upload a local file</font><br>
<br>
<input type="submit" value="Upload Image">
</form>
</body>
</html>
<?php
/*== FUNCTIONS ==*/
function getFileExtension($str) {
$i = strrpos($str,".");
if (!$i) { return ""; }
$l = strlen($str) - $i;
$ext = substr($str,$i+1,$l);
return $ext;
}
?>
--- End Message ---
--- Begin Message ---
While I'm not 100% sure, I'd say something's wrong with this line:
system("pnmscale -xy 250 200 $tmpimg | cjpeg -smoo 10 -qual 50
>$imgfile");
I would say that Linux is not writing the output to the location
stored in $imgfile, and thus there is no file there to delete.
However, I can not really be sure. Can someone support or deny this
claim?
- Craige
On 8/22/07, Beauford <[EMAIL PROTECTED]> wrote:
> I downloaded this 'upload and resize image' script, and since I have no idea
> what I am looking at as this is something I have never done, could someone
> have a look and see what the problem might be. I've been searching around
> but haven't come across anything that makes any sense yet.
>
> When a picture needs to be resized I am getting the following error. If it
> is the same size or under I don't get this error.
>
> Warning: unlink() [function.unlink]: No such file or directory in
> /usr/local/apache/htdocs/website/upload.php on line 92
>
> The full code is below.
>
> Thanks
>
> ------------------------------------------------------------------
>
> <html>
>
> <head>
> <title>web.blazonry : PHP : Upload and Resize an Image</title>
>
> <?php
>
> if ($_SERVER['REQUEST_METHOD'] == "POST")
> {
>
> /* SUBMITTED INFORMATION - use what you need
> * temporary filename (pointer): $imgfile
> * original filename : $imgfile_name
> * size of uploaded file : $imgfile_size
> * mime-type of uploaded file : $imgfile_type
> */
>
> /*== upload directory where the file will be stored
> relative to where script is run ==*/
>
> $uploaddir = "images";
>
>
> /*== get file extension (fn at bottom of script) ==*/
> /*== checks to see if image file, if not do not allow upload ==*/
> $pext = getFileExtension($imgfile_name);
> $pext = strtolower($pext);
> if (($pext != "jpg") && ($pext != "jpeg"))
> {
> print "<h1>ERROR</h1>Image Extension Unknown.<br>";
> print "<p>Please upload only a JPEG image with the extension .jpg or
> .jpeg ONLY<br><br>";
> print "The file you uploaded had the following extension:
> $pext</p>\n";
>
> /*== delete uploaded file ==*/
> unlink($imgfile);
> exit();
> }
>
>
> //-- RE-SIZING UPLOADED IMAGE
>
> /*== only resize if the image is larger than 250 x 200 ==*/
> $imgsize = GetImageSize($imgfile);
>
> /*== check size 0=width, 1=height ==*/
> if (($imgsize[0] > 250) || ($imgsize[1] > 200))
> {
> /*== temp image file -- use "tempnam()" to generate the temp
> file name. This is done so if multiple people access the
> script at once they won't ruin each other's temp file ==*/
> $tmpimg = tempnam("/tmp", "MKUP");
>
> /*== RESIZE PROCESS
> 1. decompress jpeg image to pnm file (a raw image type)
> 2. scale pnm image
> 3. compress pnm file to jpeg image
> ==*/
>
> /*== Step 1: djpeg decompresses jpeg to pnm ==*/
> system("djpeg $imgfile >$tmpimg");
>
>
> /*== Steps 2&3: scale image using pnmscale and then
> pipe into cjpeg to output jpeg file ==*/
> system("pnmscale -xy 250 200 $tmpimg | cjpeg -smoo 10 -qual 50
> >$imgfile");
>
> /*== remove temp image ==*/
> unlink($tmpimg);
>
> }
>
> /*== setup final file location and name ==*/
> /*== change spaces to underscores in filename ==*/
> $final_filename = str_replace(" ", "_", $imgfile_name);
> $newfile = $uploaddir . "/$final_filename";
>
> /*== do extra security check to prevent malicious abuse==*/
> if (is_uploaded_file($imgfile))
> {
>
> /*== move file to proper directory ==*/
> if (!copy($imgfile,"$newfile"))
> {
> /*== if an error occurs the file could not
> be written, read or possibly does not exist ==*/
> print "Error Uploading File.";
> exit();
> }
> }
>
> /*== delete the temporary uploaded file ==*/
> unlink($imgfile);
>
>
> print("<img src=\"images\\$final_filename\">");
>
> /*== DO WHATEVER ELSE YOU WANT
> SUCH AS INSERT DATA INTO A DATABASE ==*/
>
> }
> ?>
>
>
> </head>
> <body bgcolor="#FFFFFF">
>
> <h2>Upload and Resize an Image</h2>
>
> <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="POST"
> enctype="multipart/form-data">
> <input type="hidden" name="MAX_FILE_SIZE" value="50000">
>
> <p>Upload Image: <input type="file" name="imgfile"><br>
> <font size="1">Click browse to upload a local file</font><br>
> <br>
> <input type="submit" value="Upload Image">
> </form>
>
> </body>
> </html>
>
> <?php
> /*== FUNCTIONS ==*/
>
> function getFileExtension($str) {
>
> $i = strrpos($str,".");
> if (!$i) { return ""; }
>
> $l = strlen($str) - $i;
> $ext = substr($str,$i+1,$l);
>
> return $ext;
>
> }
> ?>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: mike [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 22, 2007 6:22 PM
> On 8/22/07, Chris <[EMAIL PROTECTED]> wrote:
> > I'm agreeing with the ideas behind Grasp & Suhosin - I'm just
> > disagreeing with Daevid's comment about them only being for 'newbie'
> > installations.
>
> oh, most definately. i consider myself a very tight coder - but i'd
> prefer to have them in my PHP install as well. i mean, why not? sorry
> i misunderstood! i want these in the core PHP source for everyone,
> newbies or not!
I think you misunderstood what I was saying as well...
> Amen to that... I too don't see why the 'fork' or add on... It should
> just be a normal compile time switch, like --with-suhosin or
> --with-grasp or something like you do everything else. In fact, I'd
> almost be swayed into a --with-out-suhosin and
> --with-out-grasp options
> instead, and make this stuff default so that even newb' installations
> would be less susceptible to attack -- they're probably the ones that
> need the most security!
I was at first suggesting these security hacks be something one has to
explicitly enable.
Then I thought about it, and thought they should be default "on", and
you would have to explicitly turn them "off" if you didn't want them.
Related to that was that most newb's wouldn't necessarily know to enable
these features on one hand, and they are the types of sites that hackers
would target -- low hanging fruit as it were.
I work in a security company, and we use LAMP/Ruby almost exclusively. I
would (as a professional and expert) ALSO welcome these security hacks
on by default. So it's a win-win for everyone.
The few extra ms to execute some secure code is well worth it IMHO over
the chance of a XSS or script kiddie causing me hours of grief later.
So in effect, we're on the same page I think.
(p.s. I removed the 'Announcement' portion of the subject, because like
other people I'm sure, I color code the subjects based upon certain key
words. Announcements are in red for me, and this get's "alarming". ;-) )
D.Vin
http://daevid.com
--- End Message ---
--- Begin Message ---
Rob,
This has to be a browser problem. I cannot see it being anything else.
For arguments sake however, would you mind showing us your code. While
I'm sure it is a browser issue, it may have something to do with what
PHP is returning to the browser.
- Craige
On 8/22/07, Rob Adams <[EMAIL PROTECTED]> wrote:
> I have a pdfs saved in a database (created with pdflib). When I output them
> in firefox, it works just great everytime. But when I try in IE, it doesn't
> always work. I know, I know, it sounds like a browser issue, but here's the
> problem. I figured out that when I run session_start(), the pdf never shows
> up in IE. When I don't run it, it works just as well as in firefox. When I
> put my header calls to set the content type to application/pdf before the
> session_start() call, IE spits out an error:
>
> "Internet Explorer cannot display the webpage
>
> Most likely causes:
> You are not connected to the Internet.
> The website is encountering problems.
> There might be a typing error in the address. "
>
> Anyone know of a fix for this?
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Is there a simple php way to make a webpage read-only, please?
www.coderewind.com
Best Place to hunt for Code
--
View this message in context:
http://www.nabble.com/read-only--tf4316703.html#a12291195
Sent from the PHP - General mailing list archive at Nabble.com.
--- End Message ---
