Common Sense and Websites

Just recently, I ran across the third Wordpress weblog in my feed list that had been hit with spam via what I assume to be the vulnerability fixed in version 2.3.1. It only shows up in feed readers, because it uses CSS to hide itself on the regular pages. That CSS is stripped by most feed readers' sanitizing process that removes all markup that may be malicious.

The striking thing about it is that all of the weblogs were related to web development: one was on a personal browser developer's website, one was a prominent web development news site, and the most recent one was the official weblog of a web browser. Now, I'm not necessarily putting the single browser developer at fault, since web applications aren't necessarily his area of interest. His webhost should make sure that classic security holes (like PHP's register_globals option) are turned offor disabled. On the other hand, the other two sites should know better. The web development news site has a significant number of posts on web application security, and the browser vendor deals with the security of its product every day, so surely they should be monitoring (or at least, find an automated process to monitor) feeds such as the ones at the National Vulnerability Database, in case exploits are discovered for any web applications that they may have installed.

To everyone else, if you can, please make sure that your webhosting environment is properly secured. Also, definitely subscribe to the news feeds of all the web applications that you run, because more often than not, there will be security vulnerabilities discovered, so you should upgrade as soon as possible in those cases.

HOWTO restrict ssh access by IP and user

There's a way to restrict access to a user account or set of user accounts via PAM (and by extension, SSH)—the obviously named pam_access module. It's available on Gentoo Linux in sys-libs/pam, and on Debian Linux (and I assume the derivatives) in libpam-modules.

In order to enable this module for SSH, you have to edit the SSH's PAM file (Gentoo: /etc/pam.d/sshd; Debian: /etc/pam.d/ssh) to enable the access module: account required pam_access.so

There's some pretty good documentation in /etc/security/access.conf (at least, in the default distribution of it) on how to configure the file, but one thing that it doesn't say explicitly is that you can use IP address blocks in CIDR notation to denote access privileges. For instance, if I wanted to limit bob to the local network (192.168.0.*) and the VPN (172.16.*). The configuration line for that would be:

-:ALL EXCEPT bob:192.168.0.0/24 172.16.0.0/16

Re: Protecting a JavaScript Service

In How to Protect a JSON or Javascript Service, Joe Walker looks at a few solutions such as:

1. Use a Secret in the Request
2. Force pre-eval() Processing
3. Force POST requests

The last time that I worked on an JSON-based web application, I did number 1, sort of. I basically implemented a simplified version of HTTP digest authentication in order to send a username and password to the server. In order to accomplish this, I used an nonce plus a JavaScript implementation of the SHA-1 hash function.

If I were to reimplement the user authentication portion today, I would probably use this "clipperz" library that I also found on Ajaxian. I'm amazed that someone has implemented AES in JavaScript. I would think that it would be difficult, although I haven't read the specification for it. Maybe one of these days I'll implement the Diffie-Hellman key exchange, if I get bored enough or I need it for something.