• No results found

Security Risk Analysis for the Extreme Insecure Website

N/A
N/A
Protected

Academic year: 2021

Share "Security Risk Analysis for the Extreme Insecure Website"

Copied!
21
0
0

Loading.... (view fulltext now)

Full text

(1)

Security Risk Analysis for the Extreme Insecure

Website

 

 

Tyler Lovell Kennetha Anderson Eugene Steslicki Justin Kurdila Daniel Clark   Team Unconquered Team Unconquered Team Unconquered Team Unconquered Team Unconquered   Florida State University Florida State University Florida State University Florida State University Florida State University   tjl12@my.fsu.edu kwanderson@fsu.edu xyz@my.fsu.edu jrk12b@my.fsu.edu dc14r@my.fsu.edu  

 

Part A

 

Abstract

 

This term paper is designed to provide information and analysis of the vulnerabilities of the website we created. We decided to do a risk analysis of varying parts of the website as well as covering the vulnerabilities. This term paper will define the security objectives, find the vulnerabilities and report on those vulnerabilities. We will be using different programs to go through different parts of the code in the website, finding what its security vulnerabilities are. After finding out what they are we will report on them and explain what can be done to fix these security vulnerabilities.

 

 

Keywords: Vulnerabilities, Risk, Security, DoS, Virtual Machine, PhP, Virtual Private Network  

 

 

Introduction

 

 

Since the beginning of the Internet, security has been an issue. The Internet has changed the world, as we know it. Not only has the Internet revolutionized the world and the way we communicate, but it has also is an example of “sustained investment and commitment to research and development of an information infrastructure” (Daniel C. Lynch). Websites have evolved dramatically over the years going from a static page with few icons and links to dynamic web pages that can move with the scroll of your wheel. The majority of websites nowadays can accept user input data and can translate that into another form of information allowing users to login to that particular company's website.  

 

Hackers are finding new ways to break into websites and steal people’s information. There are many ways hackers can get in or many ways hackers can get information simply from what people may enter into a text box. Hackers can exploit the software vulnerabilities through malformed Uniform Resource Locator (URL) or POST Headers. They can enact some of the attacks like Remote Code Execution (RCE), Remote/ Local File Inclusion (R/LFI), and SQL Injection (SQLI) attacks (Tony Perez). These attacks can exploit all sorts of vulnerabilities of web sites and web servers. These are just a few of the attacks that can happen. There are many more types of attacks than this, but these are the most common ones.  

 

The tools we will be using to scan the website will look for vulnerabilities in specific parts of the coding. Each scanner that will be used is for a particular part that will scan each line and go into the directories of the files. On in particular that we will be using is the Web server scanner. This scanner performs tests against the web server’s item such as files and programs and makes sure they are not vulnerable to any attacks. The PHP scanner looks into the PHP coding on the website. Hackers can upload code to the site and by simply doing that they could gain access to that site. This will sniff out that code and return values saying that the coding was not right.  

(2)

The overall goal of this project is to exploit the vulnerabilities of the extreme insecure website and

conclude a solution as to how to fix these issues. We are using these particular tools and scanners to help us better show what needs to be done.  

This paper will look at how to prevent hackers from entering our hypothetical website used in a previous lab during class. We will be using scan codes to find the vulnerabilities in this website and later find ways to prevent hackers from accessing these vulnerabilities. A few of the tools we will be using include a Web server scanner, a DoS Vulnerability scanner, and a PHP scanner. These will scan separate parts of the code in the websites and look for holes where a potential hacker could get in and access data.  

 

Current Attacks

 

Scanning for PHP vulnerabilities serves as a very important part in securing a web site. Sensitive sinks are constructs or functions that can cause vulnerabilities when passed specific data (Bouwers, 2006). These along with command execution and other vulnerabilities can lead to a possible loss of server security. Vulnerabilities in PHP code can also lead to unauthorized access. Having unauthorized access can lead to unwanted users executing malicious commands against the user’s program. “Common vulnerabilities include weak IIS configuration and unpatched servers that allow patch traversal and buffer overflow attacks, both of which can lead to arbitrary code execution” (Meier et al, 2003).

