Category: web testing

Total 32 Posts

Hanselminutes – Test Driven Development is Design – The Last Word on TDD

In show 146 of Hanselminutes, Scott interviews agile coach Scott Bellware.

It is an interesting conversation about whether test driven development is a misnomer, the misuse of the word testability, test smells, etc. A valuable conversation for testers to consider when discussing ways to improve the quality of a product. (Especially if someone asserts that additional testing is not required since "we use test driven development".)

 

How to Verify that HTTP TRACE is Disabled – Telnet Disabled

In a prior post, I described how to use telnet to verify that the HTTP TRACE command is disabled. A commenter asked:

What if telnet is actively being blocked… is there another way to invoke the TRACE request in an attempt to verify whether the potential vulnerability exists?

My immediate reaction was that I needed to research how to do this. What a fool I am…

The fact of the matter is that if an HTTP connection is able to connect to the server than the method I described will still work. Because we are using telnet to impersonate a browser – connecting via port 80 – even if telnet is blocked (usually port 23), using telnet via port 80 will still work. If the browser can connect via this way, so can telnet via port 80.

 

Annual Bug – Update Copyright Statement

With the new year, it is time for me to write my annual bug. Like many products, ours includes a copyright statement of the format "© 2006–2008 Company Name" that is displayed to our users. Every year, I submit a bug to change the ending year.

The United States Copyright Office provides the following guidelines in the copyright basics PDF.

Form of Notice for Visually Perceptible Copies

The notice for visually perceptible copies should contain all the following three elements:

  1. The symbol © (the letter C in a circle), or the word “Copyright,” or the abbreviation “Copr.”; and
  2. The year of first publication of the work. In the case of compilations or derivative works incorporating previously published material, the year date of first publication of he compilation or derivative work is sufficient. The year date may be omitted where a pictorial, graphic, or sculp­tural work, with accompanying textual matter, if any, is reproduced in or on greeting cards, postcards, stationery, jewelry, dolls, toys, or any useful article; and
  3. The name of the owner of copyright in the work, or an abbreviation by which the name can be recognized, or a generally known alternative designation of the owner.

By these guidelines, the second date is not required. However, sometimes it is better to go with the flow.

 

Michael Hunter’s “You Are Not Done Yet”

Over several months, Michael Hunter, in his blog on Dr. Dobb’s Portal, ran a series of posts with the title of "You Are Not Done Yet", each of which picked an area of a software deliverable and listed items that a tester needs to consider before considering themselves done testing it. This is a great series and I have referred numerous individuals to it time and again.

I recently wanted to refer someone to it and it took me a while to find the particular URL I needed. So, in order to save myself some time, here is the link to the table of contents to all of the articles in the series.

 

Browser Compatibility Matrix

Bruce McLeod recently posted on the topic of browser compatibility testing. This is an excellent post and I agree with Bruce’s analysis as to what to include and to why. It was also timely because Google’s Chrome had just gone out of beta which spurred me to reconsider what to include in my matrix.

What is lacking in Bruce’s post is an analysis of which operating systems should each browser be run on. This is especially important when considering Firefox which is often run on Windows, Linux and Mac. Taking Bruce’s list, I would modify it as follows:

  • Internet Explorer 7.x – Windows Vista
  • Internet Explorer 6.x – Windows XP
  • Firefox 3.0 – Windows XP or Windows Vista
  • Firefox 3.0 – Mac OS X
  • Safari 3.x – Mac OS X
  • Internet Explorer 8.x – Windows Vista
  • Google Chrome – Windows XP or Windows Vista

This is what I would put on my tier B list (after completing the list above):

  • Safari 3.x – Windows Vista
  • Firefox 3.0 – Linux

 

How to Verify that HTTP TRACE is Disabled

In the past, the TRACE command in the HTTP specification was considered a “safe” command. However, due to the information disclosed combined with other cross-domain exploits, TRACE is no longer considered safe. See US-CERT Vulnerability Note VU#867593 for more information.

I was asked how to verify that the TRACE command (in Apache) is disabled. The easiest way to do this is to use telnet. Launch telnet.

telnet hostname 80
Now, we can issue the TRACE command for a given url.

TRACE /index.html HTTP/1.0


If TRACE is enabled, you will get output that looks something like this:

HTTP/1.1 200 OK
Date: Fri, 05 Dec 2008 05:59:45 GMT
Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.3 with Suhosin-Patch
Connection: close
Content-Type: message/http

TRACE /index.html HTTP/1.0

Connection closed by foreign host.

Now, if TRACE is disabled, the output will look like this:

HTTP/1.1 405 Method Not Allowed
Date: Mon, 08 Dec 2008 21:26:13 GMT
Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.4 with Suhosin-Patch
Allow:
Content-Length: 347
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for the URL /index.html.</p>
<hr>
<address>Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.4 with Suhosin-Patch Server at localhost Port 80</address>
</body></html>
Connection closed by foreign host.

 

Testing Perl Code – Suppressing Warnings

