What Is Sql Injection

What is SQL Injection SQL injection refers to the act of someone inserting a MySQL statement to be run on your database without your knowledge. Injection usually occurs when you ask a user for input, like their name, and instead of a name they give you a MySQL statement that you will unknowingly run on your database. Its a trick to inject SQL query/command as an input possibly via web pages. Many web pages take parameters from web user, and make SQL query to the database. Take for instance when a user login, from web page the user gets the usernaem and password and make SQL query to the database to check if a user has valid name and password. With SQL injection, it is possible for us to send crafted username ans/or password field tha will change the SQL query and thus grant us something else.

What Do you need? Any web browser.

What you should look for? Try to look for pages that allow you to submit data, i.e: login page, search page, feedback, etc.

Sometimes, HTML pages use POST command to send parameters to another ASP page. Therefore, you may not see the parameters in the URL. However, you can check the source code of the HTML, and look for "FORM" tag in the HTML code.

You may find something like this in some HTML codes:

Everything between the and have potential parameters that might be useful (exploit wise).

What if you can't find any page that takes input? You should look for pages like ASP, JSP, CGI, or PHP web pages. Try to look especially for URL that takes parameters, like: http://duck/index.asp?id=10

SQL INJECTION ATTACKS 1. Hacking the querystring a) While By Passing Login,

The login page had a traditional username-and-password form, but also an email-me-mypassword link;Well, lots of people thinks that only the valid user can log in inside the system but that’s not true.Well anybody can log in to that website with a simple trick. Let’s look at the usual query for user login in PHP,

$sql=”SELECT * FROM tbl_user WHERE username= ‘”.$_POST['username'].”‘ AND password= ‘”.$_POST['password'].”‘”; $result=mysql_query($sql);

Let’s suppose that a intruder injected x’ OR ‘x’='x in the username field and x’ OR ‘x’='x in the password field.Then the final query of fetching the user will become like this, SELECT * FROM tbl_user WHERE username=’x’ OR ‘x’='x’ AND password=’x’ OR ‘x’='x’; Well you can see that query is always true and returns the row from the database. As the result , the intruder could log in to the system.

b)Through URL's, Other than bypassing login, it is also possible to view extra information that is not normally available. For example consider a asp page that will link you to another page with the following URL: http://duck/index.asp?category=food In the URL, 'category' is the variable name, and 'food' is the value assigned to the variable. The SQL statement should become: SELECT * FROM product WHERE PCategory='food' The query should return a resultset containing one or more rows that match the WHERE condition, in this case, 'food'. Now, assume that we change the URL into something like this: http://duck/index.asp?category=food' or 1=1-Now, our category equals to "food' or 1=1-- ", if we substitute this in the SQL query, we will have: SELECT * FROM product WHERE PCategory='food' or 1=1--' The query now should now select everything from the product table regardless if PCategory is equal to 'food' or not. A double dash "--" tell MYSQL server ignore the rest of the query, which will get rid of the last hanging single quote (').

Sometimes, it may be possible to replace double dash with single hash "#". However, if it is not an SQL server, or you simply cannot ignore the rest of the query, you also may try ' or 'a'='a The SQL query will now become: SELECT * FROM product WHERE PCategory='food' or 'a'='a' It should return the same result. Depending on the actual SQL query, you may have to try some of these possibilities: ' or 1=1-" or 1=1-or 1=1-' or 'a'='a " or "a"="a ') or ('a'='a

2.Finding the table name The application's built-in query already has the table name built into it, but we don't know what that name is: there are several approaches for finding that (and other) table names. The one we took was to rely on asubselect.

A standalone query of SELECT COUNT(*) FROM tabname

Returns the number of records in that table, and of course fails if the table name is unknown. We can build this into our string to probe for the table name:

SELECT email, passwd, login_id, full_name FROM table WHERE email = 'x' AND 1=(SELECT COUNT(*) FROM tabname); --';

We don't care how many records are there, of course, only whether the table name is valid or not. By iterating over several guesses, we eventually determined

that members was a valid table in the database. But is it the table used in this query? For that we need yet another test using table.field notation: it only works for tables that are actually part of this query, not merely that the table exists.

SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x' AND members.email IS NULL; --';

When this returned "Email unknown", it confirmed that our SQL was well formed and that we had properly guessed the table name. This will be important later, but we instead took a different approach in the interim.

3.Finding some users At this point we have a partial idea of the structure of the members table. We'd like to get some user names to work with, preferably those likely to have access to more data.

The first place to start, of course, is the company's website to find who is who: the "About us" or "Contact" pages often list who's running the place. Many of these contain email addresses, but even those that don't list them can give us some clues which allow us to find them with our tool.

The idea is to submit a query that uses the LIKE clause, allowing us to do partial matches of names or email addresses in the database, each time triggering the "We sent your password" message and email. Warning: though this reveals an email address each time we run it, it also actually sends that email, which may raise suspicions. This suggests that we take it easy.

We can do the query on email name or full name (or presumably other information), each time putting in the%LIKE supports: wildcards that

SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x' OR full_name LIKE '%Bob%';

Keep in mind that even though there may be more than one "Bob", we only get to see one of them: this suggests refining our LIKE clause narrowly. Ultimately, we may only need one valid email address to leverage our way in.

4. Password guessing and resetting Password a)Password Guessing One can certainly attempt brute-force guessing of passwords at the main login page, but many systems make an effort to detect or even prevent this. There could be logfiles, account lockouts, or other devices that would substantially impede our efforts, but because of the non-sanitized inputs, we have another avenue that is much less likely to be so protected. We'll instead do actual password testing in our snippet by including the email name and password directly. In our example, we'll use our victim, [email protected] and try multiple passwords.