Denial-of-Service (DoS) attacks are one of the most powerful attacks performed by hackers that can impact a business or organization. DoS attacks are an attempt to make a machine or network resource unavailable to its intended users, such as to temporarily interrupt or suspend services of a host connected to the Internet. A DDoS or Distributed Denial of Service attack occurs when multiple systems flood the bandwidth or resources of a targeted system, usually with one or more web servers (Wikipedia, 2015). Many different network protocols can be used to launch these types of attacks.

In March of 2015, the Maine.gov state website was targeted by a DDoS attack that attempted to overwhelm the state’s web portal service with artificial web traffic. Maine.gov released a statement on the attack. Part of the statement mentioned, “The site remains online at this time, but users may

experience slowness or notice other performance issues as the attack continues” (Drinkwater, 2015). The group who took credit for the attack was ‘Vikingdom2015’. This same group is also credited with the attack on Amazon Twitch and claims that it tried but failed to take down the official website of the National Security Agency (NSA) (Drinkwater, 2015). There are certain recommended preventive measures against DoS and DDoS attacks:

Possible Countermeasures

 

Here are the countermeasures against sensitive sinks and unauthorized access:   •   “Configure IIS to reject URLs with “../” to prevent path traversal”

•   “Lock down system commands and utilities with restricted Access Control Lists (ACLs)” •   “Stay current with patches and updates to ensure that newly discovered buffer overflows are

speedily patched” (Meier et al, 2003)

•   Constructing secure and safe web permissions to prevent unauthorized access

•   Securing files and folders with restricted Network Transfer File System (NTFS) permissions Below are the countermeasures against DoS and DDoS attacks:

Firewalls

In the case of a simple attack, a firewall could have a simple rule added to deny all incoming traffic from the attackers, based on protocols, ports or the originating IP addresses. More complex attacks will however be hard to block with simple rules: for example, if there is an ongoing attack on port 80 (web service), it is not possible to drop all incoming traffic on this port because doing so will prevent the server from serving legitimate traffic (Wikipedia, 2015).

(3)

Most switches have some rate-limiting and ACL capability. These would have to be manually set. Some switches provide automatic and/or system-wide rate limiting, traffic shaping, delayed binding (TCP splicing), deep packet inspection, and spoofed IP address filtering to detect and remediate denial-of-service attacks through automatic rate filtering and WAN Link failover and balancing. These schemes will work as long as the DoS attacks can be prevented by using them (Wikipedia, 2015).

Routers

Similar to switches, routers have some rate-limiting and ACL capability. They, too, are manually set. Most routers can be easily overwhelmed under a DoS attack (Wikipedia, 2015).

It is important to assess your website in order to determine what the current vulnerabilities are. You must know which vulnerabilities are present in order to implement the proper countermeasures as a defense against them. Therefore, we tested the Extreme Insecure website for vulnerabilities using virtual machines (VMs) provided by the FSU CCI Lab. We used a virtual machine running a Windows

operating system and a virtual machine running a Linux operating system. We also used a local personal computer running a Window operating system.

Risk Evaluation Process

 

In order to accurately assess the security vulnerabilities of the Extreme Insecure website we decided to create a step-by-step evaluation process. We modeled our process after Microsoft's Threat modeling process, which can be seen in Figure 1 in Appendix A. While Microsoft's model can be applied to nearly any application, we have decided to break it down into a simplified version that anyone can understand. Figure 2 in Appendix A shows exactly how we have done this by breaking it down into three steps where step three is a loop that can be repeated until all security objectives and goals are met.  

 

Step 1: Understanding the Hosting Environment and Website Breakdown

 

 

In order to fix security problems in the Extreme Insecure website it is important to understand what the server and website architecture look like. The first thing we need to look at is the source code and layout of the website. The website consists of five listed pages that are available for navigation as well as several sub navigation pages that provide an updateable list of products and services that are offered. A full listing of the pages includes:

 

●   Primary Navigation

○   Index.htm – consists of information regarding the company and acts as the landing page ○   Toc.htm – contains the links to services.htm and products.htm as well as information

regarding content

○   Feedback.htm – provides a location to offer feedback and contact the company ○   News.htm – provides updates as to changes of the Extreme Insecure website ○   Search.htm – allows users to search the web site but currently directs the user to the

search_results.htm page ●   Sub Navigation

○   Services.htm – gives a list of the services that are provided

