Chapter 13: Hacking Web Servers and Web Apps

The purpose of hacking web servers and web apps is to search for and discover potential vulnerabilities. It helps us identify important upgrades that are needed for software, thus improving security and helping us recognize and respond to any malicious activity. Additionally, with so much being transacted online including shopping, banking, and communications, web apps give us an additional resource to gain access to a person's login credentials, private messages, and financial information.

In this chapter, we will cover the following topics:

• Why web servers create security issues
• Types of architectures
• Threats to both servers and applications
• The vulnerabilities of web APIs, web shells, and webhooks
• Detecting web server hacking attempts

Let's begin by discussing why web servers create security issues for us.

Why web servers create security issues

It's important to understand that web applications and servers are not inherently secure. The fact is that they were never designed to be secure – they were designed for functionality and to provide a service. The responsibility for making them safe rests with us, as system administrators, coders, and security professionals.

This is why attackers turn their attention to web servers and web application-level attacks – because a web server that hosts web applications is accessible from anywhere over the internet. This makes web servers an attractive target. Poorly configured web servers can create vulnerabilities in even the most carefully designed firewall systems. Attackers can exploit poorly configured web servers with known vulnerabilities to compromise the security of web applications. Furthermore, web servers with known vulnerabilities can harm the security of an organization, even if the web applications they host are secure.

Every open port on a web server is an entry point for a possible attack, especially if it hosts applications that use protocols such as HTTP and FTP. The operating system must protect the application from Denial-of-Service (DOS) attacks by ensuring that processes have sufficient resources to function properly. The real problem with these operating system security features is that they can be used against the application. Adding add-ons, plugins, and their configurations on top of the OS and its applications creates a perfect storm for attackers.

Before you start trying to hack a web server, it's important to understand how they work.

There are three main components to a web server:

• The web server software, which is what we want to attack.
• The website content/files, which need to be in a certain format for the web server to access and read them.
• The operating system itself.

Every web server essentially works the same way; it receives a request from a user and then tries to find the file they want. Then, it reads the file and sends it to the user so that they can see it.

Every web server has a piece of software behind it called an HTTP daemon/service/server. The name varies, depending on the server. Apache/httpd is a popular HTTP daemon for Linux-based servers, while Internet Information Server (IIS) is a popular one for Windows servers.

HTTP daemons essentially run in the background and receive requests from users on port 80 by default. So, every time you type facebook.com into your browser, your computer is sending a request to the Facebook web server to find out the files it needs to display for you to see the page.

The process of finding these files is called mapping URLs/domains to certain directories on the server, indexing, and so on. Then, when a user tries to access a file, it maps the filename onto the corresponding path that has been mapped to that URL.

These web servers also contain security features, such as limiting the amount of physical memory it can access for each process, preventing unauthorized code execution, and ensuring certain file types are not allowed to be executed.

Now, let's discuss the components of a web server.

Components of a web server

First, we have the document root. This directory is where all the web content/files are stored. For example, if you have an images directory inside your document root, all the images can be accessed from http://wayne-technologies.net/images/.

When a user requests a page using a URL, such as wayne-technologies.net/, it maps that URL onto the document root and then searches the folder for a file that matches that URL. This is called mapping URLs to files and folders. If it finds a match, it sends the contents of this file back to the user so that they can see it.

If no matching file is found, an index document such as the default page, or index.php, will be searched for and sent back if found.

If no index document is present, the server will typically return a 404 error to the user, saying that it can't find what they're looking for. A redirect may also be returned, telling them to look somewhere else for this file/content.

Second, we have the server root. This is the directory tree's top-level root directory, including the server's configuration and error, executable, and log files. It consists of the server's implementation code. Typically, the server root consists of four files. One file is dedicated to the server's implementation code, while the remaining three are subdirectories – that is, conf, -logs, and -cgi-bin – that contain configuration data, logs, and executables, respectively.

Third, there's the virtual document tree. In addition to the physical directory tree that stores content, a virtual document tree is maintained by HTTP daemon software. The purpose of the virtual tree is to map URLs onto files stored in the server's filesystem; for example, it may associate the http://wayne-technologies.net/images URL with an actual directory named /var/www/images on the server's filesystem.