SELECT email, passwd, login_id, full_name FROM members WHERE email = '[email protected]' AND passwd = 'hello123';

This is clearly well-formed SQL, so we don't expect to see any server errors, and we'll know we found the password when we receive the "your password has been mailed to you" message. Our mark has now been tipped off, but we do have his password. This procedure can be automated with scripting in perl, and though we were in the process of creating this script, we ended up going down another road before actually trying it.

b)Resetting Password (to gain more privileges )

"UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';"

But a malicious user sumbits the value ' or uid like'%admin%'; -- to $uid to change the admin's password, or simply sets $pwd to "hehehe', admin='yes', trusted=100 " (with a trailing space) to gain more privileges. Then, the query will be twisted:

// $uid == ' or uid like'%admin%'; -"UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%'; --"; // $pwd == "hehehe', admin='yes', trusted=100 " "UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE ...;";

5.Remote execution with SQL injection "SELECT * FROM products WHERE id LIKE '%$prod%'"; If attacker submits the value a%' exec master..xp_cmdshell 'net user test testpass /ADD' -- to $prod, then the query will be:

"SELECT * FROM products WHERE id LIKE '%a%' exec master..xp_cmdshell 'net user test testpass /ADD'--"; MSSQL Server executes the SQL statements in the batch including a command to add a new user to the local accounts database. If this application were running as sa and the MSSQLSERVER service is running with sufficient privileges, the attacker would now have an account with which to access this machine.

Note: Some of the examples above is tied to a specific database server. This does not mean that a similar attack is impossible against other products. Your database server may be similarly vulnerable in another manner.

6.Dropping a table So far, we have done nothing but query the database, and even though a SELECT is readonly, that doesn't mean that SQL is. SQL uses the semicolon for statement termination, and if the input is not sanitized properly, there may be nothing that prevents us from stringing our own unrelated command at the end of the query. The most drastic example is:

SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x'; DROP TABLE members; --'; -- Boom!

The first part provides a dummy email address -- 'x' -- and we don't care what this query returns: we're just getting it out of the way so we can introduce an unrelated SQL command. This one attempts to drop (delete) the entire members table, which really doesn't seem too sporting. This shows that not only can we run separate SQL commands, but we can also modify the database. This is promising.

7.Adding a new member Given that we know the partial structure of the members table, it seems like a plausible approach to attempt adding a new record to that table: if this works, we'll simply be able to login directly with our newly-inserted credentials. This, not surprisingly, takes a bit more SQL, and we've wrapped it over several lines for ease of presentation, but our part is still one contiguous string:

SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x';

INSERT INTO members ('email','passwd','login_id','full_name') VALUES ('[email protected]','hello','steve','Steve Friedl');--'; Even if we have actually gotten our field and table names right, several things could get in our way of a successful attack: 1. We might not have enough room in the web form to enter this much text directly (though this can be worked around via scripting, it's much less convenient). 2. The web application user might not have INSERT permission on the members table. 3. There are undoubtedly other fields in the members table, and some may require initial values, causing the INSERT to fail. 4. Even if we manage to insert a new record, the application itself might not behave well due to the auto-inserted NULL fields that we didn't provide values for. 5. A valid "member" might require not only a record in the members table, but associated information in other tables (say, "accessrights"), so adding to one table alone might not be sufficient.