○   Products.htm – displays a listing and description of the products that are offered. ○   Search_results.htm – search.htm redirects the users here and displays the results of any

search

○   Feedback_successful.htm – displayed after a successful feedback.htm submission ●   Worth Mentioning

○   Process.php – PHP script that processes form and search submissions and then outputs the results.

 

Upon investigation, it can be found that the website was created using a tool offered by Microsoft known as Microsoft FrontPage. This software was originally offered as part of the Microsoft Office software package and was a “what you see is what you get” editing tool containing a graphics interface that allowed for easy website design. There are several problems with this that should be noted. The first is that Microsoft FrontPage was discontinued in 2006 when it was replaced by Microsoft Expression Web and SharePoint

(4)

Designer (Wikipedia, 2015). This leads to the website being outdated and containing compatibility issues with new improvements to web scripting and design. The second problem is that Microsoft FrontPage requires the use of server-side extensions that must be added to the server that the website is hosted on. The combination of these two problems leads to the server-side extensions being extremely vulnerable to new forms of malicious attacks.  

 

Next we need to examine the hosting environment that our website is is built on. The infrastructure for the websites is hosted on the LIS 4774L assigned virtual machine (VM) and is accessed through the Hyper-V Server Management software. A VM is a virtual computer system that is “a tightly isolated software container with an operating system and application inside. . . A thin layer of software called a hypervisor decouples the virtual machines from the host and dynamically allocates computing resources to each virtual machine as needed” (VmWare, 2015). The VM operates on a virtual private network (VPN) located inside Florida State University’s network. This allows for the VM to operate as though it is connected to the global internet, but only being accessible to those inside of Florida State University’s network.    

We created the structure for the web server on the VM through the installation of the LAMP server open-source software components. These components include the Ubuntu 12.04 Linux operating system, Apache 2.2 web server, MySQL database management system, and lastly PHP 5 scripting language. The Apache 2.2 web server is what will manage the sending and receiving of data from and to the website over the Internet. It will allow for the Extreme Insecure website to be accessible through the use of a browser once it is stored on the server.  

 

Step 2: Security Goals and Objectives

 

 

The next step in the process of securing the website from threats that seek to compromise its

confidentiality, integrity, and availability is to set out firm objectives and goals. We have chosen to follow a simple and modified version of the SAN Securing Web Application Technologies checklist that we feel is appropriate for our application. This checklist consists of the following criteria:

 

●   Error Handling and Logging

○   Display Generic Error Messages ○   Log any and all data access and activity ○   Store logs securely

●   Data Protection

○   Limit the usage and storage of sensitive information

○   Disable data caching using cache control headers and autocomplete ●   Configuration and Operation

○   Harden the Infrastructure ○   Define an Incident handling plan

○   Update existing code with the latest standards ●   Authentication

○   Do not disclose too much information in error messages ●   Input and Output handling

○   Set the encoding for the application ○   Validate the source of input Access Control  

○   Apply the principle of least privilege ○   Do not use invalid forwards or redirects

This list is subject to change as we progress through the steps of securing our website and new issues may come to our attention and take precedence. Once the majority of these have been accomplished we will feel more secure about the risks involved with hosting the Extreme Insecurity website.  

 

Step 3: Identify Threats and Implement Countermeasures

 

(5)

Identifying Vulnerabilities in PHP

 

For the Extreme Insecure Web Site, there are multiple html files that are responsible for the site’s content and navigation. These files handle and compile languages such as HTML, CSS, and JavaScript. For identifying vulnerabilities in the web site, we focused on the single file that processed the PHP for the web site: process.php. The process.php file is responsible for printing the results of the user input in the products page. When the user enters input such as ‘; cat Pointshere/points.htm’, and the process.php page uses the $_POST super global variable to navigate through the file structure, then the php file returns the correct content that the user queried. Figure 3 in Appendix A shows the content of process.php.  

 

To scan for the vulnerabilities in our process page, our group decided use the RIPS PHP Vulnerability Scanner. When researching an appropriate scanner to test the PHP file for vulnerabilities, we began with The National Institute of Standards and Technology (NIST) website. The RIPS Scanner is a tool written by Johannes Dahse and is used to detect sensitive sinks (potentially vulnerable functions) that can be corrupted by a malicious user. Figure 4 in Appendix A shows the landing page for the RIPS scanner.  

 