Fourth, we have virtual hosting. This is where you may host multiple domains/websites on one web server. For example, you could have your main domain, www.wayne-technologies.net, and then to add another site, you would have to create a subdomain such as blog.wayne-technologies.net that points to the same document root directory to keep everything separate under one roof. Using this method, you could also host an unlimited number of sites on one web server. However, keep in mind that each subdomain will need unique passwords/credentials to prevent unauthorized access.

Fifth, we have the web proxy. A web proxy is a domain that acts as an intermediary between your computer and the website you are trying to access. When you type in an address, it goes through the proxy DNS server, which then forwards the request to your requested website's IP address. The response is sent back through the proxy server so that it cannot be traced back to you. Web proxies are used to help mask/hide your IP address, and anyone attempting to trace the request back to you will come up with a different IP.

Next, we will talk about the different types of architecture you may experience.

Types of architecture

Web server architecture is the overall layout of a web server. It gives an attacker an idea of how they can prepare for and deploy an attack. Let's discuss the most common web server architectures you may encounter.

IIS web server architecture

Let's take a look at the typical architecture of a web server and its applications, as shown in the following diagram. This is based on an open source architecture. As you can see, a lot of moving parts and components are involved in supporting an application. A web server is designed to host multiple sites on one system, which adds to the complexity. Did your hacker red flag just go up? It should have. Anytime we talk about complexity, it means more areas to make mistakes, overlook settings, or miss an attack vector:

Figure 13.1 – A typical open source architecture for a web server and its applications

Open source web server architecture

The three most popular open source web servers are Apache httpd, Nginx, and lighttpd. Their principal components are as follows:

• Apache, which is designed to be a secure, efficient, and extensible server
• MySQL, which is ideal for storing data
• PHP, which is a widely used, general-purpose scripting language that is especially suited for web development and can interact with MySQL to retrieve and store data

Let's look into some of the challenges the Microsoft world gives us next.

Microsoft

Microsoft's Internet Information System (IIS) is the most widely used web server software in the world, boasting over 800 million downloads. IIS is flexible, secure, and easy to host using HTTP/HTTPS, FTP, RTSP, SMTP, and much more. Microsoft uses application pools, which are an extremely useful part of IIS. They allow the administrator to set different resource limits for applications running on port 80, or any other port you wish.

But why should you care about setting up user accounts and application pools? There are many reasons why an administrator may want to establish individual identities or set up application pools to run independent versions of the same website.

For instance, imagine that you run a very busy web server with two separate websites on it – one dedicated to your business and another that's a marketing site for a client's new product release. It would be ideal if each site ran under its credentials and had an application pool. The business website would require more processes, while the marketing site may need additional memory and processor speeds to handle large quantities of traffic. On a traditional server, these requirements would conflict and cause problems. With IIS and application pools, you can easily configure user accounts and resource allocations for each site with specifications without them affecting each other.

What about security?

Listen, I'm not trying to tell you that Microsoft's IIS is unhackable – far from it. Its history is quite sorted when it comes to being hacked, but it's come a long way.