In the case at hand, we hit a roadblock on either #4 or #5 - we can't really be sure -because when going to the main login page and entering in the above username + password, a server error was returned. This suggests that fields we did not populate were vital, but nevertheless not handled properly. A possible approach here is attempting to guess the other fields, but this promises to be a long and laborious process: though we may be able to guess other "obvious" fields, it's very hard to imagine the bigger-picture organization of this application. We ended up going down a different road.

8.Mail me a password We then realized that though we are not able to add a new record to the members database, we canmodify an existing one, and this proved to be the approach that gained us entry. From a previous step, we knew that [email protected] had an account on the system, and we used our SQL injection to update his database record with our email address:

SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x'; UPDATE members SET email = '[email protected]' WHERE email = '[email protected]';

After running this, we of course received the "we didn't know your email address", but this was expected due to the dummy email address provided. The UPDATE wouldn't have registered with the application, so it executed quietly. We then used the regular "I lost my password" link - with the updated email address - and a minute later received this email:

From: [email protected] To: [email protected] Subject: Intranet login This email is in response to your request for your Intranet log in information. Your User ID is: bob Your password is: hello

Now it was now just a matter of following the standard login process to access the system as a high-ranked MIS staffer, and this was far superior to a perhaps-limited user that we might have created with our INSERT approach.

We found the intranet site to be quite comprehensive, and it included - among other things - a list of all the users. It's a fair bet that many Intranet sites also have accounts on the corporate Windows network, and perhaps some of them have used the same password in both places. Since it's clear that we have an easy way to retrieve any Intranet password, and since we had located an open PPTP VPN port on the corporate firewall, it should be straightforward to attempt this kind of access. We had done a spot check on a few accounts without success, and we can't really know whether it's "bad password" or "the Intranet account name differs from the Windows account name". But we think that automated tools could make some of this easier.

Posted by Anoop at 11:01 PM 0 comments Labels: How to do SQL injection, Security testing, SQL injection, SQL Injection through Forms, SQL Injection through URLs

Wednesday, April 1, 2009

QA Check list Test Carried out Expected

1. Functionality 1.1 Links Internal Links

Should be present

External Links Should be present Mail to links Should open mailbox Orphan pages (a Should not be present page that has no links to it) Broken links Should not be present Are all referenced web sites or email addresses hyperlinked? If we have removed some of the pages from our own site, set up a custom 404 page that redirects your visitors to your home page (or a search page) when the user try to access a page that no longer exists. 1.2 Forms

Actu Remark Ticket al s Reference (Yes (Correspondi or No ng bug id if u ) have any bug tracking tool )

Acceptance of invalid input Input longer than Checked Unique records, Date field allows validation Functional checks Create, modify, view and delete are working. Error Handling for Appropriate error messages to wrong inputs or be displayed. actions. Optional and Mandatory field should not be mandatory fields. left blank. Optional should allow the user to skip the field. 1.3 Cookies Check to see what happens if a user deletes cookies while in site Check to see what happens if a user deletes cookies after visiting a site 1.4 Data integration Check the maximum field lengths to ensure that there are no truncated characters? If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers? If a particular set of data is saved to the database check that each value gets saved

fully to the database. (i.e.) Beware of truncation (of strings) and rounding of numeric values. 1.5 Data field check Assure that leap years are validated correctly & do not cause errors/miscalculati ons. Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations. 1.6 Numeric fields Assure that lowest and highest values are handled correctly. Assure that numeric fields with a blank in position 1 are processed or reported as an error. Assure that fields with a blank in the last position are processed or reported as an error Assure that both + and - values are correctly processed. Assure that

division by zero does not occur. Include value zero in all calculations. 1.7 Alphanumeric field checks Use blank and non-blank data. Include lowest and highest values. Include invalid characters & symbols. Include valid characters. Include data items with first position blank. Include data items with last position blank. 2. Usability: How Simple Customer can browse the website 2.1 Navigation: It describes the way user navigate with in a webpage, between different user interface controls ( buttons, text boxes, combo boxes, drop down lists etc) Navigation through Should be proper Mouse Navigation through Should be proper Tab Main features Should be accessed from access home/Main page Hot Keys, Control Should work Keys for menu or action 2.2 Content: Correctness is whether the information is truthful or contains misinformation. The accuracy of the information is whether it is with out grammatical or spelling errors. Spelling and To be proper Grammar Updated Past events/ information’s to be information’s. removed.

