THE BASICS OF WEB HACKING: OUR APPROACH

Our approach is made up of four phases that cover all the necessary tasks during
an attack.
1. Reconnaissance
2. Scanning
3. Exploitation
4. Fix
It’s appropriate to introduce and discuss how these vulnerabilities and attacks
can be mitigated, thus there is a fix phase to our approach. As a penetration tester
or ethical hacker, you will get several questions after the fact related to how
the discovered vulnerabilities can be fixed. Consider the inclusion of the fix
phase to be a resource to help answer those questions.
Our Targets
Our approach targets three separate, yet related attack vectors: the web server, the
web application, and the web user. For the purpose of this book, we will define
each of these attack vectors as follows:
1. Web server: the application running on an operating system that is hosting
the web application. We are NOT talking about traditional computer hardware
here, but rather the services running on open ports that allow a web
application to be reached by users’ internet browsers. The web server may be
vulnerable to network hacking attempts targeting these services in order to
gain unauthorized access to the web server’s file structure and system files.
2. Web application: the actual source code running on the web server that provides
the functionality that web users interact with is the most popular
target for web hackers. The web application may be susceptible to a vast collection
of attacks that attempt to perform unauthorized actions within the
web application.
3. Web user: the internal users that manage the web application (administrators
and programmers) and the external users (human clients or customers) of the
web applications are worthy targets of attacks. This is where a cross-site scripting
(XSS) or cross-site request forgery (CSRF) vulnerabilities in the web application
rear their ugly heads. Technical social engineering attacks that target web users
and rely on no existing web application vulnerabilities are also applicable here.
The vulnerabilities, exploits, and payloads are unique for each of these targets,
so unique tools and techniques are needed to efficiently attack each of them.
Our Tools
For every tool used in this book, there are probably five other tools that can do
the same job. (The same goes for methods, too.) We’ll emphasize the tools that
are the most applicable to beginner web hackers. We recommend these tools not
because they’re easy for beginners to use, but because they’re fundamental tools
that virtually every professional penetration tester uses on a regular basis. It’s
paramount that you learn to use them from the very first day. Some of the tools
that we’ll be using include:
■ Burp Suite, which includes a host of top-notch web hacking tools, is a musthave
for any web hacker and it’s widely accepted as the #1 web hacking tool
collection.
■ Zed Attack Proxy (ZAP) is similar to Burp Suite, but also includes a free vulnerability
scanner that’s applicable to web applications.
■ Network hacking tools such as Nmap for port scanning, Nessus and Nikto for
vulnerability scanning, and Metasploit for exploitation of the web server.
■ And other tools that fill a specific role such as sqlmap for SQL injection,
John the Ripper (JtR) for offline password cracking, and the Social Engineering
Toolkit (SET) for technical social engineering attacks against web users!

Noteworthy HTTP Headers

Each HTTP cycle also includes headers in both the client request and the server
response that transmit details about the request or response. There are several of
these headers, but we are only concerned with a few that are most applicable to
our approach covered in this book.
The headers that we are concerned about that are set by the web server and sent
to the client’s browser as part of the response cycle are:
■ Set-Cookie: This header most commonly provides the session identifier
(cookie) to the client to ensure the user’s session stays current. If a hacker can
steal a user’s session (by leveraging attacks covered in later chapters), they
can assume the identity of the exploited user within the application.
■ Content-Length: This header’s value is the length of the response body in
bytes. This header is helpful to hackers because you can look for variation
in the number of bytes of the response to help decipher the application’s
response to input. This is especially applicable when conducting brute force
(repetitive guessing) attacks.
■ Location: This header is used when an application redirects a user to a new page.
This is helpful to a hacker because it can be used to help identify pages that are
only allowed after successfully authenticating to the application, for example.

The headers that you should know more about that are sent by the client’s
browser as part of the web request are:
■ Cookie: This header sends the cookie (or several cookies) back to the server
to maintain the user’s session. This cookie header value should always match
the value of the set-cookie header that was issued by the server. This header is
helpful to hackers because it may provide a valid session with the application
that can be used in attacks against other application users. Other cookies are
not as juicy, such as a cookie that sets your desired language as English.
■ Referrer: This header lists the webpage that the user was previously on when
the next web request was made. Think of this header as storing the “the
last page visited.” This is helpful to hackers because this value can be easily
changed. Thus, if the application is relying on this header for any sense of
security, it can easily be bypassed with a forged value.

Noteworthy HTTP Status Codes
As web server responses are received by your browser, they will include a status
code to signal what type of response it is. There are over 50 numerical HTTP
response codes grouped into five families that provide similar type of status
codes. Knowing what each type of response family represents allows you to gain
an understanding of how your input was processed by the application.
■ 100s: These responses are purely informational from the web server and usually
mean that additional responses from the web server are forthcoming.
These are rarely seen in modern web server responses and are usually followed
close after with another type of response introduced below.
■ 200s: These responses signal the client’s request was successfully accepted
and processed by the web server and the response has been sent back to your
browser. The most common HTTP status code is 200 OK.
■ 300s: These responses are used to signal redirection where additional
responses will be sent to the client. The most common implementation of
this is to redirect a user’s browser to a secure homepage after successfully
authenticating to the web application. This would actually be a 302 Redirect
to send another response that would be delivered with a 200 OK.
■ 400s: These responses are used to signal an error in the request from the
client.
This means the user has sent a request that can’t be processed by the
web application, thus one of these common status codes is returned: 401
Unauthorized, 403 Forbidden, and 404 Not Found.
■ 500s: These responses are used to signal an error on the server side. The most
common status codes used in this family are the 500 Internal Server Error
and 503 Service Unavailable.
Full details on all of the HTTP status codes can be reviewed in greater detail at
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.

Usual Arithmetic Conversions

 Most C operators perform type conversions to bring the operands of an expression to a common type or to extend short values to the integer size used in machine operations. The conversions performed by C operators depend on the specific operator and the type of the operand or operands. However, many operators perform similar conversions on operands of integral and floating types. These conversions are known as "arithmetic conversions." Conversion of an operand value to a compatible type causes no change to its value.

These conversions are performed on the operands of a binary operator to bring them to a common
type, which is then used as the type of the result:
[1] If either operand is of type long double, the other is converted to long double.
• Otherwise, if either operand is double, the other is converted to double.
• Otherwise, if either operand is float, the other is converted to float.
• Otherwise, integral promotions (§10.5.1) are performed on both operands.
[2] Otherwise, if either operand is unsigned long long, the other is converted to unsigned long
long.

• Otherwise, if one operand is a long long int and the other is an unsigned long int, then
if a long long int can represent all the values of an unsigned long int, the unsigned long
int is converted to a long long int; otherwise, both operands are converted to unsigned
long long int. Otherwise, if either operand is unsigned long long, the other is converted
to unsigned long long.
• Otherwise, if one operand is a long int and the other is an unsigned int, then if a long
int can represent all the values of an unsigned int, the unsigned int is converted to a
long int; otherwise, both operands are converted to unsigned long int.
• Otherwise, if either operand is long, the other is converted to long.
• Otherwise, if either operand is unsigned, the other is converted to unsigned.
• Otherwise, both operands are int.
These rules make the result of converting an unsigned integer to a signed one of possibly larger size
implementation-defined. That is yet another reason to avoid mixing unsigned and signed integers.