This lesson presents material from chapter 9. Objectives important
to this lesson:
Attacking web servers
Cloud computing aspects
The chapter begins with some hints that a web server may have vulnerabilities
that a server administrator may miss, overlook, or not have in today's
list of things to handle. The list that should be addressed begins on
server defects and misconfigurations - this covers servers that allow
hackers to steal information, to enumerate them, to run scripts and
executables, and to run DoS attacks
browser and network risks - browsers are meant to interact with servers,
which are part of the network; we need to guard against captured traffic
being of any use to the attacker
client side risks - as we have discussed, attacks can take place on
the client's machine, harvesting information and planting malware
The text addresses server side issues for several pages:
general issues that apply to any server on a network, which
the text reminds us is critical for a company that has no brick-and-mortar
presence, and must rely on its web presence as the only face its customers
comments and actual functional code in web pages - on
page 216, we see an example of a documentation comment marking a section
of code that sends mail to several servers, plus actual server URLs
and email addresses in that block of code
buffer overflow - this topic is rarely explained, so I will
offer this video from Computerphile,
which has the best discussion I have seen about why a buffer overflow
could cause code to actually be executed. This video was presented in
week 3 of the ITS 4050 class, so it will be review for some of you.
denial of service attacks - the text gives us a brief idea
about defeating a single-source DoS attack: block traffic from it;
this is best done dynamically by firewalls that can notice the kind
of traffic such attacks produce and write new rules to reject such
distributed denial of service attacks - the text realizes that
a distributed denial of service attack is harder to defend against,
due to the variety of sources of the attack packets, and due to the
volume of packets being sent by the attacker's zombie army.The text
mentions four variations on distributed denial of service attacks:
Ping flood - The idea
here is to send a ping request to the broadcast address of the network
a target machine is on. This can be a problem if there are a large
number of devices on the target network (and they all respond).
This is a reasonable argument to segment your network in a way that
your important devices are on small subnets. Another approach would
be to configure devices to refuse
response to broadcasts.
SYN flood attack - In chapter 6, we discussed using TCP
packets in a SYN-connection port scan. Knowing which ports are open,
the attacker can flood them with SYN packets requesting connection,
preventing legitimate connections from taking place.
Smurf - The same thing
as a Fraggle attack, which uses UDP packets, except that Smurf uses
ICMP packets. Essentially, the attacker impersonates the server
to be attacked, and sends pings on its behalf to other networks.
The victim is flooded with responses. This reference
indicates that this can be an obsolete attack if servers are configured
to refuse this kind of traffic, but a large enough volume of it
would still be a problem.
Fragmentation attack -
This attack requires that the attacking packets be segmented (broken
into smaller pieces) in a way that prevents their nature from being
recognized by network or server defenses. The attack only takes
place when the segments are reassembled into the actual payload
the attacker meant to send.
banners - Banners are default messages sent by a web server
in response to a telnet request. When they were invented, their purpose
was to make connection to the server easier. Obviously, this was not
considered from a defensive point of view. Page 218 shows us a typical
banner that displays a server's IP address, its default page, and other
general information. This information can be changed by an administrator.
The image below depicts the result I received from a quick attempt
to read the banner of the main Baker web server.
As you can see, I saw an IP address and a URL, but I could have gotten
that less intrusively. Also, there was no banner from the server.
more general advice - set permissions wisely, do
not share error messages with users/hackers, and harden servers
by removing services that they do not need to provide
Our author moves on to a short discussion of SQL attacks. (He seems to
like to call it "sequel". I have heard it called by its initials
more often, but both are correct.) Injecting an operating system command
is also possible, as shown in the following video, another selection from
This time Dr. Pound discusses what might be happening on the server side
when an injection attack takes place.
As the text points out, the defense against injection is to validate the
inputs gathered from a user. Don't trust that a user will enter what you
ask for. It is more than checking for a valid entry in a web form. It
is checking for attacks as well.
For those who want more information about the nature of an SQL attack,
in that last video Dr. Pound was pointing us to another Computerphile
video containing those details, this one by Tom Scott.
The very destructive attack described by Mr. Scott leads us into the
next topic, vandalizing web servers. As you can see in the lists of vulnerabilities
and attack vectors on the rest of the pages in this chapter, there are
many ways a web server can lose its functions and its contents.
We should all be believers in validation of user input at this point.
We should hope that web masters scrub their servers, deleting unauthorized
scripts regularly. Since this is probably not continuous, and since
it will never happen on servers set up by attackers, we have to watch
out for scripts running on our computers, provided by web pages.
Use the remainder of the chapter as reference material in your submissions
for Assignment 5 and Project 5, assigned this week.
This week Project 4 and Assignment 4 are both due. You need to
take the mid-term exam.
Project Part 5 and Assignment 5 will be due in two weeks. Lab 5
is due next week.