2.3 General Appearance Page Appearance Should not be any overlapping, missing etc., Colour, font and Should be as per standard size Frames All frames to be appeared Consistent Design Everywhere in the website consistent layout and design should be carried out. Favicon, logos and symbols 3. User Interface : All about how exactly website look like 3.1 Screen must be tested with various resolution screen 3.2 Varying font size 3.3 View in text browser 3.4 Without Javascripts 3.5 Without plug-in if any 3.6 Without images 3.7 Page titles 3.8 Hyperlink It should be standard colors 3.9 All the fonts to be same 3.10 All images are optimized for quick downloads 3.11 Alt tag for all images 3.12 Are all disabled fields avoid in TAB sequence 3.13 Are all read only fields avoid in TAB sequence

3.14 Link to home on every single page 3.15 Default value Should have meaningful of the drop down sentence such as "Choose one" box or "Select" 3.16 Cursor will be on first editable field 3.17 When an error message occurs does the focus return to the field in error when the user cancels it? 3.18 Persistancy of all values ( When you enter values in a form, and move on the next page and then return to change one of the previous screen. The user must not be forced to reenter all the values once again, this must be checked and ensured. ) 3.19 Pagination Use where appropriate 3.20 Error Illegal operations should give messages error messages and they should be simple and clear 3.21 Success Should display messages 3.22 Horizontal Avoid horizontal scroll bar scrolling ensure that the use of vertical scroll bar is judicious 4. Server Side Interface

4.1 Server Interface

4.2 Compatibility with server hardware, Sw, network connections 4.3 Database compatibility[s1]

Communication should be correct with respect to Web server, App server and DB server Should be proper.

Should be easily portable to other database.

5. Client side Compatibility 5.1 Platform Windows2000, NT Should be working Unix Should be working Linux Should be working Solaris Should be working Macintosh Should be working 5.2 Browsers I.E Firefox

Should work in all versions above 4.x Should work in all versions above 2.x

Safari Opera Graphics

Load of images, graphics should be proper

4.3 Printing Text and alignment Should be proper Colours of text, Should be readable. foreground and background Scalability to fit Should print in A4, Letter size. paper size. Tables and Should be proper. borders.

6. Performance 6.1 Connection speed Should be measured in 14.4, 28.8, 33.6, 56.6, ISDN, Cable and DSL Timeout Should give appropriate time to search. Incorrect message, data loss should not be present.

6.2 Load Estimated users. Peak load Large amount of data from users 6.3 Stress System Crash Error in Sw, HW, Memory

Per requirements Should withstand Should accept

Should not be present Leakage, overwrite should not happen.

6.4 Continuous use Estimate whether Try with various timings. available for 24 Hrs, 7 days a week Downtime Measure the downtime Memory or disk Should not run out of memory space or disk space. 7. Security 7.1 Valid and Should not enter with Invalid Invalid login 7.2 Number of tries Should not be more than 3 times for invalid try. 7.3 Enter url Should not display information. directly without logging in. 7.4 Log files Should be maintained 7.5 Access to Authenticated. server scripts

7.6 Does the application include time-outs due to inactivity? 7.7 Is bookmarking disabled on secure pages? 7.8 Is Right Click, View, Source disabled? 7.9 SQL injection 7.10 Java script injection 8. HTML Validations HTML Validation CSS Validation Styles should be always placed in external CSS files. Content should be formatted through cascading styles (CSS). 9 SEO 9.1 Domain name Main keyword in the domain name Easy to spell and remember Without hyphens were possible Domain extension Host location 9.2 URL Avoid using lengthy URLs with unnecessary parameters and session IDs. Create a simple directory Directory structure structure URL structure

Unique to each page

Do not have duplicate ones like http://www.mywebsite.com/ and http://www.mywebsite.com/inde x.php.