A lot of developers I have worked with have been amazed to see that I expand a suite of tests they developed by a factor of four. This is almost always because I am stressing error handling which is often not tested at all. Unfortunately, these tests will often cause many warnings. Sometimes I want to verify the exact warning. Other times it just clutters the output being sent to the screen. This can be very dangerous – it may lead someone running the test to believe there is a newly introduced bug.

Luckily, perl has a well defined mechanism for overriding the warn behavior. If you want to suppress warnings from being displayed in a section of tests do the following:

    • Scope the section of code where you want to suppress the warnings:
      { ... }
      Define your own warning handler inside the scoped code:

      {
           local $SIG{__WARN__}=sub{}; #Temporarily suppress warnings

           # Insert test code here
      }

  • Once the scoping ends, whatever warning handler was in effect before will be active again.

     

    Job Candidates and HTML Validation

    I review a lot of resumes. In the majority of the cases there is a web site mentioned on the resume. I don’t look at the website unless I am going to interview the person (phone or in person). In most cases, the website has not been updated for quite some time and I wonder why the person included it on their resume. In some cases, the web site is of a strictly personal nature and once again I wonder why they want a propspective employer to look at it. Then there are the cases where the website is relevant to the person’s professional interests and is current.

    One of these resume/websites came across my desk recently. It was a rather plain looking site but had good, relevant content. The person stated clearly his belief in web standards. He even included the W3C button that allows the pages HTML to be validated against whatever HTML version is specified in the DOCTYPE tag. I click on the button – the page fails validation. Not a good impression to set with a prospective employer.

    Hint to job seekers – If you have a HTML validation link on a page, make sure the page passes validation.

     

    Query on Organization of Test Cases

    This week I received an email from a graduate student in Sweden. He was asking about the abstraction level of test cases. My response to the email is below:


    A couple of comments on the decomposition of test cases. When I submitted the paper, the conference committee was very divided on the paper. Half of the reviewing committee was saying that the topic was obvious and not worth including in the conference program. The other half of the reviewers commented that this was a worthwhile topic because there was (and still is) very little written on the topic. When I first started out in the software testing field, this is what I discovered — there was much written on test case design but very little on how to organize the test cases.

    The situation today is different but still there is very little written on organizing test cases. Some of the best work I think that has been done organizing testing is the work by James and Jon Bach on exploratory testing / session based testing. Jon has a Google TechTalk video. There is a Wikipedia article on session based testing that might give you some pointers to more information.

    In general, the move towards agile and test-driven development has led to less documentation. However, in a lot of cases, I think this has led to less planning of testing. (Perhaps with better quality planning on some development projects.) Test driven development has focused more on organizing test cases around the structure of the source code — which evades the question of the best way to decompose the testing.

    With respect to your second question about executing “sub test cases” and the percent that they cover the “parent test case”, I have not given much thought to this topic. I generally look at eliminating redundancy – so if I can eliminate any test case I generally will do so. However, the question I think you are asking points to the larger question of how deeply do you test a particular feature before moving on to some other portion of the project. For example, say the “parent test case” is test feature A – how thoroughly do you test feature A before you say you are done. Obviously, it depends on the importance of the feature, the risk involved if the feature, etc.

    I am not sure if this is helpful. Best of luck on your thesis and continued studies.

     

    Web Security Testing Links

    I recently completed an overview of web security testing for my team. Below are the links I used as resources. I consider the OWASP Testing Guide to be the most useful.

    Payment Card Industry Security Standards
    PCI Security Standards Council – https://www.pcisecuritystandards.org/
    PCI Data Security Standard – https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf

    Open Web Application Security Project (OWASP)
    OWASP Main Site – http://www.owasp.org
    OWASP Top 10 (2007) Web Application Vulnerabilities – http://www.owasp.org/index.php/Top_10_2007
    OWASP Testing Guide (v2) – http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents

    SANS Institute (SANS stands for SysAdmin, Audit, Network, Security)
    SANS Main Site – http://www.sans.org
    SANS Top-20 Internet Security Attach Targets – http://www.sans.org

    United States Computer Emergency Readiness Team (US-CERT)
    US-CERT Main Site – http://www.us-cert.gov/
    US-CERT Security Alerts (Technical) – http://www.us-cert.gov/cas/techalerts/
    US-CERT Security Bulletins – http://www.us-cert.gov/cas/bulletins/

    Vendor Sites and Resources
    SPI Dynamics – http://www.spidynamics.com/
         
    White Papers – http://www.spidynamics.com/spilabs/education/whitepapers.html

         
    Cross Site Scripting White Paper – http://www.spidynamics.com/assets/documents/SPIcross-sitescripting.pdf

         
    SQL Injection White Paper – http://www.spidynamics.com/assets/documents/WhitepaperSQLInjection.pdf

    Fortify Software – http://www.fortifysoftware.com/
         
    Fortify Taxonomy: Software Security Errors – http://www.fortifysoftware.com/vulncat/