ITS 4050 - Internet and Web Security

Chapter 11, Performing a Web Site Vulnerability and Security Assessment

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

1. Vulnerability assessment vs. application testing
2. Discovery
3. Vulnerability and security assessment
4. Planned attacks
5. Vulnerabilities in back-end and SQL databases
6. Preparing a report
7. Best practices
   

Concepts:

Chapter 11

Looks like the author was saving some pages for this chapter.

The author gives us a short list of the critical elements of an application test:

• Does the application meet the stated user requirements? (User requirements are common when we write our own software. They are less common for over-the-counter programs, but they are just as important for them.)
  
• Does the application work as it is desired and expected to? Does it produce errors?
• Does the application have any compatibility problems with our other applications or operating systems?
  

The answers to those questions are supposed to be yes, yes, no, and no. Note that these concerns do not deal specifically with security issues. The text moves on to consider factors in a security evaluation of a web site.

• the web server software
• the hardware and operating system of the box that runs the web server
• applications that are used on the site and their features, such as the customer interface for browsing and ordering products
• the databases that are used by the web server and by its applications
  

I think the author's point is that we have a lot more to check from the security point of view. He continues the chapter with some methods of discovering the components of a web site, using them as an attacker might, starting with a ping.

• Ping all IP addresses in the presumed system's network range to find live addresses. You may want to use Nmap.
  
• Use Nmap or Zenmap to find open ports on the active IP addresses.
  
• Use Nmap or Nessus to determine the operating systems of targets.
• Use Nessus to scan for vulnerabilities. Follow the first link to a Life Hacker article about using Nessus. Follow that second link to the SecTools site for other suggestions. On page 277, the text recommends running an authenticated scan with Nessus when possible. This requires that you have admin credentials, but it provides more information on policies and domain relationships. You could also use several of the tools we have used in labs this term. Several are discussed on this web scanners page, such as Burp Suite and skipfish. As you should be aware, there are many tools available in your Kali server for this purpose.
  

The text pauses again on page 276, warning us that scanning with these tools (and others) can actually be harmful to the servers involved, so white hat scanning should be done against test copies of the systems.

For those who prefer videos, this video walks you through installing Nessus on a Kali box. The presenter gives us a bit more than the Life Hacker article provides.

On page 282, the text proposes that we make and follow a plan for site testing. It recommends three general steps for penetration testing:

1. Develop a plan for the attack
2. Identify vulnerabilities
3. Attack and escalate privilege
   

The first two steps have been discussed already. Step 3 includes access to data at whatever level we attain. The ideal would be to attain root/administrator privileges, which the text sort-of recommends by using a buffer overflow attack to start a new shell, or to break out to a command prompt with the current admin's privileges.

The text continues with a recommendation to search for security flaws in back-end and SQL databases with tools meant for such testing. The author's picks are Metasploit and Acunetix. Metasploit tools are available in Kali. Acunetix is mentioned in the link in web page link in the unordered list above. This is a link to its home page. Page 285 gives us a general recipe for an SQL injection.

Page 286 starts the section about report writing. It presents an outline for a formal report to upper management which may be confusing to anyone who has not had the pleasure of preparing such a document. Let's look at its parts:

• Executive summary - This is the headline version of the report. Tell your story to people who don't have time to read the entire paper. I once worked in an organization that was run by an executive who had the reputation of only reading a few lines of any email or memo that he received. He trained us to tell the story in a few words. This is what you do in this section of the report.
• Summary of findings - Think of this as the technical summary. What did you find, what did that tell you, and what are you proposing that we do about it? You can use more sentences and more numbers than you use in the executive summary: people who read this section want to get an overview of your actual work, so they can decide whether they need to read the rest of the report.
• Details of the vulnerability assessment and the security assessment - This is the part that you write for an analyst who is going to follow up on your work, for peers to review, for a historical record of what you did, what you found, and what it all means. This part is full of details. It is meant to convince people who do this kind of work that you did a good job.
• Recommendations - What do you propose we should do in the short term, and in the long term? How can we remediate the problems? Is there a quick fix? Are there things we must do that can be spread out for a while? Whye does that last part matter? No one ever has a budget that will cover everything you want to do. Learn to make good choices, and learn to sell the things that still need to be done.
  

The chapter ends with general suggestions about testing and not stopping.

• Use the right tools for your scans. If you don't find what you expect to find, research other tools and try them.
• Test outside your network as well as inside it. If you can't test inside it due to lack of credentials, stop and ask yourself what you are doing. Don't hack without authorization, children.
• Research again. Learn from good reporters what happened in successful exploits. Learn to protect and learn to probe from actual events.