Mixing www. and non-www. versions of URLs Odd capitalization of URLs Aim to hide the underlying technology of your website and Extension thus remove the extension, creating clean and descriptive URLs. Should include relevant keywords – Avoid keyword Keywords in URL duplication. The keyword should be mentioned sooner in the URL 9.3 Page Title Unique Informative Keyword in title 9.3 Meta tags 9.3.1 Description meta tag - Limit to 150 characters Summary of the page content Unique description for each page 9.3.2 Description meta tag Number of don’t use more than 7 to 10 keywords words for your meta keywords Unique and Use unique and relevant meta relevant keywords keywords for every single page, related to page content. Do not repeat any word more than 3 times. Usage of capital Don't use all capital letters letters unless the word is an acronym, like "SEO", which is short for Search Engine Optimization.

9.3.3 Robots Meta Tag (add in live server) Check This is specified if the current page should not be indexed by the search engines, as in the case of a custom error page. 9.4 Page contents

Number of words

Keyword density

Hyper linked keyword

Each page of your content should contain about 250 – 600 words of unique content with 4 or 5 occurrences of your targeted keywords. At least 3 keywords in a page. Your keywords should be toward the top of your page and your keyword phrase is in either every paragraph or every second paragraph depending on your paragraph length. Include your most important keyword in hyper linked text.

9.5 Alt tag Alt tag for images Keywords as alt tag

Wherever possible, put PROPER KEYWORDS in the ALT tags. Don’t go wild with this and don’t miss-label any pictures.

Alt tags for navigation buttons 9.6 Sitemap Sitemap.xml 9.7 Anchor tag 9.8 Robots.txt 9.9 Page size Check page size

Good SEO site page size ideal should be 15KB, can exceed up to 50 KB.

9.10 Error page Check for custom error page 9.11 Redirection 301 redirection 302 redirection

Check for permanent redirection Temporary redirection

Posted by Anoop at 2:26 AM 1 comments Labels: functional testing check list, QA Check list, SEO checklist

Tuesday, March 31, 2009

Website Checklist

Website Checklist Validation Validate the HTML The first stage of checking a web-site is to make sure that you have valid HTML (or XHTML). This can be done with a validator such as the W3C validator or WDG validator. Your own browser may ignore certain errors, but there is a significant risk that markup errors will result in display problems in some browser or other. There are sometimes reasons for including invalid HTML. For example some pages on my own site use the non-standard NOINDEX element, for the benefit of my site search engine. But you should only tolerate HTML validation errors if there is a clear need for the non-standard markup, and if you have tested the result in a variety of browsers.

Validate the CSS CSS can be validated with for example the W3C CSS validator. The considerations here are much the same as HTML validation. It may sometimes be necessary to use something non-standard to get Internet Explorer to work, but such rules can be placed in a separate

CSS file and hidden in an Internet Explorer conditional comment, where they won’t bother other browsers or a validator.

Check for broken links Obviously you don’t want broken links on your site. There are various tools available to help find these, such as the Link Valet (which is convenient for checking a few pages) orXenulink (convenient for checking a whole site).

Flexibility Try varying window-sizes A very important aspect of web design is coping with different window sizes. Window widths may vary from about 200 pixels on a webenabled telephone to 2000+ pixels on a technical workstation in fullscreen mode. While providing a readable site to the very smallest screens is something of a challenge, your site should at least be readable on a wide variety of sizes. As of mid 2006, nearly 20% of all readers are still using screens of 800x600 pixels or smaller, and if the reader wishes to compare the contents of your site with another document, it is entirely possible that he/she may want to use a window-width of around 400 pixels. Fortunately, at least as far as the text goes, this is not very difficult – just refrain from specifying sizes in pixels or points and you are most of the way. See my flexible designpage for further thoughts. It is obviously easy to test window-sizes smaller than your own screen-size. Testing larger window-sizes might seem impossible, but you can do a rough simulation using the zoom facility of the Opera browser – zoom down to 50% and you get a screen twice the size. It may not be very readable, but any major layout errors should be obvious. Incidentally don’t worry too much about the very long lines of text that appear at large screen sizes when small fonts are used. If the reader doesn’t use a large font, he can always reduce the window size to something comfortable – that is, after all, half the point of having windowing user interfaces in the first place. But if you wish to, you can also use the CSS2 ‘max-width’ property to limit column width, just as

this page does. (Only discerning readers are currently able to benefit from this, as IE does not support it. Rumour has it that it will finally appear in IE 7 – I suppose eight years late is better than never.)

