CAPTCHA with Seam in Three Minutes

Adding a CAPTCHA to a form using Seam is easy now that Seam is bundling jCaptcha.

The Seam documentaiton is good, and can be found in section 13.9 here:

http://docs.jboss.com/seam/2.0.0.CR2/reference/en/html/security.html#d0e7755

If you used seam-gen to create your project, you will need to make a few changes.

First, you need to modify your project’s ant build script to deploy the captcha jar into your ear (or possibly .war). In the target “ear” of the build.xml file, you will find a list of many jar files being copied from your project’s lib directory into the ear. Simply add the captcha jar to that list, like this:

<include name="lib/jcaptcha-all-1.0-RC6.jar"></include>

Now that the jar is deploying, you need to reference it in the application.xml file found under your project’s resources/META-INF directory. Add this entry:

<module>
<ejb>lib/jcaptcha-all-1.0-RC6.jar</ejb>
</module>

If you used seam-gen you will find that the Seam Resource Servlet is already defined in your web.xml so the step defined in the documentation in section 13.9.1 is not necessary.

Continue reading

How to block an IP in Linux

I run Debian on my server, and I often find that my server is being attacked by other computers. Brute force SSH attacks, viruses scanning for the ability to spread, things like that. I’ll go into the SSH brute force defenses in a later post, but for now I’ll cover how to easily block an IP address.

First, I’ll assume you are already using iptables. If you need help setting that up, use Google, Debian comes with it out of the box.

I have a small script called “block” which looks like this:

#!/bin/bash
sudo iptables -I INPUT -s $1 -j DROP
sudo bash -c "iptables-save > /etc/network/iptables.save"

Whenever I find a “bad” IP in my logs or notifications, I just run:

block bad.ip.add.18

Substituting the bad ip for that nonesense above. This adds it to the list of IP address which iptables will simply drop any incoming packets from, and saves the in memory iptables configuration, so that it is preserved through reboots.

Then in your /etc/network/interfaces file, just add this at the bottom:

post-up iptables-restore /etc/network/iptables.save

ATG Security

World-facing websites always have to be written carefully in order to prevent malicious attacks. There are tons of additional vulnerabilities and attack vectors which need to be addressed as well, but in this post I’m going to talk about the two most common: Cross Site Scripting (XSS) and SQL Injection.

If you already know what these are, feel free to skip down a bit to the section where I talk about where ATG Dynamo helps and where there are still some gaps.

Cross Site Scripting is essentially when someone malicious gets your website to source in their content, from their site usually (hence the “cross site”), to what you serve to your users. This can take many forms including embedding a malicious page inside an existing frame in your website, sourcing in javascript which runs on your user’s computer as if it had come from your site, embedding an inappropriate image in a page, or using tricks (or javascript) to redirect the user from your site to a competitor or even a site that LOOKS like yours, but isn’t.

It is an attack against your users, not your servers.

Continue reading

Lions and Tigers and Third-Party Javascript

There are many reasons that you may wish to put a third-party javascript reference on your website. Serving ads, making use of tracking and analytics tools such as Google Analytics, and many other features may want to use a remotely referenced third-party javascript. The big issue here is trust. By putting a remotely referenced javascript on your pages you are essentially handing some control of your visitors’ browsers’ over to this third-party. Maliciously crafted javascript can be used to install software, steal form submission data, rewrite elements of pages, send users to fake phishing sites instead of the real site, crash browsers, popup ads or inappropriate content, and much more. The range of possible attacks using javascript is a long discussion in and of itself, and I won’t go into it here. (Google around or ask me if you want more information on this area of things.)

Read about it after the fold….

Continue reading

What’s up with SMTPS?

Let’s start with SMTP. Simple Mail Transport Protocol. This is how e-mail gets sent. This is how e-mail makes it from you, to your recipient. When you check your e-mail, you use POP or IMAP to get the e-mail from the server. But when you’re sending e-mail, you use SMTP. SMTP is how your mail client communicates with your mail server, and then how your mail server communicates with other mail servers to deliver your precious e-mail to it’s destination.

SMTP has been around since 1982 and is used everywhere. It works, but it’s lacking in many ways, most of which are out of scope for this posting.

Basically the way it works is:

Continue reading