Chapter 5, Mitigating Web Site Risks, Threats, and Vulnerabilities
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 several ways:
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
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 occur:
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
to the victim that runs in the 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 manufacturers.
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 a two and a half page excerpt from a
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
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 malicious page.
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
Continue the reading assignments for the course.
Download the new lab handouts as they become available, and
submit your work on them.