Re: [Full-disclosure] Critical PHP bug - act ASAP if you are running web with sensitive data

[Jasper Bryant-Greene <jasper@xxxxxxxxxxx>]

Jasper Bryant-Greene wrote:
> Moriyoshi Koizumi wrote:
> > Jasper Bryant-Greene wrote:
> >
> > > I very much doubt there are many applications at all containing code 
> > > like this. It is illogical to be decoding html entities from user 
> > > input. Therefore I would not call this a "very serious problem" and 
> > > certainly not a critical bug.
> >
> > Not really. While this is not part of the HTML / HTTP standards, major 
> > browsers
> > around try to send such characters in the user input as HTML entities 
> > that cannot
> > all be represented in the encoding of the originating HTML page, it's 
> > quite probable
> > the function is used to filter the query strings.
>
> Indeed, it probably is, but hopefully the results of that are not then 
> echoed out to the browser without running htmlspecialchars() etc on 
> them... If they are (which is the root of this "security problem") then 
> that is the fault of the idiot who wrote the code, not PHP. You can only 
> protect users from their own stupidity to a certain degree...

OK, ignore that, forgot what we were talking about for a while there :)

htmlspecialchars() should still be run on the output, otherwise you have 
another security hole, but of course that won't protect against sending 
memory contents back to the user...

--
Jasper Bryant-Greene
General Manager
Album Limited

http://www.album.co.nz/     0800 4 ALBUM
jasper@xxxxxxxxxxx          021 708 334

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/