Archive for the web testing Category

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/

     

    Change in link formatting - Firefox 2.0.0.4

    With the upgrade to Firefox 2.0.0.4, I immediately noticed a change on the companion site to this blog, www.meesqa.com. Prior to the Firefox 2.0.0.4 release (and in current IE versions), the links looked like this:

    Prior Link Formatting

    After upgrading to Firefox 2.0.0.4, the links look like this:

    Firefox 2.0.0.4 Link Formatting

    My CSS file for the links looked like this:

    a:link{
    background: inherit;
    border-bottom-width: 2px;
    border-color: #000000 #000000 #000000;
    border-left-width: 0px;
    border-right-width: 0px;
    border-top-width: 0px;
    color: #000000;
    font-weight: bold;
    text-decoration: underline;
    }

    The page and the HTML both validate.

    Just commenting out the CSS entries for the links results in the site looking better but with default link behavior. Better, but not what I want. It appears that the line background: inherit; causes the issue. Removing all of the references to this line results in the pages displaying correctly in Firefox 2.0.0.4 and earlier and displaying correctly in other browsers.

    Web Site Security Testing - Quick List of Things to Check

    I am on the lookout for resources that will help my team with security testing. Usually, security is not an items that is considered up front when planning the testing of an application. A project I am working on now was built from the ground up — so it did not / could not rely on the security infrastructure in place in existing applications. I went looking for a list of items to check and came across the Open Web Application Security Project (OWASP) site.

    OWASP has a Top Ten project which is a list of what they consider the most critical web security flaws. It appears that it is updated on a yearly basis. There is a lot of detail available, but for a quick list of things to check in a web application, this page is the place to begin.

    The 2006 OWASP Top Ten list of critical web security flaws is:

    1. Unvalidated Input
    2. Broken Access Control
    3. Broken Authentication and Session Management
    4. Cross Site Scripting
    5. Buffer Overflow
    6. Injection Flaws
    7. Improper Error Handling
    8. Insecure Storage
    9. Application Denial of Service
    10. Insecure Configuration Management