Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: [tlug] Do you whitelist or blacklist utf-8?
- Date: Fri, 25 Feb 2011 10:02:36 +0900
- From: Edmund Edgar <lists@example.com>
- Subject: Re: [tlug] Do you whitelist or blacklist utf-8?
- References: <4D639689.1010302@example.com> <4D63EFBC.1020900@example.com> <4D64C5DD.1040607@example.com> <4D64CB49.10906@example.com> <4D652AF5.10304@example.com> <4D655712.1090608@example.com> <37687.61.213.3.170.1298510044.squirrel@example.com> <4D661A15.8010009@example.com> <4D666540.5000705@example.com> <4D66EF27.7070905@example.com>
On 25 February 2011 08:52, Darren Cook <darren@example.com> wrote: > As far as I know most of PHP's bad security reputation is due to bad > practices in frameworks and software built with PHP, and mostly before > attacks such as XSS has even been invented. It wasn't just PHP users - there was a lot of brain damage in the language which encouraged insecure software. PHP4 then kept changing to fix the said brain damage, which sometimes made the situation even worse. For example, by default, request input coming into a PHP script used to be automatically sql-sanitized - corresponding to a function called addslashes() - in case you wanted to put it into a database SQL statement. If you wanted to display that data right there in the browser, or write it to a file, you would then have to run it through stripslashes() to get rid of the sql escaping. This is obviously the Wrong Way To Do It - you should use bound parameters instead (which required a third-party library in PHP, long after it was the standard way for everyone else to do it), or failing that escape stuff right before it goes into the database. When they realized that they shouldn't be doing this, the PHP developers turned this automatic escaping off by default. But you still had a bunch of old PHP web applications floating around that assumed that input would already have been sql-sanitized. So an app that would have been secure as originally written suddenly became a massive security hole if set up by someone who didn't understand this stuff - and one of the main motivations for using someone else's PHP application was that it could be installed on any cheap web hosting site, without having to learn all this tricky stuff about sanitizing input and understanding configuration files. The serious brain damage was largely fixed not far into PHP4, and PHP5 is mostly non-bonkers. But if you've got code that was originally written for old PHP4 defaults, it may still contain assumptions that make it insecure to run on a default-configured PHP5. -- Edmund Edgar Founder, KK Social Minds Educational Technology for the Web and Virtual Worlds ed@example.com +81 090 3912 3380 Skype: edmundedgar Second Life: Edmund Earp Linked In: edmundedgar Twitter: @edmundedgar http://www.socialminds.jp
- References:
- [tlug] Do you whitelist or blacklist utf-8?
- From: Dave M G
- Re: [tlug] Do you whitelist or blacklist utf-8?
- From: Shmuel Fomberg
- Re: [tlug] Do you whitelist or blacklist utf-8?
- From: Dave M G
- Re: [tlug] Do you whitelist or blacklist utf-8?
- From: Shmuel Fomberg
- Re: [tlug] Do you whitelist or blacklist utf-8?
- From: Dave M G
- Re: [tlug] Do you whitelist or blacklist utf-8?
- From: Shmuel Fomberg
- Re: [tlug] Do you whitelist or blacklist utf-8?
- From: Nikolay Elenkov
- Re: [tlug] Do you whitelist or blacklist utf-8?
- From: Darren Cook
- Re: [tlug] Do you whitelist or blacklist utf-8?
- From: Nikolay Elenkov
- Re: [tlug] Do you whitelist or blacklist utf-8?
- From: Darren Cook
Home | Main Index | Thread Index
- Prev by Date: Re: [tlug] Do you whitelist or blacklist utf-8?
- Next by Date: Re: [tlug] I'll have to pay someone to do this Javascript (small job offer)
- Previous by thread: Re: [tlug] Do you whitelist or blacklist utf-8?
- Next by thread: Re: [tlug] Do you whitelist or blacklist utf-8?
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links