Stefan Esser wrote:
> My 2cents,
>
> the actually best would be to completely forbid the usage of URLs inside
> include/require and
> introduce a new keyword: include_url that works like the current include
> would work and
> rename allow_url_include into allow_dangerous_urls (for include_url only
Stefan Esser wrote:
> It is very good that bugs in PHP Applications are bad for PHP's image.
> The majority of servers get hacked because of Remote URL Includes (and
> not by XSS/SQL Injection). The existance of Remote URL Includes is fully
> to blame on the PHP engine and is UNIQUE. After years th
My 2cents,
the actually best would be to completely forbid the usage of URLs inside
include/require and
introduce a new keyword: include_url that works like the current include
would work and
rename allow_url_include into allow_dangerous_urls (for include_url only).
Basically this would protect e
Hello Ilia,
what i wanted it a SYSTEM INI setting that allows which streams work
exactly. As opposedto being able to select between all and none while
hoping that the switch works (for the reasons you specified).
best regards
marcus
Saturday, January 13, 2007, 6:22:33 PM, you wrote:
> Marcus,
I thought we also decided to default user streams to be marked as
insecure with some mechanism for overriding it.
-Rasmus
Ilia Alshanetsky wrote:
> Marcus,
>
> You want to use an INI setting to specify which streams are local and
> which are remote? That seems like a recipe for disaster to me, p
Marcus,
You want to use an INI setting to specify which streams are local and
which are remote? That seems like a recipe for disaster to me, people
adjusting this setting many not consider some streams that are remote
etc... leading to security holes. There is really no reason why PHP
cou
Hello Stefan,
i also think something should be done here. The is_url flag does not
really help. What we imho need is an ini setting that allows specifying
which stream handlers to allow. And that should not include user streams.
best regards
marcus
Saturday, January 13, 2007, 5:59:45 PM, you w
> I am not sure I would call it a blacklist. It is a flag in the streams
> layer that marks stream handlers that could possibly make a network
> connection as such and there are only a finite set of stream handlers.
>
Unfortunately there is not a finite set of stream handlers. First of all
the
Stefan Esser wrote:
> It is very good that bugs in PHP Applications are bad for PHP's image.
> The majority of servers get hacked because of Remote URL Includes (and
> not by XSS/SQL Injection). The existance of Remote URL Includes is fully
> to blame on the PHP engine and is UNIQUE. After years th
Stefan Esser wrote:
SELECT xyz FROM abc WHERE product_id IN ( 1,2,3,4,5) <- the list having
dynamic lenght
They have worked in PEAR::DB and some other DBAL's, as a result a lot of
people have come to think of prepared statements as a sprintf() replacement.
By the nature of prepared stateme
Stefan Esser wrote:
Hello Lukas,
Maybe I am missing something. If you are talking about dynamic query
generation in stored routines, then I would think that people who read
the advice over dynamic query generation for PHP, that they would
hopefully also apply those practices to when they are wr
Hello Lukas,
> Maybe I am missing something. If you are talking about dynamic query
> generation in stored routines, then I would think that people who read
> the advice over dynamic query generation for PHP, that they would
> hopefully also apply those practices to when they are writing/using
> s
Stefan Esser wrote:
While it is true that the PHP script is not subject to SQL injection
when the application does not build parts of the query based on
untrusted userinput it is not true that you are not at risk.
Ever heard of stored procedures? And precisely of SQL injection in
stored procedur
Mathieu CARBONNEAUX schrieb:
>> http://us2.php.net/manual/en/ref.pdo.php#pdo.prepared-statements
>>
> Sorry for my buz...
> This piece of manual say the same i've said...
>
Yeah and it is wrong. The manual claims the following:
> The parameters to prepared statements don't need to be quote
> I don't think you've read the section on prepared statements in the
> PDO documentation, because it does mention it there, although it
> doesn't beat you over the head with the seriousness of the problem.
>
> http://us2.php.net/manual/en/ref.pdo.php#pdo.prepared-statements
Sorry for my buz...
> A quick google search for 'sql injection prepared statements' found
> those 2 statements (1 is a security article) very quickly.
> ...And frankly, its not the manual's job to tell you how to
> write secure code. So, this has to be coming from people.
>
Yes but a php security portal that referen
Mathieu CARBONNEAUX souhaite rappeler le message [EMAIL PROTECTED] Re:
[PHP-DEV] Comments on PHP security».
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
>Limits, table names, and several other query parts are protected by
>MediaWiki's query builder. A complex select query might look like this:
>
>$result = $db->select(
># Tables
>array( 'user', 'revision' ),
># Fields
>array( 'user_name', 'rev_timestamp' ),
># Conditions (WHERE)
5
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
19 matches
Mail list logo
