Contact us:

HTTP Security Headers: X-Frame-Options

The X-Frame-Options header can be used to specify whether a web browser should be allowed to render the target page in a frame (such as a frame, iframe, embed, or an object tag). This can be used to prevent attacks such as ClickJacking.


HTTP Security Headers: Cache-Control

The Cache-Control HTTP server response header specifies whether the server response can be cached by the web browser and any interim devices such as web proxies. Generally, if the content of the page includes confidential information, then it should not be cached, as if confidential information is cached on user's device, and that device is a public device, or shared with other users then the information may be compromised by another user with access to the device.


What is Penetration Testing?

Penetration Testing, often abbreviated to PenTesting, is a method of testing the security of a system through attempting to discover and actively exploit vulnerabilities within the system. It is amongst the most effective methods of determining the actual risk posed by a system. This is due to the fact that the risk of present vulnerabilities is not estimated but they are exploited to determine how much leverage they would offer an attacker.


Same-origin Policy

Same-Origin Policy (SOP) is a critical part of the security implemented within a web browser. It’s the part of your browser’s security system that prevents malicious pages from reading confidential information from other sites. So can’t read data from because it’s blocked by SOP.

The way that it works simply, is that pages of different origins can send requests to other domains, but not process their responses. Certain items aren’t covered by SOP, such as images and scripts – this is because these are considered assets to be used within an application and not considered to affect the security of that application.


Path Traversal Cheat Sheet: Linux

Got a path/directory traversal or file disclosure vulnerability on a Linux-server and need to know some interesting files to hunt for? I’ve got you covered Know any more good files to look for? Let me know!

The list included below contains absolute file paths, remember if you have a traversal attack you can prefix these with encoding traversal strings, like these:


Path Traversal Cheat Sheet: Windows

Got a path/directory traversal or file disclosure vulnerability on a Windows-server and need to know some interesting files to hunt for? I’ve got you covered Know any more good files to look for? Let me know!

The list included below contains absolute file paths, remember if you have a traversal attack you can prefix these with encoding traversal strings, like these:


HTTP Security Headers: Strict-Transport-Security

HTTP Strict Transport Security (HSTS) enforces the use of HTTPS in the web browser, ensuring that no information is sent to the domain (and optionally subdomains too), even if the user attempts to navigate to a HTTP page. This additionally mitigates the risk of cookies without the "secure" flag set, by enforcing all traffic is HTTPS only.


CSRF: Cross-site Request Forgery

Often abbreviated to CSRF and often pronounced as “Sea-Surf” is an attack against a Web Application that abuses an application’s trust in the user. An attacker’s aim is to cause a function to execute on the application using the user’s authentication credentials simply by causing the user’s browser to request that function in the normal way, but from a malicious site.

For example, a user navigates to a malicious site and this site in turn sends a request to the vulnerable function on the vulnerable web site. This is where “Cross-site” comes from, it is a malicious site sending a request to the vulnerable site.


IDOR: Insecure Direct Object Reference

In my experience Insecure Direct Object Reference is one of the least well known vulnerabilities out there, but it’s a very simply issue to explain. It’s a vulnerability that generally leads to loss of confidential data but can result in the less of modification of data too.


Web Application Defence: Filtering User Input

Effectively filtering user input is one of the best ways to prevent an awful lot of web application vulnerabilities. There are several ways to approach this, each with their own pros and cons so I’ll run through them here an then you can think of the best way to combine them for your context. It’s important to remember though, that filters are context specific, there is not one filter that will work for a whole application and that’s what can make writing an effective filter tricky.


HTTP Header Injection

HTTP Header Injection vulnerabilities occur when user input is insecurely included within server responses headers. Specifically they are based around the idea that an attacker can cause the server to generate a response which includes carriage-return and line-feed characters (or %0D and %0A respectively in their URI encoded forms) within the server response header the attacker may be able to add crafted headers themselves. Header Injection can allow for attacks such as response splitting, session fixation, cross-site scripting, and malicious redirection.


HTML5: Cross Domain Messaging (PostMessage) Vulnerabilities

HTML5 PostMessages (also known as: Web Messaging, or Cross Domain Messaging) is a method of passing arbitrary data between domains. However if not implemented correctly it can lead to sensitive information disclosure or cross-site scripting vulnerabilities as it leaves origin validation up to the developer!


HTML5: Cross Origin Resource Sharing (CORS) Vulnerabilities

So by default SOP won’t allow bi-directional communications between two separate origins, however as applications scale up there may be a requirement to allow this kind of thing. Think of companies such as Google, who also owns YouTube – or Microsoft who also owns Outlook and Skype. They may well want inter-origin communications.


Finding Command Injection