When researching the RIPS software, we learned that the scanner had to be installed on a local web server. So to use this scanner on a local personal computer, we would have to install a local web host to run PHP files. In order to use the RIPS software, we installed Apache, MySQL, MongoDB, PHP, Perl & Python for Windows (Ampps) on a local personal computer. To access the scanner once we had Ampps running, we navigated to localhost\rips\. From here, we were able to input the correct local file path for the process.php page and execute the scan. Figure 5 in Appendix A shows the RIPS scan complete with the results returned.  

 

Results

 

When reviewing the results from the scanner, we found that the security issue with the code was in command execution vulnerability. This vulnerability is known as a sensitive sink and the scanner found two in the process.php code. This vulnerability means that an attacker could potentially execute malicious commands on the operating system. This vulnerability could lead to a full server compromise. In addition to the command execution vulnerability, the RIPS Scanner also checks for other various vulnerabilities. Figure 5 shows the list of the vulnerabilities that the RIPS scanner checks.  

 

Identifying Denial of Service Vulnerabilities

 

DDoSPing v2.0  

In researching a way to test our Extreme Insecurity website for DoS/DDoS vulnerabilities, we found a free utility offered by McAfee called DDosPing v2.0. DDosPing v2.0 is a network admin utility for remotely detecting the most common DDoS programs. DDoSPing is a remote scanner for the most common Distributed Denial of Service programs (often called Zombies by the press). These were the programs responsible for the recent rash of attacks on high profile web sites. Scanning is performed by sending the appropriate UDP and ICMP messages at a controllable rate to a user defined range of addresses.  

The software was downloaded and installed on a Windows VM on the classroom’s internal network and configured to scan the IP Address of the Linux VM running the Extreme Insecurity, Inc. website. This utility is also capable of scanning every IP Address on the 192.168.1 subnet. There were no Zombie (compromised) servers detected. See Figure 6 in Appendix A.  

OWASP (Open Web Application Security Project) Switchblade v4.0  

OWASP Switchblade is a denial-of-service tool used for testing the availability, performance and capacity of a web application to be proactive about this type of risk condition. In 2010 the tool was created by ProactiveRISK to educate the OWASP Community about the Denial-of-Service conditions that can exist with OSI Layer7 (Application Layer). OWASP Switchblade is free to use and licensed under the

http://creativecommons.org/licenses/by-sa/3.0 Creative Commons Attribution-ShareAlike 3.0 license.

We downloaded and ran the OWASP Switchblade Tool from a Windows VM and used it as the “attacker”. The Windows VM was used to “attack” the Linux VM running the Extreme Insecurity

(6)

website. We used the OWASP Switchblade tool on our Extreme Insecurity web server to test for three different denial-of-service conditions.

Results

In each of the three attack scenarios, the Extreme Insecure Website became unavailable or unresponsive for a period of 15 – 25 seconds. These attacks successfully resulted in reducing the availability of the website. See Figure 7 in Appendix A.

Identifying Web Server Vulnerabilities with Nikto

 

Nikto2 is a vulnerability scanner that checks for possible vulnerabilities that may arise concerning the relationship that the hosted site has with its corresponding web server. It is an easy to use, concise, and open source tool that can be downloaded through the command line using sudo apt-get install nikto. Nikto has many different add-ons such as output formatting and port modulation. All such options can be

referenced a using the nikto -help command. After installing the application all you need is a target IP address and page location to scan.  

 

After entering the command nikto -host http:// xxx.xxx.x.xx/~path, nikto displays host information in the header of the report (Figure 8 in Appendix A). The body of the report starts with the server type and permitted HTTP methods. It then lists the security vulnerabilities that the scanner has found with a corresponding OSVDB reference number and file location. Each OSVDB reference number can be searched on http://osvdb.org/ where more detailed information is provided about the particular vulnerability. The osvdb.org website provides a comprehensive review of every vulnerability including solutions that may help in resolving each security issue.  

Results

 

