Vidar’s Musings

Yes, it’s a fact that people are not good at coming up with good passwords. Some administrators, security people, and such try to improve the sitatuation by providing the users “help” with coming up with good, strong passwords in the form of password rules. What those guys often forget, is that people are just that - people, and not computers. It all ends up in insanity, like Jeremy Zawodny talks about in his blog entry.

Of course, the classical source of enlightenment on this subject is the Center for Password Sanity.

I blogged earlier about using Selenium for security testing. One of the shortcomings that I pointed out, was that session handling (i.e. cookie handling) was needed. I went ahead and created extensions for this. As of version 0.8.0, Selenium now supports this out of the box. This means that Selenium now is able to test scenarios such as logging in and logging out from web applications, in additional to other cookie-based functionality. Great!

The Java keystore is powerful, yet not very user-friendly. While the Java documentation provides an OK reference on keystore commands, there are not many comprehensive examples out there.

So, here is a simple walkthrough on how to create your keystore containing your private key, your signed certificate, and the certificate of the CA that signed your certificate.

REM “Step 1: Create your store and your private/public key pair”
keytool -genkey -dname “cn=myhost,c=mycompany” -alias myhost -keypass z0Ld6#MdeR -validity 365 -keystore mykeystore.jks -storepass kru6+Qb76_

REM “Step 2: Create a Certificate Signing Request (CSR)”
keytool -certreq -alias myhost -file myhost.csr -keypass z0Ld6#MdeR -keystore mykeystore.jks -storepass kru6+Qb76_

REM “Step 3: Import CA certificate into keystore, and make it trusted”
keytool -import -alias myCA -file c:\myca.cer -keystore mykeystore.jks -storepass kru6+Qb76_

REM “Step 4: import my signed personal certificate”
keytool -import -file c:\myhost.cer -keystore mykeystore.jks -storepass kru6+Qb76_

REM “Step 5: list and verify certificates”
keytool -list -keystore mykeystore.jks -storepass kru6+Qb76_

Comments:

• If you shall use the certificate for securing browser communication using SSL, make sure the common name (CN) is the fully qualified hostname of your server, e.g. myhost.domain.com.
• When it comes to choosing key length, use www.keylength.com as reference.
• Between step 2 and 3 above, you have to have the certificate signed by a certificate authority like VeriSign. Alternatively, you can set up your own CA in your company using OpenSSL or Windows Certificate Services
• Please do not use the same passwords as shown above. That would not be very wise…

I read an interesting article called The non-denial of the non-self on the web today. An interesting article
about how to secure databases. However, I found it also interesting to read about how the human immune system relates to attackers:

“The immune system is interesting, because it protects its owner from pathogens without needing to know what a pathogen will look like. Instead, it relies on a negative database to tell it what to destroy. It learns early on which biological molecules are ’self’, in the sense that they are routine parts of the body it is protecting. Whenever it meets one that is ‘not self’ and thus likely to be part of a pathogen, it destroys it.”

In security terms, this is actually called whitelisting.  It is typically used for input validation. Instead of trying to list all  illegal inputs (which is called blacklisting), list all legal inputs. The problems  with the former is that you have to make sure you think about all illegal instances, which is often very difficult, using the latter you only have to focus on the legal cases. Seemingly, this is how nature works…

When testing for security, it is important to test that the application under test (AUT) handles unexpected input properly, i.e. does not enter an unsecure state. A typical example of an unsecure response to an unexpected input is to display an exception that reveals information about the system configuration that can help a malicious user breaking in to a system.

As I blogged about earlier, I am trying to use Selenium to do security testing. In order to be able to test how the AUT handles being passed a value that is not present in an HTML dropdown list, I created a Selenium extension that adds a new option to a dropdown list and selects it. This way, the test may add a new value before submitting the form to the application.

Here is the code for the Selenium action.

My current project uses an agile project methodology. As such, we use Selenium to create automated acceptance tests for the project. Focusing on the security aspects of the application we are developing, I had an idea about using Selenium for security testing. Basically, there are a few points that led me to this idea:

