You can use perldoc Time::Local or man strftime to find out more about possible ways
to format time.
Perl’s Time Idiosyncrasies
Although Perl is very flexible and is definitely a good tool for this job, it
has its idiosyncrasies. Be careful of the month values when writing code
like this. For some inexplicable reason, they begin counting months with
0. That is, January is 0, and February is 1, instead of January being 1.
Days are not done this way. The first day of the month is 1. Furthermore,
you need to be aware of how the year is encoded. It is the number of
years since 1900. Thus, 1999 is 99 and 2008 is 108. To get a correct
value for the year, you must add 1900. Despite all the year 2000 histrionics, there are websites to this day that show the date as 6/28/108.
4.9 Encoding Time Values Programmatically | 69
4.10 Decoding ASP.NET’s ViewState
Problem
ASP.NET provides a mechanism by which the client can store state, rather than the
server. Even relatively large state objects (several kilobytes) can be sent as form fields
and posted back by the web browser with every request. This is called the ViewState
and is stored in an input called __VIEWSTATE on the form. If your application uses this
ViewState, you will want to investigate how the business logic relies on it and develop
tests around corrupt ViewStates. Before you can build tests with corrupt ViewStates,
you have to understand the use of ViewState in the application.
Solution
Get the ViewState Decoder from Fritz Onion (http://www.pluralsight.com/tools.aspx).
The simplest use case is to copy and paste the URL of your application (or a specific
page) into the URL. Figure 4-4 shows version 2.1 of the ViewState decoder and a small
snapshot of its output.
Discussion
Sometimes the program fails to fetch the ViewState from the web page. That’s really
no problem. Just view the source of the web page (see Recipe 3.2) and search for type= "hidden" name="__VIEWSTATE"...>. Take the value of that input and paste it into
the decoder.
If the example in Figure 4-4 was your application, it would suggest several potential
avenues for testing. There are URLs in the ViewState. Can they contain JavaScript or
direct a user to another, malicious website? What about the various integer values?
There are several questions you should ask yourself about your application, if it is using
ASP.NET and the ViewState:
• Is any of the data in the ViewState inserted into the URL or HTML of the subsequent page when the server processes it?
Consider that Figure 4-4 shows several URLs. What if page navigation links were
derived from the ViewState in this application? Could a hacker trick someone into
visiting a malicious site by sending them a poisoned ViewState?
• Is the ViewState protected against tampering?
ASP.NET provides several ways to protect the ViewState. One of them is a simple
hash code that will allow the server to trap an exception if the ViewState is modified
unexpectedly. The other is an encryption mechanism that makes the ViewState
opaque to the client and a potential attacker.
• Does any of the program logic depend blindly on values from the ViewState?
70 | Chapter 4: Web-Oriented Data Encoding
Figure 4-4. Decoding ASP.NET ViewState
Imagine an application where the user type (normal versus administrator) was
stored in the ViewState. An attacker merely needs to modify it to change his effective permissions.
When it comes time to create tests for corrupted ViewStates, you will probably use
tools like TamperData (see Recipe 3.6) or WebScarab (see Recipe 3.4) to inject new
values.
4.11 Decoding Multiple Encodings
Problem
Sometimes data is encoded multiple times, either intentionally or as a side effect of
passing through some middleware. For example, it is common to see the nonalphanumeric characters (=, /, +) in a Base 64-encoded string (see Recipe 4.2) encoded with
4.11 Decoding Multiple Encodings | 71
URL encoding (see Recipe 4.5). For example, V+P//z== might be displayed as V%2bP%2f
%2f%3d%3d. You’ll need to be aware of this so that when you’ve completed one round
of successful decoding, you treat the result as potentially more encoded data.
Solution
Sometimes a single parameter is actually a specially structured payload that carries
many parameters. For example, if we see AUTH=dGVzdHVzZXI6dGVzdHB3MTIz, then we
might be tempted to consider AUTH to be one parameter. When we realize that the value
decodes to testuser:testpw123, then we realize that it is actually a composite parameter
containing a user ID and a password, with a colon as a delimiter. Thus, our tests will
have to manipulate the two pieces of this composite differently. The rules and processing in the web application are almost certainly different for user IDs and passwords.
Discussion
We don’t usually include quizzes as a follow-up to a recipe, but in this case it might be
worthwhile. Recognizing data encodings is a pretty important skill, and an exercise
here may help reinforce what we’ve just explained. Remember that some of them may
be encoded more than once. See if you can determine the kind of data for each of the