Posts Tagged ‘security’

Caja and JavaScript Security

People have been worrying about cross-site scripting, and have been careful in dealing with user input data, typically by filtering out undesired HTML elements. There are now certain applications that cannot afford to filter out user-generated scripts, such as gadgets in iGoogle and OpenSocial, and facebook applications. These applications must run user-submitted JavaScript, often inside the same webpages that are linked to very sensitive information. It would be a disaster if iGoogle gadgets get access to your GMail account, or a facebook application access your profile when you don’t want it to.

The sandbox feature of JavaScript language was not designed to handle this situation. IFrame can offer desired isolation of untrusted code, if you do it carefully, but it offers no¬†granularity in¬†control and it cannot stop some behavior such as redirecting page and initiating installation of plugins. Caja, which stands for capability JavaScript, is an emerging technique to “put untrusted third-party HTML and JavaScript inline in your page and still be secure”. There are similar offerings like Facebook’s FBJS, ADsafe, and also Microsoft’s Web SandBox. Similar concept is also applied to other programming languages.

Read Full Post »

CentOS differs from many other distros by enabling root account during setup. I prefer the Ubuntu’s (and OS X’s) way of using a separate admin account and having root account disabled. When there is a need to perform administrative task, just run the command with sudo and easily prevent the risk of abusing root privileges and doing stupid things. Following this guide, I was able to make this work on CentOS.

  1. First, log in as root account. You can switch to root account from any account by running su and typing the root password.
  2. Enabling sudo. If you are not comfortable with vim, run

    export EDITOR=gedit

    first. Now run


    The lines starting with # are comment lines and will be ignored. Just uncomment the following line:

    # %wheel  ALL=(ALL)       ALL

    by removing the # at the beginning. This line means that anybody in the group wheel can use sudo to run anything from anywhere.

  3. Add an account to group wheel. For example, if the account you use to perform administrative task is isteering, run

    gpasswd -a isteering wheel

    Now you can sudo from user isteering

  4. Disable root account. This is done by running passwd to lock the account:

    passwd -l root

It is quite obvious after we perform the above steps, we have just created a second root account: the user isteering is exactly the same as root user, just having a different name. So we have not added much protection, if the attacker can guess the name of this new account. So you might want to consider limiting where the user can log in from. Use your favorite editor to edit file /etc/security/access.conf. Add the following lines for the admin group:

-:wheel:ALL EXCEPT LOCAL 192.168.1.

This will deny user in group wheel to log in from anywhere but 192.168.1. subnetwork (note the suffix dot) or host You still need to add this line

auth       required     pam_access.so

to /etc/pam.d/sshd to tell SSH server to consult the access control, otherwise SSH server by default will ignore this access control mechanism built in PAM.

Read Full Post »