Home > Archive > Software Testing > January 2006 > how to break a website
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
how to break a website
|
|
| rati_lion@yahoo.com 2006-01-17, 4:03 am |
| Can anyone help me with some thumb rules for breaking a website ? I
have done the required (manual) testing but now its time for breaking
the system. Please define what should be the strategy of crashing down
a site.
PS: We donot use any tool. So suggest something which sud be a better
way manually and if we have a tool, thn i can evaluate it on basis of
our budget and feasibility.
Thanks
| |
|
|
| Vladimir Trushkin 2006-01-17, 7:09 pm |
| In order to get a meaningful answer you need to ask a meaningful
question ;)
Generally speaking, you may break your site with something that can
break _your_ site. It depends on what it does, what type of input from
a user it accepts, and where boundaries lie, sensitizing which may make
your site to break.
Another possible way is putting your site under extreme load. However,
it will be extremely difficult, near impossible without appropriate
tools. (You can write one yourself, all you need is a method os sending
queries to the site and measuring response time).
Hope this helps,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~
Vladimir Trushkin, IMC Belarus, QA Manager
mail: <mylastname>@tut.by
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~
| |
| Shrinik 2006-01-17, 7:09 pm |
| When you say that you have broken the site. What is the purpose of this
breaking? How many different ways you want to break the website?
As far stressing the site goes -- Heard of DOS (Denial of service
attack) - Try it.
Shrini
| |
| Michael Bolton 2006-01-17, 7:09 pm |
| > Can anyone help me with some thumb rules for breaking a website ? I
> have done the required (manual) testing but now its time for breaking
> the system. Please define what should be the strategy of crashing down
> a site.
In the Rapid Software Testing course, we define "test strategy" as "the
set of ideas that guide your test design", and we identify risk as a
key driver of test strategy. The strategies (note the plural) for
/crashing/ a Web site are only part of the strategies for identifying
weaknesses or vulnerabilities that can threaten a site. You would also
do well to consider (for example) the possibility of people breaking
into a web site and obtaining information that they don't have a right
to see; people using your site as a platform for attacking client
machines or other sites (cross-site scripting); people attacking your
site in ways that don't involve crashing it; and so forth.
So: you need much more than we can give you here. Google is your
friend. Try "web.site" and or "web.application" (include the periods)
with "security", "attack", "hacking", "penetration", "vulnerability",
"weakness" and so on.
In bookware, I really enjoyed (and profited from) "Hacking Web
Applications Exposed". There are plenty of others. The fellows who
wrote the book were with a company called Foundstone; look up some of
their white papers at http://www.foundstone.com.
> PS: We donot use any tool. So suggest something which sud be a better
> way manually and if we have a tool, thn i can evaluate it on basis of
> our budget and feasibility.
Sure you use tools. I think you mean to say "we don't want to pay for
tools". Most of the tools that hackers use are free; you can use these
same tools for good purposes.
---Michael B.
| |
| rati_lion@yahoo.com 2006-01-18, 4:00 am |
| Thanks a lot Michael. You have indeed helped me. Thanks again
Rati
Michael Bolton wrote:
>
> In the Rapid Software Testing course, we define "test strategy" as "the
> set of ideas that guide your test design", and we identify risk as a
> key driver of test strategy. The strategies (note the plural) for
> /crashing/ a Web site are only part of the strategies for identifying
> weaknesses or vulnerabilities that can threaten a site. You would also
> do well to consider (for example) the possibility of people breaking
> into a web site and obtaining information that they don't have a right
> to see; people using your site as a platform for attacking client
> machines or other sites (cross-site scripting); people attacking your
> site in ways that don't involve crashing it; and so forth.
>
> So: you need much more than we can give you here. Google is your
> friend. Try "web.site" and or "web.application" (include the periods)
> with "security", "attack", "hacking", "penetration", "vulnerability",
> "weakness" and so on.
>
> In bookware, I really enjoyed (and profited from) "Hacking Web
> Applications Exposed". There are plenty of others. The fellows who
> wrote the book were with a company called Foundstone; look up some of
> their white papers at http://www.foundstone.com.
>
>
> Sure you use tools. I think you mean to say "we don't want to pay for
> tools". Most of the tools that hackers use are free; you can use these
> same tools for good purposes.
>
> ---Michael B.
|
|
|
|
|