NVH’s Blog

Client-server testing typres Web-based testing
1) Gui testing 1) Links testing
2) Data communication 2) Performence
3) Cross platform testing 3) Browser compatability
These are types of testing to diffrenciate C/S and Web testing types
and Any more pls let me know. ok

This might help you
Key Differences Between Client-Server and Web

Fundamental differences between Web applications and clientserver
applications open enterprises to significant risks when they move to
the Web. For simplicity’s sake, let’s look at two major ways these
applications differ.

Heavy Client vs. Browser

The heavy, purpose-built clients used in client-server applications are
difficult to reverse-engineer, so it was difficult for hackers to
modify inputs to the server. Think about it: when you have a piece of
software running on your PC, you have no way to alter the messages it
sends to its server- the software has fixed buttons and widgets, with
no way to access the underlying code and manipulate the commands its
generates. Browsers, however, are very easy to manipulate. The source
of the client-side code is available to anyone accessing the Web page,
and easy to change. (Users can simply go to “View Source” under the
“View” menu of Internet Explorer or other browsers, change the code,
and then reload the page.) In fact, some hacker Web sites now even
offer tools such as ‘Web proxies’ which automate this type of
manipulation.

To improve server performance, reduce traffic on the network, and
enhance user experience, client-server applications do a lot of data
validation on the client side. Web servers try to utilize the browser’s
capabilities (HTML and JavaScript) to do data validation on the client,
but HTML can be changed and JavaScript can be disabled. In other words,
any validation or checks that developers can put into a browser, users
can simply disable or change. This places the entire burden of input
validation on the server side, and most programmers simply can’t check
every single input for potentially malicious values.

This aspect of Web applications exposes them to attacks such as Buffer
Overflow, SQL Injections, and Cross-Site Scripting. For instance, users
can take advantage of input fields in Web based forms to input
malicious code. Oracle recently announced that Oracle Application
11i-their most Webfriendly enterprise software to date-had left
several inputs un-validated, and open to tampering. An online auction
site recently discovered a particularly nasty vulnerability in their
e-commerce application: malicious users were listing auctions with
dangerous JavaScript commands in the item descriptions. Since the
auction software was not checking what people entered in to their
descriptions, all these JavaScript commands were being served up to
anyone who clicked on the auction. Through execution of their browsers,
people were opening new windows, stealing cookies, and so on-a
classic cross-site scripting attack.

State vs. No State

Let’s look at the second major difference between the old
client-server environment and the Web. In client-server environments, a
continuous session is maintained between each user and the server. Once
a user logs into the application, an unbroken connection feeds the user
appropriate information. In Web environments there is no session; users
request a page and then disappear from the server’s view until
another page is requested.

This opens the Web application to many types of attack. The most common
is forceful browsing (also called broken access control). This attack
consists of simply asking the Web server for pages or resources that
you should not have access to. In some cases, it might be book-marking
an internal page of an application, then jumping to that page later
without first passing through an authentication page. A well-known
financial services company recently had just this problem-users could
literally bypass the login page if they knew the address of internal
pages. In addition, sometimes users can just guess the URL of
information they want to see. A major record label recently released a
“sneak preview”-the first song of an upcoming album with a URL ending
in /track1.mp3.

Obviously it wasn’t long before the young audience realized that if
they simply typed in “track2.mp3″ or “track3.mp3″ they could access the
entire album. Somewhat more seriously, the Minnesota State Police
Department recently discovered that anyone could append
“/personsearch/personsearch .asp” to one of their public Web site
addresses and access the department’s police records. (They have since
fixed the problem.)

Another inherent limitation of the Web’s statelessness is that, in
order to keep track of users, Web applications must leave something in
the browser that identifies the user and the types of information
requested. For instance, if the Web server leaves a hidden field on the
page with a price or user group information, you can view the source of
the page, change it, and then resubmit the page.

The most common way servers track users is session cookies. Again, a
cookie resides on your PC, so you can access it and change it. Lee
Gomes of the Wall Street Journal recently exposed this flaw at Gateway
Computer. As Gomes reported, users could change their cookies and, when
they went back to www.gateway.com, they were greeted with “Welcome
back, x” and were able to access x’s credit card information, address
the works. Change the cookie again and you would be ‘recognized’ as
someone else!