Try varying font sizes Some people use large screen fonts because they have a large screen with a very fine resolution; other people have to use large screen fonts because of declining eyesight. On the other hand, some people like to use microscopic fonts with their nose pressed against the screen (it takes all sorts...) So while doing the above activity, adjust the default text-size in your browser, and check that all the text scales appropriately. One other aspect to consider is that users may impose a minimum font size to make sure that all text is readable for them. This means that font sizes show a smaller range than you had in mind. If you have a complex page with a wide range of font sizes, it would be worth imposing a minimum size larger than your smallest font (this can be done in e.g. Opera or Firefox) and checking that this does not make parts unreadable.

Speed Access the site via a modem So you think you have a great site, full of beautiful images. Put your site on the server, then dial in via a modem (a real modem – not an ADSL gateway, which is sometimes erroneously referred to as a modem). Does it look so good half a minute later? Or are you still staring at a pretty-much blank screen? If the opening page of your site takes more than about 15 seconds to appear, then you are losing visitors fast. (Broadband users generally expect a still faster response.) Don’t overload it. If you have to include large objects on your site – perhaps it revolves around high-resolution reproductions of fine art – put them on later pages and tell (or warn?) your users what is coming. Web developers generally have broadband access, and they sometimes forget that the majority of the world's internet connections

still run via a modem. Yes, more and more people are getting broadband, but the number of people without it is still large, and many people in rural areas, let alone developing countries, simply can’t yet get broadband. By the way, don’t make the mistake of assuming that you don’t have to worry about bandwidth issues if your site is mainly aimed at companies. I have more than once worked at companies which did have a broadband connection, but had it shared between so many users and applications that the net result was scarcely faster than a dial-up modem.

Check image size specifications While doing the test above, check that at least the text of the page appears quickly. If it doesn’t (or if it dances all over the place while the page is loading) it is probably because you have forgotten to specify HEIGHT and WIDTH attributes on some of your images. Specifying these enables the browser to work out where the text needs to go, and to display it before the images have finished downloading.

Accessibility (for the disabled) Since I first wrote this page, it has been pointed out to me that actually most of the page is about accessibility: that is, ensuring that a web page is accessible under a wide range of browsing conditions. However accessibility is often used in the narrower sense I use in this section.

Test accessibility This is mainly important for handicapped users, but also relevant for e.g. people who use a text-only browser, or disable images, because of a slow connection. See the Web Content Accessibility Guidelines. Automated accessibility checking does need to be taken with a pinch of salt. Many aspects of the guidelines require human judgement to say whether a page is accessible or not – for example whether HTML Heading tags are used correctly. And even when the guidelines are unambiguous, you don’t need to follow them slavishly. For example the absence of a caption on a table is unimportant if the previous paragraph explained what the table is about. Nonetheless it is well worth running a few pages through a checker such

as Bobby or Accessibility Valet in order to familiarise yourself with the issues involved. You can then make the necessary improvements.

View in text browser It is also worth running pages through a text-only browser, or textbrowser emulator to see what e.g. a blind person using a text-tospeech converter will encounter. It will help you pick up on badlychosen or missing ALT texts for example. It also shows you the site pretty much as a search engine will see it. Incidentally the Opera browser has a built-in text-browser emulator.

Browser independence Your site may be viewed in a large variety of situations: different browsers, different operating systems, different features enabled or disabled. It is important that your site stands up well in these different situations. The first point of attention here is validation – described separately above. Then there are the following points.

Try different browsers Almost all web developers (ahem! – perhaps that should read “quite a lot of web developers”) are aware of the need to check how their site looks in a variety of browsers. How far you go obviously depends on the resources available – not everyone is in a position to check Windows, Mac, Unix and Linux platforms. The minimum test would probably be: 1. Firefox, as that has the best standards compliance and is the second most-used browser; 2. Internet Explorer for Windows – currently the most widely used browser. It is essential to check both versions 6 and 7 as version 7 fixed quite a lot of bugs in 6 but introduced a new set of its own. (Microsoft is however still kicking developers in the teeth by not making it possible to install both versions on the same computer; you will either need two computers or one of the work-arounds available on the net.) Version 5 should preferably also be checked; as of spring 2008 the number of users is not yet negligible. However it is now uncommon enough that you

needn’t worry about cosmetic issues; as long as the site is readable that should be sufficient. 3. Opera – growing in popularity due to its speed and pretty good standards compliance. For some time I also recommended checking Netscape 4 as well, as it often produces radically different results from any other browser, and was very popular for a long time. However the number of users of this bug-ridden browser is now so small (under 0.1% and decreasing) that it can now probably safely be ignored.

