| Re: Shocking amount of PHP security holes? [message #171083 is a reply to message #171078] |
Thu, 23 December 2010 21:16   |
Ignoramus30015
Messages: 4
Registered: December 2010
Karma:
|
Junior Member |
|
|
On 2010-12-23, ?lvaro G. Vicario <alvaro(dot)NOSPAMTHANX(at)demogracia(dot)com(dot)invalid> wrote:
> El 23/12/2010 16:39, Ignoramus30015 escribi?/wrote:
>> I have been looking at my apache logs, and I see a tremendous amount
>> of queries that clearly are attempts to hack me.
>>
>> One typical example
>>
>> 87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET /manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00 HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9 sun4u; X11)" my.site.com
>>
>> Many other examples about, where attackers try to override system
>> variables with web-supplied parameters. Kind of overriding PATH or
>> LD_LIBRARY_PATH variables to subvert setuid programs.
>>
>> My main question is WTF? Why exactly does PHP let remote web users
>> override those variables?
>
> It was a wrong design decision taken by the PHP team many years ago. In
> earlier versions PHP would automatically create variables from several
> input sources so you could code <input type="text" name="email"> and
> automatically get user data available at $email. After that, the web
> evolved, security become a concern and this feature was (kind of) disabled.
Thanks. Is there a way to for sure disable it, across the board, for
all PHP programs?
That is, to say that no web parameters go into global variables, and
unless php code queries some specific object or whatever to get a web
parameter, the parameter is not available.
>
>> This situation is why I never permit php software on my servers, with
>> exception of mediawiki. Even here I am very reluctant.
>>
>> I use another language to make websites, and in that language web
>> parameters can be received by querying for them specifically, they do
>> not clobber system variables.
>>
>> Can someone shed light on this, this question bugs me a great deal.
>
> PHP has two main issues regarding security.
>
> First, it's a very popular language and you need little skills to write
> your first simple script. As a result, it's being used by hordes of
> amateurs who have no programming background and are not fully aware of
> what they're doing.
I understand. I did not want to make it into a language flamewar by
saying "language X is better than language Y".
I just think that by stuffing script input into regular variables,
this creates a numbr of traps for the unwary.
> Secondly, hosting services are extremely reluctant to upgrade to newer
> versions and tend to configure their PHP set-ups with insecure settings
> with backward compatibility in mind (so they receive less support
> tickets due to legacy apps not working).
True
> So there're a lot of automated exploits that seek to abuse security
> wholes fixed years ago on poorly written apps running on badly
> configured servers. It's worth the effort if only for the Law of Large
> Numbers. I suppose there aren't many bad coders writing web sites in C++ ;-)
Do you know if mediawiki has any recently known security holes
exploitable by non-registered users?
i
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]