wood burning stoves 2.0*
The moose likes Security and the fly likes Website testing--Getting around security alerts Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Website testing--Getting around security alerts" Watch "Website testing--Getting around security alerts" New topic
Author

Website testing--Getting around security alerts

J. van Scoyoc
Greenhorn

Joined: Oct 01, 2003
Posts: 4
I'm trying to develop test data for my company's website. Among other things, the data has to simulate many sessions by many distinct userids, and have data appropriate to each user. Getting the right data for a particular user isn't a problem, but getting the right userids and passwords is. The test is to be run against a test website, the passwords of which are all supposed to have been changed to a known dummy value. The catch is, only about half of them work.
If I can just bypass the ones that don't work, I'll still be able to generate plenty of test data. So my initial idea was to use the URL package to surf to the login page, pass the userid/password combo, and do a "GET". The problem that I'm running into, is that when this website is first surfed to, I get the "Security Alert" warning saying that there are problems with the site's Security Certificate. To wit: the name on the certificate is invalid or doesn't match the name of the site, and that the certificate was issued by a company I have not chosen to trust. The Security Alert will let me bypass it as a live website user, but how can I do so when using the java.net.url (or java.net.security) package? Or is there a way I can stop the security alert from appearing at all?
Mark Vedder
Ranch Hand

Joined: Dec 17, 2003
Posts: 624

that when this website is first surfed to, I get the "Security Alert" warning saying that there are problems with the site's Security Certificate. To wit: the name on the certificate is invalid or doesn't match the name of the site, and that the certificate was issued by a company I have not chosen to trust.

Based on the fact that you mention it is appearing when you first surf to the page, I am assuming it is a warning about an SSL cert (for https) for which the name of the cert does not match the URL you are navigating to. You will have this issue if, for example, the cert was issued for www.foo.com but you either:
1) install it on and then navigate use a different URL, such as <a href="https://www.<b rel="nofollow">qa</b>.foo.com," target="_blank">https://www.qa.foo.com, or
2) if you navigate directly to the server, such as https://server1.web.foo.com.
As far as I am aware, there are only two ways to deal with this situation (without needing manual intervention)
1. Purchase a new SSL cert for the testing URL or Server's name and install it.
2. Turn off https on your server and test using http rather than https - this method has 1 major drawback: by turning off https you are sending your traffic across the wire unencrypted. If you have any private. personal, or sensitive data in that traffic, this is an major problem (and somewhat irresponsible if you are sending other people's private information back & forth) Some managers are willing to accept that risk when using testing data (i.e. everything is dummy data including user names) and/or if they are behind a firewall and can limit http (port 80) traffic from the testing clients only.
Personally, I think turning off https is a poor choice unless you are on very small Local network that has no connection to the outside world. In today's day and age, you need to be ultra paranoid and encrypt everything. (Plus my solutions deal with nothing but confidential information).
Someone else may be aware of a way to deal with that warning in an automated fashion, but I am not.
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
Moved to the security forum.


"JavaRanch, where the deer and the Certified play" - David O'Meara
Pankaj Kr
Author
Ranch Hand

Joined: Sep 09, 2003
Posts: 80
What you want to do is to bypass (or customize) the validation of server certificate at your end!
This is certainly doable, but non-trivial. Try the following steps:
1. Write your own X509TrustManager (by subcalssing javax.net.ssl.X509TrustManager) and supply passthru code for validation.
2. Use this trust manager for initializing a SSLContext object.
3. Retrieve a SocketFactory from this SSLContext object by calling getSocketFactory() method.
4. Supply this socket factory to the HttpsURLConnection.setDefaultSSLSocketFactory().
Now, your validation code will (should be!) called and you should be able to bypass the checks!
Let me know if this works. I haven't tried it myself so I would like to know if there is any caveat!


Pankaj Kumar
Home - WebLog - J2EE Security
J. van Scoyoc
Greenhorn

Joined: Oct 01, 2003
Posts: 4
Originally posted by Pankaj Kr:
What you want to do is to bypass (or customize) the validation of server certificate at your end!
This is certainly doable, but non-trivial. Try the following steps:
1. Write your own X509TrustManager (by subcalssing javax.net.ssl.X509TrustManager) and supply passthru code for validation.
2. Use this trust manager for initializing a SSLContext object.
3. Retrieve a SocketFactory from this SSLContext object by calling getSocketFactory() method.
4. Supply this socket factory to the HttpsURLConnection.setDefaultSSLSocketFactory().
Now, your validation code will (should be!) called and you should be able to bypass the checks!
Let me know if this works. I haven't tried it myself so I would like to know if there is any caveat!

Thanks Pankaj. This looks like it will turn out to be helpful. One problem is that I can't find the javax.net classes anywhere. It's not that new is it? On the unix box, I'm running java 1.4.1.
 
 
subject: Website testing--Getting around security alerts