From the Nikto scan we were able to identify four separate vulnerability cases each in multiple different locations on the site. There were 14 vulnerabilities in total with the majority of the errors being minor errors involved with files that may contain sensitive information that could easily be hidden from the global perspective (Figure 9 in Appendix A). Another aspect of the OSVDB site is the reporting of Common Vulnerability Scoring System (CVSSv2) rating which is a factoring of three different parameters: access vector, access complexity, and authentication. The site also shows which of the three key factors of security (availability, confidentiality, and integrity) have been compromised.  

 

OSVDB-3092 – was displayed in the first two lines of output that the Nikto scan gave us to look over (see Figure 8 in Appendix A). This error code deals with a file that has unnecessarily granted read permission to the world. This problem isn’t necessarily a security risk but can be if there were to be any sensitive information about the server in the files. The vulnerabilities database suggested removing the files from the web server and password protecting them.

Conclusion

After conducting this investigation into the security risks for the Extreme Insecure website, we have discussed the threats that could compromise the availability, confidentiality and integrity of the site. We used the Microsoft Threat Assessment model and adapted it to suit our needs. We conducted investigations into three of the major kinds of threats that are present in the cyber community for websites. These threats were DoS attacks, PHP script attacks and server vulnerability attacks. The results of these investigations lead us to find that our website was extremely insecure and as such we should implement several standard countermeasures listed at the beginning of this paper. Hackers will still try to take advantage of other risks that we may have missed but for the moment, they will have a harder time.

(7)

Part B

Introduction

Cross-Site Scripting attacks or XSS are types of attacks that inject malicious scripts into trusted websites (Acunetix, 2015). This is one of the most frequent types of attacks on websites in today’s society and occurs when a script uses invalidated user input within the output it generates. In this type of attack the user is not the one directly being attacked. Instead the attacker will attack the website itself which in turn will affect the people accessing that particular site. A few of the things that Cross-Site Scripting Attacks can take advantage of are VBScript, ActiveX, and Flash (Acunetix, 2015). However, the program that is taken advantage of the most is JavaScript because it makes up the majority of most websites. Another term for the XSS attacks is Server-Side Scripting Attacks. Things that a hacker can access within your browser are cookies, secession tokens, and other sensitive information just by adding code to the website that the user happens to be visiting. The hacker can then use these scripts to rewrite the content of the HTML page (Carroll, 2012).

A simple explanation of how XSS attacks work is an attacker has to find a way to encode the website with their code that the victims they want to target use the most. In order for an XSS attack to happen, the website needs to accept user inputs in its pages. The attacker can insert a string of code that will be used within the page itself while the browser will think that it is just normal code. When the page that the victim visits loads in their browser the malicious script will execute in the background so the user will have no idea that they are being attacked.

The importance of this attack is that it is a very common attack and the user has no idea what is happening to them. Because this is such a common attack it is important to know how to go about protecting yourself from these attacks and the ways to know if you are the victim of it. This part of the paper will describe the ways of prevention and give examples of the XSS attacks using the class website. Everyone should know the risks of using websites that are not trustworthy or have the possibility of being a victim of this type of attack. Also in this paper we will describe the steps taken for this part of our project as well as the countermeasures that can be taken to defend against this type of attack.

Breakdown of the host environment and website

As with part A of this paper, it is important to understand the hosting environment and website architecture in order to grasp what the security vulnerabilities are and from there implement countermeasures. We are hosting both the XSS and script-attacks vulnerability websites in the same environment as the Extreme Insecure website, with only a small modification to the Apache2’s default root directory. The default directory was changed to /var/www from /var/www/html. At this point we need to break down the website architecture. In the /var/www directory there can be found two subdirectories named /XSS and /script-attacks. Inside these two directories are located the .htm and .php files that are used on each website respectively. A full breakdown of each file can be found in Table 1 and Table 2 in Appendix B.

Initial Setup

Step 1: Move and unzip webhacking.zip.

To begin this exercise you must first move and unzip the webhacking.zip file into the /var/www directory. This is one through the use of the mv and unzip commands followed by webhacking.zip /var/www/.

Step 2: Edit directory and file permissions

In order for Apache2 to properly host the website we must first change the global permissions on the two directories as well as on the .htm and .php files. The directories must be given global read and execute permissions through the use of the command chmod + 705 directoryname. Inside each directory we must also give read permissions for the .htm files and execute permission for the .php files. This is done, again through the use of chmod +604 *.htm and chmod +705 *.php.