Command Injection vulnerabilities occur where user supplied input is insecurely included within an operating system command, allowing an attacker to execute additional commands or alter the syntax of the executed command. This vulnerability typically allows for confidential data theft and may allow a threat actor to target internal network connections for further attacks.


SQL Injection: Filter Evasion with Sqlmap

We've previously written about many different techniques for Finding and Exploiting SQL Injection vulnerabilities. However, there are often restrictions and interim technologies such as Web Application Firewalls that can prevent certain payloads from being used. In some instances filters can be bypassed through common encoding mechanisms, however often these will be ineffective and other methods much be used.


Exploiting SQL Injection with Sqlmap

We've previously posted about manually finding and exploiting SQL injection vulnerabilities. However one of the reasons SQL Injection is such a high risk vulnerability overall if due to the fact that exploitation can often be entirely automated. One tool for exploiting this vulnerability is sqlmap. From the point of view of security testers, SQL Injection can be time consuming to exploit, especially with slow extraction methods such as Time-based blind. However by automating exploitation can allow security testers to demonstrate the issue risk whilst freeing up time to check other areas of the assessment scope.


Exploiting Path Traversal

Path Traversal, also known as Directory Traversal, is a vulnerability where a user can alter a path used by an application. For file retrieval functionality this can allow an attacker to access files that are not intentionally disclosed. For file upload functionality this can allow for website defacement, code execution and stored cross-site scripting attacks.


Implementing Sub-resource Integrity

Hosting web application content such as dynamic scripts and stylesheets on third parties such as Content Delivery Networks (CDNs) can allow for significant improvements to site performance and can reduce bandwidth costs. However, scripts included within a web application will execute within the user's browser with the same privileges as the currently logged in user. Therefore if a script is included from an external domain, that domain is trusted with the confidentiality and integrity of data stored within the application.


SQL Injection Exploitation: Out-of-Band

Out-of-band exploitation refers to exploits where the extracted information is received over a connection other than the one the payload was delivered over. It can be used to bypass defensive technologies as well as complicating the detection and response capability. SQL Injection can be exploited out-of-band through protocols such as DNS in order to extract database contents. This is particularly useful as an alternative to Time-based exploitation where it can allow for faster extraction. If you're new to this vulnerability, it's worth starting at SQL Injection basics first, before reading this article.

The idea behind out-of-band exploitation is fairly simple, instead of inferring content in the database through something like Boolean logic, you can request the target system transmit the information over protocols such as HTTP, SMB or DNS.


Fixing SQL Injection

SQL Injection is a vulnerability that occurs where user supplied input is insecurely concatenated into an SQL query. We showed how easy can be to detect in our Finding SQL Injection article, and we’ve run through exploitation in many posts such as our post on Exploiting Error-based SQL Injection.

However, in this post, we’re looking at fixing it. The fix is quite a simple code change. As the issue described is user input insecurely concatenated into a query, the remediation for SQL injection is fairly simple: don’t build queries through string concatenation. Instead, it’s more secure to use “Prepared Statements”, often called “Parameterized Queries”. All modern languages support this type of query either directly or through a framework; here we will supply a PHP example to show the difference.


Fixing Cross-site Scripting (XSS)

This issue comes about where user supplied input is included within server responses without filtration or encoding.

One very effective method of preventing this attack is to use an allow-list (sometimes called a whitelist) which will allow only known good content. For example, if your expected input is an integer and the user supplies anything other than an integer you can simply reject that input – and perhaps supply a message to inform the user what the issue is, without including the original payload.


Fixing DOM-Based XSS

Whilst Reflected and Stored XSS can generally be addressed through server-side user input encoding (such as through the PHP htmlentities() function) or with browser protections such as Content-Security-Policy – this is not sufficient for DOM-XSS.

Where a dangerous function is used, user input into that function should be limited through user input filtering. An allow-list approach of restricting user input to only known-good input should be used. For example, limiting input to the smallest number of characters possible (such as alphanumerics only) and checking the expected data type (such as limiting input to integers only). This is in contrast to a block-list of known-bad inputs being blocked, which is often less effective due to the large degree of flexibility that JavaScript allows. For a good example of this flexibility, consider something like JScrewIt.


HTTP Security Headers: Content-Security-Policy

Content Security Policy (CSP) allows the application to restrict the location of resources to an allow-list of preapproved locations, including where scripts can be loaded from and when the application may be framed. This can therefore mitigate reflected and stored cross-site scripting attacks as well as issues such as Clickjacking.


XXE: XML External Entity Injection

XML Entity Injection is a powerful vulnerability that can allow for confidential data theft and in rare cases command execution. It was also often overlooked for a while - but now it features in the OWASP Top 10 as A4 it's a lot more well known. The issue comes about within XML parsers where external entities are processed which can allow for URIs to be loaded.

