Categories
- Advertising (1)
- Artificial Intelligence (AI) (10)
- Classification (2)
- Coding / Programming (6)
- Cryptography (1)
- Data Mining (11)
- ewrt linux (2)
- Fixing Stuff (5)
- Machine Learning (21)
- Math (1)
- Politics (2)
- Psychology (3)
- Ramblings (19)
- Random (6)
- Security (13)
- Society (9)
- Sociology (3)
- spam (2)
- Statistics (9)
Latest Postings
- August 14, 2008 11:13 pm: CAPTCHAs - Not dead
- August 1, 2008 10:25 pm: ISC on the Future of Anti-Virus Protection
- July 12, 2008 4:41 pm: The cloud obscuring the scientific method
- June 22, 2008 5:05 pm: Debugging and Evaluating Predictive Models
- May 21, 2008 8:08 pm: Cult of the Amateur
- April 21, 2008 1:38 am: ART OF SEDUCTION: Not Pretty, Really
- March 25, 2008 2:25 am: "Internal Server Error" when converting phpBB v2 to phpBB v3
- March 6, 2008 1:29 am: Firewire and DRM
- February 28, 2008 10:46 pm: Using Psychological Domain Knowledge for the Netflix Challenge
- February 12, 2008 1:24 am: VPN Tunnels from within VMWare (Windows XP and GRE weirdness)
Links
Blogroll
Useful Links
Archives
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
Safe Strings in PHP (2)
I wrote about the problems with PHP strings here and the possible solution I liked using a class encapsulating strings in PHP. I now worked out some details to make every string function in PHP work with the new “SafeString”-class. You can find the details and source here. This is still more a proof-of-concept and for all practical purposes would require the re-writing of a couple of things like database abstraction layers and such to return SafeStrings as well.
January 20, 2008 9:18 pm at 9:18 pm (January 20, 2008)
I was struck by the complexity of your solution to the safety (”injection”) issue for strings in PHP that come from a user.
I, too, have produced programmed solutions to other PHP problems.
I now believe that the proper solution is to fix PHP and/or the other components of Web programming. Something that you always want done should be done in the language or computer system, not in explicit coding.
Since the environment (the server programming tools) know which strings come from users and which do not, they can implement safety automatically.
If the maintainers of PHP are reluctant to improve it in areas such as string safety, that is a political or psychological problem only, and could be solved by proper justification.
After all, PHP has had some large changes in its history already, and people accepted them. A great example of this is the unsafe automatic importation of all GET and POST data into global variables, which is no longer done.
As a former professional compiler writer and language designer, I am well aware of the tradeoff between keeping a language fixed (standard) and improving it. But there are well-known ways to manage this process, such as the standards development policies of Ada and Fortran. In PHP, a simple directive could enable or disable a new feature like automatic safe strings. To gain the advantages, webmasters or programmers would only have to add one line to each PHP page or to the site’s .htaccess file or the equivalent to enable the feature, and remove any existing safety code.
I can’t see why the maintainers of PHP should object.
David Spector
Springtime Software