Entries tagged 'security'

what is it about websites for government entities that result in login systems that try to do something clever that just falls down in the real world? treasurydirect used to have a password entry system that relied on a virtual keyboard, which was an accessibility nightmare and of course did not play nicely with a password manager. calsavers, the state of california’s retirement savings program does something fancy when submitting passwords that results in apple’s built-in password management wanting to save the transformed password on every log in, which means the saved password no longer works.

one small project i have in mind is to explore passkeys and how to implement them, and i sure wish the folks at calsavers had spent time on that rather than whatever janky client-side password chicanery they have going on now.

stefan esser has dug up and fixed more php xml-rpc vulnerabilities, and best of all, has worked with the package maintainers to purge them of their use of eval().

stefan can be a bit of a blowhard, but it’s excellent work like this that makes that easier to swallow.

stefan esser dissects one tip in a bad article about php, but is merciful in leaving the others alone. one thing you’ll note if you line up this second article with the first article is that not only are the tips not very good, the author can’t count to ten.

and on the useful-php-news front, andrei’s unicode work* has landed in the php development tree, and rasmus sparked a long discussion of other php6 features. the perennially lost cause of trying to rename functions and change their argument order resurfaces, of course, but it doesn’t look like anyone is taking it all that seriously.

the race is now on between perl6 and php6.

• other people have been involved, i’m sure. i just don’t know who they are.

there was a hole in the pear xml-rpc package, and as a result many php-based applications had a security hole as a result, such as the many php blogging apps.

the thing is, this came about because the xml-rpc library builds up some code and calls eval(). whoever wrote code to parse xml-rpc by building code and calling eval() should have their computer taken away. and then possibly be beaten with it.

the pear code is actually a fork of edd dumbill’s php xml-rpc code, and this is not the first security hole that has been discovered in that code as a result of this positively shameful architecture. i will not be at all surprised if it is not the last.

and for those keeping score at home, i pointed out how dumb this was almost four years ago.

here’s a few resources that someone may find helpful:

• php’s htmlspecialchars() function, useful for encoding user input that may contain characters like <
• php’s addslashes() function, useful for escaping user input for putting into an sql query (even better is to use a parameter-based query api)
• a list of the top ten php security vulnerabilities

and don’t forget that in php, variables like $_SERVER['REQUEST_URI'] and $_SERVER['HTTP_REFERER'] are user input.