Tải bản đầy đủ - 0trang
13 Using Threading for Performance
The example in Example 8-13 is pretty minimal and just shows you the basic techniques. The threads execute in an unknown order, and they might take any amount of
time to run. That’s part of the point: to simulate a bunch of unrelated web browsers
hitting your application in random order.
One of the best uses of multithreading like this is to test applications where it is acceptable to have the same account logged in more than once. Build a subroutine that
logs in, executes a function or two, and tests the resulting output or state, then exits.
Now launch a bunch of threads executing that subroutine. Take care to note our warnings about threading in the upcoming sidebar Threading Is Hard!.
Threading is an optional module in Perl. It might be compiled into your Perl, or it might
not. If it is not, you either have to get a threading Perl or give up on running this kind
of test. Run the command perldoc perlthrtut to learn about threading and how to tell
if your implementation has threads enabled.
Threading Is Hard!
Be aware that multithreaded and concurrent programming is hard for many, many
reasons. If you don’t stray far from the example in Example 8-13, you’ll do alright, but
it is very easy to imagine some simple modifications that are surprisingly hard to do
correctly. Telling you how to do multithreaded programming is beyond the scope of
this book, but we can offer a few guidelines on things that will help get it right most of
Make sure to use my on all the variables in your threads. Don’t try to pass data between
threads. Writing to global variables is a sure way to get into trouble when you’re multithreading. Your programming language (Perl in this case) will let you do it, but you’ll
almost certainly get unexpected results. Only pass data from the thread to the main
program through the return value in the join() call. It’s not that there is no other way
to pass data around; it’s just that this is the safest, simplest method if you’ve never done
A cobbled-together, threaded Perl script is not a substitute for a well-planned, properly
executed performance test plan. Just because you can execute a whole bunch of threads,
doesn’t mean you’ll accomplish a lot. You might bog down your Perl program so much
that you actually don’t execute many concurrent processes at all. Do some experiments
to see just how many threads you can realistically get going at the same time.
Be careful with things like the sleep command in Perl. In some operating systems, your
whole process (i.e., all threads) may go to sleep and stop running if you call sleep in
just one of them or in your main program. Unfortunately, it’s beyond the scope of this
book to tell you which operating systems and Perl versions will behave this way.
176 | Chapter 8: Automating with LibWWWPerl
Seeking Design Flaws
This is the rock-solid principle on which the whole of the
corporation’s galaxy-wide success is founded. Their fundamental design flaws are completely hidden by their
superficial design flaws.
This chapter takes a look at common design flaws. We explore possibilities where an
application may be used against itself. Up until this point, we have focused on manipulating the basic structure of web applications. We’ve taken apart HTTP and HTML,
decoded encodings, and automated some of our methods. Now, we will focus on
There are two kinds of security defects in the world: bugs and flaws. The difference
between them is important to how we test and how we report our findings. The difference also factors into how they get fixed.
Bugs are the simplest kind of security problem. They’re a very local mistake. The software was specified and designed correctly, but the developer made a mistake in the
implementation. Bugs can typically be fixed by applying a very localized change to a
small subset of the software. Redesigning or changing requirements is not necessary.
Many of the most popular security issues are bugs: SQL injection, cross-site scripting,
buffer overflows, code injection, etc. All of these can be the result of bugs.
The other kind of security defect—flaws—are the result of a mistake in the design or
requirements. The developer could write the code correctly and implement exactly
what the design calls for, but there would still be a defect. Imagine an online shopping
cart that stores the quantities, item numbers, and prices in the web browser’s cookie.
Even if it is implemented correctly, this is a bad idea from a security point of view. The
attacker can modify prices by simply changing his cookie. Fixing this flaw in the design,
however, will require cross-cutting changes across many parts of the application, as
well as changes to the design. It’s not a simple fix of a few lines of code in a couple of files.
All kinds of people make mistakes that create defects for us to find: business analysts,
application designers, developers, architects, and so on. While an architectural flaw
can be more difficult to fix than a code change, it is possible to detect such flaws earlier
in the development cycle. Even if there is not a single line of code written for your
application, you might want to mentally rehearse some of these tests against the proposed design. Would the design rely on randomness, or access controlled identifiers?
If so, how should the design adapt? Asking these questions early can prevent a lot of
9.1 Bypassing Required Navigation
If navigation between protected areas of your web application is easily predictable and
weakly enforced, it may be possible to skip some protections by directly requesting
pages out of order. This recipe demonstrates how to predict navigation and then attempt to bypass it.
By far, the easiest way to predict navigation is to follow the required course, then go
back and use what you have learned to skip a step. For instance, imagine a shopping
cart system that uses the following URLs in sequence:
What happens if a user pastes in the confirmOrder.asp URL immediately after verifying
their address? If the sequence of the order were weakly enforced and poorly validated,
conceivably the order would be shipping without ever having been paid for!
In order to discover this weakness, all one must do is place a valid order, record the
appropriate URLs, and use this information the next time to navigate to an out-ofsequence URL.
While the example above is somewhat trivial, this particular vulnerability is quite common. Another variation on this theme is to include parameters in the URL that indicate
the current state of the process. If you see a URL like http://www.example.com/down
load.jsp?step=1&auth=false, you should consider what happens if you change that to
http://www.example.com/download.jsp?step=5&auth=true. Many software-download
websites try to force users to enter a name and email address before downloading free
or trial versions of software. Very often a quick glance at the HTML source will tell you
178 | Chapter 9: Seeking Design Flaws
where the download link is. You can directly browse to that link without entering a
name or email address.
There are many ways to prevent this vulnerability, such as using formal authentication
or authorization, or just keeping a checklist of visited pages in session data. The difficult
part is identifying a sequence as required and what the various paths are. As these paths
are essentially state information about the user, state transition diagrams can be particularly helpful during test design.
You may be familiar with state transition diagrams from software development.
Traditionally, state transition diagrams formalize the legitimate pathways through the
system. By following a few valid paths, one can test many states sequentially. However,
in this case you should use the state transition diagram to identify and attempt the
invalid transitions. This removes the efficiencies normally associated with state transition test design, but still helps identify good security tests.
While predictable IDs represent the majority of cases, there are other forms of unprotected predictable navigation. The most classic example is perhaps the default administrator account. Many software packages are shipped with a default administrator
account, accessible via an admin page with a default password. Do not let default admin
pages remain exposed without a custom password (and perhaps not even then)! The
default admin password will usually be specified in the documentation for all to see.
This example is so well known that it’s become something of a cliché, but a quick
Google query reveals that many, many applications still expose admin pages (http://
www.google.com/search?q=intitle). The lesson here is: when using software packages,
always check to ensure that the passwords and settings have been changed from the
default or that the defaults are built to be secure.
Beware Bypassing Navigation
At a major university, the Psychology 101 course was extremely popular with as many
as 500 or more students enrolled in any given semester. The professor and teaching
assistants found it cumbersome to proctor and grade exams for so many students, so
they built an online exam system. Exams could be taken in computer labs, scored immediately, and the grades could be more easily tracked and curved.
Each exam required the student to answer all the questions, then it showed the student
her score and ultimately revealed the questions she got wrong—along with the correct
answers. The online exam system allowed students to take previous years’ exams from
home, just like proctored exams, except they could be taken by anyone at any time.
While taking a practice exam, one student discovered that you could skip to the answer
page prior to submitting the questions! While the page indicated that the student got
every answer wrong, it clearly displayed the correct answers. Using this information,
the student could then go back to the question portion of the exam and submit the
correct answers. The proctored exams fell prey to this technique as well.
Rather than face these sorts of issues, the professor decided to scrap all online exams
and resort to pencil and paper—and video record the entire lecture hall during tests.
9.1 Bypassing Required Navigation | 179