Wait, back up. What's an entity? An easy way to think of entities is like a variable. It can hold strings, so an entity can be used in XML to hold text content - or it can be used with a URI to load remote content.


Becoming a Penetration Tester

Breaking into Penetration Testing can be a daunting career move; so in this article we talked about ways you can make your first move towards a career in this industry. To be clear, this isn't a definitive guide to the industry - it's just our opinion on what has worked for our team and what we like to look for when hiring. So, when interviewing for a position as a junior penetration tester - what makes you stand out from the crowd?

Whilst it's certainly useful to know how to use common security testing tools, it's better if you can understand what's going on under the hood. It's also just as important to know how to remediate the issues found. For example, knowing which flags to use when executing Responder is good; but it's better if you can talk about the underlying protocols such as Link Local Multicast Name Resolution and why it can lead to significant vulnerabilities.


Finding SQL Injection

SQL Injection is an old vulnerability; first published on Christmas Day 1998 in Phrack Magazine 54. The issue occurs where user supplied input is insecurely concatenated into an SQL query. It generally allows an attacker to perform any of the operations that the database user can execute – such as extracting, changing, or deleting database contents. Rarely, where the database user is highly privileged, this can allow for command execution through features such as the MSSQL xp_cmdshell system stored procedure.

Exploiting the issue manually is often trivial, but there are freely available public exploitation tools available – such as SQLmap.


SQL Injection Exploitation: Error-based

With error-based injection, data can be extracted from the database where an error message can be crafted which contains confidential data. For example:

MySQL: AND ExtractValue('',Concat('=',@@version))
MSSQL: AND 1 in (@@version)

With the MSSQL payload above the intention is to cause a string to be converted to an integer – which may throw an error where the error will contain the contents of the string. With the MySQL payload above a similar thing is attempted however this is achieved through an XPath function.


SQL Injection Exploitation: Union-Based

UNION SELECT statements can be used for retrieving the results of a second SELECT statement by appending it to the end of another query. This is useful for SQL injection as it allows you to append a query to the end of a query executed by a developer to retrieve arbitrary database contents. It’s important to note that the details of the second query must match the first, specifically they must have the same number of columns and those columns must match in type.

Therefore the first step to exploiting SQL injection through UNION injection is to determine how many columns there are in the original query. This is possible in two main ways – either by creating a select statement and increasing the column count until the query executes or alternatively using “ORDER BY” syntax and increasing the column count until an error occurs – which implies that the number which causes an error is higher than the number of columns in use.


Finding DOM-Based XSS

We’ve previously written about Reflected and Stored Cross-site Scripting, however this time we want to tackle DOM-Based Cross-site Scripting, or DOM-XSS for short. The exploitation of DOM-XSS is frequently very similar to Reflected Cross-site scripting, were the payload is stored within the URL and exploitation occurs where a user can be tricked into clicking the link, such as through a phishing email – but we’ll break it down step by step.

Cross-site Scripting vulnerabilities occur where scripts can be executed within another user’s view of a web application. It can allow for attacks such as virtual defacement of the page, the theft of confidential data, or the distribution of malicious software to users of the site.


Finding Cross-site Scripting (XSS)

Cross-site Scripting (XSS) issues occur where user supplied input is insecurely included within a server response, or insecurely processed by a client-side script. If the payload is included with the response that immediately follows the request containing the payload then this is known as Reflected XSS. It is also sometimes referred to as Non-persisted XSS. If the payload is stored by the server and returned in a later response, it is known as Stored XSS, or Persistent XSS. Where the issue is due to insecure client-side processing it is known as DOM-Based XSS. Finding and exploiting DOM-Based XSS is quite different to stored or reflected, so we’ve separated it into its own article: Finding DOM-XSS.


SQL Injection Exploitation: Time-based

In terms of crafting payloads, Time-based injection is very similar to Blind-Boolean injection. That is to say that extracting data from the database is generally done one character at a time. Time-based exploitation uses a function which causes a temporary pause in the database response; these differ depending on the database type.

This can then be used within an IF statement to execute Boolean statements against the database.


SQL Injection Exploitation: Blind-Boolean

Blind injection refers to exploit where the output of the payload is not directly displayed within application output, but the attacker is able to infer what the output was. This is possible with SQL injection and essentially involves asking the database a series of true/false (Boolean) questions to determine database content. A simple true/false can be something like:

AND 1=1
AND 1=2

If the difference between a true statement and a false statement is visible within the application response, then Boolean exploitation is possible. To enable this, Boolean statements need to be crafted which allow the attacker to infer what the database content is.