php-general Digest 18 Jun 2006 01:04:47 - Issue 4191
Topics (messages 238186 through 238211):
Re: GET, POST, REQUEST
238186 by: Satyam
238187 by: David Tulloh
238188 by: tedd
238189 by: Mark Charette
238194 by: Ben Ramsey
238195 by: Anthony
Yesterday when reading some doc on PHP I noticed the $_REQUEST predefined
array, which looked like a solution to having to check in GET and POST
data (I'm not sure if it will really have an impact on my program yet).
The thing is, I also saw this description:
Variables provided to the script
In general, user input should never be trusted. Someone once told me that
if you ask for yes or no, you should always validate for yes, no and don't
know (of course, this was before windowed environments where the users can
only click what you offer them).
In a web environment you have a
Martin Marques wrote:
Yesterday when reading some doc on PHP I noticed the $_REQUEST
predefined array, which looked like a solution to having to check in GET
and POST data (I'm not sure if it will really have an impact on my
program yet).
Yes, request is simply a merge of these arrays. It
At 8:52 AM -0300 6/17/06, Martin Marques wrote:
Yesterday when reading some doc on PHP I noticed the $_REQUEST predefined
array, which looked like a solution to having to check in GET and POST data
(I'm not sure if it will really have an impact on my program yet).
The thing is, I also saw this
Satyam wrote:
In general, user input should never be trusted. Someone once told me
that if you ask for yes or no, you should always validate for yes, no
and don't know (of course, this was before windowed environments where
the users can only click what you offer them).
Users can submit
On 17/06/06, Richard Lynch [EMAIL PROTECTED] wrote:
I dunno if AJAX will let you quit partway through, but you could
definitely do this with the lean and mean hand-coded XmlHttpRequest
object and sending HEAD to see if the URL is there or not.
For security reasons, an XMLHttpRequest objects
Hi Richard..
On 15/06/06, Richard Lynch [EMAIL PROTECTED] wrote:
HTTP just plain ain't gonna let you open a file up for writing --
thank god.
I think it does in form of PUT requests..
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
(apparently not supported by PHP streams(?))
Security
Well, this is what I've done.
First, made a test on a Fedora Core 2 installation by running
./configure --with etc,etc and --enable-bcmath
Then executed make in order to generate executables but
*DID NOT* run make install
After that, copied manually libphp4.so from the build directory to
On 15/06/06, Andras Kende [EMAIL PROTECTED] wrote:
Is there any drawback servings video files through php downloader script on
high load site?
the question is why you want that?
If you want to log how many times/when the video files were viewed,
you can send the request to a PHP script that
On 6/17/06 9:30 AM, David Tulloh wrote:
Martin Marques wrote:
Yesterday when reading some doc on PHP I noticed the $_REQUEST
predefined array, which looked like a solution to having to check in GET
and POST data (I'm not sure if it will really have an impact on my
program yet).
Yes, request
simply using $_POST is by no means more secure than $_REQUEST.
On 6/17/06, Ben Ramsey [EMAIL PROTECTED] wrote:
On 6/17/06 9:30 AM, David Tulloh wrote:
Martin Marques wrote:
Yesterday when reading some doc on PHP I noticed the $_REQUEST
predefined array, which looked like a solution to
But it would seem that using $_POST cuts down on the number of possible ways
that something bad could happen, doesn't it? (Someone correct me if I am
wrong, I am by no means a security or PHP expert, though working towards
both :D)
On Saturday 17 June 2006 14:51, Anthony Ettinger wrote:
Maybe it is not essential, but shouldn't it say:
header(Content-type: image/jpeg);
notice jpeg - not jpg.
/frank
16 jun 2006 kl. 22.15 skrev Mariano Guadagnini:
Brian Dunning wrote:
I'm trying to serve up a jpeg like this:
header(Content-type: image/jpg);
readfile('images/banner-ad.jpg');
it's more like painting the color of your front door, but still
leaving it unlocked. It doesn't change the fact that people can still
open the door.
every input field needs to be validated regardless of get vs. post.
the web developer toolbar for firefox can easily convert all form
fields to one
On 6/17/06 3:07 PM, Anthony Ettinger wrote:
it's more like painting the color of your front door, but still
leaving it unlocked. It doesn't change the fact that people can still
open the door.
every input field needs to be validated regardless of get vs. post.
the web developer toolbar for
On Sat, 17 Jun 2006 15:01:23 +0200, Satyam [EMAIL PROTECTED] wrote:
In general, user input should never be trusted. Someone once told me that
if you ask for yes or no, you should always validate for yes, no and don't
know (of course, this was before windowed environments where the users can
On Sat, 17 Jun 2006 14:25:30 -0400, Ben Ramsey [EMAIL PROTECTED] wrote:
On 6/17/06 9:30 AM, David Tulloh wrote:
Martin Marques wrote:
Yesterday when reading some doc on PHP I noticed the $_REQUEST
predefined array, which looked like a solution to having to check in
GET
and POST data (I'm
$_REQUEST is not particularly dangerous compared to $_GET or $_POST, it is
just one more validation you can make: if you expect data from a POST,
check it from POST. That's why I mentioned that form where I entered my
personal data, the form was sent as POST but it took a faked GET from me,
On Sat, 17 Jun 2006 09:55:05 -0400, tedd [EMAIL PROTECTED] wrote:
At 8:52 AM -0300 6/17/06, Martin Marques wrote:
Yesterday when reading some doc on PHP I noticed the $_REQUEST predefined
array, which looked like a solution to having to check in GET and POST data
(I'm not sure if it will
On 6/17/06 5:25 PM, Martin Marques wrote:
I know user input shouldn't be trusted. What I want to know is IF and WHY
$_REQUEST should be more untrusted then $_POST or $_GET.
It's untrusted because you know the data comes from a request. It's more
untrusted than GET, POST, or COOKIE because
On 6/17/06 5:34 PM, Satyam wrote:
Your application might require that flexibility or accepting data via
POST or GET, in which case, it is just fine. Contrary to another post
I've read, there is nothing good of register_globals, that is why it is
now defaulted to off and kept for
on 06/17/2006 07:10 PM Ben Ramsey said the following:
On 6/17/06 5:34 PM, Satyam wrote:
Your application might require that flexibility or accepting data via
POST or GET, in which case, it is just fine. Contrary to another
post I've read, there is nothing good of register_globals, that is
On 6/18/06, Ben Ramsey [EMAIL PROTECTED] wrote:
On 6/17/06 5:34 PM, Satyam wrote:
Your application might require that flexibility or accepting data via
POST or GET, in which case, it is just fine. Contrary to another post
I've read, there is nothing good of register_globals, that is why it
So, a secure application always has to validate values from client side
originated variables, independently if the values were retrieved from
$_GET, $_POST, $_COOKIE or $_REQUEST .
You should always validate ALL external variables.
As for server side originated variables, these do not need
Hello,
on 06/17/2006 08:35 PM Rory Browne said the following:
So, a secure application always has to validate values from client side
originated variables, independently if the values were retrieved from
$_GET, $_POST, $_COOKIE or $_REQUEST .
You should always validate ALL external
WINDOW/OFFICE àÃÒÃѺ«×éÍ - ÃѺ¨Ó¹Ó §èÒ æ à§Ô¹´èǹ·Ñ¹·Õ ·Ñ¹ã¨
¢Ò¶١ Licensed Windows XP Pro, win 98, 98 se, Office XP Small, Office
XP Professional, Office Pro 2003 ¶Ù¡ÁÒ¡ ¢Í§á·éá¹è¹Í¹ 100 %
µÔ´µèÍ Paisarn 06-5881135
- Windows 95 ẺÁÕ CD ¤ÃºªØ´ 200 bath
- Windows 98 book+COA only 800 bath
I don't think that using request over post adds anything in the way of
security, at the most it's going to delay an attacker for up to a
minute. I advocate using request if it's convenient, it can also open a
few nice tricks for advanced users. Using request allows me to bookmark
a login page,
WINDOW/OFFICE àÃÒÃѺ«×éÍ - ÃѺ¨Ó¹Ó §èÒ æ à§Ô¹´èǹ·Ñ¹·Õ ·Ñ¹ã¨
¢Ò¶١ Licensed Windows XP Pro, win 98, 98 se, Office XP Small, Office
XP Professional, Office Pro 2003 ¶Ù¡ÁÒ¡ ¢Í§á·éá¹è¹Í¹ 100 %
µÔ´µèÍ Paisarn 06-5881135
- Windows 95 ẺÁÕ CD ¤ÃºªØ´ 200 bath
- Windows 98 book+COA only 800 bath
WINDOW/OFFICE àÃÒÃѺ«×éÍ - ÃѺ¨Ó¹Ó §èÒ æ à§Ô¹´èǹ·Ñ¹·Õ ·Ñ¹ã¨
¢Ò¶١ Licensed Windows XP Pro, win 98, 98 se, Office XP Small, Office
XP Professional, Office Pro 2003 ¶Ù¡ÁÒ¡ ¢Í§á·éá¹è¹Í¹ 100 %
µÔ´µèÍ Paisarn 06-5881135
- Windows 95 ẺÁÕ CD ¤ÃºªØ´ 200 bath
- Windows 98 book+COA only 800 bath
30 matches
Mail list logo