Step 3: Update and restart Apache2.

Inside of /etc/apache2/sites-available are two files named 000-default.conf and default-ssl.conf. In both of these files we must change the default directory to /var/www from /var/www/html. This will allow us to

(8)

type access the subdirectories located in /var/www and view them in our web browser. In order for these changes to take effect we must now restart Apache2 through the use of sudo service apache2 restart.

XSS Cookie Stealing Exercise

Step 1: User Interaction

This part of the exercise will deal with a method of how an attacker might steal cookies off of your machine. As such, the first thing that must be done is the user visits a webpage, in this case it will be localhost/setgetcookie.htm. The user will then enter a name and password, click the submit button and then view the cookie (See appendix B, images 1 and 2).

Step 2: Attacker provides malicious link

The next thing that will happen is that the attacked will provide a malicious link for the user to click on. In this assignment we are provided with two potential links. The first, when hovered over, displays that when click the user will be redirected to stealcookie.php. The second does not display the link location but sends the user to stealcookie.php as well (See appendix B, images 3 and 4).

Step 3: Stolen Cookies

Once the user has clicked on either of the two links, they will be taken to stealcookie.php on redirect.htm. At this point the attacker has successfully stolen the cookies in their browser through the use of the GET method.

Step 4: Final Step

At this point, the attacker will view the location that the cookies have been logged to, for this exercise that is log.txt (See appendix B, image 5)

Script-Attack

Step 1: Navigate to the webpage.

The first thing when enacting a script attack is to navigate to the website of your choice. During this exercise the website was localhost/script-attacks/sample.htm.

Step 2: Insert desired command

Once the attacker has reached the desired location, they may begin their script attack. In this case we found a vulnerable input field (See appendix B, image 6). At this point we were able to see a full listing of the files where this webpage can be found (See appendix B, image 7).

Step 3: Locate target information and extract

We found a directory named confidential where in there was a file called bankInfo.htm. Unfortunately for the owner of the file we were able to see the confidential contents of it through the means of our script-attack (See appendix B, image 8). In addition to this private bank information we were able to view a complete listing of details for the system (See appendix B, image 9)

 

Countermeasures

The Open Web Application Security Project (OWASP) is an online source that presents eight rules to follow when trying to avoid XSS and server side scripting attacks. These eight rules are the necessary countermeasures against XSS and server side scripting attacks (OWASP, 2015).

•   Rule 0 – Never Insert Untrusted Data Except in Allowed Locations

o   The first rule on this list is to simply deny all and do not put any untrusted data into any of your HTML code. Unless it is pertaining to one of the other rules.

•   Rule 1 – HTML Escape Before Inserting Untrusted Data into HTML Element Content o   This rule is put to use when you insert trusted data into common HTML tags such as

<body><</body> or <div></div>. As a web developer, you want to be able to escape certain characters with HTML coding in order to prevent a switch to an execution context, such as a script or style. This keeps your program running the way it was intended and having a backup plan when untrusted data is inserted.

•   Rule 2 – Attribute Escape Before Inserting Untrusted Data into HTML Common Attribute o   This rule applies when inserting untrusted data into common attribute values such as

name, height, and width. See Figure 10 in Appendix B.

(9)

o   This rule strictly applies to the use of JavaScript code. According to OWASP, the only safe place to put untrusted data into JavaScript is inside a quoted data value. Putting untrusted data in other context can lead to unwanted execution context.

•   Rule 4 – CSS Escape and Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values

o   Rule 4 is for when a web developer needs to put untrusted data into a stylesheet or style tag. Only use insert untrusted data inside a property value. Do not put the data anywhere else in the styling. See Figure 11 in Appendix B.

•   Rule 5 – URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values o   This rule is for when a web developer wants to put a set of untrusted data into an HTTP

GET parameter value. o   For example:

•   <a href="http://www.somesite.com?test=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >

•   Rule 6 – Sanitize HTML Markup with a Library Designed for the Job

o   Validating and sanitizing HTML markup is a very important and essential step in

preventing XSS and server side scripting attacks. You will need a library that can validate and lean HTML text. OWASP provides that are very easy to use:

•   https://github.com/mganss/HtmlSanitizer •   Rule 7 – Prevent DOM-based XSS