Application pools for running websites have default settings that mimic the original Windows Server 2003 version of IIS. Unless the administrator changes it, there are no anonymous users (which is what hackers want), and no direct access to the webroot (we'll talk about this in a second). With application pools, you can set up an anonymous user with limited rights, or create another restricted account, as we mentioned previously for your marketing site. This way, if one website is breached, there's no chance that a hacker could get into the other one because they're running under completely different security settings… in theory. Again, there are a plethora of attack vectors out there that have Microsoft pretty busy patching IIS, but the same can be said about Linux and Apache.

Let's learn more about why web servers are compromised.

Why are web servers compromised?

The most common reasons for attackers to compromise a web server are as follows:

• Web servers are often used as attack launch points for attacking other applications.
• When an attacker compromises one system on the network, they can often use that system's access privileges to move around freely and gain access to additional systems that may host sensitive data. This is known as privilege escalation.
• Attackers are often able to use vulnerabilities in the web server's software to compromise the system because it's easy for developers to make mistakes when writing code, or they may leave backdoors and debug options open. Attackers can use these vulnerabilities and configuration errors to take control of a system.

Now, let's talk about adding web apps and how to do so more securely.

Adding web apps

Web applications are becoming more and more vulnerable to more sophisticated threats and attack vectors, which makes them less safe. In this section, we will teach you about web applications and attack vectors, and how to protect an organization's information from them. Web application hacking is a common method most attackers use to get into a system.

The best protection against web application hacking is to not have a vulnerable or insecure website. You can do this by evaluating the code and design practices before deploying your site.

A great example of why you need to secure code before deploying is what happened with Yahoo! Voices. The developers did not escape the input before inserting it into the database. As a result, a hacker was able to gain access to more than 450,000 unpublished articles on the website.

Now, let's look at some of the threats to web servers and applications.

Threats to both servers and applications

What types of attacks can be launched at these technologies? Well, first, let's start with web servers.

Note

You'll see some similarities in the attacks that are used to target both web servers and web applications as one can create a vector for the other.

Web server attacks

When it comes to the servers themselves, attackers can launch attacks against web servers using any of the following methods:

• Denial of Service (DoS): By launching a DoS/DDoS assault on a web server, an attacker attempts to bring the service down or make it inaccessible to legitimate users. A DoS/DDoS assault on a web server is frequently directed at high-profile web servers, including bank servers, credit card payment gateways, and even root name servers.
• Brute-force attacks: Here, an attacker attempts to use combinations of usernames and passwords until one of them is found to be valid; these often result in a dictionary attack.
• DNS server hijacking: This occurs when an attacker hacks a DNS server and modifies its mapping settings to redirect users' requests to the attacker's rogue server. As a result, when a user enters a genuine URL into a browser, the settings redirect the user to the attacker's bogus site.
• DNS amplification attacks: For this attack, the attacker spoofs a DNS request from a target and sends it to another open DNS resolver. The targeted DNS server will now send a large DNS response to the forged IP address of the victim. This can result in a large number of data packets being sent to the victim's system and can overload and shut down the system.
• Directory traversal: This attack consists of an attacker obtaining access to a hidden directory on a web server, bypassing normal access restrictions, and exposing data that shouldn't be allowed to be accessed.
• Man-in-the-middle: This method is where an attacker intercepts communications between two systems without either of them knowing. The attacker intercepts the communication and can view or edit it before passing it back to the systems.
• Phishing attacks: This is an attack in which the attacker sets up a fake website to trick users into entering sensitive data, such as passwords and credit card information.
• SQL injection: This is a type of attack where an attacker attempts to access information from a database on a web server, which would normally be disallowed. However, if the web developer did not use parameterized queries when communicating with the database, it leaves the system vulnerable.

Session initiation protocol (SIP) and real-time protocol (RTP) are used for communication by Voice over Internet Protocol (VoIP) systems and are also vulnerable to this attack.

• HTTP response-splitting attack: This is a web-based attack in which the attacker deceives the server by injecting new lines and arbitrary code into response headers. The attacker manipulates the input parameter and cleverly builds a request header that prompts the server to return two answers. By inserting header response data into the input field, the attacker makes a single request appear as two requests. Each request is then responded to by the web server. The attacker can provide malicious data to a vulnerable application, which then stores it in an HTTP response header.
• Web cache poisoning attack: This makes the intermediate web cache source less reliable because of web cache poisoning. In this attack, an attacker changes the cached content for a random URL that has malware on it. When requesting the required URL through the web cache, unaware users may mistakenly utilize the misidentified content rather than the genuine and secure material. The attacker causes the web server's cache to be purged of actual cache content and asks it to store a specially crafted request. As a result, all the users on the web server's cache will receive harmful content until the servers purge the web cache. Web cache poisoning attacks are possible if the web server and application have HTTP response-splitting flaws.
• Secure shell (SSH) brute-force attack: Attackers use the SSH protocol to make an encrypted SSH tunnel between two hosts so that they can send unencrypted data over an unprotected network. Most of the time, SSH runs on TCP port 22. Attackers will scan SSH servers using bots. Once the credentials have been discovered, attackers will use this powerful new host as a base station to target internal systems and/or scan for vulnerabilities on auxiliary servers.
• Server-side request forgery (SSRF) attacks: Attackers use SSRF flaws to send crafted requests to internal or backend servers through public web servers. These flaws come from the functions in an application being misused on public web servers. Internal servers are usually put in place by firewalls to keep unwanted traffic from getting into the network. SSRF flaws can allow attackers to send crafted requests from public web servers and connect to internal or backend servers directly.

Now, let's look at some common web server vulnerabilities.

Common web server vulnerabilities

Web servers may be configured with unnecessary features and services that create potential security holes. This could include files containing sensitive information, such as configuration files and scripts containing database names, user IDs, and passwords.

Some of the most common misconfigurations include the following:

• File and directory permissions that have been set up incorrectly or that allow unauthorized access to sensitive data
• Default usernames and passwords that haven't been updated from their default settings, allowing anyone who knows it to access the system without a password
• Unused services or accounts being enabled, which may have been left by mistake or by previous attackers
• Unnecessary features being enabled, which may have been installed for testing or development purposes and never removed after the site was put into production
• Poorly chosen passwords by administrators, allowing potential attackers to successfully guess administrative credentials, giving them unrestricted access to the web server itself

Authorization attacks

Here, the attacker finds a legitimate account with limited privileges, then logs in as that user, and gradually escalates privileges to access protected resources. Attackers then manipulate the HTTP requests to subvert the application authorization schemes by modifying input fields related to the user ID, username, access group, cost, filenames, file identifiers, and more.

HTTP request tampering

HTTP request tampering is when someone tampers with the information in a client request by changing the values within the URL to falsify data or steal user information. This can be used to fool users into providing sensitive information or to spoof entire pages, giving an attacker access to privileges that they would not normally have.

Most of the time, HTTP request tampering is used to change hidden values in a URL, such as HTTP_AUTHORIZATION, or cookies that have been sent to the server with the request. The most common types of attacks that are dealt with include cross-site scripting (XSS) or man-in-the-middle (MITM) attacks, in which the attacker is intercepting requests and sending different values in each request. When these are done correctly, the server will assume that the attacker has access to these values (to make things easier for users), when it's just the attacker talking.

Authorization attacks are very easy to prevent by using HTTPS and other security measures. HTTPS encrypts the data being transferred, which prevents MITM attacks from intercepting requests to change information. Authentication will always be present when you're using HTTPS, so XSS or cookie injection is nearly impossible with encryption. Authentication can also be used to prevent invalid token manipulation, as tokens are usually encrypted before being sent to the server.

The most important step to take is verifying the authenticity of all the requests that are sent from a user, which can be achieved by requiring authentication for sensitive pages and checking that all the other requests have valid tokens attached. This will stop any type of HTTP request tampering attacks before they begin.

Cookie parameter tampering

Cookie parameter tampering is when someone tampers with the information that's sent in a cookie from the client to the server by changing the values within a single cookie or multiple cookies. This can be used to fool users into providing sensitive data or to steal user information. Most of the time, this attack deals with manipulating session cookies, which are usually encrypted and unique for each user session. In most cases, the attacker is intercepting requests and sending different values in each request, specifically targeting the cookie that was used to access a protected service.

Burp Suite (https://portswigger.net) is a great tool to use to test your servers and apps for these types of attacks.

Next, let's look at the potential threats to web applications.

Web application attacks

Even if a web server has been set up securely or is protected by network security measures such as firewalls, a poorly written web application or the web server itself could give an attacker a way into the web server's security. An attacker can use many different types of attacks on web applications that aren't secure to get into the web server's security.

SQL injection attacks

SQL injection attacks occur when a developer does not properly validate their user input before passing it into a database. An attacker can inject SQL commands into the input and gain access to sensitive information on the server, such as usernames and passwords.

To avoid this flaw, developers should always escape their user input with special escaping methods so that the input cannot affect the query:

SELECT * FROM users WHERE UserID=2302 or 1=1

The or 1=1 expression returns a value of TRUE, which can be used to get all the user IDs from the database. An attacker finds a flaw in a web application and uses it to get around normal security measures and get direct access to valuable data. When hackers try to do SQL injection attacks from things such as the web browser's address bar or form fields, queries, or searches, the hacker can get information that's not meant for them. Various commands can be used to modify data, delete massive amounts of data, or even create accounts within a web application.

To avoid SQL injection attacks, it is necessary to securely store web application data. The web application data should have correct character types to avoid SQL injection attacks. Also, SQL injection attacks can be prevented by using one of the most basic secure programming techniques – parameterized queries. However, they are still vulnerable to SQL injection attacks because folks don't use prepared statements. Prepared statements are the most secure way to prevent SQL injection attacks.

A prepared statement is an approach that helps prevent SQL injection attacks because it makes the web application explicitly indicate where user input goes in the statement. Many frameworks have adopted this method of preventing SQL injections, so developers don't have to worry about it.

However, there are still some web applications and developers that don't use prepared statements and can be vulnerable to SQL injection attacks, so be aware.

Other web application attacks

Let's look at some other types of web application attacks you can use:

• DNS rebinding attacks: This is when the hacker tries to fool the web browser's DNS system into looking up an IP address that is not correct. This forces your browser to bypass the firewall and gives the hacker access.
• Cookie snooping: These attacks occur when the hacker steals your authentication to a website by sniffing cookies. Cookies are often sent back and forth during HTTP requests, so they contain lots of important information about what someone has done on a website. If any of that information is sensitive (such as the session ID or user identification), then it can be used to log in to that website remotely.
• Cookie tampering: In this attack, the attacker manipulates cookies as they travel to a browser from a web server. In other words, an attacker can change the cookie's values before it reaches the user's browser. If the altered cookie has any unauthorized privileges associated with it, then the attacker gains those privileges when performing malicious tasks.
• Obfuscation application: Attackers are usually very careful and ensure they hide their attacks and stay out of the way. Intrusion detection systems (IDSs) keep an eye out for signs of well-known attacks, which forces attackers to come up with new ways to stay unnoticed. This type of attack involves the attacker encrypting the attack to look like something else.
• Parameter/form tampering: This is a type of malicious intrusion in which an attacker exploits web applications that include parameters to authenticate users. This includes form fields for user login names and passwords.
• Cross-site scripting (XSS): This is a security flaw that's present in some web applications that allows attackers to gain unauthorized access to the victim's system. Attackers can exploit this vulnerability by injecting malicious scripts into HTML forms or by enticing the vulnerable site's visitors to click on an attacker-supplied link.
• Session hijacking: This is a type of attack in which an attacker steals another user's session ID and takes over their authenticated session. By taking control of the victim's browsing session, the attackers can gain access to the victim's account information without knowing their login credentials.
• Unvalidated input attacks: These are created so that an attacker can submit data to the frontend of a web application. The backend database can't handle this information, leading to unintended behavior within the application.
• Directory traversal/command execution: This is another web server attack where attackers exploit web servers that can't properly sanitize input. If the attack is successful, it allows attackers to read sensitive files, list directory contents, write files, and run arbitrary commands on the underlying system.
• Denial of service attacks: This is an attack in which a malicious party tries to make a machine or network resource unavailable for users. For example, they could try to send too many requests to a service, such as a web server. Attackers could also try to send malicious packets that will tie up resources or cause the system or application to fail.
• SQL injection: This is just like what we saw for web server attacks.
• XSS attacks: Here, the attacker tricks someone into viewing a page containing a malicious script. When the user accesses this URL, the browser renders the page containing the malicious scripts, which could send requests to other applications or embed malicious code in pages.
• Buffer overflow attacks: This attack occurs when an application tries to put more data into a buffer than it can hold. This causes the excess data to spill out, corrupting other data in the process. Buffer overflows are frequently exploited by attackers.
• Source code disclosure: This attack occurs when an attacker gains access to the source code or other information that could help them exploit vulnerabilities in the system. This threat occurs during product development, maintenance, and testing.
• Cross-site request forgery attacks: This attack forces an end user to execute unwanted actions on a web application that they're currently authenticated in. The most common example of this is forcing users to make purchases or transfer funds.
• Command injection attacks: This is an attack in which an attacker injects unauthorized commands into a command line that will run under the privileges of the user running them. If successful, attackers could gain access to operating system functions or download sensitive information.
• Credential stuffing attacks: Credential stuffing is the process of trying stolen credentials (usernames/passwords) on multiple websites. Most credential stuffing attacks are unsuccessful, but it can be worthwhile to monitor for this type of activity as users often use the same password on different sites. This could allow an attacker to gain access to other systems that were not part of the original attack.

Now, let's learn more about the vulnerabilities of web APIs, web shells, and webhooks.

The vulnerabilities of web APIs, web shells, and webhooks

It is important to understand and be familiar with the vulnerabilities of web APIs, web shells, and webhooks. Recognizing best practices will help you provide greater security.

Web APIs

One of the most important parts of a website is its web application programming interface (API). The API takes data from a server and makes it compatible with another server. This way, other programs can read the information that would otherwise be difficult to access. With the help of an API, computer applications can perform actions on websites, such as posting comments. However, the API must be secure and not vulnerable to security concerns such as XSS.

Some of the most popular APIs are as follows:

• SOAP API: This is a standard that's used by Microsoft and uses the Web Services Description Language (WSDL). WSDL is an XML language that contains information about how to communicate with a web server.
• REST API: REST stands for Representational State Transfer. This type of API is more of a software architectural style rather than an actual standard. It doesn't include WSDL but does use HTTP methods (GET, POST, and so on) to communicate with web servers.
• XML-RPC: This is like the SOAP API in that XML-RPC is an interface rather than a specification. It is created using HTTP requests with XML supplied as the data format.
• JSON-PRC: This is a modern web API standard that uses JavaScript Object Notation (JSON) for its data format and HTTP requests for communication.

Recent years have seen a huge rise in the use of web-based APIs to support different types of devices, such as mobile devices and loT devices. APIs are often used by these devices to communicate with backend web servers. To make these web-based APIs easier for people to use, developers often cut corners on security. This makes online web services more vulnerable to attacks. Attackers use a variety of methods to find and exploit flaws in these APIs. The attackers who want to get into an API have to figure out what API technologies are used, what security standards are used, and where they can attack.

Now, let's discuss some API security best practices.

Best practices for API security

You should utilize the same strategies that work for web applications. In addition, you should set up a rate-limiting system to ensure an attacker can't make requests more frequently than legitimate users. You may also want to monitor your logs for requests from bots and scrapers as this could indicate attempts at gathering additional information on your application or website.

Here are some key points to help you out:

• Use HTTPS for encryption.
• Use IP-based whitelists to gain access to APIs.
• Monitor and review logs.
• Parameterize statements in SQL queries.
• Use quotas and throttling against your API.
• Limit the request body and length of your API.

It's also important to understand security standards. Let's discuss some of these standards next.

Web API security standards

APIs, like any other software, have security flaws. They adhere to standards such as OAuth and SSL but include numerous vulnerabilities that attackers can use. If any of these standards are configured incorrectly, hackers can exploit them. Often, the developers of web applications don't think about the consequences of using security flaws in their API. For example, they'll use session IDs to identify users and allow access to information on their website or server without realizing how easy it is for hackers to reroute fraudulent traffic through an authorized user's connection. Administrators must check for security standards such as SSL when they're testing their web applications for vulnerabilities. They should also review XSS and SQL injection attacks to prevent future attacks on that API.

Now, let's talk more about web shells and webhooks.

Web shells

A web shell is a backdoor on a website or server that allows attackers access via HTTP/HTTPS. It can allow an attacker to upload and download files, execute system commands, modify server settings, view source code, and do other things. It's typically used to make the website or server more secure or easier to use by the administrators of that website or server. These types of shells are usually uploaded through vulnerabilities in the web application.

Preventing the installation of a web shell

An attacker can send a series of requests to install a web shell on the server. The payload for this attack would look something like http://kali:1337/index.php?install_shell=1&language=../../../../../etc/passwd%00.

To prevent this, make sure that the application has a strong input validation layer that is aware of the different types of above-the-fold input payloads. Note that this only prevents the installation of a web shell – it does not prevent an attacker from viewing any file on the system if they have been granted access to do so by another vulnerability.

The following is an example of preventing the installation of a web shell:

if (preg_match('/../../../../etc/passwd/', $_GET['install_shell']) ) {

    // don't allow shell to be installed for this user }.

Webhooks

Webhooks provide a communication channel between two web APIs. This allows one API to receive notifications from another, so information can be exchanged without a direct connection. Webhooks are a little harder to detect because the source of the data isn't always clear unless it's a POST request or uses a similar type of identifier. These types of requests may bring attention to your web application if you're not expecting them or if you don't know what to do with them.

Many developers do not understand that webhooks require security, just like any other API endpoint: it is easy to make mistakes by doing what appears to be the right thing for a specific case, which can leave systems exposed to various attacks. These include MITM, replay, and arbitrary code execution attacks. The risk of attacks is higher when the webhooks are exposed to third parties, such as mobile applications or other outside services. It may be possible to blacklist certain IP addresses that appear to be performing these types of attacks, and implementing CAPTCHAs on your login pages will also help.

Detecting web server hacking attempts

There are several ways you can find out if your web server has been compromised.

The first way is to monitor the logs from the web server. A good practice is to have more than one log file, but it's even better if they're monitored and sent to a separate system so that if something happens on the current web server, the logs will still be available.

Another way to do this is to audit ports on the web server. Make sure that all the open ports are accounted for and do not return any strange responses.

You should also look at traffic between the web server and users. If you see abnormally large requests or file downloads, this could be an indication of hacking attempts.

Some other ways to protect your web servers/apps

The machine.config file specifies the resources that are available on the web server, including access to files, directories, and registry keys. Restrict access to these resources to prevent any kind of false file uploads and other dangerous requests.

You should also make sure all your other applications are up to date to ensure they're patched against any vulnerabilities that may have been found in them.

Next, secure any certificates that are used for your keys. This is the easiest way to protect your keys. If you don't need them, remove them. If possible, restrict the permission of user accounts on the server. This will keep an attacker from gaining local administrator access.

Also, look into implementing secure coding practices. If your web pages aren't built securely, then hackers will be able to exploit that weakness and gain access to the system.

Finally, install security patches for your operating system and other applications as soon as they become available. The longer you wait, the more opportunities your system will have to be compromised. Patch management is an important part of secure computing.

Now, let's look at web application security testing.

Web application security testing

Web application security testing is done to assess the performance and security of the apps you have in place. These types of tests should be scheduled regularly to ensure the app can handle a variety of different attacks.

Here are some tips on how to get started with your web application security testing:

• Identify what you hope to learn by conducting the tests.
• Identify which performance and security issues are the most important for your project.
• Create an attack plan before you start the testing process.
• Perform the tests you have planned out.
• Review the results of your testing and develop a plan for fixing any performance or security issues.
• Perform source code reviews.
• Evaluate the encoding schemes.

For more details on this topic, check out OWASP's Testing Guide at https://owasp.org/www-project-web-security-testing-guide.

At this point, I should mention that one of the best tools for testing the security of your web servers and their apps is Metasploit. Metasploit is an open source penetration testing software that allows users to find vulnerabilities in systems and networks and creates exploits for those vulnerabilities. This tool is a framework, which means that it is a platform that allows users to easily create custom tools and uses modules for different exploits.

Various things make Metasploit popular among the hacking community: it is free and has an immense library of user-generated scripts, modules, and modularization. You can also create modules.

Although the CEH exam doesn't cover a lot of information about the modules and plugins for Metasploit, I highly suggest that you learn about this awesome tool for your career. My recommendation would be Metasploit 5.0 for Beginners – Second Edition, from Packt Publishing (https://www.packtpub.com/product/metasploit-5-0-for-beginners-second-edition/9781838982669).

There are so many attack tricks and tips you should be aware of for the real world. A whole book could be written about web server/application hacking. However, our goal here was to cover the information you'll need to know for the exam.

Summary

In this chapter, we discussed ways you can hack web servers and web apps. This allows you to discover existing and potential vulnerabilities. Then, we discussed why web servers and web apps create security issues. We talked about some of the different types of architectures you may experience and looked at some of the threats the wireless world presents us with. After that, we covered some attacks you can use for web application attacks. We covered some of the specifics and vulnerabilities of web APIs, web shells, and webhooks. Finally, we discussed some of the ways we can detect web server hacking attempts and prevent or limit what attackers can do.

In the next chapter, we'll dive into hacking the Internet of Things (IoT) (or, as I like to say, Internet of THREATS) and Operational Technology (OT).

Questions

As we conclude, here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:

1. A web application is best described by which of the following?
   1. Code designed to be run client-side
   2. Database SQL code
   3. Web service targeting
   4. Code designed to be run server-side
2. What is used to store session information?
   1. A cookie
   2. A directory
   3. A snoop
   4. A file
3. The _________ scripting language is used on the client side.
   1. PHP
   2. JavaScript
   3. ASP.NET
   4. ASP
4. Which of the following is used to access content that is not located in a website's root directory?
   1. Directory traversal
   2. Brute force
   3. SQL injection
   4. Port scanning