Chapter 5, Mitigating Web Site Risks, Threats, and
This lesson presents some material from chapter 5. Objectives
important to this lesson:
Monitoring and controlling visitors
Page 112 presents a list of visitor tracking information that can
be used to determine the sorts of traffic a web site is
experiencing. It also presents five features of Google Analytics, which is a "premium
service" that is apparently the most used tracking information
product on the Internet. It has been years since I looked at it,
so it is probably time to take a look again.
As the video shows, this product is meant to be used by web
entities who are selling products. For my web site, it seems like
quite unnecessary. The service is for people who are trying to
make sales of some sort. That being set as a beginning, the text
proposes that a web provider should create a profile/description
of the kind of customer the site is for. A list of demographic
attributes appears on page 115. Some vendors will not care about
some of these attributes, but unless you determine which are the
common factors that describe your customers, you won't know which
ones are actually important to increasing your customer base.
This leads us to ask how we get such information? The text
proposes that we collect it from our existing customers in any of
Forums - People participating in forums often supply
information about themselves, but we have to question whether
the posted information is true. Analysis of forum postings can
be difficult, as can monitoring them for trouble from bullies
and stalkers. Forums need to be monitored for content as well as
for antisocial behavior.
Feedback forms - Data about customers may be more
reliable when the customer fills out a form to register for
updates, sales notifications, and product support. Feedback on
the site itself should be separated from feedback on specific
products, but both kinds are useful to the vendor. Be aware that
people are more likely to fill out a feedback form when they are
unhappy than when they are happy or content. The same is true
for the next tool.
Online surveys - An effective survey takes more time
and expertise to create than the average user of Survey Monkey might think. The
people who run that service know that asking the wrong question
will make a survey useless. In general, ask questions that get
to your point of interest. Provide responses to multiple choice
questions that are mutually exclusive: don't make the user
choose between two choices when they actually want both. Keep
your surveys short, and try very hard not to make the customer
less happy than when they started the survey. I often find this
happens to me when I take employee surveys. I am less happy with
my employer at the end than I was before I started. That is no
way to retain an employee or a customer.
The chapter spends the next thirty pages on the topic of threats,
as listed by OWASP. Let's see what we can learn from that.
Injection attacks - Injecting SQL commands affects a
database, so it is a favorite technique for manipulating a DBMS
running on a web server. Injecting operating system command is
also possible, as shown in the following video, another
selection from Computerphile. 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.
Broken authentication and Session Management - Broken
authentication happens when a hacker uses the ID and
password that belong to a legitimate user. The authentication
process has failed its purpose, so it is 'broken". The text
recommends the usual ideas: protect your password, use a strong
password, and change your password often. Students who have been
at Baker for a while may notice that their network/web passwords
expire more often than they once did. This is a setting that the
administrators of a network or a web application can take to
make their users act more responsibly.
Session management is more complicated. The text explains
that a session between a user and a web application server may
only use plain text in a URL to identify a session. This is not
at all secure. The text recommends that session identifiers be
protected with SSL and that caching be limited to prevent a
lurking hacker from using the back button on a browser to
reenter a session that should have been closed. Sessions should
automatically close when the user closes their browser, when the
user signs off, and when a set time limit has been reached.
Normally this time limit is based on inactivity in the session,
but it can be based on total connection time.
Cross-Site Scripting (XSS) - Yes, it should have
been CSS, but that is already used for Cascading Style Sheets,
so good for the person who chose an unused TLA (three letter
acronym). The text describes two ways this kind of attack might
A stored attack starts by sending a message or
spam to a victim. The victim is given a link that takes them
to a web server set up for the attack. The server sends a
victim's browser. The victim will not notice this happening.
The script harvests data from the victim's computer and
sends it to the attacker.
A reflected attack is similar, but it depends on
the script being in the URL sent to the victim. Following
the URL sends the script to a server that is not defended
against this attack, which then sends the script back to the
victim's browser, which runs the script, harvesting
information and sending it to the attacker.
The text recommends that we train users about XSS spam and other
mail and message threats, and that we use policies and firewall
rules to prevent access to known threat sites.
Unsecure Direct Object References - The short version
of this seems to be that giving users access to part of a
directory tree can lead to their having access to the entire
tree unless rights are properly restricted. We should use file
system rights restrictions, and examine user inputs to keep them
from requesting access to folders that they should not access.
Security Misconfigurations - This is the classic
"admin, admin" problem, which comes from devices like switches
and routers having default ID and password values for the
administrative user that are never changed by the proper user.
The text discusses examining devices for default settings and
changing device settings as necessary. It also suggests keeping
devices patched and updated, which is really another issue, but
it is good advice. The text also recommends removing devices
from your system/network that are no longer receiving security
updates due to reaching the end of support from their
Sensitive Data Exposure - Most companies and people
have sensitive data that needs protection from attackers. The
text recommends making plans to identify sensitive data, to
protect its storage devices, and to limit access to it. There is
Department of Education. It addresses most of these ideas, and
some from other numbered areas in this list.
Missing Function Level Access Control - The text
compares this problem to the directory tree problem in number 4.
The main difference seems to be that this one allows users to
access web pages with a browser that they should not have
permissions to access. The recommended mitigations are
essentially the same.
Cross-Site Request Forgery - This one takes a little
more explanation than some of the others. The attack takes place
on a malicious web site that reads cookies from your browser,
uses them to reconnect to an authenticated session worth
attacking (such as on accessing your bank account), and uses the
cookie to make transactions on the site where you actually have
rights. This kind of attack makes it clear that we need to deal
with session management, as discussed in item 2 above.
Using Components with Known Vulnerabilities - As noted
above (is everything a remix?) devices and
software reach the end of support from their
manufacturers/publishers, and there comes an end to patches and
updates for them. This means that new vulnerabilities will not
be countered. Why does that matter? It matters because people
are still using those devices and that software, which puts them
at risk for attack from anyone who knows about the unprotected
system that is using them. Mitigation? Quit doing that.
Unvalidated Redirects and Forwards - The last of the
ten items from OWASP describes the use of redirects and
forwards, which can be used by legitimate web masters or by
hackers to cause requests for URLs in one domain to be converted
into requests for another domain. The text give us an example of
redirecting with a set of Google tools. If you run a search on Google about the subject,
you will see several links from various domain providers to
instructions on doing the same thing through their web consoles.
This is meant to be a tool used by web masters who want to move
to a new domain, but need links to pages in the old domain to
resolve to the new one. The text does not make it clear why this
is a problem, nor does it provide a mitigation for it that would
do any good. The result of redirection is the same as DNS
poisoning: it sends a browser to the wrong page which could be a
This chapter continues to discuss other variants on its issues. I
will direct your attention to the table on pages 143 and 144,
summarizing threats and mitigations.
Continue the reading assignments for the course.
Download the new lab handouts as they become
available, and submit your work on them.