Many websites have the requirement that transactions be SSL encrypted. When this is the case, you see HTTPS instead of HTTP in the address bar, and down at the bottom of your browser, you likely see a little padlock icon that you can click to pull up information on the security certificate being used. However, for whatever reason, sometimes websites choose to implement both secure and non-secure versions of their site. Other times, the web server can be misconfigured allowing HTTP transport when it should all be HTTPS.

A quick test you can do to see if both are available is to just try dropping the 's' from HTTPS in your address bar. For an example, check out https://www.getafreelancer.com/ - the site works under both HTTP and HTTPS. (I assume that's by design, but I'm using it as an example because there aren't many sites that support HTTPS and also support HTTP at the same time.) If you can access both HTTP and HTTPS, you might want to double check your security requirements for the site and/or your web server configurations. Also, some sites have portions of the site that are HTTP while others are HTTPS. In those cases you might want to come up with some listings of what should be only HTTPS and just check those areas of the site.

Foundstone (a division of McAfee) hosts a bunch of free tools on their website. These include tools that you can use to learn and practice security testing (like Hacme Bank). If you're new to security testing, consider spending some time with these tools and learning utilities.

When doing penetration testing, if you need user id's, you can often find them posted on public websites. Many times all you have to do is download documents (.doc, .xls, etc...) from the website and look at the properties for the document.

To find a document on a website, try something like this in Google:
site:http://www.owasp.org filetype:doc

That should return Word documents on the OWASP website. At the time of this posting, the second result from that search was "Threat modelling of pharming" by Cheong Kai Wee. If you open that document at look at the properties, you'll see the following:



There are a couple of things that can be learned from these properties:

First, it's likely the logged in user on the windows machine where this was created was "kiwi." You can see that under the template directory. So if you found this document on a companies website (instead of OWASP, which I figured would be a safe test case), you would likely have a user id for that network.

In addition, you can see that the author's name is listed as "kiwijuice." Many times this is also the user id, but sometimes I've also found that it contains good password fodder. For example, one time in the past I did this on a penetration test and found enough information to get both a username and password on the first guess.

A few years ago I was testing an e-commerce system that had just been rewritten by an outsourced vendor. I was asked to identify possible security errors in their implementation. As part of that testing, I looked at the HTML, tried some basic SQL injection, and did some URL manipulation. All the basic tests I could think of were failing. Before moving on to the big guns - setting up tools and writing some custom scripts to try different things - I decided to step back and ask some simple questions.

This site had been rewritten by a company that specialized in secure web development. Looking at the code, you could tell these guys knew there stuff. I could spend days or even weeks testing this site before I found anything. I knew that. Instead of attacking the site to get what I wanted, I asked what this outsourced team likely didn't develop. What would the company be too cheap to outsource? What would they feel like they could do themselves?

Within minutes I had a show stopper issue. I could access every item I wasn't suppose to.

The company had not outsourced the development of the search function on the site. It had been a guess. Everyone thinks they can develop a good search feature - even though few actually can. When I searched for an item to purchase, all the results came back referenced using their primary key in the database. I knew that because of the creative variable naming of "pk=". Armed with this information, I was able to do some pattern matching and noticed that the key was used in the URL in certain places. From there, I could access whatever I wanted.

The following tip comes from OWASP, it's a small collection of tools for interception proxies and tampering with HTTP requests. This list comes from the OWASP Testing Guide 3.0. Each tool description has been taken from it's respective website.

WebScarab: WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms.

Burp Proxy: Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications. It operates as a man-in-the-middle between the end browser and the target web server, and allows the user to intercept, inspect and modify the raw traffic passing in both directions.

Paros Proxy: Through Paros's proxy, all HTTP and HTTPS data between server and client, including cookies and form fields, can be intercepted and modified.

TamperIE: TamperIE is a useful tool for security testing your web applications, in order to ensure you don't make foolish assumptions about the data sent by client browsers. Since the tool exposes and allows tampering with otherwise inconvenient input, many user-input security flaws immediately become apparent.

Tamper Data: Use tamperdata to view and modify HTTP/HTTPS headers and post parameters. Trace and time http response/requests. Security test web applications by modifying POST parameters.

The only one I've used (and I highly recommend) is WebScarab. While writing this, I did play around a bit with Tamper Data, and I suspect I'll find a use for that tool as well in future testing efforts.