o   DOM-based XSS is another form of XSS that needs to be prevented in order to keep a program completely clear of XSS and server side scripting attacks. OWASP provides an entire list just for preventing DOM-based XSS attacks. (OWASP, 2015)

•   HTML escape then JavaScript escape before inserting untrusted data into HTML sub context within the execution context

•   JavaScript escape before inserting untrusted data into html attribute sub context within the execution context.

•   Be careful when inserting untrusted data into the event handler and JavaScript code sub contexts with an execution context.

•   JavaScript escape before inserting untrusted data into the CSS attribute sub context within the execution context

•   URL escape then JavaScript escape before inserting untrusted data into URL attribute sub context within the execution context

•  

Populate the DOM using safe JavaScript functions or properties (OWASP, 2015)

 

Conclusion

This paper was a comprehensive overview of the potential vulnerabilities that our website contained and gave some insight as to how to fortify the site against a number of different attacks. It doesn’t take much for an experienced hacker to threaten one of the three tenants of computer security. Knowing how to diagnose and fix most all of the possible types of attacks is a necessity as a security professional.    

Over the course of this paper some of the issues discussed dealt with coding as it pertained to the application coding such as the PHP vulnerabilities, while others dealt with problems regarding the sites configurations to the network such as the possible DDOS vulnerabilities.  

 

Understanding the ever-changing nature of computer security while sticking to a methodical auditing method are keys to keeping your site safe from any attacker looking to find loop holes. At the same time, having the security of the site set up for success from the onset of its use can help prevent a lot of common problems that hackers may find and help to keep sensitive information in the hands of those who need it most.

(10)

 

Appendix (OWASP, 2010)

 

 

 

 

 

 

 

 

 

 

 

 

Figure 1. Microsoft Threat Model Process

Figure 2. Modified Risk Evaluation Process

(11)

 

 

 

 

Figure 3. Process.php

Figure 4. RIPS opening in \\localhost\rips\\

(12)

Figure 6. DDoSPING v2.0 Scan complete with no detected Zombies

(13)

Figure 8. Nikto Vulnerabilities

(14)

APPENDIX  B  

Figure 1. Set Cookie page

(15)

 

Figure 3. Malicious Links

 

(16)

 

Figure 5. Log file output showing stolen cookie

(17)

 

Figure 6. Web Page with PHP script showing vulnerabilities

 

Figure 7. Output of test.php script

 

 

 

Figure 8. Contents of Confidential file bankinfo.htm

 

 

 

Figure 9. System Details Output as a result of poor scripting

 

 

 

(18)

Figure 11. CSS Escape and Strictly Validate before inserting untrusted data

 

(19)

/XSS Files

Description

Log.txt   Logs  the  result  of   stealcookie.php.  Stolen  cookies  

are  found  in  here   malURL.htm   Provides  two  malURL’s  that  use  

redirectpage.htm  and   stealcookie.php   Process.php   Used  by  setgetcookie.htm  to  

display  the  users  cookie.   Redirectpage.htm   Use  by  malURL  to  redirect  the  

user  and  steal  their  cookies   Setgetcookie.htm   This  page  allows  the  user  to  set  a  

browser  cookie  that  will  later  be   stolen  

Stealcookie.php   Steals  the  users  browser  cookies  

Table 1. XSS Files

/script-­‐‑attacks  Files  

Description  

/confidential   A  sub  directory  of  script-­‐‑attacks   that  contains  bankInfo.htm   /confidential/bankInfo.htm   Hidden  from  direct  view  but  can  

be  accessed  through  exploiting   the  website.  Contains  

confidential  bank  information   Lilies.htm   Contains  information  about  lilies   Lotus.htm   Contains  information  about  lotus   Roses.htm   Contains  information  about  roses   Sample.htm   This  is  the  page  where  users  can  

find  the  input  field  that  can  be   manipulated  to  access  the  server   Test.php   Processes  and  displays  the  

results  of  the  user  input  field   Tmp.txt   A  blank  webpage  with  a  header  

saying  “A  page  about  lilies  –Ssh  .  .   .  .  you  are  not  supposed  to  read   this  file!”  

 

(20)

References

 

Bouwers, E. (2006, December 29). Sensitive Sink. Retrieved November 9, 2015, from http://www.program-transformation.org/PHP/SensitiveSink

 