Check printed pages Print some of the pages on a normal printer (i.e. with a paper size of A4 or Letter) and check that they appear sensibly. Due to the somewhat limited formatting options available for printing, you probably can’t achieve an appearance comparable to a document produced by a word-processor, but you should at least be able to read the text easily, and not have lines running off the right-hand side of the page. It is truly extraordinary how many site authors fail to think of this most elementary of operations. You should also consider using CSS to adjust the appearance of the page when printed. For example you could – probably should – suppress the printing of information which is not relevant to the printed page, such as navigation bars. This can be done using the “@media print” or “@import print” CSS features. Some sites provide separate “printer friendly” versions of their pages, which the user can select and print. While this may occasionally be necessary as a last resort, it significantly increases the amount of work needed to maintain the site, is inconvenient for the reader and shouldn’t usually be needed.

Switch Javascript off There are unfortunately quite a number of Internet sites which abuse Javascript by, for example, generating unwanted pop-ups and irritating animations. There are also a number of Javascript-related security holes in browsers, especially Internet Explorer. As a result a lot of readers switch Javascript off – indeed I often do myself. (I have a page giving thereasons in more detail.) Some organisations even block

the usage of Javascript completely. Furthermore few, if any, search engines support Javascript. It is therefore important to check that your site still functions with Javascript disabled. A lot of sites rely – quite unnecessarily – on Javascript for navigation, with the result that the lack of Javascript renders the site unusable. Clearly if you need it for essential content, that functionality will be lost. But there is no reason why the basic text of the site should be unavailable. Avoid nearly-meaningless messages like “Javascript needed to view this site”. If you have something worth showing, tell the user what it is, e.g. “enable Javascript to see animation of solar system”.

Switch plug-ins off The considerations for plug-ins (such as Flash or Java) are very similar to those for Javascript above. Check the site with any plug-ins disabled. The basic text and navigation should still work. Interest the reader sufficiently, and he might just go to the trouble of down-loading the plug-in. Greet him with a blank screen or a “You need Flash to read this site” message and he will probably go away, never to return.

Switch images off If scanning a number of sites quickly for information, many readers (including myself) switch images off, for quick loading. Other people cannot view images. So switch images off and check that the site is readable and navigable. This means, in particular, checking that sensible ALT texts have been provided for images. (This check is similar to using a text browser, but not quite the same).

Other checks Check non-reliance on mailto In order to give readers a chance to contact them, web authors often include a link of the form “mailto:[email protected]”. However this unfortunately does not work for anything like all browser/e-mail client

combinations. And people in e.g. an Internet cafe cannot use this type of link. Indeed the figure is sometimes circulated that as many as 50% of readers cannot use mailto links. While I doubt whether the true figure is quite this high, it is a substantial number. Many readers prefer a form anyway: most of the responses I get to this site come via the contact form rather than the mailto link. Therefore the best thing is to provide a contact page which has both a mailto link and a contact form; the user can then choose which to use. See my own contact page as an example.

Check for orphan pages An orphan page is one that contains no links back up to its ancestors – i.e. to pages higher in the hierarchy of the site. Once one arrives at an orphan page, the only way to get to the rest of the site is via the ‘back’ button. Which is fine until people arrive at the page via a search engine, or via a link that someone else gave to them. They cannot then visit the rest of the site. (True, they may be able to get up the hierarchy by lopping off the end of the URL, but this depends on how the site is built, and is in any case not reader-friendly.) So ensure all pages include a link back up the hierarchy. Orphan pages are particularly easy to overlook in sites with frames. Remember that when one addresses the page directly the other frames are absent.

Check sensible page titles Check that the page titles (i.e. the contents of the elements) are sensible. Page titles are important, as for example they show up prominently in search-engine results, in bookmarks and also on the tabs of multi-tab browsers such as Opera. Generally speaking, each page of a site should have a unique title. They seem to be somewhat prone to the dreaded cut & paste disease. The “grep” tool is convenient for quickly checking the titles in all your page source files. A quick web search reveals over a million pages with the illuminating title “New Page 1”, while “Untitled” pages run into several millions. Posted by Anoop at 2:01 AM 0 comments Labels: functional testing check list, testing check list, Website Checklist