• Using Selenium we would perhaps not need to introduce yet another tool into the process, lowering the project’s effort to handle security.
• Using Selenium, security testing could get attention equal to the acceptance tests.
• Selenium tests could perhaps be created to simulate Black Hat activity.

Being a Selenium newbie, I started looking at Selenium to see of it could be used for this purpose. I quickly realised that Selenium out of the box does not have the functionality that is needed. It is, however, easily extensible.

I have found some areas where Selenium has shortcomings when it comes to security testing:

1. Session handling: Proper session handling is important when it comes to security, for instance vulnerabilities like session fixture and rights elevation. To enable testing of session handling, Selenium needs functions for inspecting and deleting cookies. Furthermore, if one where to run test suites with tests which involves sessions, these would have to be deleted in between tests to avoid the tests interfering with each other.
2. HTTP protocol: Testing which involves inspecting and setting HTTP headers would be an integral part of a security test suite.
3. Input validation: Testing that the AUT does proper input validation and/or can handle input out of range would be important. For example, one test that comes to mind is whether the AUT can handle being sent a value that is not a part of an HTML drop down list.

Even though Selenium has shortcomings, I am fairly optimistic that these can be overcome, and I would like to investigate this further. For instance, I have created basic cookie handling routines for Selenium which seems to do the job. (Item 1 above) I will post them on my homepage later (www.kongsli.net). For item 3 above, I have created a method that will dynamically add options to dropdown lists on a page before the page is submitted, making it possible to send parameters out of range to the server. Furthermore, I will look into AJAX related techniques to handle item 2 above, possibly using the Dojo framework.

I am currently working on deploying eTrust SAML Affiliate Agent (Computer Associates) for a customer , and found myself totally baffled by its behaviour. In the solution in question,
we are running a web server in front of our application server. The SAML Affiliate Agent runs as a plugin on the web server. When users are authenticated by SiteMinder via the Affiliate Agent, the Affiliate Agent will insert user identity into the HTTP header that is forwarded to the application server. On the application server, we use this header to assert the user’s identity.

The basic idea with the concept of transferring user identity in the HTTP request header, is that trust is established between the Affiliate Agent and the application. In other words, the application trusts, without proof, that the header information it receives is correct. In so doing, it trusts that the Affiliate Agent handles this correctly. (This is sometimes referred to as perimeter authentication). So far, so good.

It turns out, though, that if the Affiliate Agent is configured not to enforce authentication (thereby allowing anonymous users to access resources in the application), it allows identity information to pass through from the user agent to the application! This means that any rogue client can impersonate any user by inserting a user name into the HTTP request as the application server will assume that the user was authenticated by the Affiliate Agent! The configuration is completely insecure, I would say wide open. What the Affiliate Agent should do, but which it doesn’t, is to check for incoming headers in the request, and act on it. The best thing to do, is to log the event and deny access to the application.

Be careful out there, kids.

Once upon a time there was this platform renowned for its security features.
But as the platform became of age, the security features was woven into a large
quilt with considerable number of patches. And then chaos arise.

Domino has a lot of nice security features. It has its own public key
infrastructure, encryption, access control, etc. However, there are a lot of
features that need to work together. Lots of security settings generates
complexity. And complexity is the greatest foe of security.

Take, for example, agent security. In R6, agent restrictions may be set on
each agent instead on each server. This generates more complexity as each and
every agent would have to be administered security-wise. An agent has three
runtime security levels:

• Do not allow restricted operations
• Allow restricted operations
• Allow restricted operations with full administrative rights

One particular agent of mine needed to access the file system on the server,
which is a restricted operation. So, I set the runtime security to level 2.
But, what the documentation fails to tell me, is that there is a setting on the
server document that overrides this. In order for user to be able to run an
agent performing restricted operations, not only has the agent security level
to be set correctly, the user also needs to be listed in the “run restricted
methods and operations” field in the server document. I guess Lotus added this
feature for flexibility. But flexibility is often perpendicular to simplicity.
And when it comes to security, simplicity is king…