Carroll, T. (2012, December 6). It.ucsf.edu. Retrieved November 23, 2015, from

https://it.ucsf.edu/services/application-and-website-security/types-attacks-web-applications

Dahse, J. (2011). RIPS - free PHP security scanner using static code analysis. Retrieved from SourceForge:

http://rips-scanner.sourceforge.net/

 

Denial-of-service attack. (2015, November 6). In Wikipedia, The Free Encyclopedia. Retrieved November 6, 2015, from https://en.wikipedia.org/wiki/Denial-of-service_attack

Drinkwater, D. (2015, March 27). New hacking group DDoS attacks Amazons Twitch, US state websites. Retrieved October 21, 2015, from http://www.scmagazineuk.com/new-hacking-group-ddos-attacks-amazons-twitch-us-state-websites/article/405796/

 

Leiner, B., Cerf, V., Clark, D., Kahn, R., Kleinrock, L., Lynch, D., Postel, J., Roberts, L., Wolff, S. (2015,

June 1). Brief History of the Internet. Retrieved October 21, 2015.

 

 

Microsoft FrontPage. (2015, September 6). In Wikipedia, The Free Encyclopedia. Retrieved 13:31, October 21, 2015, from https://en.wikipedia.org/w/index.php?title=Microsoft_FrontPage&oldid=679763549  

 

Meier, J., Mackman, A., & Dunner, M. (2003, June 1). Improving Web Application Security: Threats and Countermeasures. Retrieved October 20, 2015, from

https://msdn.microsoft.com/en-us/library/ff649432.aspx

 

 

National Institute of Standards and Technology. (n.d.). Retrieved October 20, 2015, from http://www.nist.gov/  

 

OWASP. (2010, September 29). Threat Risk Modeling - OWASP. Retrieved from The Open Web Application Security Project: https://www.owasp.org/index.php/Threat_Risk_Modeling  

 

OWASP. (2015, July 27). DOM based XSS Prevention Cheat Sheet- OWASP. Retrieved from The Open Web Application Security Project:

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

 

OWASP. (2015, September 23). XSS (Cross Site Scripting) Prevention Cheat Sheet- OWASP. Retrieved from The Open Web Application Security Project:

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

 

SANS. (n.d.). Securing Web Application Technologies [SWAT] Checklist. Retrieved from SANS Securing the Human: http://www.securingthehuman.org/developer/swat

 

Sensitive Sink. (n.d.). Retrieved November 9, 2015, from http://www.program-transformation.org/PHP/SensitiveSink

VmWare. (2015). What is virtualization? Virtualization 101 Retrieved from https:www.vmware.com/virtualization/how-it-works.  

(21)

 

Website Security: How Do Websites Get Hacked? - Sucuri Blog. (2015, May 18). Retrieved October 21, 2015.

What is Cross-site Scripting and How Can You Fix it? (2015, March 2). Retrieved November 23, 2015, from https://www.acunetix.com/websitesecurity/cross-site-scripting/

References

Related documents

How to Insert Google Forms Chart into a Google Slides Open a spreadsheet in Google Sheets Select the cells with data you want to include in.. Spreadsheets and drawings to

Execution monitors are enforcement mechanisms that work by monitoring the computational steps of untrusted programs and intervening whenever execution is about to violate the

In order to deliver rigorous evaluations under PERFORM, the Analyze, Collaborate, Evaluate (“PERFORMANCE”) Indefinite Delivery, Indefinite Quantity (IDIQ) contract will engage a

Since it is well known that EBU (as any other model of that kind) degrades its global accuracy as the number of species increases, we decided to restrict our calculations, used in

Together with the marginal probabilities, MMAP predictor and reference profile, 5,000 realizations from the correct posterior model are given in Fig. The marginal

In the transition from pregnancy to lactation, dairy cows exhibit a period of decreasing insulin sensitivity in the peripheral tissues to support the partitioning

The highest chlorophyll mutation frequency was obtained with 0.3% EMS &amp; chlorophyll mutation spectrum with MMS in kasuri methi, but the mutation spectrum was broader in desi

The results show that the Si-PV modules manufactured in China consume 28–48% more primary energy resources than their coun- terparts made in Europe, which indicates that the