ITS 4050 - Internet and Web Security

Chapter 5, Mitigating Web Site Risks, Threats, and Vulnerabilities

This lesson presents some material from chapter 5. Objectives important to this lesson:

1. Monitoring and controlling visitors
2. User input
3. OWASP threats
4. Additional threats
5. Mitigation
   

Concepts:

Chapter 5

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.

1. 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.
   
2. 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.
3. 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:
   1. 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 script (typically Javascript) 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.
   2. 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.
4. 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.
5. 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.
6. 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 privacy policy for the US Department of Education. It addresses most of these ideas, and some from other numbered areas in this list.
7. 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.
8. 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.
9. 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.
10. 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 and mitigations.